0

I want to query the Overpass Api to find out the distance of special relations (railways). The request is fine, and returns me all relation, way and node objects I'm interested in. Example for Hamburg:

[out:json];(rel(53.55224324163863, 10.006766589408304, 53.55314275836137, 10.008081410591696)["route"="train"];>;);out body;

In Overpass, each relation object has members defining this relation. For way objects you can resolve the lat/lon of its node attributes and calculate the distance for that way. If you sum up all the way distances it seems to be reasonable.

However, there are members from that relation of the type node (most of the time, they have a role of "stop") which seem to represent the right order of stops from that relation. But instead being in between the members, they are roughly at the end. If I try to look the stops up inside the ways, they are not all present. How am I supposed to calculate the distance between two particular stops?

Rafael T
  • 15,401
  • 15
  • 83
  • 144

1 Answers1

1

There seems to be a misconception about relations. Relation members don't necessarily have to be sorted. Consequently you might have to sort the members yourself, if necessary at all.

You can take a look at JOSM which has a neat sorting algorithm for various types of relations. But I don't think it is able to place members with the role stop at the correct position. This isn't always possible because a way doesn't necessarily have to be split at each node with the stop role. This also means a single way can contain more than one node with a stop role, making it impossible to sort the relation members correctly. Unless you do some pre-processing for splitting each way accordingly.

For calculating the distance between each stop it seems unnecessary to sort the elements. Just follow the way by iterating over all each nodes and check for each node if it has a stop role in the corresponding relation. When reaching the end of the way continue with the one which shares the same node at its start or end and which is also member of the relation.

scai
  • 20,297
  • 4
  • 56
  • 72
  • if the ways are not ordered either, It will be very hard to iterate over them. How am I supposed to find the first way member to start iteration? – Rafael T Nov 05 '14 at 22:59
  • The first (or last) way is the one whose first (or last) node is not shared with any other way. Also do note that consecutive ways can have different directions, i.e. the last node of a way can be either the first *or* the last node of the subsequent way. If you have problems understanding the data model you might want to take a look at the map data directly using one of the [editors](https://wiki.openstreetmap.org/wiki/Editors#Top_three_editors). – scai Nov 06 '14 at 07:47
  • my last trys shows, that you are not right with finding out the first way member. I spend like 3 hours to debug my code, only to find out, that there are sometimes missing links, meaning that there is no matching start or end node for more than one way... – Rafael T Nov 07 '14 at 05:15
  • Of course, you can't expect relations (or data in general) to be always correct. OSM data changes constantly which in turn leads sometimes to some minor errors appearing and disappearing again. This would also be true for data from other sources. – scai Nov 07 '14 at 07:50
  • I don't excpect it to be correct or very precise. I just wanted to find a method to sort the `way` elements of a `relation`. If they come not sorted (which is what I expected because of the List return-type instead of a dict which is unordered by default refereing to JSON data-structures), and there are several ways which do have no matching end (or start) node, the only way I see is to try to parse the `name` Tags of that relation, find the matching stop and see which way is closest to that point. – Rafael T Nov 11 '14 at 01:51
  • Can you give us an example of such a relation? The relation ID would be fine. – scai Nov 11 '14 at 07:44
  • in example relation(1304744). there is a 27 kilometer gap at way 191079938, 0.5km at 135863150 and 0.35km at 28679354... Or relation(1788865) which has 4 open ends. However I found out, that they are ordered most of the time, so just looking up their directions will be fine mostly.... – Rafael T Nov 11 '14 at 08:12
  • 1
    Way 191079938 is not connected to the rest of the route, that's correct. I cannot see a gap at way 28679354. And way 135863150 is a special case, look at this section: http://www.openstreetmap.org/relation/1304744#map=15/54.0724/12.1453 One of the adjacent ways must be used twice. Yes, that's not always easy :). And relation 1788865 is broken at some parts and must be fixed, that's correct. – scai Nov 11 '14 at 09:16