Proposal:Vending=tickets

From OpenStreetMap Wiki
Jump to navigation Jump to search
Vending=tickets
Proposal status: Draft (under way)
Proposed by: AlesKubr
Tagging: vending=tickets
Applies to: node
Definition: A general-purpose value for ticket vending machines, analogous to shop=ticket, used with the established tickets:* namespace to specify ticket types.
Statistics:

Rendered as: icon
Draft started: 2026-03-14

This proposal was inspired by Proposal:Vending=ski pass, which proposed the narrower vending=ski_pass value. Based on community feedback, the approach has been reworked into a more general and scalable tagging pattern.

Problem Statement

There is no general-purpose vending=* value for ticket vending machines. OSM has specific values for certain ticket types (vending=public_transport_tickets, vending=admission_tickets, vending=parking_tickets), but when a machine sells tickets that don't fit these categories, mappers have no good option. For example:

  • Ski pass vending machines are increasingly common at ski resorts but don't fit any existing value. They are not public transport (ski lifts at resorts are private recreational services, see Public transport#Cable cars, chair lifts, gondolas, etc.), and calling them "admission tickets" is a stretch.
  • Multi-type machines that sell e.g. both ski passes and public transport tickets cannot be accurately tagged with a single vending=* value.

Meanwhile, shop=ticket exists as a general-purpose tag for staffed ticket shops, and the tickets:* namespace (tickets:public_transport=*, tickets:bus=*, tickets:ski_pass=*, etc.) is widely used to specify what a shop sells. But there is no equivalent general-purpose value on the vending machine side.

shop=ticket

This forces mappers to either pick an inaccurate specific value or invent ad-hoc ones like vending=ski_pass.

Proposal

This is a two-part proposal:

  1. Introduce vending=tickets as a general-purpose value for ticket vending machines, analogous to the already established shop=ticket for staffed ticket shops.
  2. Encourage use of the tickets:* namespace on vending machines, the same namespace already widely used with shop=ticket, to specify what types of tickets a machine dispenses.

The motivating use case is ski pass vending machines, but the tagging pattern is general and applies to any ticket type not already covered by existing specific values.

The tag applies to node nodes representing individual vending machines.

Rationale

Part 1: vending=tickets

The value vending=tickets fills the gap described in the Problem Statement. It is the direct analogue of shop=ticket: where shop=ticket says "this shop sells tickets", vending=tickets says "this vending machine sells tickets". Simple and consistent.

Note that vending=tickets is not intended to replace the existing specific values. Machines that sell only public transport tickets can continue to use vending=public_transport_tickets. The new value is for cases where the existing specific values are not a good fit, or where a machine sells a mix of ticket types.

Part 2: tickets:* namespace

The tickets:* namespace is already well established in OSM, primarily in combination with shop=ticket. As of March 2026, Taginfo shows more than 40 distinct tickets:* keys in use, with tickets:public_transport=* being the most popular at ~2,800 uses. Other widely used keys include:

Key Count
tickets:public_transport=* 2,797
tickets:suburban_train=* 385
tickets:avia=* 138
tickets:train=* 122
tickets:theatre=* 67
tickets:bus=* 67
tickets:museum=* 27
tickets:ferry=* 18
tickets:ski_pass=* 7

As it turns out, around 250 vending machines already carry tickets:* keys (Overpass query: nwr["vending"][~"^tickets:"~".*"];). That is roughly 10% of all tickets:* usage, already on vending machines. Mappers are clearly applying this pattern organically. This proposal simply formalises that practice and encourages its wider use. The benefits are:

  1. Scalability. Instead of creating a new vending=* value for every ticket type, the tickets:* namespace allows open-ended refinement without fragmenting the core tag.
  2. Composability. A machine selling multiple ticket types is simply tagged with multiple tickets:* keys. For example, a machine at a Swiss resort selling both ski passes and public transport tickets can carry both tickets:ski_pass=yes and tickets:public_transport=yes.
  3. Consistency. The same tickets:* keys work on both shop=ticket and amenity=vending_machine + vending=tickets, creating a unified pattern for ticket-selling points regardless of whether they are staffed or automated.

A note on ticket vs tickets

The shop value uses the singular form (shop=ticket) while the namespace uses the plural (tickets:*). This inconsistency already exists in current usage: shop=ticket is routinely combined with keys like tickets:public_transport=*. This proposal does not attempt to resolve that; it simply follows the established convention. For the new vending=* value, the plural form vending=tickets is chosen to match the namespace and because a machine typically dispenses multiple tickets.

Prior art

In 2015, KartenKarsten drafted Proposal:Ticket type, which proposed a comprehensive overhaul of ticket tagging including vending=tickets, the tickets:* namespace, deprecation of existing values like vending=public_transport_tickets, and renaming shop=ticket to shop=tickets. The proposal never advanced beyond draft status, likely due to its broad scope (see the discussion).

However, the core idea proved its worth: the tickets:* namespace grew organically to over 2,700 uses without needing a formal proposal. This proposal takes a narrower, more pragmatic approach compared to the 2015 draft:

  • It does not propose deprecating existing vending=*_tickets values.
  • It does not propose renaming shop=ticket.
  • It does not attempt to define an exhaustive taxonomy of ticket types.
  • It simply introduces vending=tickets and documents the already established tickets:* namespace for use with it.

