Proposal:Freight Terminal - OpenStreetMap Wiki

Proposal:Freight Terminal - OpenStreetMap Wiki
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
Contents
Problem Statement
Proposal
Rationale
3.1
Previous attempts
Tagging
4.1
Base feature
4.2
What to map
4.3
Cargo handled reuses cargo=*
4.4
Transport modes use freight:mode=*
4.5
Differences and disambiguation with other terminal tags
Examples
Impact on Data Consumers
Features/Pages affected
External discussions
Comments
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:
Hutchison Delta 2 Terminal
in Maasvlakte uses
landuse
industrial
industrial
port
cargo
container
. The
industrial
port
tag is reused here for a single operator's site within a much larger port. It is unclear from the tagging that this terminal has access to the road, barge and rail network. The terminal is part of the Port of Rotterdam, but the encompassing port area is not explicitly tagged.
Port Newark Container Terminal
in New Jersey uses
landuse
industrial
industrial
port
without any further indications other than the word terminal in the name. It is also part of the wider
Port Newark-Elizabeth
port tag.
MPET (MSC PSA European Terminal)
in Antwerp's Deurganckdok is tagged only as
landuse
industrial
with a name. There is no indication from the tagging that it is a freight terminal at all.
PSA Noordzeeterminal‬
, also in the Port of Antwerp-Bruges and this time tagged as
industrial
container_terminal
Genk Cargo Connect
uses a combination of
industrial
port
port
cargo
railway
terminal
. This is an intermodal terminal. That is already clearer from the tags, but they seem scattered.
Port of Dover - Eastern Docks
is entirely tagged
landuse
industrial
industrial
port
. This is correct for the port envelope but offers no way to express that it is also a single ro-ro/passenger terminal.
Brucargo
is simply tagged as
landuse
industrial
. No indication that this is a transport hub with warehouse capacities.
Terminal Container Athus
is only tagged as
man_made
container_terminal
. While this is also a transport hub that connects the road and rail network and offers storage and other terminal services.
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:
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.
The existing
cargo=*
schema is reused unchanged.
The wiki already recommends semicolon separated lists (
cargo
container
) for multi-value cases.
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.
amenity
bus station
is a passenger bus terminal, out of scope.
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=
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=
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:
Key:terminal
Tag:terminal=yes
Tag:industrial=terminal
Key:freight:mode
Existing wiki pages to be updated with cross-references:
Tag:industrial=port
— note the relationship to
terminal
yes
as an additive marker
Key:cargo
— note extended use on freight terminal features
Tag:amenity=ferry_terminal
— note the relationship to
terminal
yes
for the operational footprint surrounding the passenger building
Tag:railway=yard
— note that rail freight terminals may co-tag with
terminal
yes
External discussions
To be added: links to forum threads, mailing list discussions, and any related conversations.
OSM Community Forum (tagging category):
Comments
Please comment on the
discussion page
Retrieved from "
Categories
Proposals with "Proposed" status
Proposed features under way
Proposals with "Proposed" status sorted by newest edit
Navigation menu