planet_osm_polygon import seem sensitive to tags order

[jocelynj]

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

--- alsace.osm  2013-06-01 00:38:25.182404624 +0200
+++ alsace-fail.osm     2013-06-01 01:29:07.841660538 +0200
@@ -31910,6 +31910,7 @@
     <member type="way" ref="48683073" role="outer"/>
     <member type="way" ref="48565263" role="outer"/>
     <member type="way" ref="23301554" role="outer"/>
+    <tag k="type" v="boundary"/>
     <tag k="admin_level" v="4"/>
     <tag k="alt_name:la" v="Elisatia"/>
     <tag k="boundary" v="administrative"/>
@@ -31933,7 +31934,6 @@
     <tag k="ref:INSEE" v="42"/>
     <tag k="ref:ISO 3166-2" v="A"/>
     <tag k="ref:NUTS" v="FR42"/>
-    <tag k="type" v="boundary"/>
     <tag k="wikipedia" v="fr:Alsace"/>
   </relation>

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 ?

[apmon]

No, the tags should not need to be sorted. That looks like a bug. I will investigate. Thanks for the examples to reproduce.

[apmon]

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.