Evolution of this proposal

This proposal started as Proposal:Vending=ski pass, which suggested vending=ski_pass for ski pass vending machines. Community feedback in the original RFC discussion and follow-up discussion led to a rethink. Several alternatives were considered along the way:

  • vending=ski_pass (original version): Creates a narrow, non-composable value. Does not scale when machines sell multiple ticket types. This was the main criticism raised during the RFC.
  • vending=admission_tickets + sport=skiing: Reuses an existing value, but sport=skiing is an imprecise qualifier (the machine is not a sports facility). Also does not compose well for multi-type machines.
  • vending=public_transport_tickets: Sometimes used for ski lift ticket machines, but ski lifts at resorts are generally not part of the public transport network (see Public transport#Cable cars, chair lifts, gondolas, etc.). They are private recreational services.

The current approach (vending=tickets + tickets:ski_pass=yes) addresses all of these concerns.

Tagging

Primary tags

Tag Value Description
amenity=* vending_machine Standard tag for vending machines
vending=* tickets This machine sells tickets (new value proposed here)
tickets:*=* yes One or more keys from the established tickets:* namespace specifying what types of tickets the machine sells

Use vending=tickets when the machine sells ticket types not well covered by the existing specific values, or when it sells a mix of ticket types. When a machine sells only public transport tickets, vending=public_transport_tickets remains appropriate.

Corresponding shop tagging

The same tickets:* keys work for staffed ticket shops, which is the whole point of using this namespace:

Tag Value
shop=* ticket
tickets:*=* yes

This pattern is already in wide use, with ~2,800 shops tagged this way.

Optional tags

All tags commonly used with amenity=vending_machine apply as usual (payment:*=*, operator=*, location=*, etc.). The only addition specific to this proposal is the use of tickets:* keys to specify ticket types, e.g. tickets:public_transport=yes if the machine also sells public transport tickets.

Use with existing vending values

The tickets:* namespace is not limited to vending=tickets. It can also be used alongside the existing specific values to provide additional detail about what types of tickets a machine sells. For example:

amenity=vending_machine
vending=public_transport_tickets
tickets:bus=yes
tickets:tram=yes

Or:

amenity=vending_machine
vending=admission_tickets
tickets:museum=yes

This is fully consistent with how tickets:* keys are already used on shop=ticket and does not conflict with the existing vending=* values in any way. Note that unlike Proposal:Ticket type (2015), this proposal does not suggest deprecating the existing specific values. The tickets:* keys are purely additive.

Examples

Public transport machine with detail

A vending machine at a tram stop in Lyon selling bus and tram tickets. Uses the established vending=public_transport_tickets with tickets:* keys for additional detail.

amenity=vending_machine
vending=public_transport_tickets
tickets:bus=yes
tickets:tram=yes
operator=TCL

Excursion boat tickets

A vending machine at a lake pier in Bavaria selling tickets for sightseeing boat trips. Excursion tickets are neither public transport nor admission.

amenity=vending_machine
vending=tickets
tickets:excursion=yes
operator=Bayerische Seenschifffahrt

Aerialway tickets

A vending machine at a cable car station in the Alps selling single-ride tickets for a recreational aerialway. Not public transport, not quite admission.

amenity=vending_machine
vending=tickets
tickets:aerialway=yes

Ski pass vending machine

A vending machine at a ski resort in South Tyrol where skiers can buy day passes or recharge RFID ski cards.

amenity=vending_machine
vending=tickets
tickets:ski_pass=yes

Impact on Data Consumers

This proposal has minimal impact on existing data consumers:

  • No existing tags are changed or deprecated. All current vending=*_tickets values remain valid. Data consumers that already handle vending=public_transport_tickets, vending=parking_tickets, etc. are not affected.
  • New value is additive. vending=tickets is a new value that data consumers can choose to support when ready. Until then, machines tagged this way will simply appear as generic vending machines to consumers that don't recognise the value, which is the existing fallback behaviour for any unrecognised vending=* value.
  • The tickets:* namespace is already in use. Data consumers that already process tickets:* keys on shop=ticket nodes can extend that logic to vending machines with no schema change.
  • No rendering changes required. The proposal does not depend on any specific rendering. A vending machine icon (the existing default for amenity=vending_machine) is sufficient.
  • Query cost for existing ticket types is minimal. A data consumer looking for all public transport ticket selling points - both shops and vending machines - can already query tickets:public_transport=yes across both feature types. For vending machines specifically, consumers that currently query vending=public_transport_tickets can extend their query with one additional clause:
 nwr["vending"="public_transport_tickets"];
 nwr["vending"="tickets"]["tickets:public_transport"="yes"];

In practice, machines tagged vending=tickets with tickets:public_transport=yes will be rare - most pure public transport machines will continue to use vending=public_transport_tickets as before. The new value primarily covers machines selling ticket types that have no existing vending=* value at all.

Features/Pages affected

External discussions

Comments

Please comment on the discussion page.