Proposal , pilgrimage=stamp_office and network=pilgrim

General talk
1

Hi ! While working on support for pilgrimage routes (Gudbrandsdalsleden, St. Olavsleden, Kystpilegrimsleden, Tunsbergleden, and others), I’ve found a specific data issue in OSM that you folks might be interested in looking into, or perhaps you know someone in the broader tagging community who is working on it.

The problem: pilgrim centers—the places where you get your pilgrim passport (Pilegrimspass/credencial) stamped—currently lack consistent tagging. I’ve checked well-known centers such as the Oslo Pilgrim Center, Granavollen, Hamar, Dale-Gudbrand, Dovrefjell, Stiklestad, Avaldsnes, Bergen, and Smøla (regional centers), and found a mix of:

- tourism=information + information=office (without any pilgrim-specific sub-tags)

- simply building=office

- simply guideposts

- (internationally, e.g., the Camino) office=company

Without a stable, unambiguous tag, it is not possible to build a reliable searchable category for this—a name-based search would mostly return guideposts, and including all `information=office` entries would bring up general tourist offices.

Proposed tagging convention I would like to see considered:

1. For the pilgrimage center/stamp office itself: tourism=information +

information=office, plus a new or more consistently used sub-tag, such as network=pilgrim or pilgrimage=stamp_office, as well as operator=. This makes it possible to filter precisely without including regular tourist offices.

  1. For pilgrim-related accommodations (hostels, youth hostels associated
    with a route): a corresponding network=<route_name> tag on
    tourism=hostel/guest_house nodes, in the same way that DNT cabins
    are already tagged with network affiliation in Norway. This makes
    pilgrim accommodations distinguishable from ordinary accommodations without
    relying on the name text.
2

Related:

1 Like
3

In the past I used this tag:

As Wiki:

A stamping point to obtain evidence of visit by using a stamp booklet

p.s. there’s something happening with your text formatting that makes it unnecessarily more difficult to read, with lots of line breaks.

1 Like
4

Fixed.
PS: I have done some small edits for those in Norway.

5

I ended up tagging such stamp collection & information points like this Node: ‪Pamuk Hostel‬ (‪13506498478‬) | OpenStreetMap Here I added the tags on a separate node within the hotel building because tourism=checkpoint and tourism=guesthouse/hotel are in the same tourism key. When the checkpoint is not on a PoI in the tourism key, I added the tags to the PoI itself like Node: ‪Dionysos Lapis‬ (‪13478469874‬) | OpenStreetMap In both cases I added the checkpoints to the two stages of the hiking route that begin and end there with the “information” role.

6

Thanks for pointing to checkpoint:type=stamp/checkpoint=hiking/tourism=checkpoint. I looked at the 2011 proposal and I don’t think it actually closes the gap I raised, and it has a further problem I want to flag: a navigation app can’t do anything useful with this data as currently structured.

In my opinion, this is why:

  1. No structural link to the route. course=* (or name/ref as used on the German trail, per the recent thread here) is free text, not a reference to the route relation. An app following a GPX track or a route relation has no reliable way to associate a checkpoint=hiking node with this specific route versus any other trail passing nearby — it would have to fuzzy-match strings, which isn’t something you can ship in a routing engine. There was a suggestion years ago on the Key:checkpoint talk page to add role=checkpoint to members of a type=route/route=hiking relation — that at least gives a machine-readable membership link — but it’s not consistently applied and doesn’t seem to have gone anywhere..
  2. The tourism-key collision means incomplete coverage, not just messy tagging. As rhhs described, when the checkpoint sits inside a hotel, hostel, or café, mappers either drop the checkpoint tag to keep the venue’s primary tourism=* value, or split off a second synthetic node for it. Either way, an app querying checkpoint=hiking will systematically undercount real stamp points — that’s missing data by design of the tag scheme, not just inconsistent application.
  3. No rendering or preset support. tourism=checkpoint isn’t in openstreetmap-carto, iD’s default presets, or, as far as I can tell, any major consumer routing/navigation app (OsmAnd, Organic Maps, komoot etc ). Even where it’s applied correctly and completely, nothing surfaces it as “stamp point in 2km” — so from an app’s perspective, tagging it doesn’t get you anything.
  4. No pilgrimage semantics for an app to act on. What a Camino-specific app actually needs to know isn’t covered at all: whether a place can issue a credencial (not just stamp one), whether it counts toward the “two stamps per day” rule in the last 100km, or which network/branch it belongs to where routes overlap (Camino de Santiago crossing Camino del Cid in Burgos was literally raised as an unresolved case on that same talk page).

So I don’t think tourism=checkpoint + checkpoint=hiking + checkpoint:type=stamp is a substitute for what I was proposing — it’s a related but more generic schema that predates and doesn’t address the spesific pilgrimage-specific cases. If anything, I’d want my proposal to go further than a bare pilgrimage=stamp_office and also pin down (a) explicit route-relation membership instead of free-text course, and (b) a distinction between “can stamp” vs. “can issue credencial,” since both matter for an app trying to help a pilgrim plan a valid day’s stages.

7

If you peruse the thread I linked above, the suggested solution was to add the objects representing stamp offices (or rest points, or whatever) to the route=foot relation with a new role (checkpoint). In a similar situation, I (ab)used role stop for lack of a documented alternative.

Roles for nodes documented in Tag:route=foot#roles currently only include guidepost, route_marker and parking, none of them appropriate for the “checkpoint” semantics. And indeed, support between data consumers for those is slim to non-existent. (OSM website will only highlight node members when a relation is selected, regardless of their role).

So yes, I guess a proposal is called for, formal or informal.

1 Like
8

I hope someone does something with the proposal before next season sets in. A winter is a long time to get these implemented and in place.