On 28-4-2010 10:46, John Smith wrote: > They render as lines instead of areas, but they still render, I've > dealt with this issue a lot of time with broken postcodes in > Australia, fix the relation you fix the rendering...
type=multipolygon boundary relations do not render. Just realised after sending my previous reply. The fix is easy, the result gobsmackingly ugly (read: overlapping lines). > That doesn't solve the issue, that just excludes information from > relations, we need to use relation information if the way information > doesn't exist, similar to the way information from relations work for > other objects. That cannot be solved from mapnik. This is a job to be done during the db import for mapnik, both for non-slim mode (a one off job) and slim mode imports, which have to take into account loading diff files. At some point, it just sounds much simpler to correctly tag the member ways. This is *not* wrong, they *are* boundary demarcation lines. > This is the order things need to be found, through a subselect or > join, after finding distinct segments, from those segments we need to > sort by way admin_level, and then by relation admin_level, simply > excluding information only glosses over the issue by excluding broken > multipolygons. By the time mapnik sees the data, it has been processed. Relations could have been converted into line geometries, and there is no way for mapnik to discern those from the proper ways, other than the test for osm_id>0. I suggest you play around with a limited dataset, and see how that ends up in the pg db, in which tables, for different taggings. -- Lennard _______________________________________________ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev