Overpass Route Coordinates Wrong Order?

Hello,
I am working on a solution for displaying public transport routes and am using Overpass.

I would like to extract the coordinates of each route from a particular transport operator and store them in an array list according to direction/variation, and display this in my frontend.

For this, I initially used the following query:

[out:json][timeout:25];
rel["operator"="Operator"];
out body;
>;
out skel qt;

Unfortunately, this query also gives the coordinates of the platforms along with the bus stops and route coordinates, so I switched to the following query:

[out:json][timeout:25];
rel["operator"="Operator"]->.route;
(
  way(r.route)[highway!="platform"][public_transport!="platform"];
  node(r.route)["public_transport"="stop_position"];
);
out body;
>;
out skel qt;

This essentially provides all the data I need. (Information about the route, route coordinates, bus stop coordinates, variations)

For the most part, this looks nice and the route is displayed perfect.

However, I also have some routes where the order of the coordinates does not seem to be correct:


I can only imagine that the order of the coordinates is incorrect, or that some way coordinates are reversed in the list I get from Overpass. But how do I recognize this?

Additionally, I have noticed that each roundabout looks like a whole circle.
Here, I suspect that Overpass returns the entire roundabout as a way, which is why it is displayed this way. Is there an alternative solution for this?

Ultimately, I just want a list of coordinates for a route/direction and display them in my frontend. Using Google Maps, I want to determine distances/durations/… , but this is not possible if I can’t get the coordinates in the correct order or if I get the entire ring for roundabouts instead of the actual entrance and exit.

I appreciate any help!

Could you provide an Overpass Turbo URL specific to the area you wish to search.

Roundabouts mapped as a single way should be split so route relations can be accurately added.

You should check if the routes are actually correctly ordered in the original OSM data, likely they are not (adding a whole/unsplit roundabout is legit tagging, consider it a node/vertex).

Now the bummer: in the general case it isn’t possible to automatically order the route segments, so if things are wrong, you are going to have to fix them manually.

2 Likes

