Feb 7, 2012 at 9:27 PM

Hi all,

I had a close look on OSM multipolygon relations and how they are handled by OSM Editor. I hope this review may be helpful for development.

I see that Load OSM File creates one extra polygon feature per multipolygon relation. This conversion looks almost perfect on the geometry side, but (for me) doesn't work at all on the tagging side.

The way tags are attributes on its corresponding polygon or line feature. The relations tags are attributes on its corresponding polygon feature. I see no transfer of tags from the outer way to the (relations) polygon feature, even though I spotted a function named MergeTagsFromOuterPolygonToRelation in OSMGPFileLoader.cs.

Have a look at this OSM files, each contains one relation.

Relation 1246087 is an example where both the relation and the (one) outer way are tagged as landuse=residential. Result is one polygon for the outer way and one polygon with holes for the relation, both with attributes landuse=residential.

Relation 222876 has no landuse tag, the outer way is tagged as landuse=residential. Result is one polygon for the outer way with attribute landuse=residential and one polygon with holes for the relation without landuse attribute. Btw: The inner way 24887807 is tagged as highway=pedestrian area=yes. It is represented as line feature, but should be a polygon feature.

Relation 1818497 is tagged landuse=residential, the various outer ways are without landuse tag. Result is one line for each outer way without landuse attribute and one polygon for the relation with landuse=residential. This kind of tagging is suggested in OSM Wiki, and therefore the result in OSM Editor is best, too.

I think, while inner ways/isles usually are valid objects themselves, the features for outer ways should be omitted, attributes should go to the multipolygon features. At least, if the former would interfere with transfering back to OpenStreetMap, there should be a clear mark in ArcGIS which features are not valid objects themselves. Btw it would be preferable to see if an osm_id is a way or a relation ID.

For a minor detail regarding the geometry look at relation 70884. There are three inner ways that each share a border segment with the outer way. These "holes" are not cut from the polygon feature shape.


Feb 8, 2012 at 3:12 AM


excellent discussion point. Dealing with (non-homogeneous) multi-polygons as in relation 1818497 is a new feature for version 2. We've been talking about for some time at the various conferences but we haven't been challenged on the topic yet.

First of all, you found two bugs:

- Relation 1246087 was the first one. The code was calling the MergeTagsFromOuterPolygonToRelation but it wasn't assigning the merged attributes to the relation itself.  

- Relation 222876 was the second issue. The inner way 24887807 should have been indeed a polygon.

The issues have been fixed with change set 74046. (I do see a beta4 in the near future).

Now that leaves us with the discussion of the two polygons as in relation 1246087. 

When you import the data with the "Load OSM File" tool, the data that is added to ArcMap is "everything". Think of "everything" as the sort of JOSM x-ray view of the data, you see the nodes, ways, and relations as they are. Which is good and bad. It is good in the sense that you see all of the elements but bad because you see everything and it is hard to distinguish between nodes with attributes and supporting nodes that only exist because they are part of a way. Those supporting nodes shouldn't really be of interest to you as they are "only" a vertex in a higher order geometry as in a line or in a polygon. The same can be true for lines and polygons and even relations (think super-relations) as well. 

At this point we are getting into a little data management dilemma as our tools are offering read/write functionality. As mentioned before you don't really care about the vertex, your interest is the line itself. However if you move the vertex the tools need to submit the full information of the node (vertex) back to the OSM server and at that point we do very much care about all the metadata like user id, etc. As a result of that dichotomy the import routine assign an attribute of "osmSupportingElement" to everything where it makes a best guess on the fact if feature is of interest to the user or not. 

For all of your above relations try the following. Once you have the polygon layer assign a definition query of "osmSupportingElement" = 'no' and for most of your cases you should only have 1 feature (the relation itself) left in the display. Once you have the definition query applied you'll see that relation 70884 is properly cut. This is the way the symbolization models work that are part of the OpenStreetMap toolbox - they are applying definition queries and they are creating multiple views into the three feature classes.

Let us know what you think,


Feb 8, 2012 at 9:18 PM


this has been an instructive lesson.

I did not recognize that osmSupportingElement is exactly the flag I was asking for. Knowing this, and knowing that the first bug will be fixed soon, I think it will finally be easy for me/us to use OSM data in ArcGIS.

I think you did not get my point regarding relation 70884. This has eight inner ways - three are inside the outers (isles/holes), one touches at one node, one crosses the outer, and three touch the outer on more than one adjacent nodes. The last three are not cut from the polygon feature. This is, I hope, a rather unique case.

Again thank you very much for the support,