conversion of route relations

Aug 20, 2012 at 3:18 PM


I am using the load-Tool to convert raw osm-xml-data for toplogy analysis concerning foot, bike and car routing. I am wondering how route relations are treated during conversion. for Example, a route=bicycle relation is converted into several lines with the attributes of the relation. Even the OSMID of all those Linie objekts is identical. In comprisson to the OSM database, the original tags of the member way-Objects are ignored and are getting lost. Am I right with this assumption?

I use OSM-Editor version 2.0.67.

best regards


Aug 22, 2012 at 9:49 PM

Hi Tilo,

The route relations are processed by adding a new line (overlapping the existing line from the way) tagged with the relations tags.  If the route has multiple member ways, the line feature will be a multipart polyline containing all of the way geometries as parts.  This is why you see what appears to be the same attributes for a bunch of lines - they are actually one multipart feature.  

So what you're seeing is correct except that you should also see the existing line with its tags and attributes below the new one.  You can freely edit the tags on either line to update the route or underlying way.

There is an issue if your route has mixed member types (i.e. the route relation is related to both nodes and ways).  In this case the route is left as a record in the relation table and cannot be displayed on the map.  We are working on a resolution to this issue as part of our network dataset creation feature in the upcoming version.


Aug 23, 2012 at 9:36 AM

Hi Greg,

thanks for the answer.

Yes, I see the multipart polyline with the attributes (IDs) of the relation, but unfortunately not the underlying way-object.  i.e. I found the Problem, that the bicycle relation linie was present and the member way, which was originally tagged with highway=residential was missing. This causes serious problems in carrouting. Might this be a version related problem (version 2.0.67). Unfortunately updating wont help, because I already converted all data needed (more than 20 GB) and don't have the time to do it again. If you want to check it out, here a small extent, where the relation "name=Radwegenetz Bad Soden" is present and the street (way) "name=Kronthaler Straße" is missing (bbox=8.48874,50.15366,8.50767,50.16223).


Aug 23, 2012 at 10:44 PM


the line should still exist - however it might have its attribute set to be a supporting element. If the definition query is set this way then the way  (Kronthaler Strasse) might not show in the attribute table and it appears to be missing.

I guessing at this point I'll check when I get back into the office next week.

- Thomas


Aug 24, 2012 at 2:27 AM

Hi Thomas,

thanks for the guess.

If you are right and in this case the way object's attribute supportingelement is set to yes, its no wonder it doesnt appear in my dataset, because all sup.elements are deleted by my script directly after conversion. Then the Question would be, why a relation is treated with priority to a way object even if the attributes of the way  mean a more general usage of the way. 


Aug 24, 2012 at 4:22 PM


this behavior originates from multi-part polygons mostly. The original premise was to provide a "clean" data view - where no overlapping features exist.

Your approach of deleting supporting elements should only apply to point features. For lines or polygons you can't really tell -- well, you could open the Blob attribute field in Python and check if it contains relevant tags.

The handling of routes within the OSM Editor is not yet 100% defined with respect to transparency to the user. As always the premise is that no data gets lost or dropped.

We could consider leaving the supporting element attribute as 'no' if the way has relevant attributes.

- Thomas

Sep 25, 2012 at 2:55 PM


Thanks for the answer!

after my first disappointment, that this behaviour caused some trouble, I think you should not make exceptions for this attribute for lines or polygons. I think the behaviour to set it to "no" if the object is part of a higher object is easy to understand and lets anyone use this attribute without having to consider a list of exceptions...