[OSM-talk] live rendering (was: Mapnik has busstops)

[Frederik Ramm]

Hi,

> 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.

Nothing against all that. (As far as I know, the current database  
*is* spatially indexed, only not in a way suitable for Mapnik.)

> 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

I remember reading Artem complaining about lots of things that our  
current model has and which upset rendering, e.g. self-intersecting  
ways and so on. While I can easily believe that these can be fixed in  
a conversion step, I am not sure whether they can be fixed by adding  
indexes and not changing the real data.

Furthermore, I believe that spatial indexing isn't all; you will  
probably also need indexes on various metadata aspects. Rendering a  
level-7 tile "on the fly" would require transferring more than a  
gigabyte of data from the database if you only have "bounding box"  
requests. You will need to have the ability to query the database for  
exactly what you want to render - and even then, say if you only use  
motorways and cosatlines, the amount of data retrieved for processing  
will be very large.

> 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.

Provided that a proper mechanism for invalidating tiles exists, and  
provided that both database and rendering engine really deliver the  
power to re-render a level-7 tile every time something in its area  
has changed.

> As a side effect, the API will run a lot quicker because it will
> be able to use the spatial columns to speed queries.

Unless, of course, the database is bogged down by delivering data to  
the rendering viewer.

I would be extremely happy to see a "live renderer", don't get me  
wrong - but I am not exactly over-optimistic that we'll have it  
within the next half year.

I believe that the way to go is to have a live copy of the current  
database, modified for the renderer's needs. If we manage to  
implement the live distribution tree, then this should be easy to do.  
For real live rendering on all zoom levels, we will probably need  
multiple instances of the database, and filter the data on entry -  
e.g. if a new coastline way comes in from the central server, copy it  
fully only for the detailed zoom levels, and create a smoothed  
version with limited number of nodes for the low zoom levels.

But of course any way is fine if it works.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00.09' E008°23.33'