OpenStreetMap Nominatim

Why does a search for “Gamsspitzl” not yield this result: Node: ‪Gamsspitzl‬ (‪337853401‬) | OpenStreetMap

Thank you!

1 Like

Is it correct, that there is a second “Gamsspitzl” only 7,06 km away?
This could irritate the search.

I don’t know. I can check a printed map later.

Should this really be a problem? What if both are legit?

In my area there are several peaks called “Hirschberg” in relatively close proximity. That doesn’t seem to cause a problem.

I don’t have the relevant sheet of the Alpenvereinskarte here. Basemap.at, however, shows both of those Gamsspitzl. So that might be correct.

Is there anything one can do to help Nominatim to overcome its confusion?

Looking at the debug output at nominatim.openstreetmap.org it looks like the node is found initially and filtered out towards the end.

1 Like

Ich kann das Problem nicht nachvollziehen:
grafik

you need to look at the node ID. it is missing in the result.

1 Like

The problem seems to be the importance-value:

Places:  1395369 => 'osm_type' => 'N'
                    'osm_id' => 337853401
                    'class' => 'natural'
                    'type' => 'peak'
                    ...
                    'langaddress' => 'Gamsspitzl, Krimml, Bezirk Zell am See, Salzburg, 5743, Österreich'
                    'placename' => 'Gamsspitzl'
                    'ref' => 'Gamsspitzl'
                    'lon' => '12.2688049'
                    'lat' => '47.0993844'
                    'importance' => 0

I would expect that a search result with an importance of zero will be filtered out.
But what is the cause of this value? I don’t know.

I am not so sure about that. The hotel (‘osm_id’ => 893970955) also has an importance of zero at first but is not filtered out.

Also, all importance values change to non-zero in the pre-filter results.

This is a simple case of deduplication. Both mountain peaks come out with exactly the same name and address, so Nominatim files them under duplicates and throws one of them out. Undeduplicated result: Nominatim Demo

Please check in the field if there are really two mountain peaks with exactly the same name in exactly the same valley. If, so Nominatim will have to be fixed. If not, simply fix the data.

5 Likes

I believe that the data is probably correct. Both of these peaks are shown in the official Austrian geodata. Mountain names are often not very original. There are dozens of Gamsspitzl, Gamsspitze, Gamsspitz, Gamskarspitze etc.

The two peaks have an elevation difference of 350 m. I think that Nominatim really should not consider those duplicates.

The tagging already indicates that the source of data was basemap.at, so it’s no surprise that basemap.at agrees. That’s why I was asking to check with the locals. I don’t expect names for mountain peaks to be very original but I would expect peaks to be named differently within the same valley. If they are the same, it would be interesting to know (and very relevant for geocoding), how they keep them apart.

Also, the peaks derived from basemap.at are oddly out of line with the altitude profile in the area: OpenTopoMap - Topographische Karten aus OpenStreetMap That doesn’t necessarily mean they are wrong but is a strong incentive to look for a second source.

5 Likes

I’ve checked it with a few other maps (BEV ÖK50, Alpenverein, Kompass) and the names indeed seem to be the same.

At first glance it looks like the one with ele 2.888 near Krimmler Törl is called “Gamsspitz” without the trailing “l” on ÖK50, but this seems to be some rendering issue, as you still can see the outline of the “l” and it’s also shown on the guideposts:

1 Like

The Gamsspitzl 2359 as seen from the Krimmler Tauernhaus. It is a very minor peak barely noticeable on the arete down from the Schlachtertauern - https://www.on-tour.at/touren/krimmler_wasserfaelle/data82/images/krimmler_tauernhaus.jpg - SRTM Contour lines just do not capture that. The other Gamsspitzl 2888, even tough just as minor, is featured in lots of accounts.

Nomintim could use summit:cross (could be added to the 2888 one) or Wikidata present to dedupe the other instead?

As the name itself sounds plausible and will be hard to find witness, it does not exist: Most easy perhaps, dedupe in mapping, make “Gamsspitzl (Achental)” the northern one, like they do here Salzburgwiki:Projekt Salzburger Berge – Salzburgwiki ?

Gerade noch einmal den abgebildeten Wegweiserbaum angeschaut, da sind tatsächlich auch ein paar “Alpine Routen” ausgewiesen, d.h. die Ziele sind nur weglos erreichbar :slight_smile:

This is how open source and community projects always bring you to doing things that you never intended to do :slightly_smiling_face:.

I have sent a mail to the friendly people at Krimmler Tauernhaus. It is run by the Geisler family since 1906 and they can surely be regarded as experts of the area. Mr. Geisler responds:

Im hinteren Krimmler Achental in der Venedigergruppe gibt es das Gamsspitzl 2888. Im Bereich Schlachtertauern (richtig Schachtertauern) heisst der Berg Gamsspitz ist ein markanter Felssporn.

Consequently, I will rename the 2539 m peak to Gamsspitz.

Also, from a personal visit on a bad weather day in 2010, I can confirm summit:cross=yes for the 2888 m summit and will add that.

Still, I would consider it a bug that Nominatim deduplicates two peaks of significantly different height and seven kilometers away from each other.

3 Likes

Okay, that make sense. “Gamsspitz” and “Gamsspitzl” would make a huge difference for the locals. It just adds to the fun that the printed maps do have the difference, but the wrong way around. It effectively means that both names should return both peaks.

I need to ponder a bit on how to make the non-deduplication work here. It should be a criterion that is as generic as possible. ele might work. Added to Nominatim’s todo list: Be less strict with deduplication of mountain peaks · Issue #2917 · osm-search/Nominatim · GitHub

3 Likes

I have already intended for a while to report that Nominatim does not find names ending in -spitz when searching for -spitze and vice versa. However, for many mountains, there does not seem to be one single “true” name in terms of -spitz/-spitze. It is a matter of local dialects as well as of the development of the language over time.

One could and maybe should add the respective other variant as an alternative name everywhere.

I believe that Nominatim should be able to find both variants in any case. According to my extremely superficial understanding of Nominatim, this might be achievable by tokenizing -spitz and -spitze (and maybe also -spitzl) the same way. It is my impression that -spitze is already shortened to -sp here. Would it be sufficient to add lines for -spitz and -spitzl there?

I’d add “Gamsspitzl” as “official_name” to the one near Tauernhaus, as that is what the BEV has on book. UPDATE: Und “Schlachtertauern” ebenso.

Spitze, Spitz or Spitzl indeed should not make much of a difference for a search engine. I’d expect several locals giving any of them, when asked. Ideally this should be taken care of when stemming, but there are people here who know their stuff much better than I do :slight_smile:

I’m happy to see you found the variant stuff. Indeed, it would solve the problem. In theory…

<technical rant>
The variants were rather meant for abbreviations. In this particular case, we’d need a rule like:

~spitze,~spitz,~spitzl => spitze,spitz,spitzl

That rule means that any of these terms can be replaced by any other. Rules like this (with many terms on the right side) cause a bit of a bloat in Nominatims table of search terms, which can make search queries a lot slower. I’m planning to look into that problem as part of the frontend rewrite.
</technical rant>

In practice, a mechanism that is better adapted to such spelling variants would be good.

3 Likes