[Overpass] Is this a bug? My query returns a few ways with reversed orientation

[slopez-Tfe (Samuel)]

Hi!

I’m learning Overpass QL and just noticed a strange behavior from the Overpass API. I think it is probably a bug, but maybe I’m doing something wrong?

I’m running the following simple query, which tries to download all nodes, ways and relations from a train route, a relation with the name “S8: Wiesbaden => Mainz Hbf => Hanau” I. My intention is to use the data to recreate and plot the tracks on my computer.

// Query settings
[out:json][timeout:25];

// Get the relation that interests us
relation["name"="S8: Wiesbaden => Mainz Hbf => Hanau"];

// Recurse down and get all info from all members and sub-members
>> -> .s8_all;

// Filter out all members outside of bbox
nwr.s8_all(49.987325, 8.237257, 50.035367, 8.318367) -> .s8_bbox;

// Return all details
.s8_bbox out;

In Overpass Turbo, I export the data as JSON (“raw OSM data”) and plot the route in my computer.

Then I notice the following problem:

This is what the overpass turbo website shows: https://overpass-turbo.eu/s/1Trc

This is what my own plot shows, based on the exported data:

See those blue lines jumping out of the tracks? They shouldn’t be there.

I’ve dived into the data to see what the problem is, and found the following:

• The jumping lines originate at node 571665114.
• That particular node is the edge node between two ways: way 45087986 (North of the node) and way 172430977 (South of the node).
• In the JSON export, edge nodes typically appear as the last node of one way and the first element of the next. However, this node appears as the last node of both ways:

{
  "type": "way",
  "id": 45087986,
  "nodes": [
    571665104,
    2206001213,
    571665114
  ],
}

{
  "type": "way",
  "id": 172430977,
  "nodes": [
    1833363809,
    5200797311,
    3994516701,
    11592724831,
    11295780887,
    3946270847,
    1833363813,
    3946270846,
    1833363817,
    3946270848,
    571665114
  ],
}

• Upon further inspection, I realize that way 172430977 has its orientation reversed. Thus, when plotting, the blue line follows 45087986 southwards until its last node. Then it continues to the first listed node of 172430977, which corresponds to its southern end, creating the first visible jump in the plot. It then goes back along 172430977, and once it reached the northern edge, it jumps to the first node of the next way, creating the second visible jump.

All ways in the data export are orientated in the correct way, except 172430977 and a few more down the line. However, there are no jumps visible in Overpass Turbo.

I don’t understand why a few of the ways have their orientation reversed. Could this be a bug from the API? Or is there something subtly wrong with my query?

Other things I have tried that yield the same problem in the JSON export:

• Use OSMPythonTools instead of Overpass Turbo. If it’s a bug, it’s not in Overpass Turbo.
• In the query, used >> instead of nwr.s8_all(49.987325, 8.237257, 50.035367, 8.318367)

[Jofban]

You can use ID to see the direction of the way (indicated via small arrows): OpenStreetMap
The way is mapped in reverse, Overpass is correct. Thus every tool will produce the same result.

Someone mapped it in this way regardless of actual use. You can sometimes see this with double-tracked railways, where both are mapped in the same direction. E.g. here: OpenStreetMap (Part of S2 between Offenbach-Bieber and Heusenstamm)

The mapped direction affects certain properties like *:left, *:right, *:forward, and *:backward. It does not constrain services or which direction traffic can flow, unless oneway is specified.

The “bug” is on your side, you will have to teach your tool to deal with such sections, e.g. by comparing nodes. If you hit any single-track railway with use in both directions (e.g. Way: ‪Südmainische S-Bahn‬ (‪24795769‬) | OpenStreetMap), you’ll otherwise have trouble mapping both.

[DaveF]

Unsure of your final requirements but you seem to be importing the ways in your JSON to your program as a polyline. If you treat them as individual lines, the orientation is irrelevant. Is that good enough for your purposes?

And as you say you are plotting tracks, do you explicitly require all the 23 returned relations? If not:

1. Try removing one of the ‘>’ to return just the ways
2. or try this:

[out:json];
rel[“name”=“S8: Wiesbaden => Mainz Hbf => Hanau”];
way(r)(49.987325, 8.237257, 50.035367, 8.318367);
out geom;

[slopez-Tfe (Samuel)]

Thank you @Jofban and thank you @DaveF! Especially for your incredibly fast reaction!

@Jofban: Thanks for this insight. I hadn’t realized that some ways could be mapped in different directions, but of course, now everything makes sense.

Ok, so I should check the direction of the nodes in adjacent ways… What about relations of type route - Are their member ways ordered?

In other words, in the members property of a relation with type=route, if two ways with role = "" appear next to each other as in the picture below, can I assume that they are adjacent, or should I check that, too?

@DaveF Thanks for the idea! Yes, you are right - For plotting I could just plot each way individually and I’d get the desired result. The reason that I’m importing them as a poly-line (actually, what I’m doing is concatenating all the nodes from the relation’s beginning until the end into a single, long line) is that after plotting I want to be able to e.g. compute a length, or select an arbitrary subsection of the route.

Also thanks for sharing the more concise version of the query. You are right that I don’t need all relations right away, I’ll look into simplifying it!

[DaveF]

[out:json];
rel[“name”=“S8: Wiesbaden => Mainz Hbf => Hanau”];
out geom(49.987325, 8.237257, 50.035367, 8.318367);

Also, do a search for ‘JOSM relation sort’ which may help in simplifying the concatenating of the nodes.

[Jofban]

No problem! Always happy to help people interested in OSM.

@slopez-Tfe

What about relations of type route - Are their member ways ordered?

They are usually ordered, but depending on circumstance, they might not be. See also Relation:route - OpenStreetMap Wiki. If they are unordered, that’s bad data, so you can fix that in OSM.
It can make sense to do a sanity check to find potential issues.