[Tile-serving] [osm2pgsql] Bad multipolygon tags (#80)
Petr Morávek
notifications at github.com
Fri Sep 20 13:24:02 UTC 2013
@apmon The main problem is that the current algorithm breaks multipolygon tags even if it's tagged correctly, e.g. the relation mentioned in my initial post.
At the moment we can't get rid of tag transfer completely, because there are simply too many "old-style" tagged multipolygon relations. I think, that whatever strategy for the tag transfer is applied, it should not under (almost) any circumstances break the correctly tagged multipolygons, but it's ok if it produces buggy features for the "old-style" tagged relations - the relation should be fixed anyway.
There are three important points that need to be addressed:
1) **How do we recognize if the relation is tagged old or new way?**
At the moment this is decided by checking if the relation has at least one polygon tag.
This works in most cases (but not all, e.g. the infamous relation that started this issue report). I think we should consider a more strict approach, specifically: If the relation has only type=multipolygon tag and nothing else, then do the tag transfer (i.e. this is "old-style" tagging), otherwise let the tags be as they are.
(I did a quick check on smallish data extract from Central Europe - roughly half of the multipolygon relations has type=multipolygon tag only, roughly half has at least one well known polygon tag, less than 1% of multipolygons does not fall into any of these two categories.)
2) **What tags should we transfer on old-style tagged relation?**
Current strategy of simply copying everything is definitely wrong. As mentioned before, it should copy over only the tags that are present on all outer ways.
3) **What to do with member ways? Should they be imported separately?**
Current code tries to mark ways as superseeded regardless of the fact whether it's "old-style" or "new-style" multipolygon, I think this is wrong as well. It should try to mark ways as superseeded only in case of "old-style" tagged multipolygon.
The way should be marked as superseeded only if all of its tags were transferred to the multipolygon in the previous step. This would ensure that we don't throw out linear features present on the member ways.
The proposed changes will definitely break parsing of some relations and will fix parsing of others. The main theme here is that _parsing of correctly tagged multipolygon relations must result in the expected features in pgsql_.
---
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/osm2pgsql/issues/80#issuecomment-24809818
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tile-serving/attachments/20130920/25bfbd61/attachment.html>
More information about the Tile-serving
mailing list