Re: [OSM-talk] Mapnik maxing CPU with Corine data set

2011-01-18 Thread Dermot McNally
Right - it has taken longer than I expected, but I have an update. We have solved the problem, which was, indeed, down to at least one over-large polygon. Stripping out the sea polygons didn't fix things, so we looked for the largest polygon and found a pasture-cover polygon covering most of the

[OSM-talk] Mapnik maxing CPU with Corine data set

2011-01-17 Thread Dermot McNally
Hi folks, I need help with a Mapnik problem we're having in the context of a Corine Import we're preparing in Ireland: http://wiki.openstreetmap.org/wiki/Republic_of_Ireland_Corine_2006_Import An outline of the problem is at the bottom of the page, but here are the key details: * We have

Re: [OSM-talk] Mapnik maxing CPU with Corine data set

2011-01-17 Thread Lennard
On 17-1-2011 17:37, Dermot McNally wrote: Any tips? Do you have some overly complex and/or large features in the data? If you have some polygons that span half the country, that could be slowing down mapnik. If that's the case, and you import this as-is, you'd likely affect everyone else

Re: [OSM-talk] Mapnik maxing CPU with Corine data set

2011-01-17 Thread Dermot McNally
On 17 January 2011 19:19, Lennard l...@xs4all.nl wrote: If you have some polygons that span half the country, that could be slowing down mapnik. If that's the case, and you import this as-is, you'd likely affect everyone else rendering Ireland in their mapnik renderer stacks. Assuming it's

Re: [OSM-talk] Mapnik maxing CPU with Corine data set

2011-01-17 Thread Frederik Ramm
Hi, Dermot McNally wrote: And here I begin to have a doubt - the sea polygons are tagged natural=water_sea. My assumption was that these would be ignored in rendering because no such tag is understood. But as it's a natural tag, won't it actually be considered a polygon and stored in the DB

Re: [OSM-talk] Mapnik maxing CPU with Corine data set

2011-01-17 Thread Lennard
On 17-1-2011 20:55, Frederik Ramm wrote: It will certainly be stored in the DB because osm2pgsql does not know about rendering rules. Plus, there it at least one query in the standard rendering rules that will actually *retrieve* such a polygon and return it to the Mapnik library for processing