Proposal:Freight Terminal

From OpenStreetMap Wiki
Jump to navigation Jump to search
Freight Terminal
Proposal status: Proposed (under way)
Proposed by: Takje
Draft started: 2026-04-14
RFC start: 2026-04-14

Problem Statement

Freight terminals are the operational sites where cargo is loaded, unloaded, or transferred between transport modes. They are often owned by one company and fenced off. They can be recognised from the typical stacks of containers, warehouse buildings, but also liquid storage facilities, or bunkers.

These freight terminals occur most commonly in ports but are not port exclusive. They are often tagged as ports in OpenStreetMap, but not consistently. This also creates duplication since often they are already part of a wider port tagged region. Terminals are frequently tagged as their main mode (e.g. port, railway or air), but often are connection points and the other modes are just as important. It is typically unclear what other modes they connect to. Other times they are tagged as container_terminal, but often their functions are wider than just containers. Here are some examples to illustrate the problem:

None of these patterns clearly express the main role of a terminal: which transport modes connect to the terminal, and which cargo types it handles. The current tagging scheme also makes it virtually impossible to separate functions of the wider port areas from the individual terminal functions.

Proposal

Introduce terminal=yes as an additive marker for freight terminals, combined with two orthogonal namespaces: the existing cargo:* schema for cargo handled, and a new freight:mode=* namespace for transport modes connected.

Applies to areas (closed ways and multipolygons) and relations.

The proposal is strictly additive. No existing tag is deprecated, retagged, or replaced. Existing industrial=port, aeroway=aerodrome or railway=yard features that are also terminals simply gain terminal=yes. For new freight terminals not already tagged as ports, railway yards or airports, industrial=terminal is introduced as a peer to industrial=port. This also facilitates the tagging where a port can encompass multiple distinct terminals. The wider area is tagged with industrial=port, while the individual terminals can be tagged with industrial=terminal.

The terminal=yes marker does double duty: it classifies freight terminals and serves as a migration bridge. Large ports like Antwerp and Rotterdam are currently mapped as patchworks of industrial=port polygons without an encompassing envelope. terminal=yes can be added to those polygons immediately, and as port envelopes get drawn over time, individual polygons can migrate to industrial=terminal nested inside an industrial=port multipolygon without changing the marker's meaning. The bare terminal=* key is safe at the top level because terminal has a very logistic centric meaning and other uses are also logistics related (aeroway=terminal, amenity=ferry_terminal).

Rationale

A freight terminal is the operational unit where cargo is handed off between modes (ship to rail, truck to barge), or between transport and storage. It is smaller than a port (an envelope containing many tenants and operators) and larger than a single quay or dock. Most modern terminals are intermodal and multi-cargo.

Three things improve upon previous proposals:

  1. terminal=yes is additive. Rather than introducing a competing top-level value or forcing retagging of existing industrial=port features, terminal=yes sits on top of existing tagging.
  2. The existing cargo=* schema is reused unchanged. The wiki already recommends semicolon separated lists (cargo=container) for multi-value cases.
  3. The freight:mode=* namespace introduces similar semicolon keys for the second important characteristic.

Previous attempts

Two earlier proposals tried and failed: Combined transport terminal (2012, rejected as unclear) and Intermodal Terminal (2014, rejected on key namespace grounds and because there was no way to express which transport modes the terminal served). This proposal addresses the 2014 substantive objection directly via the freight:mode=* namespace, and avoids the namespace fight by being additive to existing industrial=* tagging.

Tagging

Base feature

For freight terminals that are not an existing port polygon: 

landuse=industrial
industrial=terminal
terminal=yes
name=*
operator=*
operator:wikidata=*
website=*

For features already tagged as industrial=port that are terminals (or contain a single terminal coinciding with the port boundary), keep the existing tags and add: 

terminal=yes

The terminal=yes marker is what makes a feature discoverable as a freight terminal regardless of whether it is also tagged as a port.

However, in the future recommend tagging separate terminals within a port with industrial=terminal while the surrounding port is tagged as a whole with industrial=port.

What to map

