Talk:Tag:aeroway=holding position

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)

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)

Hi, what do you think about add a direction=* to the aeroway=holding_position ? It will be more easy to draw there a line perpendicular to the direction? -- Phd0 (talk) 12:01, 23 August 2022 (UTC)

I see two objections to your proposal of adding direction: while adding direction to a holding position node might be useful for flight simulators, I don't think automatically drawing a line perpendicular solves the problem in a really elegant manner: there are many quite complicated situations where the line on the tarmac is asymmetrically placed, or even bends. Drawing the actual real world line, will give a better representation. In addition, while your proposal might work for this one-off case of holding position nodes, there are a thousand other uses and objects being tagged by users in OpenStreetMap. Every "special interest group" of users has its own desires, and might wish similar "automated" placement. This is just to much of a burden to expect many renderers or applications to take care of such "logic".

I am very much in favor of the KISS principal whenever possible (https://en.wikipedia.org/wiki/KISS_principle), and drawing the actual line with a new tag, although adding some minor duplication, is the more straightforward solution in my opinion.

As I proposed, I would suggest to create a new tag for this, simply tagging aeroway=holding_position_line on a way object would do for me, and allow drawing and tagging the line in a distinct manner, and still tag nodes with the original aeroway=holding_position tag for flight simulator routing purposes. --Mboeringa (talk) 09:31, 31 August 2022 (UTC)

I have now created a new tag proposal page for the "aeroway=holding_position_line" tag I have suggested: https://wiki.openstreetmap.org/wiki/Proposed_features/aeroway%3Dholding_position_line. In addition, I have created a stub tag page for the same tag, that references the proposal page: https://wiki.openstreetmap.org/wiki/Tag:aeroway%3Dholding_position_line. The stub page would need replacing with the proposal text if that is finalized and accepted. Feel free to comment on the proposal.--Mboeringa (talk) 18:45, 31 August 2022 (UTC)