I’ve made a proposal for how to tag freight terminals. These are locations where freight switches between modes (e.g. ship to rail).
Proposal:Freight Terminal - OpenStreetMap Wiki
Please discuss this proposal on its wiki talk page.
How are existing terminals (large and small) tagged?
@SomeoneElse there are quite some examples mentioned on the wiki page. There are many different conventions used and there is no consistency at all. Even for terminals close to eachother (e.g. almost every terminal in the Port of Antwerp uses a different tagging scheme).
The basis is that typically one mode is chosen and that serves as the tagging. E.g. if it is in a port, it is tagged as port, even though it has rail or other connections.
In some other cases the cargo type is tagged (e.g. container_terminal), but that’s an even bigger problem since many terminals handle more than one type of cargo (e.g. dry bulk, liquids, etc).
Finally, many just tag a generic landuse=industry in combination with a name that mentions some specific uses (e.g. container terminal).
The proposed scheme targets all this by proposing a more generic terminal tag combined with separate mode and cargo tags (the latter is reused from an existing tagging scheme).
1 Like
It’s between undefined and a mess, since not even Seamarks got it correctly/clearly and up-to-date How to tag seamark:type=berth by the cargo it handles? - #7 by Kovoschiz
landuse=industrial
btw, there is a proposal about ports that has some overlap: Proposal:Seaway - OpenStreetMap Wiki
1 Like
@Kovoschiz agreed. But I also want to stress that while terminals often occur in or around ports, they also frequently are located far from water (e.g. rail or air terminals). The current proposal tries to find a way to not mess with the current specific systems (e.g. for ports or rail) but extend it and make it truly a system that maps this boundary region well. Hence it needs to work wider than just the seamark tags alone.
@dieterdreist I think that proposal indeed shares interesting ideas. It also flags the need for a terminal mapping scheme.
What is aligned:
- Need for a terminal tag. And more specifically the need for similar tags for cargo terminals and ferry terminals.
- Re-use of the cargo keys.
A few distinctions:
- It also proposes to use the cargo mapping, but is not entirely consistent with the current cargo scheme as documented on the wiki page for cargo (e.g. tag bulk versus dry_bulk).
- It suggests to map terminals as ports (e.g. cruise_port, ferry_port). In my view this is not correct. Often one port can have a cruise terminal or a cargo terminal. And even between those, functions are sometimes mixed. The wider area needs a port tag while the smaller specific area needs a terminal tag, combined with functional tags (which modes can be transshipped).
- This also starts again from the main function tags. While it is in a port, for a terminal, the water connection is just as important as the road or rail connection. They link modes. Therefore, every system that only works from one classification will always have inherent limitations or biases.
What I like is that it proposes the seamark tag as a similar structure to other modes (e.g. highway=*, aeroway=, railway=*). That could be another way of looking at it. Tagging it as a terminal with all its specific subtags. E.g. for the same way, use highway=terminal, railway=terminal and seaway=terminal.
In general, are there other groups I need to involve to get good feedback on this proposal?
when I wrote the proposal there wasn’t documentation for dry_bulk and liquid_bulk, it was introduced here by user rtfm Key:cargo - OpenStreetMap Wiki
and isn’t very established yet, although more than the practically unused tags from the seaway proposal.
I must admit I wasn’t aware of the cargo tag, it seems it was started in 2016 by user geozeisig and half of its use is cargo=passengers which wouldn’t have come to my mind as a combination that even makes sense.
Generally we need such a kind of property and should agree on common tagging. What I am trying to say is that IMHO the current cargo tags aren’t so established that there is no way as to adopt them. If we find out most people prefer the term liquid_bulk to liquids, it wouldn’t be a show stopper ;-)
The more interesting question is whether we have distinct keys per cargo type or a list of types as ‘cargo’ values.
there was the tagging mailing list but I am not sure it is still alive.
Regarding your proposal, I think it would be helpful if you defined a feature tag, currently you are proposing a property, terminal=yes. Why not a feature tag, e.g. under the man_made key?
The proposal is about multimodal hubs but seems to be implicitly limited to sea terminals, or is it for truck terminals as well? Distribution centers? Air cargo terminals? Railway yards? Logistic parks?
Maybe each should have its own main tag (we already have established tags for most such facilities, but some might be missing)?
Binding the feature to a landuse area can be a problem, you said that there can be several terminals in a port, so if for example the port is tagged landuse=industrial industrial=port (not my preferred tagging style but it seems this is the current state), and inside you
wanted to tag a gas and a liquids cargo terminal, how would you proceed?
The word “terminal” is not so helpful, terminal=yes could mean a lot of things, better make it more specific, cargo_terminal for example
Somewhat connected question that I asked a little wile ago but was never resolved.
Does a “port” have direct waterfront access?
e.g. is Way: 1388431450 | OpenStreetMap a “port”? It’s a grain-loading terminal, that’s separated from the water by a public road, walkway, & beachfront area, with an enclosed conveyor belt passing over the top of them out to the loading wharf. So is the complex a port, or just industrial + freight_terminal?
Similarly, should there be mention of conveyor belts, possibly under freight:mode=* ?, for either / both bringing the cargo into the terminal, & / or out to whatever is taking it away?
There is a tag railway=container_terminal included in the OpenRailwayMap tagging scheme. Not sure how widely it is used. But I think I’ve used it at least once…
- The current proposal is a combination of a feature tag (industrial=terminal) and a separate key value pair (terminal=yes). I would happily just live with one feature tag, but the reality is that many ports are not explicitly tagged (e.g. port of Rotterdam, Port of Antwerp, etc.). They are a combination of smaller parts, usually terminals, that are tagged individually as ports (although with limited consistency as well). Port is well established, so pushing for retagging these terminals that are wrongly tagged as port instead of terminal might break things in the short term. That’s why I proposed using this split tagging. Use terminal=yes first. Then do work to retag the larger port area as port. Then tag the individual terminals as terminals. For new ports/terminals, immediately adopt the full schema.
- I chose for industrial=terminal rather than man_made because and earlier proposal suggested man_made and it was advised against this since man_made is used for singular structures.
- The proposal is for all terminals. So, road, water, rail and air. Can be extended to warehouses as well but left this out for now to not make the scope too wide. They are a slightly different beast. They are also typically named warehouses and the term terminal is less common for them. There is another proposal on the wiki discussion page to not use industrial=terminal but rather have a combination of the different types. Seaway=terminal, railway=terminal, airway=terminal and highway=terminal. That could be another way to look at it.
- To answer your landuse question. The larger area (e.g. full Port of Antwerp) could be tagged landuse=industrial, industrial=port. The terminal area would be landuse=industrial, industrial=terminal. This is the ideal case, but see my comment on retagging above. For very small inland ports, there is also the specific case that the full port is one terminal, which is another exception.
- Finally, there is also a discussion on the wiki discussion page about the use of the word terminal already. Happy to continue the debate over there. Long story short, similar to cargo, do you want to include passengers or not.
On all these fronts, happy to change things, but these were the reasons to arrive at the current proposal.
I have included a section with a proposal of how to tag terminals. In general, it seems logical that a port includes the waterfront. In this case, the waterfront is the pier across the road. I would certainly tag the pier as the official port (green section below). You could debate to tag the wider pier + terminal section as the port (red). In both cases, the current purple section (tagged currently as port) should ideally be the terminal.
In this case, I think it makes sense that the terminal does not per se live inside the port. And it might be an even stronger argument to really have a separate tag for the terminals (not re-using the rail, road, air and water tags). They can genuinely be their separate thing and still be connected to water, road, rail etc.
1 Like
@jplahti Tag:railway=yard - OpenStreetMap Wiki also has a mention of this tag being used for freight terminals in some countries.
In general, usage of container_terminal seems overly specific. There are many freight cargo types that are not containerised (e.g. bulk liquid, dry bulk, etc). This invites a user to tag very specific types. E.g. do we also need railway=bulk_liquid_terminal? What if the terminal processes both bulk_liquid and containers? This happens quite often in larger terminals in big ports.
In fact there are only ~5k, and OSMAnd listing support of it. Is it too big already? industrial=port | Tags | OpenStreetMap Taginfo
@Kovoschiz At the moment I was just being careful to not mess with existing schemas. But not sure where people usually draw the line.
It would make sense to retag the terminals properly as terminals, because that is what they are. People refer to this specific area as a terminal, never as a port, except for the unique case where the port and the terminal might take up the same space. In any case, both will have landuse=industrial, which is what most renderers (apart from OsmAnd apparently) will probably optimise for. And the easy fix is to tag the wider region as port if someone decides to tag the terminal properly, which will also improve map accuracy.
Choosing this option means we could drop the whole terminal=yes part from the proposal. We could align on industrial=freight_terminal as the main tag for a terminal. This in combination with the cargo tags (re-using the existing ones since they are already documented and they seem fit for this purpose) and the freight:mode tags.
Hi,
I am the “creator” of the landuse=port proposal, I made the change to landuse=industrial+industrial=port following suggestions (and for the rendererer 
)
I didn’t want to use the seamark:* tagging scheme as it wasn’t too supported on OSM proper.
The aim was to map single terminals [like container or bulk facilities] in detail (before it was possible to map ports in general). Nothing stops to map the whole port area if there’s no sufficient knowledge of the single areas.
Is the same logic of other kinds of industrial facilities.
Keep in mind also industrial=intermodal_freight_terminal | Tags | OpenStreetMap Taginfo which I used for inland intermodal terminals (rail+road)