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.

@alexnevermaps: I sent you a private message, did you notice?

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!

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] osm.wiki/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] osm.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

Wees er allemaal op bedacht dat er twee aparte nummeringen zjn in Antwerpen: die van de Scheldekaaien (die weliswaar amper gebruikt worden) en die van de dokken.