OpenStreetMap
Contrary to common practice, I hold (after much deliberation and consideration) that the best way to map runways is to make them an area.
One reason is that everybody and their dog, including our very own dearest wiki, defines a runway as being an area, with various elaboration. Example from our own wiki: [quote]A runway is a defined rectangular area on a land aerodrome (aeroway=aerodrome) prepared for the landing and take-off of aeroplanes. [/quote].
The eternal counter-argument is the parallelism to ways, railways, waterways and perhaps more; but I hold this argument to be non-valid. Unlike all the other categories, runways can NOT be joined to create routes. An aviator’s route planning mentions aerodromes and optionally other waypoints, navaids, visual reference points, but never runways. So that there is really no point in defining a runway as a way, or any other linear element.
I therefore strongly oppose both the mapping of runways as linear elements, and the additional use of area:runway or any such. The latter are totally redundant, and thus a waste of valuable resouces, storage capacity in the first place.
I am not the only mapper with this opinion, even less am I the first; many French ultralight terrains and their runways (“Base ULM”) have been mapped this way, and never been questioned. I find them perfectly satisfactory, too. For just one example among many, see [url] https://www.openstreetmap.org/way/587820283 [/url]
Discussion
Comment from alexnevermaps on 3 June 2023 at 15:10
Hello, I’m new with contributing to OSM, but I’ve recently made a handful of edits to runways in Baja Mexico. I’m a pilot trying to document some of the lesser known airstrips and correcting data nearby. One thing I do appreciate about the current line method is it is very easy to calculate length of the runway pragmatically. Following the instructions on the runway wiki page, I have been changing area tagged ways to area:runway per the instructions and adding a line for runway. Is having both a problem?
Comment from Jan Olieslagers on 3 June 2023 at 18:09
Good afternoon! Thanks for contributing to OSM, and thanks for discussing. As I stated, having both aeroway=runway and area:aeroway=runway is a waste of resources, and a potential source of confusion; but it isn’t necessarily intrinsically a problem, neither is it “wrong” or “problematic”. Possible confusion: imagine a runway that is entered twice, then is changed, becoming disused or changing surface or whatever. Then someone updates one entry but not the other - a mistake that is easy to commit. Then there we have two conflicting entries.
Also, we have an old principle [url] https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element [/url] which neatly corresponds to what I learned as correct database content management. It must be said though that that there are cases where it is deliberately disrespected; for example a restaurant will often be mapped as a node with “amenity=restaurant” inside a way with “building=yes”
An alternative is illustrated in [url] https://www.openstreetmap.org/way/161682271 [/url]: here, both tags are given in a single “way” entry. That seems much more acceptable to me, though I still do not see the added value of the “area” tag. But it does avoid the potential confusion, and it also respects the principle of “One feature on the ground, one entry in the OS database”.
As for the runway length (and width), these should not be calculated, they should be mapped with their proper tag, ideally according to published documentation.
Kindest regards! Karel ADAMS
Comment from alexnevermaps on 3 June 2023 at 19:40
Karel, thank you for taking the time to respond to my question. I really appreciate it.
One of the things I’m trying to do is create guidebooks/charts of all the backcountry and lesser known areas that have legal airstrips. In places like Mexico, these are poorly documented, but there are spreadsheets and things you can compile from the govt to make the status clear. My dream is to contribute that data to OSM, then use that data to compile the chart/guidebook. Essentially use OSM as the source of truth, contributing to OSM the gaps.
Right now the current best practice for getting data like runway length/width from these areas is to simply look at google earth and measure it. It does not need to be perfect. It seems like marking the line that is a runway is a similar method to this if there are no direct measurements available, and it’d be impracticable (or trespassing) to measure it directly. Obviously when there is direct measurement, that’s better. But for now calculating the length gives us a guidepost that a pilot could use to filter what they should even consider going into.
I’d be curious if you had any suggestions on OSM best practices for getting this data. As well if there are ways for me to automatically generate changesets using these govt sources and then review everything all at once before contributing.
Please feel free to tell me to RTFM… I’ve found a lot of these materials on the wiki but it is unclear to me what the best practice/standard is… I was very surprised to see your post today when it is in contradiction to what the wiki for runway says. How does consensus on these approaches happen?
Thank you again for your time and thoughts.
Comment from Friendly_Ghost on 4 June 2023 at 09:10
It’s an interesting approach to runway mapping. I’ve mapped areas on occasion using area:aeroway=runway (so not exactly area:runway). Runways can also be rendered as areas if they have a width=* tag, which could make runway areas more or less redundant for rendering purposes.
The main benefit of linear map features is that they inherently have a direction and a length. It’s possible to tag these things explicitly on areas, but this doesn’t seem to be common practice as of now.
Very few features in real life are lines. Fences may be, but roads and hedges always have a certain width. We still map them as lines as that is useful for many cartographic purposes.
I think it’s destructive to remove runways mapped as lines and I think this idea should go through a formal proposal first.
Comment from SomeoneElse on 4 June 2023 at 11:03
I absolutely agree with this comment. It’s easy to calculate the length of a runway from a line but impossible from an area.
Taginfo suggests a number of consumers for
aeroway=runway, so I’d suggest discussing this more widely - perhaps at https://community.openstreetmap.org/ , and also contacting data consumers listed at taginfo (there will be at least a github project listed for each) to point them to the community discussion.However, if someone was to add a polygon
area:aeroway=runwayaround an existing linearaeroway=runwaythen clearly no data would be lost.Comment from Jan Olieslagers on 4 June 2023 at 12:51
Thanks for polite discussion, and for mentioning some points that I was not yet aware of. Let me first point out two premisses that I apply in this context: 1/ the information is in the first place relevant for aviators; it might also be consulted by builders of models/maquettes/dioramas, but I expect such people to consult photography primarily, including satellite imagery. 2/ the database should be kept as frugal as possible, both to minimise the use of precious hardware resources (this comes from my professional career as a server hardware engineer) and to avoid double information - an eternal source of confusion and conflict. It also conforms to the very basic principle of “one feature on the ground, one entry in OSM”.
I thought a good deal about the possibility to calculate a runway’s heading and length if mapped linearly; it is one detail I was not aware of. After due consideration, though, I see little added value there. * the heading can be deduced from the ref (ex. “17/35” or “08L/26R”) which is quite sufficient for aviation requirements; and this a standard field when mapping a runway; * the calculated length will be little relevant to aviators, the one bit of info they want is the useable length, which may be less or even much less than the physical length. Again, the length should be mapped as such with the runway, it is primary information. If more precision is required, I would suggest the use of aviation specific tags, such as “runway:qfu” for the headings, and/or “runway:tora” and similar for the useable lengths. These would reqally add value to our database - but they require a fair bit of effort to keep up, especially the headings, since these are indicated as “magnetical” thus changing over the years, as the magnetic declination changes. (On a sidenote: Did you know that, occasionally, runways even change their ref., for example from “12/30” to “11/29” due to this historic practice? Today, very few pilots fly by the magnetic compass so it would be much more logical to use “absolute” instead of “magnetic”; but the effort to update all procedures and documents would be gigantic.)
I wil consent (though not without a gentle grudge) to not remove runways mapped linearly; however I insist that mapping them as an area and only as an are should at least be considered acceptable, too. Again, this was not invented nor pioneered by me, it has been common practice for several years.
Again, thanks to all for polite and constructive discussion!
Comment from Jan Olieslagers on 4 June 2023 at 12:54
@alexnevermaps: I sent you a private message, did you notice?
Comment from 快乐的老鼠宝宝 on 9 June 2023 at 23:02
Retaining a line may be helpful for the computer to deal with the most basic “this is a runway”, otherwise data users will have to calculate this line based on the long and short sides of the area?
Comment from Minh Nguyen on 11 June 2023 at 22:21
The “One feature, one OSM element” guideline goes on to list many examples of where multiple features are a good idea.
Sometimes it’s a matter of perspective. When you think of a river, you might be thinking of a channel to cross or navigate along, or you may be thinking of a body of water to enter. We can reconcile these two perspectives by mapping the “centerline” or perhaps the thalweg as a
waterway=riverway and simultaneously mapping the waterbody as anatural=waterwater=riverarea. Similarly, the idea behindarea:aeroway=runwayor any otherarea:*=*key is to provide an option to micromap the surface of something as opposed to the navigable path of something. By this logic,aeroway=runwaywould correspond to the centerline marking.From a technical perspective, it’s possible but not necessarily straightforward to simplify a series of runway and taxiway areas into a series of centerlines that intersect correctly, especially because an
area:aeroway=taxiwayarea would join to anarea:aeroway=runwayarea with gentle curves on both sides. It wouldn’t be unreasonable for a renderer to make use of this kind of simplification as you zoom out.Comment from Jan Olieslagers on 12 June 2023 at 01:43
My point is that runways (and taxiways) are not “navigable” - they are not joined or connected to create routes or other relations. Therefore, mapping them as linear elements makes no sense. Only mapping their area is quite sufficient. Take the little aerodrome in way 118617414 and its runways 118617424 + 118617420 as an example: it is concise, and all needed information is there. Adding more to it is a waste of resources and a potential source of confusion.
Comment from adreamy on 12 June 2023 at 04:05
Please understand that English is not my first language and I am not able to participate in deeper discussions.
This is a very novel idea, but as I reflect on my experience in the Air Force, I think the biggest problem with mapping runways as areas is this.
An area has all of its properties applied within it.
But runways, more than anywhere else, are about linear motion.
The moment you step out of that line, even if it’s within the area, you’re at risk of a major accident.
I think it would be a good idea to discuss this more broadly in the OSM forums if there are strong opinions.
Comment from 快乐的老鼠宝宝 on 12 June 2023 at 06:04
Yes, the idea @adreamy pointed is also interesting, since the centerline of the runway was “designed to follow this line”, it could somehow represent the abstract “runway”?
Comment from adreamy on 12 June 2023 at 07:40
@快乐的老鼠宝宝, What does the abstract runway refer to?
For example, inside a ‘pedestrian area’ in OSM, traffic is free and has no fixed direction, but if you don’t draw a ‘highway’ inside that area, it doesn’t show up as a passing place.
Inside a runway, there could be multiple potential runways, but if it’s a defined path, I think it should be defined as a ‘highway’.
I think that’s the consistency within OSM.
Comment from Timmy_Tesseract on 12 June 2023 at 09:04
Any proposal to overhaul the convention of linear runways should include considerations on how this would be compatible with aeroway=aircraft_crossing.
Comment from Minh Nguyen on 12 June 2023 at 15:35
It may help to consider nontrivial examples such as an international commercial airport that typically has not only taxiways but also service roads for airport vehicles crisscrossing the taxiways and apron.
OSM is already being used by flight simulator games that make use of runway centerlines (as well as their surface areas) for rendering and gameplay. This is not routing in the sense of an OsmAnd user getting directions to the supermarket, but it is still relevant for a “navigable path” concept to be mapped.
Comment from GPar on 17 June 2023 at 14:03
In my opinion, the use of “area logic” would also require a change to acft stands, taxiways, taxilanes, holding bays, service roads, etc. Don’t forget there are many grass /ice runway where we can’t define pavement/clearance limits, at least from a sat image. And as mentioned above, it would be problematic to manage intersections. On the other hand,I believe that the need to manually calculate declared distances involves few non-certified aerodromes in remote corners of the planet. In fact, when pilots use commercial aerodromes certified by EASA/FAA, etc., they always have a country official aeronautical publications available, or a jeppsen chart. They certainly don’t search an osm tag… Thank you for this interesting discussion!