Talk:Tag:aeroway=holding position

From OpenStreetMap Wiki
Jump to navigation Jump to search

Changes on April 1, 2019 evolved from discussions the tagging list about a now canceled runway_holding_position proposal. These changes allow the mapper to identify the type of holding position marking in the tag, and to use ways in addition to nodes. Ways allow the user to provide the exact shape of the holding position marking, and conform to international standards (ICAO and FAA) for airport GIS databases. The proposed feature has been canceled. Tapestes (talk)

:type suffix

Hi all. I just discover the key holding_position:type=* and wonder why a type suffix is used there. Why holding_position=* isn't enough? Fanfouer (talk) 19:44, 2 January 2021 (UTC)

I agree, that this seems unnecessary. A closer look at Taghistory reveals, that there have been quite some dramatic shifts in past usage. A proposal concerning runway holding postions was started in March 2019 in the context of which I pointed out the existing holding_position:type=* on the talk page, although I also noted, that the suffix seemed unnecessary. At the time I wasn't aware that there had been a relative massive shift in December of the previous year, that led to the disappearance of holding_position=*, which had seen some usage before. Additional discussions on the mailing list (start of thread) also hinted at a preference of just holding_position=*. Subsequently this tagging scheme was documented and the tag was back on a rise (see history above). Then on 14. October 2020 this page was edited to promote the tag with suffix, while simultaneously the second shift happened, again leading to the eradiction of holding_position=* about two weeks later. In this later time frame I couldn't find any discussions.
@Grille Chompa: Could you please explain your reasoning or maybe point at further discussions, if I overlooked them? From what I could gather, the concensus seems to favour holding_position=*.--TOGA (talk) 23:01, 2 January 2021 (UTC)
The benefit of using a :type suffix is that it clarifies that this tag cannot be used alone. E.g. you cannot just tag an object as holding_position=runway, but it always requires the main tag aeroway=holding_position to be present and the :type suffixed key specifies this main tag in the aeroway=* key space. I think this is particularly useful for new mappers reading the keys to understand that key with a namespaced suffix are not top level keys. Some arguments for both sides were shared in the forum discussion here: https://forum.openstreetmap.org/viewtopic.php?id=64825
Most of the initial tagging of holding positions around airports were indeed done my me. For a while I was using the version without the :type suffix and after the discussion on the forum I went to review my older taggings (and also the others I could find) and updated them to use the :type suffix. "Consensus" is a tricky term to use given the very low number of participants on mailing list, forum and wiki discussions. It would be great if this would have undergone a full proposal process with a lot of participation by the broader OSM community, but it doesn't look like there was much interested back then and now. --Claudius (talk) 09:46, 15 February 2021 (UTC)
It's not clear to me how you understand cannot be used alone here. It's certainly possible to use a :type suffixed tag without any related value on the same object, especially by newbies that won't read the same implication as experienced mappers. A validation rule or quality assurance tool is better and it relies on meta-data, collected on this wiki or in Data_Items. Indeed you shouldn't use holding_position:type=* without aeroway=holding_position, not because there's a :type but only because model says so.
Facts are the :type doesn't bring any additional information and don't accurately prevent errors. Despite the hint that can be understood by some mappers, it's not a deterministic way to proceed as to ensure quality on a growing variety of tools. Introducing such suffixes at a given moment means more involvement required to remove them later. Consensus could change, once appropriate information have been brought. Fanfouer (talk) 20:48, 16 February 2021 (UTC)
The cannot be used alone I meant exactly as you described it: A reading hint. I understand that it is in no way enforced and since the majority of users edit with an editor nowadays that have validation built in this argument is really only regard the few craft mappers that still enter tag values by hand. I am not attached to either the suffixed or non-suffixed tagging variant. I changed the wiki article back in October 2020 because the majority of tagging occured with the suffix. Also back then I reached out to editor maintainers to update their presets accordingly which is probably why the usage of the suffixed variant has been organically growing.
JOSM ticket: https://josm.openstreetmap.de/ticket/20021
iD ticket: https://github.com/openstreetmap/id-tagging-schema/issues/100
The amount of mappers and users of this tag seems to be a pretty small group as with most infrastructure tagging schemes. I guess one could go ahead with a mini proposal to update the tagging scheme to remove the suffix. Then follow up with getting the editor presets updated again and finally a maproulette task to align the tagging. Do you think it's worth the effort? --Claudius (talk) 10:36, 23 February 2021 (UTC)
Thank you for details. Yes, I think it's the right way to achieve it (I certainly support it) Fanfouer (talk) 18:31, 23 February 2021 (UTC)

Runway and ILS holding position digitization direction needs a standard

Currently, there is no standard digitization direction for runway holding position way objects defined. While ILS and intermediate holding positions have symmetrical painted linework on the tarmac, runway holding positions don't, they are oriented in a particular manner with the toothing towards the runway. This resembles e.g. the situation of a tag like natural=cliff.

Additionally, from a cartographic point of view, any labels of the holding position's 'ref' tag, should preferably be similar to the "on-the-ground" orientation, which usually means the runways identification is painted "below" the runway holding line, on the opposite side of the holding line's toothing. In order to replicate this in a map rendering framework, GIS or CAD system based on OpenStreetMap data, it is best if the line is oriented with the left side towards the runway, as most systems will label a line left to right / begin point to end point according to left-to-right Latin script. This results in the label being "upside-down" compared to runway orientation if the digitization direction is "wrong", as can be seen in the attached images, where the "NO ENTRY" holding line and label are oriented wrong. Note that only by digitizing all holding lines in a standard manner, all objects will look OK.

I therefor suggest introducing a recommendation to always digitize the holding line in a standard manner, e.g.:

"The direction of the way should be so that the runway is on the left side of the way direction."

to remember this one, a phrase like "(L)eft side is where you (L)and" might help.

This recommendation should likely only apply to holding_position:type=runway and holding_position:type=ILS holding lines, as those have a clear orientation in relation to the runway. I am not sure if this if is ever the case with holding_position:type=intermediate holding lines.--Mboeringa (talk) 19:46, 27 March 2021 (UTC)

Aeroway holding position digitization direction
Aeroway holding position switched orientation.jpg
Aeroway holding position accurate orientation due to standard digitization direction.jpg

I would also like to suggest to change the preferred way of tagging from a node to a way, to support the proper rendering and labeling. This will likely also need to include a ticket for the editors like JOSM. JOSM even currently flags ways tagged with aeroway=holding_position as an error, warning they should be nodes. This is not in line with the current tagging guideline of the Wiki, that clearly allows and even recommends way objects where the holding line is not a straight line.--Mboeringa (talk) 11:18, 28 March 2021 (UTC)