Why does searching for "HWN 124" not work?

Help and support
1

Dear community,
I used to plan trips along the “Harzer Wandernadel Stempelstellen” (Relation: ‪HWN Stempelstellen‬ (‪148007‬) | OpenStreetMap) for years and always could find the according POIs by searching “HWN ”, e.g. “HWN 124”. If you look at Node: ‪HWN 124 - Köte am Heidestieg‬ (‪460479333‬) | OpenStreetMap, you will find this string as ref, as well as beginning of the name, yet I end up in San Juan with this search.
Any ideas why this does not work anymore?
Thanks!

2

For an OSM object to be searchable in the the search engine Nominatim it needs to have a known main tag. tourism=yes doesn’t work for that because it looks more like an attribute than a main tag. The wiki page for checkpoints suggests using tourism=checkpoint. That would be recognised.

2 Likes
3

Also relevant: Relations are not categories - OpenStreetMap Wiki

2 Likes
4

Hi @King_Danyo and welcome here,

I can’t tell you what changes in Nominatim are responsible for that.
But maybe you want to use overpass-turbo instead like

[out:json][timeout:25];
// gather results
node["checkpoint"="hiking"]["ref"~"HWN 124|HWN 087"]({{bbox}});
// print results
out geom;

Currently you have to try several times until it works because of heavy load :-(

2 Likes
5

… or use Postpass as the backend.

{{data:sql,server=https://postpass.geofabrik.de/api/0.2/}}
SELECT osm_id, tags, geom 
FROM postpass_pointlinepolygon
WHERE tags->>'checkpoint' = 'hiking'
AND tags->>'ref' like 'HWN%'
AND geom && {{bbox}}

The linked overpass query covers your area. You can change like 'HWN%' to whatever you desire.

Obviously this isn’t a “solution” for the problems affecting public overpass servers, but it’ll work until the muppets abusing overpass discover the next target :slight_smile: .

2 Likes
6

Alright, thanks for your inputs! I could search for this in the past, so I assume something has changed. I might give it a try with the tagging your proposed, even though I admittedly would have to dig into the documentation a bit to mess up things.

7

Thanks for this proposal, I played with Overpass Turbo together with a friend yesterday. My actual main issue is having the POIs available in other tools like komoot, which are obviously based on the OSM information for this. So alternative tools do not solve my actual problem. :slight_smile:

1 Like
8

There was (or better is) a discussion about that in the German Forum:

Edit:

This too: :grinning_face_with_smiling_eyes:

9

Specifically with regard to Komoot, I suspect that you may struggle. Last year they sold out to different owners.

Taginfo suggests that you’re grand with Osmand, though.

Edit: Actually, if “online” is good enough something like uMap would be very simple to set up!

1 Like
10

Example:

1 Like
11

Tested it for HWN 124, with that simple change it now appears in the search results.

12

This is what the new owners like to do to companies they acquire btw.: Vimeo Lays Off Staff Following $1.38 Billion Sale to Bending Spoons - Business Insider

13

Don’t like this at all. However have been using it for years, have some history there, bought the world package a while back etc., so would still like it to work.

14

So tourism=checkpoint instead of tourism=yes was the actual solution! This shows, that the other HWN-checkpoints should also be changed the same way.

Off topic: I don’t understand, why the search found San Juan, Puerto Rico.
Does Nominatim read this as “San HuWaN” :speak_no_evil_monkey:

As long as the other HWN-checkpoints are not updated, similar searches still go this way:
HWN 123, HWN 125, etc.

EDIT: I added an Overpass-Turbo Query to display the tourism=* tags of HWN-Stempelstellen:

HWN-tourism-tags
HWN-tourism-tags1391×396 85.8 KB

2 Likes
15

The hebrew version ‘סן חואן’ transliterates to “sn hwn”.