-
-
Notifications
You must be signed in to change notification settings - Fork 473
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
planet_osm_polygon import seem sensitive to tags order #35
Comments
No, the tags should not need to be sorted. That looks like a bug. I will investigate. Thanks for the examples to reproduce. |
Reported in github issue #35 The previous fix b80cb3e did not fully fix everything. (hopefully this time it will) There are still some differences (with respect to tag copying from member ways of multipolygon relations) to the original code, but they should all be either improvements, or the correct behaviour is ambivalent.
I think I have fixed this issue now. Thanks for the detailed bug report that made it easy to track down. There are still some differences in the way multi-polygons are handled compared to prior to the lua-tagtransform commit, but I think for all of the ones I have seen, the new behaviour is either better, or the correct behaviour is not obvious due to broken relations. (The following only applies to the builtin C based tagtransform, not the actual lua tagtransform, as its behaviour depends on the lua script used) The differences I am aware of are the following: In both cases, the copying of tags from member ways to the multi-polygon relation is only triggered if there are no tags on the relation other than type=multipolygon and name=. However, the new code does tag filtering first, removing tags like note= or FIXME=, resulting in more multipolygons correctly being handled. The old code would copy over tags from member ways to the relation, even if the relation already had that tag with differing value. E.g. if both the relation and the member ways had (differing) names, it now uses the name tag of the relation rather than of the member way as previously. If member ways have conflicting values for tags to be copied over to the relation, the way who's value "wins" has changed. However, I don't think there is a correct behaviour here and those are broken relations. So this change shouldn't be a regression. |
Reported in github issue osm2pgsql-dev#35 The previous fix b80cb3e did not fully fix everything. (hopefully this time it will) There are still some differences (with respect to tag copying from member ways of multipolygon relations) to the original code, but they should all be either improvements, or the correct behaviour is ambivalent.
I'm hitting an issue with some tags that are not correctly imported in table planet_osm_polygons, and I think it might be because of the tags order in the .osm source.
For example, these two osm files only differ on the tag ordering of type=boundary:
http://osm7.openstreetmap.fr/~osm2pgsql/alsace.osm.gz
http://osm7.openstreetmap.fr/~osm2pgsql/alsace-fail.osm.gz
With the second file, admin_level column of planet_osm_polygon is not filled with value 4.
Must the tags be sorted before importing with osm2pgsql ?
The text was updated successfully, but these errors were encountered: