When talking with clients there is always a turning point in my mind where their request turns from being a “Google Map” to being a “web mapping application”. It is usually where data is being filtered, updataed, or when ‘users’ are mentioned. This a pivotal point where the project both gets more interesting, a lot more complex, and likely more expensive for the client. in this post I will take apart what a web mapping aplicatiuon actually looks like and outline some high level application considerations.
“I want a Google Map showing some field data points, that’s easy right?”
“Sure”
“And I want my guys to be able to update them, you know like from a spreadsheet?”
“Oh, ok…”
That is the point where the “simple” Google Map turns into a mapping application. A web map is usually what you might call a “one shot deal”, it contains a discrete dataset which is being displayed mostly all at once, with the exception of some cleint side magic. An application starts to happen when the map is being asked to display more and disparate data to perhaps a qualified user base. Additionally there might be the opportunity to add data to the application, or edit it. Whilst the data is still one of the primary components of the application, in general terms there is “more” happening.
Frameworks
I use django where its possible, but I will not get into a religious war on the benefits of django vs rails vs codeigniter vs <>. The point is, unless you want to write a really large amount of extra code to support users, authorization, forms, validation, administration, etc. using a framework makes good sense. Remember that your key value is likely that you can build a map, not that you can write an awesome server-side form validation technology. Using a robust, modern framework will ease your pain somewhat. if your app becomes terriblely popular, its likely that you might want to tinker with your framework to acheive a touch more performance, but frankly; that’s not a problem, until its a problem.
I use django partly because geoDjango is baked in, but more so because python fits my rather simplistic brain better than rails. So, this is very much a personal choice. In your choice make sure that spatial objects are well looked after, ideally your framework will plug straight into PostGIS or another robust spatial data storage solution.
The Story
Whether this application is for field data collection of fire hydrants or for sharing the history of polar bear movement there is a story. The map will part of that story. Perhaps it is a major part, perhaps its a minor character role, either way the map is a key piece of visual storytelling and needs to be intertwined into the rest of the site in a way that supports the site’s motive. In terms of the design of the appliation always consider the story and the motive of that story first. As a cartographer, web designer, web developer, or even backend devops engineer your purpose is to scupt a story for your users understand.
Map Choices
To add data to your application, it is likely that a user will have to have an account. It is likely they will have to log in. This seemingly common act raises a problem. If only some people can log in (ie if it is an enterprise solution, or if a user pays for an account) and if that user needs to interact with a map whilst logged inin a manner which is not available to a non-logged in user then it is possible, (likely) that you will contravene implicit licensing agreements. That means you as the developer need to pay for an enterprise license, deal with multiple mapping API /basemap solutions or use an open source mapping solution from the beginning. This is a tricky business because its likely that your client asked for a “Google Map”, not just a map, so they have a certain expectation around the cartography and the interactivity. A nice feauture of the geoDjango admin is that it wires in openlayers and openstreetmap into the admin by default, thus aleviating much of this issue.
In terms of basemap cartography, we are now spoilt for choice and though I would argue that Google Maps has the most robust and well documented set of functionality choices around, in terms of pure cartography choices are very must up for discussion now.
Check out these examples from around the town of Mammoth Lakes in California:
There are some differences between each example, but it is obvious that the quality of online web mapping cartograhy has increased hugely, with the consumer being the biggest winner.
Think mobile first
The seemingly simple act of adding the concept of users to a web map can ceratinly blow out the compelxity of any map. But the key idea to remember is that the value is being driven here by the map as a visualization platform. With that in mind, the user functionalities should be removed as far as possible from the UI. With the focus on the map, if we go to the original example its only a brief mental streach to be thinking mobile. With all the benefits that geolocation and mobile data collection can provide, not suggesting to a client or employer that any web mapping application be built with location intrinsically considered in the workflow is verging on the irrisponsible.
Summary
I hope this article has helped highlight some of my thoughts around web mapping application development as an extension to the idea of a simple web map.
The key points are:
- you should consider a web application framework (django, rails etc)
- you should always remember your story throughout the entire UI
- you have some decision making to do around mapping APIs (particularly in terms of protected parts of an enterprise site)
- you should consider any application to be mobile ready