[OSM-talk] Mapnik has busstops

Robert (Jamie) Munro rjmunro at arjam.net
Thu May 3 14:22:36 BST 2007


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Frederik Ramm wrote:
> Hi,
> 
>> The Mapnik renderer (on both sites) uses some black magic for
>> coastlines.
> 
> AFAIK, coastline data on the lower zoomlevels is taken from a non-OSM  
> source.
> 
>> This bug in the Mapnik renderer might be
>> the last hope for the Tiles at home subproject.
> 
> Funny language you're using. The raison d'etre of the t at h system is  
> providing current renderings of OSM data; if someone else does that  
> better, then we do not need the complicated t at h stuff any longer and  
> nobody is going to be unhappy about that. You sound like you expect  
> the t at h participants to say: "Phew, are we lucky that mapnik has this  
> bug, otherwise we'd be out of business". But there's no reason for  
> that; we are all in the same business.
> 
>> If Mapnik gets
>> coastlines right
> 
> ... and bridges, and tunnels ...
> 
>> and planet.osm is dumped on a daily
> 
> ... or hourly ...

Mapnik is many orders of magnitude faster than tiles at home - fast enough
to generate tiles on demand and not store them, as
http://labs.metacarta.com/ demonstrates (although it does cache tiles it
has made in case they are used again, because disc space is cheap). The
problem is that it can't run on the current database, mainly because the
current database isn't spatially indexed. Schuler is working on what I
think will be the answer to all our problems - migrating the current
database structure to PostGIS without changing it, and then adding
spatial columns with triggers.

These spatial columns are not part of the logical model of the data,
which remains unchanged, they are just added as a sort of index or
cache. Mapnik should be able to work directly from these columns, and
you won't have to wait a week for Planet.osm, or even an hour for T at H to
see your changes, they will be rendered instantly once you have uploaded
them. As a side effect, the API will run a lot quicker because it will
be able to use the spatial columns to speed queries.

T at H may well go away in this scenario, but osmarender will still be
useful for producing easily customisable vector maps for printing.

Robert (Jamie) Munro
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGOeIZz+aYVHdncI0RAsnZAKC0gMTp7LlEjhC0LzLXn4hQpApLswCfRsDH
EM1UZHA7Dz5U5ssDYv91pho=
=DPDI
-----END PGP SIGNATURE-----




More information about the talk mailing list