What are some of the tools that map makers use to make maps?
It’s a question that not only concerns developers but also concerns managers and project leads. Many projects, ranging from that small website for a restaurant, or for say a small eco-roofing company, to say a corporate intranet mapping the location of company vehicles, all eventually come to a need for a good mapping solution.
If you’d asked this question even 4 years ago it would be a fairly complicated answer. And in fact the answer can still be complicated. But today you have a spectrum of choice. There are tools that range from pretty much hands off all the way to complete control.
A mapping solution is best thought of as a stack rather than a single ‘widget’. The stack consists of pieces ranging from the ‘user interface’ to the ‘map styling’ to the low level ‘data storage’ – which can also include ‘data collection, management and grooming’.
Here’s a quick fly through of what a typical stack is going to look like;
At the top we have Google Maps. It’s worth mentioning this one just to get it out of the way. Most folks are familiar with the map interface pioneered by Google of course. It is an almost ideal 80% solution for web mapping. Since the maps are served as tiles, and since the display logic is largely running on the client, this is a very fast very satisfying user experience. The only real drawback is that the map itself is not highly customizable. It’s easy enough to draw lines, place markers and have popups, but it is only part of a total mapping solution. If you have your own custom display such as you might see at http://serveyourcountryfood.net you’ll need to start dealing with managing your own data.
Most readers can stop right here basically. If you want a simple mapping solution – just throw in Google Maps (or even Yahoo Maps) and move on to other things in your lives. A few readers are going to need more however and the rest of this essay is for them.
OpenLayers is similar to Google Maps but it starts to enter the land of providing you real power. This is also a client side browser based mapping solution but is open source and is very feature rich and highly customizable. There’s been extensive support for edge cases and special features such as handling different coordinate projection types, different rendering targets ( rendering to a FireFox Canvas for example ), and things of this nature.
At this “user interface level” there also exist a variety of other mapping solutions. Stamen Maps has a good flash based mapping solution that is open source and that you can customize. Many other folks have also written mapping clients and you’ll find a lot of solutions to choose from.
Even here most people who are still reading are going to stop; they may need more than what Google Maps offers but Openlayers may be good enough. But beyond this there are a few businesses and ventures that need something that provides an order of degree of more customization. One of the projects I’ve been contributing to has a need to print maps in Arabic. Another organization I know wants to feature an emphasis on watersheds rather than roads. Both of these kinds of criteria start to incur radically increased costs but as well improved fidelity over your message.
When you decide to generate your own map data you’re forced down a split in choices – and your costs are going to rise dramatically. You can go with commercial solutions such as ESRI and the like – these are very very good – superlative in fact – but you pay for this quality. On the other side of the fence you’re going to be looking at a lot of pieces that have to be assembled with some care.
It is this ‘middle tier’ of the stack – the zone where you can customize appearance – that we’ll look at briefly now.
The art of actually ‘making maps’ relies on a designerly asthetic, it’s going to rely on good map data, and it’s going to rely on a map generation engine. There’s a whole history of how to make maps look good. Drop by Powell’s Technical Books to see a wide selection of books that simply deal with issues of map layout, color choices, decluttering strategies and a whole host of other complex factors.
Luckily tools like MapServer, Geoserver, Mapnik and others can automate away most of this work with reasonable defaults. Feed these engines the right data, the right styling information and they’ll produce for you reasonably high quality maps that you can pass off to Google Maps or to OpenLayers or any other top level mapping widget.
Below this level we come to the basics of data management. Aside from issues like caching, and scalability (which I’ll gloss over) there is the fundamental issue of storing your map raw data. The choice here is often constrained by needing to interoperate with conventional relational databases. Often applications treat map data as an aside, and the mapping solution has to fit within the broader scope of a pre-determined technology framework. These days MySQL is a good choice; but up until recently there was a significant bias towards PostgreSQL because it had better feature for “spatial queries” via a tool called PostGIS. PostgreSQL is still somewhat favored by many of the open source solutions. As well it is worth noting that many projects ( such as my own older project at civicmaps.org ) you can even get away with just supplying “shapefiles” that are not in a database at all.
This more or less defines the basics of serving maps. But often people who are going this far are going to be doing their own map processing as well. These are people who are going to be using tools such as Grass to do analytics on raster map data, or the kinds of tools you can find at OSGEO for manipulating and managing vector datasets.
There is one piece below all of this that is worth mentioning: your hardware infrastructure. Somebody in your organization is ultimately going to be serving that map on some kind of hardware. It might be you – on your own hardware – it might be a team of dedicated sysadmins ready to jump to your every call. Depending on what kind of mapping solution you’re providing this could range from fairly heavy dedicated machines; multiple database servers, fallover redundancy and the like – to just something as simple as a dreamhost account or an amazon EC2 account. Almost inevitably this is going to be running some commodity operating system; FreeBSD, Ubuntu, MacOSX even Microsoft Windows – all solutions that work well. And inevitably there’s going to be some kind of web server; be it Apache, or Mongrel or some of the other solutions. This stuff is all pretty rote – your sysadmins are basically going to have well defined opinions on these issues – but it’s worth mentioning because each of these architectures deals with caching, multiple concurrent connections and the like in different ways and this can ultimately affect the quality of the experience [ except possibly in the case of Google Maps ].
Beyond this it’s worth mentioning that some of the basic data management chores such as geocoding can be accomplished using tools such as Geocoder.us or Google Maps itself. There is also the excellent MetaCarta Geolocation Engine. There is a database of place names at Geonames, and you’ll find lots of great map data all over the net such as the excellent NASA Blue Marble Next Generation, Tiger Data (for USA Streets), and Open Street Maps for streets for the entire planet ( which includes Tiger as well anyway ). Lots of social web 2.0 services like twitter support location queries, and you can even collect random pretty images from locations using services such as Flickr.
Hopefully this serves as a quick cursory overview of the various mapping stacks and what it takes to make a mapping solution. For 80% of website builders the answer is just going to be ‘Google Maps’; but for those who want more – the technology is there – the expertise is there – and the solutions are quite complete.
