Here’s a quick guide to making odd maps. Since most of the time I’m working on TileMill or some part of MapBox’s mapping stack, I make a lot of test maps. The normal stuff gets boring quick, so I tend to make more odd things.
The pixel size of this map is 100,000 meters.
It’s not too hard: just use node.js to run some
rounding value a variable,
r, to be able to tinker with values.
So you’d call this file
doit.js and have
countries.geojson in the
same directory, and then run
node doit.js and it’ll get done.
This map is not a West Wing reference, and I take a hard stance against Mercator hate.
No surprises here: basically the same code, but instead of rounding values,
I’m flipping them with
If there can be takeaways here:
That said, it’s inefficient. So, I usually use it just as a go-between. Get really friendly with ogr2ogr, because it’ll do the conversion, and lots more. Something like
So: you convert to GeoJSON, do stuff, and then back to a shapefile. Shapefiles are faster and (usually) more space-efficient than GeoJSON.
On the same point, these scripts don’t need to be hyper-fast. They generally run once, and even if you have slow constructs, like having to keep a gig of data in memory, if it works, it works. Chill out and make crazy stuff.
For more complex map builds, you can pull together your
ogr2ogr magic and your processing scripts and even the
that opens up QGIS to preview into a Makefile.
I don’t abuse Makefiles or do magic or real scripting in them: they’re just pretty decent for remembering what commands you want to run to do a thing. For instance, I pulled together the stuff for my presentation at foss4g with this little guy:
Making odd maps is generally a practice of making things that look wild, and complex. Usually they boil down into sixty lines of code, that’s not very elegant. This is actually a pretty great way to practice not caring: not making a general solution, not using a more elegant tool that does the thing ‘correctly’, and not optimizing unless you need it.
Here’s a map of sorted countries that I made for my presentation at foss4g.
When you actually need to do stuff with shapes, you need to bring in the big guns: which in my case usually means Shapely, a swiss-army knife of geographic & geometrical functions that works with OGR. OGR’s the less savory part of the equation, being kind of a ‘wrapper for Python’ that feels like a wrapper and not like Python. But Shapely is wonderful!
Here’s the Python source for this one. As you can see, an unfortunate amount of time is devoted to Shapefile + OGR bookkeeping and boilerplate. Also: this isn’t knocking the OGR project in general - it’s actually a massively impressive wealth of code that can parse and emit practically everything, and does it remarkably fast.
My workflow is obviously a bit TileMill-centric: since most of this work is just a weird route to testing various bits of functionality and code. I’m looking to try out more prototyping with Polymaps, but for the time being, QGIS is the only middle-step that I have for testing that things look right.
You may have noticed in the last one, countries have that awful skewed look remniscent of Greenland taking over every Mercator map. Basically, if you’re doing your final output in Mercator, it’s wise to do your datasource in Mercator as well.
In some cases, it’s kind of cool: I generated this maze map in EPSG:4326 (longitude, latitude)
And you can see it becoming more exaggerated in the north and south. Fine for this effect, but if it was done in EPSG:900913, aka ‘Spherical Mercator’, it would look a bit less odd. But, still about as odd as a neon green maze on a map.