[RFC] Feature Proposal: vending=tickets

General talk Tagging general discussion
,
1

Hi all,

Some of you might remember my earlier proposal for vending=ski_pass (original RFC thread) and the more recent follow-up discussion about how to tag ski pass vending machines. The feedback was clear: don’t create narrow vending=* values for every ticket type. Fair point.

So I went back to the drawing board, and the result is a broader proposal:

:point_right: Proposal:Vending=tickets

The idea is simple and has two parts:

1. Introduce vending=tickets

We already have shop=ticket for staffed ticket shops. It makes sense to have vending=tickets as its counterpart for machines. This is not meant to replace the existing specific values (vending=public_transport_tickets, vending=parking_tickets, etc.) - those remain perfectly fine for their domains. The new value fills the gap for machines that sell ticket types not covered by those, or that sell a mix of ticket types.

2. Use the tickets:* namespace

The tickets:* namespace is already well established on shop=ticket - Taginfo shows 74 distinct keys with tickets:public_transport alone at ~2,800 uses. Even tickets:ski_pass already has 7 uses in the wild.

The proposal encourages using these same keys on vending=tickets machines. So a ski pass vending machine becomes:

amenity=vending_machine
vending=tickets
tickets:ski_pass=yes

And a Swiss machine that sells both ski passes and public transport tickets? Just stack them:

amenity=vending_machine
vending=tickets
tickets:ski_pass=yes
tickets:public_transport=yes

No need to pick one vending=* value over another. No semicolons. Clean and composable.

What this proposal is NOT

For those who remember KartenKarsten’s 2015 Ticket type draft - this is deliberately much narrower. No deprecations, no renaming shop=ticket to shop=tickets, no exhaustive ticket type taxonomy. Just vending=tickets + the tickets:* namespace that already grew organically over the past decade.

The ski pass angle

My original motivation was tagging ski pass vending machines, which are popping up at resorts everywhere and currently have no good tagging option. vending=public_transport_tickets doesn’t fit (resort lifts aren’t public transport), vending=admission_tickets is a stretch, and inventing vending=ski_pass was rightly called out as non-scalable. The vending=tickets + tickets:ski_pass=yes pattern solves this cleanly while being useful for far more than just ski passes.

Full proposal with examples, tagging details, and impact analysis is on the wiki:
Proposal:Vending=tickets - OpenStreetMap Wiki

Looking forward to your feedback. Please comment on the wiki discussion page or here on the forum.

Cheers,
AlesKubr

2 Likes
2

This proposal effectively generates several parallel tagging schemes for vending machines depending on whether they are single-kind-of-ticket, multi-ticket or multi-purpose.
Depending on what combination they offer, the tagging is completely different:

A simple public transport ticket machine is
vending=public_transport_tickets,

but if it offers some other tickets it is
vending=tickets, tickets:public_transport=yes, tickets:something=yes,

but if it offers something that is not a ticket, then it stays
vending=public_transport_tickets;drinks,

This last example may seem a bit far-fetched but we already have things like vending=public_transport_tickets;cigarettes and I’m confident that we can find a parking ticket machine that also provides excrement bags at some hiking spots.

There’s nothing wrong about having lists in tags that are supposed to list things. vending already uses semicolon separated lists to a comparably large extent, e.g. the 179 use cases of vending=parking_tickets;public_transport_tickets. This is the option that I would call “clean and composable”

1 Like
3

Thanks for the feedback! You raise a fair point about the parallel schemes.

Let me share the practical motivation behind this. As a skier, I want to be able to look at a winter sports map and quickly see where I can get a ski pass - whether from a staffed ticket office or a vending machine. Without a ski pass you can’t use the lifts, so this is essential information.

Right now, ski pass vending machines are typically tagged as vending=public_transport_tickets, and ticket offices as shop=ticket. Both are far too broad - if I filter for these, I get every bus ticket machine and every concert box office in the area. There’s no way to distinguish “sells ski passes” from “sells tram tickets”.

The tickets:* namespace solves this. With tickets:ski_pass=yes on both shop=ticket and vending=tickets (or even on vending=public_transport_tickets as the proposal suggests), a data consumer can filter precisely for ski pass selling points. A semicolon value like vending=ski_pass or vending=public_transport_tickets;ski_pass doesn’t help here because ski_pass is not an established vending=* value, and the semicolon approach doesn’t carry over to shop=ticket.

That said, I’m genuinely interested in your perspective. If you think there’s a cleaner way to achieve this - making ski pass (and similar niche ticket type) selling points discoverable for both shops and vending machines - I’m all ears. What would you suggest?

4

Which is definitely not correct and should be fixed. Ski passes are not for public transport but entry tickets to some type of attraction (although open-air, large area and partially freely accessible)

This is true for any tagging scheme that explicitly lists ski passes.
But any (much more common) data consumer filtering on public transport now needs to take three times the effort to find all applicable POIs. As long as tagging is unambiguous, a data consumer can always find the corresponding POIs. What distinguishes tagging schemes is how much effort both mappers and data consumers have to put in to get the data they want. If a mapper finds that one kind of item tagged is not on sale any more and has to completely change the tagging is a nuisance which should avoid.

A solution should not touch the existing tags for parking and public transport tickets and leave their tags as they are. E.g. propose vending=tickets and tickets=x;y;z to cover everything apart from the well established parking and public transport.
If you prefer tickets:x=yes, tickets:y=yes, tickets:z=yes instead of tickets=x;y;z is a matter of personal preference. I personally prefer the list, at least on minor tags like these.

5

Thanks again for the follow-up. I think we agree more than it seems: the proposal explicitly keeps existing PT, parking and admission tags as they are (see Use with existing vending values). vending=tickets is only for the cases those don’t cover.

On tickets=x;y;z vs tickets:x=yes: the namespace approach is already the established pattern on shop=ticket (2,194 features). Having different rules for specifying ticket types on shops vs machines doesn’t make much sense, the proposal unifies this.

You raise a fair point about query cost for PT consumers. But note that the net effect is simpler, not more complex: today, finding all PT ticket selling points requires querying vending=public_transport_tickets on machines and tickets:public_transport=yes on shops, two different patterns. With this proposal, tickets:public_transport=yes works everywhere.

I do acknowledge the temporary coexistence of two patterns for things like PT tickets. But that’s a fairly normal part of how tagging evolves in OSM: a more general solution appears, both approaches coexist for a while, and eventually the community converges on the one that works better. This proposal doesn’t force that process, it just makes sure the general solution is available.

I’ve updated the Impact on Data Consumers section to address the query cost point.

6

What I like about the aproach is not only could it help to potentially tag multiple tickets it could also help to make it explicitly clear when only specific tickets can (not) be bought. E.g. at a train station some mapper could think a machine (same applies for staffed ticket desks) sells public_transport and ski_pass, when in reality maybe these are seperate entities.

ticket:public_transport=only (which is already documented and somewhat in use) or even ticket:*=no could then be used to make this explicit.

The proposal is also in a sense ‘complete’ because shop=ticket together with vending=ticket would covery every possible use case of buying/selling tickets.

On the concern

Why not use vending=food;tickets tickets:public_transport=yes food= (or even food:*= ? vending=food (~5k) and food=* (~10k) and fast_food=* (~10k) are already in use, so data consumers shoud(?) already support this and would only need to add support for what is discussed in this proposal.

Also, If I’m not mistaken this proposal would - if accepted - in theory still leave the possibility to easily deprecate vending=public_transport_tickets etc. at some future point (even if this is out of scope for this proposal)?