Talk:Proposed features/runway=displaced threshold
- Yes, I think turn pads very much deserve their own tags. I am struggling a bit with a simple enough mapping definition though as they come in various shapes and forms. Sometimes they are just a circle extension to the runway pavement (Skiathos: https://www.openstreetmap.org/#map=19/39.17027/23.50104 ), then there is some that are fully marked with an ellipsoid driving path (Kristiansund: https://www.openstreetmap.org/#map=19/63.11584/7.85069 ) and then there's these 90 degree drops (Myambat: https://www.openstreetmap.org/#map=19/-32.37378/150.61342 ) that look like https://caasref.wordpress.com/runway-turn-pad-making/ - I haven't seen enough of these to come up with a tagging proposal, but my guess is already that these might work on both nodes and ways. I won't include them in this proposal, but think it deserves its own.--Claudius (talk) 08:49, 11 November 2020 (UTC)
As with Proposed features/aeroway=stopway, good job overall.
I do see a similar issue: I don't think the direction of the way should matter, since a displaced threshold can only ever be at the end of a runway. And if it does matter, it's sufficient to say it points "towards the runway it belongs to", rather than "towards the closest threshold of the runway it belongs to."
Regarding rendering, you suggest "Way rendered with width and opacity between runways and taxiways". Grammatically, I think this is missing a word or two: "Way rendered with width and opacity between that of runways and taxiways". However, I'm also not sure I agree. The displaced threshold is part of the runway; we've already established that. Why is it beneficial to render it narrower than the rest of the runway? In the common map styles, runways are just rendered as a large opaque rectangle (without any regard for the runway's width=*, annoyingly), which makes sense because those styles are mainly for people navigating on the ground by foot/bicycle/car; runways are a nice landmark, but the details of a runway are irrelevant to most people. Then again, we render taxiways in a different width and that seems reasonable, so maybe given a lack of other visual distinctions there is some merit to graphically depicting a displaced threshold distinctly, too. --BigPeteB (talk) 20:57, 1 December 2020 (UTC)
- As mentioned in the stopway proposal: Agreed to simplify the orientation/direction description.
- In regard to rendering: You are totally right. Should render same style in width and opacity as runways (with a potential bonus rendering to mimic the arrow markings).
- I've updated the proposal accordingly. Thanks again for the time to review and share your feedback. --Claudius (talk) 09:37, 4 December 2020 (UTC)
- These stretches of runway inherently have a directionality; very clearly marked by the customary arrow markings. To give renderers a way to use that information, I would suggest keeping the way's direction pointing towards the runway proper and documenting it as such (kind of like how we map a oneway street). The example below gives an idea of what renderers can do with that information: I use the way's direction to have the arrows point in the right direction. It's easy to include in the tag's documentation now and not much of a burden on mappers; much harder to retroactively fit it in later. --JeroenHoek (talk) 13:52, 14 June 2022 (UTC)
I am experimenting with rendering this feature along with the runway proper based on its width=* over here. This is just a personal experiment, so I don't expect Carto will render it like that at the moment, but it might be interesting to have a look at. --JeroenHoek (talk) 19:38, 12 March 2021 (UTC)
Excuse me for rowing against the stream ;) I have long been thinking about a consistent and coherent ruleset for the mapping of runways, and the more I think, the more confused I get. Still, a few points are clear to me:
- we should not be too eager to map details that are only relevant to a specialised minority; displaced thresholds are not relevant to the public at large. Some hold that anything may be mapped, others (especially in Germany) would rather limit mapping to generally useful information. The whole discussion is not super-relevant, IMHO;
- we should map in the first place what comes most readily to the eye, as visible on the ground. In the case of a runway, that is its total area;
- subdivisions of the runway can (and, for me, should) be handled as optional extra information; the more so that this information is rather volatile - it only requires a brush and a pot of white paint to move them around (not really, of course, but I hope my point is clear).
My approach would thus be:
- to map the complete runway in its full length, including stopways and displaced thresholds, and what not, not from threshold to threshold as currently recommended in the wiki;
- to optionally map displaced tresholds, stopways, and perhaps more such, as markings on the runway, much as a holding point is marked on a taxiway.
The worst idea of all is the current recommendation in the wiki with aeroway=runway+runway=displaced_threshold! By adding a tag "aeroway=runway" it suggests the presence of a second runway, apart from the main one. That is obviously not the case. The previous suggestion "aeroway=displaced_treshold" is at least coherent, though I still find it needlessly complicated.
- A highway=residential cut into two or more ways because the tags differ (extremely common) is still conceptually one street. The same holds true for aeroway=runway. Also: you can't map the displaced runway as markings without cutting up the runway way (unlike the holding points, which can be mapped as nodes or separate ways perpendicular to the taxiway). These markings apply to a section of the runway way, not to a node. This proposal is entirely consistent with how we map other linear features.
- That argument turns up again and again, but it is not really applicable: linear features, such as roads or railways or canals, can be split up in sections, which can then be joined (in OSM relations) to create routes. A driver, or her/his route planner, will plan a route by joining route segments, similar for a yacht captain. A pilot OTOH will plan a route as a list of waypoints - which will by the way normally not include runways. I agree that the similarity to highway & railway has a certain degree of poetry, but it does not go any further.Jan olieslagers (talk) 11:45, 19 June 2022 (UTC)
- Displaced runways are not volatile at all. They change, but just about as often as the whole runway. That's not really an argument here. Besides, displaced runways are just about the most visible and accurately mappable feature there is due to their high visibility on imagery (i.e., “readily to the eye, […] visible on the ground”).
- The mapping of aerodromes mostly consists of mapping details that are only relevant to a specialized minority. We might as well leave out most of aeroway=* and stop naming taxiways if avoiding that is a criterium. --JeroenHoek (talk) 11:20, 19 June 2022 (UTC)
- I would quite support such a proposal, indeed :) Jan olieslagers (talk) 11:45, 19 June 2022 (UTC)
- As with all matters of detailed mapping: you are under no obligation to map such details yourself, but others do have the freedom to do so if done in a reasonable and non-destructive manner. This proposal, together with aeroway=stopway, help more clearly define the concept of a runway, and formalize how to tag a runway's common components. I wouldn't even classify this as micromapping; more along the lines of lanes=* or sidewalk=* for highway=*. --JeroenHoek (talk) 11:58, 19 June 2022 (UTC)
- I would quite support such a proposal, indeed :) Jan olieslagers (talk) 11:45, 19 June 2022 (UTC)
- You also wrote “we should map in the first place what comes most readily to the eye, as visible on the ground. In the case of a runway, that is its total area”. For the total area, use area:aeroway=runway. This is about the linear way representing the conceptual runway (from threshold to threshold, as it should be), not the total surface area which may include stopways or blast pads. The Wikipedia article Grille_Chompa links to helps explain this. --JeroenHoek (talk) 11:28, 19 June 2022 (UTC)
- The tag area:aeroway=runway annoys me above all else: in 99% of cases, it only serves to add one runway twice to our database, with identical information (especially after a recommendation in maproulette). This is in violent contradiction to our basic principle "one feature, one OSM entry". I will admit though that there are cases where it can add useful information. Jan olieslagers (talk) 11:45, 19 June 2022 (UTC)
Disagree with the proposed name
Displaced thresholds are not sections of runways - they are thresholds beyond which certain activities aren’t allowed (in this case touch-downs aren’t allowed before crossing such a threshold). So they are actually lines across the runway. Displaced threshold is like a runway end/threshold (a line across that marks the edge of a usable runway surface), but located not at the end of the runway but further down the runway surface.
FAA AIM corroborates this: “2. Displaced Threshold. A displaced threshold is a threshold located at a point on the runway other than the designated beginning of the runway. Displacement of a threshold reduces the length of runway available for landings. The portion of runway behind a displaced threshold is available for takeoffs in either direction and landings from the opposite direction.”
- Yes, the concept of the "displaced threshold" is indeed represented in real world just with the marked perpendicular runway threshold bar. The area behind that threshold doesn't seem to be named anywhere in FAA or IATA documents, but just described as "The portion of runway behind a displaced threshold". The wikipedia article https://en.wikipedia.org/wiki/Displaced_threshold refers to it in what seems to be colloquial pilot speak as "displaced threshold area". I used in this proposal what was already an in use tagging since I couldn't really come up with a better name.
- Any suggestions what would be more descriptive? Added "area" to the value as runway=displaced_threshold_area didn't feel to add much. --Claudius (talk) 13:03, 26 September 2022 (UTC)
- I wouldn't rename it at this point just because of a minor semantic disagreement. I think the current tag-name makes sense; Wikipedia does use displaced threshold in the sense this tag is using it. Personally, I would solve any ambiguity with clear documentation here on the wiki. --JeroenHoek (talk) 13:49, 26 September 2022 (UTC)