Proposal:Loading dock details
The Feature Page for this approved proposal is located at Tag:amenity=loading_dock |
Loading dock details | |
---|---|
Proposal status: | Approved (active) |
Proposed by: | Kylenz |
Tagging: | dock:height, dock:width, door:height, door:width=* |
Applies to: | |
Definition: | Clarifies the definition of the dimensional tags used on loading docks. Also approves amenity=loading_dock and deprecates door=loadingdock |
Draft started: | 2022-03-26 |
RFC start: | 2022-03-26 |
Vote start: | 2022-09-14 |
Vote end: | 2022-09-28 |
Proposal
This proposal seeks to:
- Clarify the definition of dimensional tags (width/height/length) when they're used with amenity=loading_dock.
- Formally approve amenity=loading_dock
- Deprecate door=loadingdock
Rationale
Currently, it is not clear what height=* means when it it used on a node tagged as amenity=loading_dock. It could mean either the height of the door, or the height of the dock.
The wiki page currently contradicts itself, it says:
- height=* - Describes the height of the loading dock.
However, the example on that page is height=5.1 m which must be the door height because it's far too high to be the dock height.
Tagging
Part 1: Clarify definition of dimensional tags
These definitions apply when the tags are used on the amenity=loading_dock node.
Key | Change | Definition | Purpose | Taginfo |
---|---|---|---|---|
door:height=* | New tag | The height of the opening when the door is open (see photos below) | Constraints on the load | |
door:width=* | New tag | The width of the opening when the door is open | ||
dock:height=* | New tag | The height of the dock (see photos below). This value can be a range for docks with variable heights | Constraints on the vehicle | |
dock:width=* | New tag | This tag is only needed if door:width=* and maxwidth=* do not sufficiently define the dimensional constraints. dock:width=* defines the (usable) width of the dock platform, if this is different to the width of the door. |
||
maxlength=* | No Change | The maxmimum length of a vehicle that can use the dock | Constraints on the vehicle | |
maxheight=* | No Change | The maxmimum height of a vehicle that can use the dock | ||
maxwidth=* | No Change | The maxmimum width of a vehicle that can use the dock | ||
width=* | Discouraged | Do not use this tag on loading docks due to ambiguity | ||
height=* | Discouraged | Do not use this tag on loading docks due to ambiguity | ||
length=* | Discouraged | Do not use this tag on loading docks due to ambiguity |
All these tags use metres, unless a specifc unit is defined. See width=* for more information.
Part 2: Formally approve amenity=loading_dock
This proposal also seeks to formally approve amenity=loading_dock. The definition will be slightly tweaked, since it currently suggests that only heavy goods vehicles can use a loading dock.
New definition: "amenity=loading_dock marks the entrance of a building used for loading and unloading goods vehicles."
Part 3: Deprecate door=loadingdock
door=loadingdock is used 1,000 times, while amenity=loading_dock is used 10,000 times.
This proposal deprecates door=loadingdock because it is an 'orthogonal tag' that prevents you from defining the physical type of door (such as sliding or overhead)
Examples
An example of dock:height=0 - The dock is level with the ground, so vehicles need a Tail lift or ramp.
A (rare) example of where dock:width=* is useful, because door:width=* and maxwidth=* do not convey all the constraints.
Other tags
- There are no proposed changes to how capacity=* can be used. If you map multiple doors with one node, you can use this tag to specify the number of doors. If not explicitly tagged, capacity=1 is assumed.
Rendering
No change
Features/Pages affected
External discussions
- osm-us slack, #tagging channel, March 2022
- Tagging mailing list, March 2022
Comments
Please comment on the discussion page.
Voting
Voting on this proposal has been closed.
It was approved with 17 votes for, 0 votes against and 0 abstentions.
- I approve this proposal. --Kylenz 23:28, 14 September 2022 (UTC)
- I approve this proposal. Good job! --Fizzie41 (talk) 03:17, 15 September 2022 (UTC)
- I approve this proposal. Seems like a sensible proposal. Diacritic (talk) 06:59, 15 September 2022 (UTC)
- I approve this proposal. --Rskedgell (talk) 09:00, 15 September 2022 (UTC)
- I approve this proposal. Nice and clear. Well done! --Martianfreeloader (talk) 09:51, 15 September 2022 (UTC)
- I approve this proposal. --Mashin (talk) 18:11, 15 September 2022 (UTC)
- I approve this proposal. --Fanfouer (talk) 20:07, 15 September 2022 (UTC)
- I approve this proposal. Thanks for accommodating non-metric units when appropriate. – Minh Nguyễn 💬 04:16, 16 September 2022 (UTC)
- I approve this proposal. --Popball (talk) 07:40, 16 September 2022 (UTC)
- I approve this proposal. Rtnf (talk) 07:57, 16 September 2022 (UTC)
- I approve this proposal. Nicely thought thru, and it handles the existing tagging about as well as can be. JesseFW (talk) 12:52, 16 September 2022 (UTC)
- I approve this proposal. A 'loading ramp' is the other thing I was thinking of when I read this, loading ramps don't require a building. --Warin61 (talk) 04:58, 19 September 2022 (UTC)
- I approve this proposal. Excellent proposal, we have been adding loading_dock details in Ontario for the last 12 months. Very eager to assist with this. --Eric Geiler - A&B Courier (talk) 19:20, 21 September 2022 (UTC)
- I approve this proposal. --快乐的老鼠宝宝 (talk) 14:55, 24 September 2022 (UTC)
- I approve this proposal. --Reino Baptista (talk) 09:46, 26 September 2022 (UTC)
- I approve this proposal. Felt like I was the only one who even mapped loading docks, this is lit --Emilius123 (talk) 10:21, 26 September 2022 (UTC)
- I approve this proposal. I've never mapped a loading dock, but this is a good proposal that will improve data in OSM. --Riiga (talk) 14:15, 26 September 2022 (UTC)