[OSM-dev] Slippy map's future

Nick Whitelegg nick at hogweed.org
Sat Sep 30 09:37:50 BST 2006


[ to talk and dev as the first bit is talk-related, second bit is dev...]

Further to earlier messages and initial work on 'osmabrowser', an interactive 
osmarender viewer, I'm coming to the following conclusions about the future 
of the 'slippy' map:

* We should perhaps promote osmarender-generated maps, rather than the slippy 
map, as examples of what has been done already. Perhaps osmarender (via 
'osmabrowser' once it becomes more mature), should be the preferred way for 
interested general web users to get a static map of their area. Some 
mechanism (see below) to deliver a static PNG if their browser doesn't do SVG 
could be implemented.

* Nonetheless we still need a slippy map, particularly for use in mash-ups, 
such as Freemap. We really need OSM to be as amenable to mashups as Google is 
now, to allow the sort of apps which have developed with Google to become 
popular with OSM.

* The slippy map should be based off planet, to maximise performance. Perhaps 
it could go on dev, at least until we get more hardware. If it was based off 
planet, the database schema could be relatively stable and need not include 
versioning information. The code which generates the slippy map could also 
provide a drop-in PNG replacement if SVG was not available on the user's 
browser (see above)

* This now comes down to the question of language and technology. A few 
options:

- The GML-shapefile-mapserver approach is one option, but generating 
shapefiles from planet seems to be a big and memory intensive job. Also I 
have heard that mapserver has some text placement issues. Also to my mind a 
custom OSM solution, allowing people familiar with Map Features and 
osmarender rules files to easily configure the map, seems better to me - why 
should people have to learn another set of configuration options?

- This brings us down to the question of language and graphics library.

- PHP/GD is my preferred option but cannot do rounded linecaps and linejoins 
and is a bit wobbly with antialiasing, so not really the best option for 
high-quality maps.

- Better options revolve around ImageMagick or possibly cairo. mod_ruby seems 
to have too many inherent issues on dev so would not be my preferred choice. 
PHP bindings for ImageMagick exist but are poorly maintained, and in one 
case, very poorly documented. Perl/ImageMagick is more regularly maintained 
but documentation is poor (couldn't find - even on google - how to do custom 
line joins, for instance). 

- C/C++ seem to be the best-documented and maintained languages for use with 
ImageMagick (and cairo). That said, neither are exactly the best languages 
for working with databases and XML; scripting languages (and Java) are IMX 
much easier to work with. 

- However, and particularly as I would want to incorporate image-generation 
into a larger utility for converting OSM to other formats (see 'osmbabel' 
post earlier in the week), they are maybe the best choice.

So what I propose to do on OSM between now and Christmas is:
- improve osmabrowser
- work on said slippy renderer using C/C++ with ImageMagick.
- patch JOSM to do SRTM contours. 

Please do speak up if you feel I'm going down the wrong path. I say that as my 
free time will be limited in the coming weeks and I'd prefer to do stuff 
which will be useful!

Thanks,
Nick








More information about the dev mailing list