[OSM-dev] Direct .osm plugin for Mapnik
artem at pavlenko.uklinux.net
Tue Mar 6 09:58:42 GMT 2007
it's interesting idea and I was thinking about it the other day.
In an ideal world OSM database would hold 'clean' geometries, well defined
tags and there will be some sort of spatial index to retrieve data
efficiently. In reality it takes lots of CPU and memory to convert OSM into
something that can be used for real-time rendering or for anything else you
might want to do with geo data.
There were some talks about improving data model, tags/values etc .
But until this is implemented, 'raw' osm data is hmm.. well is 'raw' osm
data:) and it requires post-processing.
You can write a plugin for mapnik to read *.osm files, but you'll need to
re-order nodes, get rid off duplicates, decide 'is it a polygon or a
line?' and so on.
But takes only 20-40 min to convert planet.osm to pgsql 'Simple Features'
with osm2pgsql. Why don't you like this approach?
On Tuesday 06 March 2007 08:52, Nick Whitelegg wrote:
> Hello Artem (and anyone else interested),
> I was thinking that it would be a good idea to work on a direct plugin for
> .osm data in Mapnik. I decided to risk upgrading from sarge to etch on the
> Freemap server last night (I say 'risk' as I broke my Debian installation
> on my home box last summer doing the same thing due to something going
> wrong upgrading XFree86 -> X.org) and now have Mapnik installed on
> However, to do rendering I'll still need to go through shapefile which
> obviously is not the most efficient way of doing things on a webserver.
> What would be good would be to fetch .osm from the API, render tiles
> directly then cache for say a month or a week, whatever's the best balance
> between an up-to-date tile set and reducing the load on the OSM API.
> Should this be easy to do? I already have the libosm C++ library for
> parsing .osm. I guess it's a case of looking at the existing plugins in
More information about the dev