Search for Flüelapass doesn't find pass road

Search for “Flüelapass” only lists the “col” and countless segments (50?), but not

How can we improve this? Which modules need to be fixed?

1 Like

The search results look okay to me. If you search for “Flüelapass” you get the pass not a road. Entirely expected.

That said, this relation needs to be fixed. It doesn’t describe the pass, so the name is clearly wrong and the Wikipedia link and Wikidata number refer to the wrong articles.

Open issue for including route relations into Nominatim is here.

3 Likes

What do you think is wrong about the relation? Should it be renamed to “Flüelapassstrasse” or its equivalent in Romansh?

I’m not sure about the Wikidata/Wikipedia links, but they don’t appear to be about something entirely different.

We still need to find the pass road when searching. The pass road is what’s between two starting points, not the 50 segments listed instead. Why would they be relevant?

Possibly, there are needed fixes in Nominatim for other things, but we need to make sure this works correctly for this search here.

The solution for Nominatim appears to be change the type to “waterway” and then it works. Alternatively, to create a new type “mountain_pass” and defined that in Nominatim at the same place as “waterway”.

ATYL doesn’t meant that any tool will automatically support the TYL. In this case you are asking support for a tag that has been used worldwide 11 times with no community consensus that it is even a good thing.

You need to realise that other people in the OSM community are not your employees and are not going to jump just because you have a “good idea”.

2 Likes

The question remains why the community should think that listing 50 segments instead is a good thing.

It doesn’t really matter which type is used, as long as it’s in the config. Apparently some are, others not. We just need to pick one that is. I guess some of us realize that this isn’t at all what millions you mentioned before should have been spent for.

@SimonPoole if you don’t want to help analyze or resolve the issue, I don’t really see why you post in this thread. If you need more info about mountain pass roads, feel free to ask.

Depending on what you’re actually looking for, Nominatim simply may not be the best way to do that. If I was searching for something like “pub near durham” then I’d absolutely use Nominatim - in answering that query it’s guessed one of the many Durhams that I might be asking about, and realised that “pub” is a type of thing not a name of a thing, and that in OSM bar is a pretty similar type of thing.

However, if I was searching for “objects named X” I would instead use something like taginfo (perhaps even looking for only exactly that value) and then maybe even overpass to look explicitly for a relation.

It’s true that OpenStreetMap without that relation suggests that each part is a different road. So the comparison with pubs is understandable. The reality on the ground is a different one.

No, it really doesn’t.

It suggests that different objects in OSM are associated with the thing that you call “a road”. That’s entirely as expected, because they differ in tags or other relation membership. There are numerous ways to handle things like this as one, such as this.

3 Likes

To work with your pub comparison, it’s as if you would spilt each pub in 5:

  • 1 way for the entrance
  • 1 way for each of 3 bar sections
  • 1 way for the exit

Or would it be 3 entrances/exits and 3 bar sections? Thus 6.

So if we split pubs this way, there would be five or six results .. what is your solution for that?

If you do a simple split:

  • entrance
  • bar
  • exit
    You would have three ways, but you would need each time all three of them. Also, 1 without the 2 others were pointless, even if they share the name of the same pub.

The waterway comparison appears much suitable, searching for “Rhine” find the entire river and no longer places it at Chur (as mentioned in the Nominatim ticket )

In case one didn’t notice: pass roads are a thing in the real world ..