On Wed, Nov 24, 2010 at 8:33 PM, Dane Springmeyer <[email protected]> wrote: > I commented on the ticket with my assessment of the problem, basically that > only lines are being created as the tag matching for polygons is not robust > enough in the osm plugin. Look forward to others feedback on how to improve > this.
Glib answer: use osm2pgsql and the postgis plugin. Slightly longer answer: the handling of areas in OSM is massively complicated. First, as hinted at in the trac ticket, it's pretty arbitrary which closed loop ways should be treated as polygons - based on the shifting sands of which tags imply areas (e.g. natural=wood) or that override other tags (e.g. adding area=yes to highway=pedestrian, which is otherwise a linear feature). Moreover, as soon as you start touching multipolygons you are into relation parsing, with all the subsequent edge cases - taking tags from the relation to use as the tags on the output geometry, or using the tags on the outer way, or stitching together outer ways, even down to special cases where the relation has a name and no other tag. (Starting to get the feeling I've spent too long in osm2pgsql/output-pgsql.c relation handling?). Or, in summary, making areas "work properly" would require so much duplication of osm2pgsql, and keeping up with whatever the OSM contributers decide is this months' way of doing thing, that mapnik's implementation is likely to slowly bitrot. I'd leave the OSM plugin as a quick hack, but when people outgrow it they should look into the mainstream OSM/mapnik toolchain. Anyway, just my view. Cheers, Andy _______________________________________________ Mapnik-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/mapnik-users
