This post originated from an RSS feed registered with Ruby Buzz by . Original Post: On Coordinate Systems Feed Title: cfis Feed URL: http://cfis.savagexi.com/articles.rss Feed Description: Charlie's Blog Latest Ruby Buzz Posts Latest Ruby Buzz Posts by Latest Posts From cfis

If you feel like ending a conversation with a developer then simply bring up the topic of character encodings. Or, if you're talking to a GIS wonk, then simply mention coordinate systems. In either case, your compatriot is sure to beat a hasty retreat to the nearest exit.

Which of course makes you wonder why I'm mentioning both of them in my blog. Perhaps I'm delusional, but with the explosion of web-based mapping using Googe, Microsoft or Yahoo apis, I've been seeing a lot of questions about coordinate system lately.

So in the spirit of Tim Bray's and Joel Spolsky's wonderful writeups of character encodings, I thought I'd put together a basic survival guide to coordinate systems over my next few posts and then tie it back to Google Maps.

I mentioned encodings and coordinate systems together in the first paragraph because they share a fundamental similarity - both are needed to correctly interpret a piece of data. Given a set of bytes you need to know the encoding to correctly extract the characters. Given a set of coordinates you need to know the coordinate system to correctly locate them.

So what is a coordinate system? It is an agreed upon way of representing locations. The best explanation I've ever seen comes from GE's Smallworld documentation. Spicing it up a bit, imagine you've buried some treasure on a deserted island, and like any good pirate, you want to make a map so you can find it later. You send off two of your trusted lieutenants to do the job. The first one comes up with this map:

Image courtesy GE.

He explains it to you by saying:

Start at the giant conch shell on the western beach, define one axis to run east and the other one to run north. Then divide the island into a grid where each grid unit is 10 paces square. To find the treasure walk 4 units along the first axis and one grid along the other axis. Thus the treasure is located at coordinate 4,1.

Your other lieutenant comes back with this map:

Image courtesy GE.

He explains it to you by saying:

Starting at the the clump of two palm trees on the western beach, look towards the giant conch shell. Call this one axis and make the other one perpendicular to it. Then divide the island into a grid where each grid unit is 10 paces square. To find the treasure walk 2 units along the first axis and then 3.5 units along the second. Thus the treasure is located at point 2, 3.5

Both lieutenants unknowingly defined their own coordinate systems. To do this they first defined an origin, then two axes and finally a default unit size.

Without knowing the definitions of the coordinate systems, the points (4, 1) and (2, 3.5) are meaningless. And we would have no way to see that they actually define the same place!

There are of course an infinite number of coordinate systems that could be defined for this treasure map, and if you sent out a few more lieutenants they'd come up with a few more coordinate systems. Of course most people naturally focus on obvious physical features so its no surprise that the giant conch shell plays an important part in the definition of both coordinate systems.

Both of the coordinate systems above are know as local coordinate systems. To define a local coordinate system requires specifying an origin, two axes and a unit size. You've probably done this yourself - as a kid I used to do this all the time when creating maps of my neighborhood.

We use maps with local coordinate systems all the time. Golf course maps, bus maps, train maps, garage sale maps, quaint maps of downtown's, amusement park maps, etc. The examples are endless.

Local coordinate systems have a major limitation though - its harder to share data. Try creating a map that combines information from two different maps with local coordinate systems. First you'll have to reverse engineer each coordinate system (your golf course map probably doesn't tell you where the origin is, what the axes are or what the unit size is). Then you'll have to take the data on one map, convert it from its coordinate system to the other map's coordinate system, and then redraw the map. All in all quite a pain.

It would also be useful to have coordinate systems that accurately cover larger extents - for example the state of Colorado where I live.

There is class of coordinate systems, called geodetic coordinate systems, designed to solve this problem. Geodetic coordinate systems are based on mathematical models of the shape of the Earth. They are used by Google Maps, road atlases, navigation charts, etc. Defining a geodetic coordinate system is a much more complex undertaking than defining a local coordinate system, so I'll leave that until the next post.