Debunking map myth #1: All coordinates are in “Latitude/Longitude”

Yesterday I published a post called Falsehoods programmers believe about maps, where I listed 18 falsehoods I believe or have seen programmers believe about maps and spatial data.

What I did not do was provide any backing for my claims that these are in fact falsehoods, and after this was pointed out in the comments I figured “here’s material for some follow-up posts”. I’m not sure I’ll go through all the falsehoods, and it might be that I have to revise some of my claims, but I’ll start with the first falsehood in this post.

So: the first falsehood is: “All coordinates are in “Latitude/Longitude””. Why isn’t it?

TLDR: look at a search for coordinate systems for Norway: “Found 247 valid records”. This is far more than 1, so case closed.

In depth: We separate between geographic coordinate systems, which is (to simplify a bit) angles of latitude and longitude on an ellipsoid that represents the earth. These coordinate systems are also known as “unprojected coordinate systems”. What makes things even more difficult is that there is several reference ellipsoid models used (specified by ellipsoid parameters a and f) and also different datums (specifies how the actual earth is aligned with the ellipsoid).

Thus: given pair of longitude/latitude coordinates, there are several options for ellipsoid and datums. True enough: when people refer to lat/lon they usually refer to the ellipsoid/datum-combination most widely used: WGS84. This is the system used by GPS, by Google Maps and in most cases where “laypeople” refer to “latlon”. Still, there are a lot of other datums (such as ED50, still used by the Norwegian petroleum industry).

In addition to the unprojected geographic coordinate systems we also have a bunch of projected coordinate systems. These usually have meters (or feet for the strange americans) as units, and one can actually use (with some minor exceptions) the Pythagorean theorem to calculate distances between coordinates. The downside with projected coordinate systems is that going from a 3- to 2D-representation _will_ introduce some errors (see Mercator). One common solution is to make a projected coordinate system valid for only “small” areas of the earth (such as “norway”). There are a lot of techniques for projecting a map, but the most commonly used is the Universal Transverse Mercator (UTM). This is not a single projection, but a series of zones.

Zones 32N, 33N and 35N covers Norway, and for web mapping purposes it’s ok to use zone 33N to cover the whole of Norway (there will be errors in the edges, but these are negligible for purposes of screen display). The UTM projection is usually used in combination with the WGS84 datum, but can also be used with other datums.

So: in conclusion: there are a lot of ways to express where on the earth you are, and when given a “latlon”-pair you cannot be sure what coordinate system it’s in (although a fair guess is WGS84)

Falsehoods programmers believe about maps

Ok, I’m probably not the first one to write a post about falsehoods programmers believe about maps, but I still remember reading “Falsehoods programmers believe about names” and “Falsehoods programmers believe about time“, and thinking “there should be a post like that about maps”. So, go ahead, read those two posts to get to know the style of a post like this and then read on here.

  1. All coordinates are in “Latitude/Longitude” (Why is this false?)
  2. If you know the “Latitude/Longitude” you can be certain of exactly where you are
  3. “Spatial is special”
  4. The earth is round (Why is this false?)
  5. The earth is ellipsoidal (Why is this false?)
  6. The GPS-satellites know where I am
  7. There is a single, right, map projection
  8. Scale numbers works on a screen (Why is this false?)
  9. There are no good alternatives to Google Maps
  10. Web Mercator works for all purposes
  11. The shortest path between two points is a straight line
  12. All programmers agree on the ordering of latitude and longitude pairs
  13. Given a paper map I can always digitize and georeference it
  14. My background map will be better if I cache it, always!
  15. GIS software is always expensive
  16. The whole world is mapped, thouroughly
  17. Looking up a street address and get it’s position is easy
  18. Offline maps is as easy as Goole Maps

That’s what I’ve come up with this far, I might fill in something here when I think about it. Comments? Additions? Any errors? Want citations? Well, the comment section is open, so go ahead!

Lightweight coordinate transformations in JavaScript

We (as in: people that work with geospatial JavaScript) have all been there: We have coordinates as “latlons” (i.e. Geographic coordinates in WGS84), but we need to transform them to some other coordinate system (as a Norwegian: replace “some other” with UTM Zone 33N). Ok, that shouldn’t be that difficult, just include proj4.js. It’s a mere 73.275 kb, and handles almost all coordinate transformations (given that you know their definitions).

But, sometime you just care about one single transformation (say: EPSG:4326 to EPSG:32633), and you are really concerned about file size (maybe you are targeting a mobile site), because size does matter and you feel that proj4.js weighs in a bit too heavy. Well, that was what Bjørn Sandvik thought yesterday:

Then I got around to thinkning: how hard can this be? After a bit of thinking I realized that, yes, this is actually rather complicated in terms of maths. But, after a bit more thinking, I remembered this project from a couple of years ago (blog post in Norwegian). Basically, my old department at NTNU had some fortran code from around 1990 written by professor Jon Holsen in Fortran.

A couple of years ago I ported that code to JavaScript (on GitHub), but did not think much more about it (although I heard reports that the department has used it some).

After looking at old notes and books on coordinate transformations it dawned on me that Holsen.js has a “bl_to_xy”-function, which transforms Geographic to planar coordinates. I then ripped out the relevant code, removed things that wasn’t needed for my simple WGS84 to UTM33 conversion, looked up the right params for UTM33N and made a gist in the middle of the night.

I did some testing against proj4js, and Bjørn did some more (reporting: “similar down to the centimetre”), and after figuring out that the original code used X for North and Y for East it seems to do the work. Result: a js file of about 100 lines, and that is rather readable lines as well. Running this code through a minifier (uglify.js) results in a 8 kb file (that is, about 10% of proj4js).

The code is tailored to transforming to one specific UTM Zone, but it should be easy to modify to work for other zones as well. Another idea is to make a similar script for transforming the other way, from UTM33 to Geographic coordinates. Holsen.js has support for this, so it shouldn’t be that difficult.

In closing: I think that small, simple scripts like this (which is small in size and does _one_ thing) is much more needed in JavaScript than in other languages. Download size matters for web apps, and the idea of one, monolithic library to solve all conceivable tasks does not work for JavaScript the way it does for Java and similar languages. Also: beeing able to provide a fellow geo-geek with working code in the course of a couple of hours is always cool! In addition: nice to see that work I did mostly for fun two years ago can be of use to someone.

Øltur til Brussel

I anledning 30-årdagen min fikk jeg en fantastisk gave fra samboer og bror: 3 dager i Brussel for å drikke øl sammen med broderen! Vi er begge relativt ølopptatte, men ingen av oss er noen særlige eksperter på belgisk øl (sånn rent bortsett fra at vi begge er glade i surøl da). Vi hadde tre fine dager i Brussel fra 1. til 4. mai og nå har jeg endelig fått somla meg til å skrive en oppsummering.

Jeg har eksperimentert litt med interaktive kart og litt sånnt, så dermed blir det ikke direkte en bloggpost, men en frittstående side. Les saken på http://code.atlefren.net/brussel/index.html. Kommentarer og sånn kan du legge igjen under her!

Og: skulle du være interessert i hvordan kartløsningen er laget: se github.