In this array

      "geometry": {
        "type": "MultiLineString",
        "coordinates": [

I can not see which array is the roundabout

But you say, when i take the coordinates from the ways ther are two arrays saved? How can i search for them in the json?

I have compared the order of my list and the list in the OSM data using an AI, and they are the same. Hence, I would say the order I am receiving is already incorrect. This doesn’t become apparent in Overpass as the visualization likely only shows the ways and doesn’t display them as a route according to their order. Is that clearly formulated?

I still hope that it’s an issue with the query…

I’ve no idea what you just sent through.
Provide your full & complete code in a OP Turbo URL.
It’s not up to others to spend their time deciphering what you might have done.

rel["operator"="Operator"]-;

This returns nothing.

In general it is a lot easier to help when people are specific about the areas they are working. I see Winkhausen on the map, so are you looking at MĂĽlheim an der Ruhr? Which bus line specifically is giving that shape?

2 Likes

OK, so I’m guessing that the line is one of these:

These seem alright in OSM, at least as far as all the ways appear to be in the correct order.

Querying with Overpass seems fine in Overpass visualization, for example NE1: http://overpass-turbo.eu/s/24gM

[out:json][timeout:25];
rel["operator"="Ruhrbahn"]["ref"="NE1"]["from"="MĂĽlheim Stadtmitte"]->.route;
(
  way(r.route)[highway!="platform"][public_transport!="platform"];
  node(r.route)["public_transport"="stop_position"];
);
out body;
>;
out skel qt;

One thing I notice is that NE1 and NE3 are loop lines, so they traverse some of the same ways twice. But the ways seem sorted correctly in OSM.

So I’m wondering if it’s a problem with your visualization code? Can you share it please?

1 Like

Even if these are correct, you can’t assume that all route relations in OSM have the correct order. If you want to have a generic solution that works for other relations as well, you need to be able to handle out-of-order route relations.

1 Like

Sorry, I did not understand what you meant.
Here is the Query:

[out:json][timeout:25];
rel["ref"="NE1"]["name"="Bus NE1↻.: Stadtmitte => Stadtmitte"]->.route;
(
  way(r.route)[highway!="platform"][public_transport!="platform"];
  node(r.route)["public_transport"="stop_position"];
);
out body;
>;
out skel qt;

I apologize for the inconvenience.

The query is:

[out:json][timeout:25];
rel["ref"="NE1"]["name"="Bus NE1↻.: Stadtmitte => Stadtmitte"]->.route;
(
  way(r.route)[highway!="platform"][public_transport!="platform"];
  node(r.route)["public_transport"="stop_position"];
);
out body;
>;
out skel qt;

For visualization, I just provide a list of coordinates to the Google Maps API and let it render.

So if the order is correct, my code for generating that list needs to be improved. Have you noticed, if the route traverses some of the same ways twice, is the way also listed twice in the JSON?

I have not seen some of these, can you explain what they are? Parts of the route that are temporary out-of-order?

What exactly are you providing to Google Maps? The Overpass output first lists the stop positions, then the ways that make up the route, then the nodes of those ways. Are you sending all of those to Google in that order? Could there be an issue with all the stop positions being at the start, separate from other nodes?

They can be unsorted, or sorted in wrong order, from software defect, or user mistake. Applications should not assume they are always sorted correctly. Relation:route - OpenStreetMap Wiki

3 Likes

Hm, I haven’t done much work with Google Maps API so I can’t really comment.

Here’s what I did that worked:

  1. Run the query you’ve shared on https://overpass-turbo.eu/
  2. Used the “Export” button in top left and then copied the data as GeoJSON (first option from top in the dialog that appears)
  3. Pasted that GeoJSON into https://geojson.io/ to visualize it and got the following:

So it seems like data is there, it’s returned by Overpass correctly, and it’s a problem somewhere in your visualization layer.

As far as I can tell, it doesn’t show up twice in the Overpass JSON response. For an example you can search the JSON for way 30108650 (Way: ‪Eppinghofer Straße‬ (‪30108650‬) | OpenStreetMap) which is traversed by NE1 twice. The Overpass JSON response contains it only once, and so does the GeoJSON-format export.

1 Like

No, I just put the coordinates of a separate route in a list and send that to Google Maps, along with the stops.

However, I think I’m starting to see the problem. My bug occurs when a part of a route is traversed twice. In the GeoJSON, this segment is listed only once, but with Google Maps logic, it needs to be provided twice. This is because the API uses the coordinates to generate the route, rather than just displaying the lines.

So, if I have route parts 1, 2, and 3, and part 2 will be traversed twice, I shouldn’t send coordinates like [{1}, {2}, {3}]. Instead, I need them to be something like [{1}, {2}, {2 reversed}, {3}].

yes for that case i want to add a check if the first or the last coord of an way is next to the following coord of a way so that some cases of wrong order can be fixed

That helped a lot.
With your comment i came to a point that think I’m starting to see the problem. My bug occurs when a part of a route is traversed twice. In the GeoJSON, this segment is listed only once, but with Google Maps logic, it needs to be provided twice. This is because the API uses the coordinates to generate the route, rather than just displaying the lines.

So, if I have route parts 1, 2, and 3, and part 2 will be traversed twice, I shouldn’t send coordinates like [{1}, {2}, {3}]. Instead, I need them to be something like [{1}, {2}, {2 reversed}, {3}].

Also I have seen, that I often see in my frontend that at A → B the route is shown correctly but B->A…when I than look at B->A ist is right.
But I would say that is not a impl bug on my side, the direction is simply not provided from overpass i would say…

You’re asking overpass for the set of all ways that are members of the route relation and that’s what it’s giving you.
If you need them to be ordered and non-deduplicated you need to look at the member list of the relation itself.

1 Like

How would the query look for example?

Also would it fix the problem that i need the ways that are traversed twice also twice in the list? And I also need a solution, that the direction is not in the right.

So, if I have route parts 1, 2, and 3, and part 2 will be traversed twice, I shouldn’t send coordinates like [{1}, {2}, {3}]. Instead, I need them to be something like [{1}, {2}, {2 reversed}, {3}].

Also I have seen, that I often see in my frontend that at A → B the route is shown correctly but B->A…when I than look at B->A ist is right.