"Unapprove" existing proposal or what about checkpoints?

First of all a bit of background.

We have a few almost equal types of tagging for security control checkpoints spanning across multiple top-level tags:

And …drums.. there is this cadaver which was “approved” by 10 people in 2011 Key:checkpoint - OpenStreetMap Wiki .

I do think checkpoint in terms of tourist stamps must not be a top-level tag of such general word. Seems like there were a few folks back in 2011 who raised this concern, but didn’t end up actually opposing the proposal unfortunately.

I feel like the proper scheme for tagging such would be something like checkpoint=police/military/yes, maybe even checkpoint=security_control/border_control (don’t treat it as any solid proposal, just some thoughts, as those all are still unified by a fact that they present some kind of barrier to pass thru and do some kind of checking, either physical (x-ray) or documents).

What do you all think, would it make sense to unify all real “checkpoints” and detach from touristic (non)-checkpoints?

@herrbert74 just in case, would be great to hear the comments from the original proposal author

1 Like

“touristic”
12178 x checkpoint = hiking

“security”:
7647 x military=checkpoint
4137 x police=checkpoint
494 x amenity=checkpoint (amenity?)
165 x amenity=security_control

29 x checkpoint = security
10 x checkpoint = police
7 x checkpoint = military

You need very good reasons to change the meaning of the “checkpoint” key. What is your solution for the touristic checkpoints?

2 Likes

Well, I do think tourism=checkpoint (or maybe something better like tourism=stamp or something) is already good enough.

But of course I also understand that this is unlikely possible to change :frowning:

Not directly related to your main question, but see also a bunch of other in-use examples. Of those I’ve found barrier=checkpoint, barrier=security_control and industrial=checkpoint useful to handle.

Some usage of checkpoint as a top-level tag were just misspelling - see for example here.

In fact the proposer started with tourism=checkpoint but was persuaded to change by discussions on the mailing list. The main argument seems to have been that the checkpoints might well already be tagged as some kind of tourist feature. Looking at taginfo, as it turned out 12.5% of these objects have a tourism= tag.

The discussions start here:

OSM in 2011 and OSM in 2025 are every different things…

12.5% sounds like a small fraction for me anyway.

What I really don’t understand is why noone back then has thought of general checkpoint meaning, which should have been way more obvious than tourist stamps….

I fully agree that reorganizing the checkpoint/border_control/security_control tagging to a checkpoint=* scheme would be an improvement …

1 Like

Is the reason “too narrow scope” and “leads to confusion with broader meaning tags” not good enough by itself?

So I think the question is - what community thinks about the possible/realistic ways to achieve that?

It seems like with amount of usages of checkpoint= in stamp/touristic meaning, and also the fact the at least OSMAnd actually uses it and has icons for it (and probably some agencies did some bulk imports, at least looking at tag usage history) - it’s not an option to actually change it to anything more meaningful.

But what we can do, is e.g. unify all “real” checkpoints into something different, e.g. barrier=checkpoint with type clarification like checkpoint:type=security/police/military (need to brainstorm better how to separate documents check on entrance in large factories/facilities from airport security checks). Sure here values of checkpoint:type would coexist with existing values from touristic checkpoint, but they won’t really overlap anyway, so probably not a big deal.

if you have a clear concept for all checkpoints than you can make a new proposal - than I think it has a chance to get an approval.
You have to consider, which “checkpoints” are mapped on the way and beside the way, which ones are relevant for navigation and which are only poi or even detail mapping?

1 Like

I want to bring this issue back once again. No proposal for the reorganization of all kinds of “real” checkpoints where passersby are actively checked by some kind of authority; just looking at the passive hiking checkpoints once again.

At present we have an extensive discussion about such checkpoints in the german forum and there is some consensus that a) these checkpoints should generally have a tourism=* tag and b) that tourism=checkpoint would definitely be a better choice than tourism=yes.

For those checkpoints, which are incorporated in other touristic objects like tourist informations there are to proposals how to avoid conflicting tourism-tags:

  1. Tag checkpoints as tourism=checkpoint + checkpoint=hiking if the checkpoint is a standalone object only. In case the checkpoint is incorporated in a tourist information the tagging should be tourism=information + information=office + checkpoint=hiking.

  2. Tag checkpoints always as a separate node with tourism=checkpoint + checkpoint=hiking notwithstanding if it is standalone or incorporated in another object.

What do you think?

4 Likes

tourism=checkpoint does have some use already (mostly, as expected, Germany).

Yes, there are 64 uses so far, but the majority of hiking checkpoints having a tourism-tag come along with tourism=yes which was recommended on the german wiki page for checkpoint=hiking for some time (has been removed recently).

Sure, the country of the Wandervogel …

1 Like

I think that’s great, and would give room for other uses of “checkpoint=” in the future! I like it

Beware, checkpoint is still in use to define the type of (touristic) checkpoint in more detail.

1 Like

OK if there is no objection I will now add this informatiom

to the wiki pages for key:tourism and key:checkpoint.

1 Like