Thread: Why it's so fun to write geography software

HUH???!!!

I was taught (and HAVE taught) that map coords were given as X being horizontal and Y being vertical (through the door and then up the stairs)......maybe the military really DOES do every thing bass ackwards...does make sense that the Aussies are all upside down though

I will bow to a certified GIS person however

Originally Posted by Korash

HUH???!!!

I was taught (and HAVE taught) that map coords were given as X being horizontal and Y being vertical (through the door and then up the stairs)......maybe the military really DOES do every thing bass ackwards...does make sense that the Aussies are all upside down though

I will bow to a certified GIS person however

It's the order that's the problem. In geography they are generally called "northing" and "easting" rather than x and y. If you have two numbers, they might be northing then easting, or they might be easting then northing. Or they might be easting, then "southing" if you are dealing with computer graphics. In that last case the origin is probably moved to the opposite side of the map too. A recent bug I had to fix involved an off by one error in converting between "y" being the distance up from the bottom and the distance down from the top.

All of those coordinate systems are just a single matrix multiply apart, so it's not that big a deal in practice.

In my experience, the problems usually arise when someone doesn't label a file format and the person (or program) doing the interpreting is using a different set of traditions than the one that wrote the file. For example, people on the ground shooting up are likely to use a Z coordinate of +Z being up while people dropping bombs are likely to use a +Z meaning down (if they're both using local tangent planes, they will do silly things like ENU vs NED just to screw with things but based on solid mathematics).

Classic computer graphics hardware uses 0,0 at the upper left with +X right and +Y down because that's how the hardware accesses memory when the raster scane goes left-to-right, top-to-bottom. OpenGL defines 0,0 at the lower left with +X right and +Y up because it was devised for mathematical convenience and there is already matrix multiply hardware in the pipeline that will absorb the transformation. OpenGL also defines +Z as coming out of the screen, while DirectX defines X and Y the same as OpenGL, but with +Z going into the screen. Describing "Computer Science" as having a native coordinate system hasn't been anything resembling true for many, many years (and even then it was just a local cultural convention).

So always label your coordiante system in your data file if it's unstructured and in the file definition if possible. And have people read that description, of course...

Even if it's labled, diferent software interperets the labels diferently. GeoServer for instance when dealing with the WMS protocol, interperets 'EPSG:4326' diferently depending on which version of WMS you are using. 1.0 goes one way, 1.1 or 1.3 the other. At one time it may be serving a 1.3 WMS by merging layers from remote 1.0 and 1.1 WMSes, and has to keep track of which way to flip things for each data set, even though they may be labeled the same.

The original WMS spec didn't specify an order. Lots of programmers assumed lon/lat, but the geographers at the standards body wanted lat/lon, and 'clarified' it by declaring that the correct order years later.

If the labels don't carry enough information to be unambiguous, then they are effectively unlabeled.

The programmers who assumed x, y (lon, lat) were coming at the problem from the wrong culture; the geographers quite correctly clarified things by labeling data with the usage from their cultural perspective. One thing that I've learned over the last few decades is that if a specification is ambiguous, then it's my job as a programmer to ASK THE CUSTOMER how to resolve the ambiguities and not just figure that I know how it should be. I have a nasty habit of including the software version taht wrote a particular file (as well as applicable spec versions) so that I can deal with errors like this later.

Geographers are related to navigators in much the same way that mathematicians are related to physicists (the one is a theoretical underpinning for the works of the other). Navigators have a historical perspective where they can determine latitude unambigously by angle of the sun above the horizon and time of year, while longitude was much more difficult to determine, and they were rarely much above sea level. From that perspective, latitude would come first in the coordinates, longitude next, and altitude (if anyone cared at all) dead last.

Yeah - I agree with all that's said here. Computer graphics windows were right down from top left corner because we (as westerners) read that way and originally computers were text based. The coord system for graphics pixels were extended from the character position on a page. Even going back to the old BBC micro I am sure 0,0 was bottom left math style since I believe that original X-Y pen plotters used to go right and up from bottom left corner.

Originally Posted by waldronate

The programmers who assumed x, y (lon, lat) were coming at the problem from the wrong culture; the geographers quite correctly clarified things by labeling data with the usage from their cultural perspective. One thing that I've learned over the last few decades is that if a specification is ambiguous, then it's my job as a programmer to ASK THE CUSTOMER how to resolve the ambiguities and not just figure that I know how it should be. I have a nasty habit of including the software version taht wrote a particular file (as well as applicable spec versions) so that I can deal with errors like this later.

Unfortunately, that didn't happen. So now there is a huge installed base of WMS clients and servers out there that are wrong, and there's no way to tell except to use a heuristic. Hence the GeoServer solution of assuming the "wrong" axis order for the old version or WMS. This mostly works but it's a pain to work with at times.