Skip navigation.
Home

Local map rendering - Can it be *that* complicated!?

For quite some time I was sort of dreaming about an open source navigation solution. The first problem one encounters is that there is no open map data available. Only some very basic stuff, at that time, was available, like coast lines, the Tiger data for the USA and that was about it.
So about a decade ago - oh boy, already so long ago - I started some programming research about it. My idea was to use my newly acquired GPS device to collect data about the roads and creat the map from that data. This is clearly similar, but this was before OpenStreeMap existed and my idea was to automatically convert the GPS tracks into ways and nodes without having to "repaint" them as OSM does. I even invented some clever algorithm to reduce the number of nodes on a way without loosing quality (similar to Peuker but simpler to implement) - you can see the result here: http://prior-art.kernelconcepts.de/sparsing-dotted-lines.html.

But the OpenStreetMap project had, in the long run, the better approach, I have to admit. Today the map data problem is, I would say, 80% solved. The road coverage is almost 100% but there are still a lot of issues that need to be fixed in order to use that data for routing. But at least good map drawing and rendering is possible.

And here we come to the point that I do not understand: We have now seen a decade of OpenStreetMap data gathering. But as it seems to me two major issues have not yet been addressed very properly:

1. Data storage and access
OpenStreetmapData is mostly stored in *huge* XML files, almost impossible to search or query. There are many approaches to stuff that into databases like PostGres and PostGIS but they require quite big infrastructure. My interest is mobile devices and a PostGIS database for live-display of a map is a clear no-go.

2. Local rendering
All renderers for OpenStreeMap map data I am aware of render tiles. Most of them even pre-render them into a large bitmap collection which an application can them fit together to display a bitmap map. What a non-sense! We have the vectorised map data at hand and display pre-rendered bitmaps crippling ourselves from taking environmental information from the user's device into account - like light condition to change contrast, device orientation (toward 0 degree north) to turn the map, to use different projections as the user sees fit and to be able to change the zoom level of the map on the fly etc.

Both problems are partially addressed but there is amazingly no consistent solution. I would have expected to see something like a "navigation map display" widget to appear sooner or later. But it didn't. Pity...

I am currenlty investigating what I could possibly use to make my life a little easier in doing this on my own.

I looked at libOSMScout but cannot get it to display anything.
I looked libchamplain and the local memphis renderer - crap, still tile based! (but took me half a night to figure that out)
And I looked at Spatialite - this is somewhat promising, a GIS extension for SQLite. But rather complicated and not very well documented for beginners like me that just want to get all roads and nodes in a bounding box.

Oh well... last night I started some small development of a small Cairo based map drawing widget and will dig out some old code I still have from Mappix (s.a.). Lets see how far I get. My first goal would be to be able to do something like
GtkWidget *map = locosm_map_new();
(my project working title is "Locosm" from "LOCal OSM").
The map widget would then have simple controls like setting the bounding box - and it would then automatically fetch the bbox data and render it or setting the viewing angle (so that the map can be oriented in movement direction like any navi does).

This is still a long way to go but as it seems nobody else is doing it... *sigh* ;)