[OSM-dev] Using NULL values in mapnik / postgres DB

[Joerg Ostertag (OSM Munich/Germany)]

On Wednesday 21 February 2007 00:43, Jon Burgess wrote:
> On Tue, 2007-02-20 at 22:12 +0000, Artem Pavlenko wrote:
> > Jon,
> >
> > Sounds good to me! Also, it might be a good idea to split osm data into
> > multiple tables in postgresql and only keep fields that are required :
> >
> > 1. roads (LINESTRING) :  osm_id,highway,level,name ...
> > 2. all points (POINT) : osm_id, amenity,...
> > 3. all polygons (POLYGONS): osm_id, natural, leisure etc.
> >
> > Thoughts?
>
> I've given this a few minutes of thought and my initial conclusion is
> that pre-processing the data on the input to the DB could possibly save
> a lot of time if it makes the rendering faster.
>
> We run the render over the for each zoom level, so anything we can do
> once on input to the DB is something we can avoid doing 10+ times when
> rendering at different zooms.
>
> It takes ~20 minutes to push the planet.osm into a DB and many days to
> render the tiles. Any trade-off which could (for sake of argument) halve
> the tile rendering time at the expense of doubling the import time would
> be a big win overall.
>
> The one caveat, as I mentioned before, is that we potentially restrict
> the flexibility of the osm.xml file if we've removed data by
> pre-processing before the DB.

I don't think this is too much of a problem, since every time you get a new 
planet.osm file you delete the complete database and then it's no problem to 
also change the osm.xml with all it's feature_id entries in it.
So i don't think there is too much loss in flexibility. Yes adding a complete 
new rendering rule would (sometimes) need a complete import rerun, but it 
would currently need it too. 

-- 
Jörg (Germany, Munich)

http://www.ostertag.name/
TeamSpeak2: ts2.ostertag.name, user: tweety, Channel: "GPS Drive"
irc://irc.oftc.net/#osm
Tel.: +49 89 420950304