The terminal polygon should cover the operational footprint. This is the area cargo actively moves through. Concretely, this includes:

  • The free-moving area for cargo (yard, container stacking, vehicle storage)
  • Storage space (warehouses, silos, tank farms)
  • Quay edges and the adjacent water surface used for berthing, for water-based terminals
  • Rail sidings used for handling, for rail-connected terminals
  • The gate and immediate access road, for road-connected terminals
  • The apron and adjacent runway access, for air cargo terminals

It is bigger than a single quay (also covers storage and gates) and smaller than the port envelope (does not extend to other operators' areas, public roads, or unrelated industrial tenants). It is usually quite easy to separate given that there is a specific owner for this land and the area is typically protected with fences.

Cargo handled reuses cargo=*

Cargo is expressed using the existing cargo=* schema with semicolon-separated values for multi-cargo terminals. For terminals that handle a single cargo type, cargo=container is sufficient; terminals handling multiple types list them separated by semicolons, e.g. cargo=container;reefer;break_bulk. This matches the semicolon form documented on the cargo wiki page and the general OSM semi-colon value separator convention.

The values relevant to freight terminals are:

Value Meaning
cargo=container Standard ISO dry containers (20', 40', 45')
cargo=reefer Refrigerated containers
cargo=tank_container ISO tank containers
cargo=dry_bulk Coal, grain, ore, aggregates, fertiliser
cargo=liquid_bulk Chemicals, oils, LNG, vegetable oils
cargo=ro_ro Roll-on / roll-off such as vehicles, trailers, heavy plant
cargo=vehicles New or used vehicles handled as cargo
cargo=break_bulk Palletised, bagged, crated, project cargo or large unitized objects (e.g. wind turbine blades)
cargo=passenger Passenger handling (ferries, cruise)

Transport modes use freight:mode=*

The transport modes a terminal actively serves are expressed with a new freight:mode=* key, using semicolon-separated values for terminals serving multiple modes, aligned with the cargo=* key. For example, a road/rail/barge inland terminal uses freight:mode=road;rail;barge; a deep-sea container terminal with full intermodal connections uses freight:mode=road;rail;barge;short_sea;deep_sea.

The values are:

Value Meaning
freight:mode=road Truck access, gate operations
freight:mode=rail Rail sidings with active handling
freight:mode=barge Inland waterway vessels
freight:mode=short_sea Coastal / intra-continental maritime
freight:mode=deep_sea Ocean-going vessels
freight:mode=air Air freight
freight:mode=pipeline Pipeline interconnection

The barge / short_sea / deep_sea distinction is commercially meaningful and heavily used in the industry. It reflects the terminal's designed and typical traffic, sourced from operator documentation, rather than a physical property observable from imagery.

Differences and disambiguation with other terminal tags

Several existing tags overlap partially with freight terminals. This section clarifies how terminal=yes relates to each, and where it adds value.

  • industrial=container_terminal is in active use (e.g. PSA Noordzeeterminal in the Port of Antwerp-Bruges) but undocumented on the wiki. It describes only the cargo type and says nothing about connected transport modes, operator footprint, or whether the site handles more than containers. Most modern container terminals do (reefer, break bulk, occasional project cargo). Existing features can be enriched by adding terminal=yes, the relevant freight:mode=* tags, and additional cargo=* sub-keys where applicable. New mapping should prefer industrial=terminal + cargo=container + transport modes. No automated migration is proposed.
  • man_made=container_terminal: The general tag for container transshipment facilities, documented on the wiki alongside railway=container_terminal in a shared "Container terminal" section. The wiki describes it as a transshipment facility for shipping containers between ships and rail, or rail and truck, recommends area mapping, and pairs it with landuse=industrial. In practice it is used on features such as Terminal Container Athus. The limitation is that it captures only the cargo type and leaves the connected transport modes implicit. The wiki text hard-codes a ship/rail/truck assumption that does not hold for barge- or pipeline-connected terminals and does not distinguish single-cargo from multi-cargo sites. The 2014 Intermodal Terminal proposal also argued on key-namespace grounds against placing transport terminals under man_made=*. New mapping should prefer industrial=terminal with explicit freight:mode=* and cargo=* tags. Existing features can be enriched additively with terminal=yes and the relevant sub-keys.
  • railway=container_terminal: The rail-specific variant, documented in the same wiki section as a tag for a container terminal that has to involve rail transport. It shares the same limitations as man_made=container_terminal: containers-only, modes implicit. Most rail container terminals are in fact intermodal road/rail/(barge) sites, which industrial=terminal combined with freight:mode=* can express directly. Existing features can be enriched additively with terminal=yes.
  • port=cargo is an informal combination seen on some features (e.g. Genk Cargo Connect, cited in the problem statement). Superseded in practice by industrial=terminal + freight:mode=* + cargo=*, which expresses the same intent more precisely and more completely. Not formally deprecated by this proposal.
  • industrial=port is the wider port envelope, typically containing multiple operators and tenants. A terminal is a single-operator operational unit within or alongside a port. See the proposal above for how terminal=yes relates to existing industrial=port features and how new terminals inside ports should be tagged.
  • amenity=ferry_terminal is a point or building tag for the ferry passenger facility. Orthogonal to this proposal: a ro-ro/passenger site such as Port of Dover - Eastern Docks can carry both, with amenity=ferry_terminal on the passenger building and terminal=yes on the operational polygon covering the yard, quays and gates.
  • aeroway=terminal is the passenger building of an airport. Air cargo terminals (e.g. Brucargo at Brussels Airport) are physically and operationally separate from passenger terminals, typically located on a dedicated freight apron with their own warehouses and landside gates. They should be mapped with industrial=terminal + freight:mode=air on the operational polygon, independently of any aeroway=terminal passenger building elsewhere on the airfield.

Examples

MPET — MSC PSA European Terminal (Deurganckdok, Antwerp — deep-sea container): 

landuse=industrial
industrial=terminal
terminal=yes
name=MSC PSA European Terminal (MPET)
alt_name=MSC PSA European Terminal
short_name=MPET
operator=PSA;MSC
website=https://www.mpet.be/
freight:mode=road;rail;barge;short_sea;deep_sea
cargo=container;reefer;break_bulk

Genk Cargo Connect (Albert Canal — replaces the homegrown port=cargo + railway=terminal combination): 

landuse=industrial
industrial=terminal
terminal=yes
name=Genk Cargo Connect
website=https://genkcargoconnect.be/
freight:mode=road;rail;barge
cargo=container

Port of Dover - Eastern Docks (existing industrial=port kept, terminal=yes added): 

landuse=industrial
industrial=port
terminal=yes
name=Port of Dover - Eastern Docks
operator=Port of Dover
freight:mode=road;short_sea
cargo=ro_ro;vehicles;passenger

The amenity=ferry_terminal tag remains valid for the passenger building on the same site.

Impact on Data Consumers

This proposal is strictly additive and introduces no breaking changes.

  • Renderers (standard layer, OpenSeaMap, etc.) require no changes. Existing industrial=port polygons continue to render as before. It is actively encouraged to have a wider area around the terminal tagged as port if the terminal has water access. Renderers may optionally introduce a distinct symbol for terminal=yes features in the future; this is not required.
  • Editors (iD, JOSM, Vespucci) require no changes. Adding presets for terminal=yes, freight:mode=*, and the cargo sub-keys would improve mapper experience but is not a prerequisite for the schema to be useful.
  • Data consumers and routers gain the ability to query for freight terminals by connected mode and cargo type, which is the primary motivation for this proposal. Use cases include freight routing, modal-shift analysis, and commercial intelligence applications.
  • Backwards compatibility: all existing tags (industrial=port, cargo=container, amenity=ferry_terminal, railway=yard) continue to function. No deprecation is proposed and no migration is required.

Features/Pages affected

New wiki pages to be created if approved:

Existing wiki pages to be updated with cross-references:

External discussions

To be added: links to forum threads, mailing list discussions, and any related conversations.

  • OSM Community Forum (tagging category): https://community.openstreetmap.org/t/rfc-feature-proposal-freight-terminal/143056

Comments

Please comment on the discussion page.

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=Proposal:Freight_Terminal&oldid=2979214"