Been busy becoming a real cartographer these last few days… Much less straightforward than I would have thought (duh) but also quite interesting.

I would seriously advise the casual reader to stop reading right here and skip this entry altogether, if you are scientifically-challenged or otherwise adverse to weak attempts at explaining the wonders of the world we live in through mathematics and geometry.

The idea is to implement a few DB components (within a much bigger system I am working on) that will generate nifty little maps complete with geopolitical data and layers containing additional sets of relevant data. All this for environmental audit (risk assessment) purposes.
Example: you want the details of a project involving the site of some kindergarten school precisely located at: Yokohama-shi, Kanagawa-ken, 4-14-2. You will first go and fetch geographical coordinates (e.g. lat/lon) matching this street address (using a geocoder component), then will extract a map of appropriate scale/size/boundaries from our map files, and finally will edit the map by placing waypoints for any other relevant data (the nuclear plant 2 miles north, the prison facilities across the street, the military training field 300 meters south etc etc).

Seems easy, doesn’t it?

Well, it’s not.

God, who would have thought that placing a point of a certain latitude/longitude on a map would be so hard…
Actually, who would have thought lat/lon measurements depend entirely on who you are talking to and where they stand in the chaotic world of geodetic standards…
My poor innocent little self was under the foolish impression that, once you get the appropriate geocoder that will spit out the lat/lon for any of your entries, you just apply a bit of high-school geometry to convert that into usable Cartesian coordinates that lets you place some “you are here” marker on your map and everything is fine… Well, it turns out that not two measurement are compatible together, in the wild world of cartography.
First, whatever lat/lon you got, it’s meaningless as long as you do not know in what datum (see below) it is measured. Same goes for the map, which is only valid for measurement made in the same datum, and, of course, same for conversions between lat/lon measurement and any usable Cartesian coordinates (what you’ll use on a flat map). The latter requiring the use of pretty ugly mathematical formulae that sent me back to the worst days of my topological math studies.

The essence of the problem lies in two things:

  • The fact that, not only the Earth is a very imperfect sphere (flattened at the poles, as most everyone knows), but the mathematical parameters of its exact shape (an ellipsoid) were until fairly recently not precisely known and only reached through approximations. This added to other parameters affecting the way the Earth may appear to cartographers (uneven gravity repartition, magnetism etc) meant people only had approximated models for the Earth (what is called a geoid).

  • Because of the lack of precision in defining the general Earth shape, any measurement done using a certain geoid would lose its accuracy as you’d get farther from the point of origin of your measurements. To insure they were getting accurate distances and useful results, cartographers throughout the world decided to use an origin within their own country for their work, hence the birth of a few dozens different coordinate systems (such as NAD27 and NAD83 for the US).

The combination of a specific geoid and a coordinate system is what we (that is, me and my good friends at the International Geodetic Association) like to call a datum. There are tons of them (each country usually has a few, as both geoid and coordinate systems were refined over the years).

The geoid used is extremely important, as it directly affects the projection. Projection is basically the transformation of 3d coordinates (e.g. lon/lat and altitude) into 2d coordinates that can be used on a flat map. The map itself needs to be projected, and that’s where it can become ugly, as there is, to put it simply, no easy way to properly squash a pseudo-sphere into a perfectly flat accurate representation.

The problem might be presented as such: if I draw a small map of the world on an orange and give you a knife and ask you to get me a flat map of this world… How do you do?

Of course, there are tons of ways to go about it and a good way to picture them is to imagine you have a semi-transparent earth globe, a flashlight and big sheet of paper that you can fold in any shape you want (basically, it’s gonna be a cone or a cylinder). You then shine the flashlight through the globe and can see the projection on the paper. Something a bit like that.

As a result of all this, you must imperatively know in which datum any of your data/maps has been measured. Any conversion (including from lat/lon to flat map Cartesian coordinates such as UTM) involves the datum.

To spice things up a little, one must add that there is now a more or less universal datum with a geocentric origin and a geoid defined using the latest information provided by satellite cartography. It is called World Geodetic System (WGS84). This is the datum in which GPS coordinates are usually given (or, actually, one of his close cousin, as there are a few different variations, depending on the precision required, but let’s not be too picky here).

All in all, these coordinates issues and specificities of each country (just for fun: in Japan alone, there is about two or three datums commonly used on top of the international one) makes it a fascinating nightmare to do any kind of cartography works with real-life data, involving enough mathematics to wake-up deeply repressed fearful memories of frightening topology classes…

And I thought this would only be boring down-to-earth computer stuff…

Picture plume.JPG After a few hours of fiddling with the MT API and playing around in perl and php, I now have a semi-automated picture listing function in my Movable Type install. Which means it will take me considerably less time to add pictures taken with my camera.
When I have 2 seconds, I’ll polish the code and release it for anybody to use (the only advantage over the other plugins already available on MT’s website is that it does not require any exotic server configuration).

it’s really thin
it’s damn slick
and most of all: it’s digital.
Today, I bought my first digital camera. Much cheaper and simpler to use than the old faithfull Lubitel and its 2″1/4 rolls.
And since we are in Japan, the only country where cell phones are cheaper than watermelons, I could even afford it without selling a kidney.
Now I’ll have to resist the urge to indulge in a photographic orgy and keep the amount of pix posted here under a strict control…

Recently inspired by a some really neat blog ideas and new concepts, I decided it was time to give mine a much deserved facelifting and move it away from the last semi-public service I was perusing, onto my ever-growing online empire, using Movable Type.
Among many ambitious (as in “I will do it someday”) projects for this blog, are moblogging, a neat integration of different media and some other things I’ve been brainstorming about lately.
For now, a bit of work on the colors and design as well as the purchase of a digital camera should do…

Much like the previous one(s), this blog is more like a way for others and myself to keep track of what I’m up to and occasionally discuss what’s on my mind… it is not really designed to become a widely publicized account of my mischief… not hiding it either (not much to hide anyway), but due to a total lack of self-censorship here and possible offensive material, I know this won’t be everybody’s cup of tea and do not want to push it unto others.
Which is why there are no links from the main page.

Anyway, feel free to give the url to whoever you think might want to read this.

PS: not yet sure what I’ll do with the previous entries, whether to move them all here, move a small selections of interesting ones (I know that’s cheating, but writing is cheating) or just forget about it… We’ll see.