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
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
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
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
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
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
6 matches
Mail list logo
