Ausgehend von der CS-Diskussion hier: https://www.openstreetmap.org/changeset/113646419#c785195
Hab ich mal ins Wiki geschaut, dort steht:
(Hervorhebung von mir)
wo ich mich dann frage, wieso
a: aeroway eine Sonderrolle zu highway&Co spielen soll
b: wie bringe ich an einem runway unterschiedliche Eigenschaften wie surface/width/bridge oder ähnliches unter?
c: ist die Beschreibung im Wiki falsch/ nicht zu Ende gedacht?
Gut das die Diskussion hier geführt wird. (aber bitte meine Rechtschreibungs/Grammatikfehler vergeben, bin ja ein blöder Ausländer 
)
In diesem Sonderfall (Piste ist teils Gras, teils hartbelegt) fürchte ich mir, wir können nur die Piste mappen als eine Relation, zusammengestellt aus ein Teil “hart” und ein Teil “Gras”. Nur die Relation bekommt dann Infos wie Länge, ref, usw. Ich vermeide lieber Relationen, hier aber sehe ich keine andere Möglichkeit.
Mehr allgemein: der Parallelismus zwichen highway= / railway = / aeroway = und veilleicht noch andere mehr, ist eine schöne Gedanke, hat aber so seine Grenzen. Strecken von Straßen oder Eisenbahnen können in Relationen zusammengefasst werden zu Routen und anderes mehr, das gilt aber nicht für Runways. Dort ist die Länge eine viel wichtigere Information.
Deswegen sehe ich auch nicht warum Runways nicht als area= gemappt werden können oder sollen - aber das is noch 'ne andere Diskussion
Das hab ich auch schon überlegt, aber Wiki sagt: keine Relation für runways - taginfo meint, es gibt nur 111 Relationen weltweit.
Wiki ist ja auch nur ein Sammlung von Hinweise, Tipps, “common practice”. Wiki ist kein hartes Gesetz. Unübliche Situationen, wie diese, sind im Wiki nicht vorgesehen. Dass es nur wenige Runways als Relation gibt, illustriert klar das es sich wirklich um Ausnahmen handelt.
Hier überlappen sich doch schon wieder einige Sachen:
surface=* oder tactile_paving=*. Multipolygone funktionieren da laut Definition nicht.Das Problem hier sind aber nicht Flächen, sondern runway-ways.
Jan und/oder das Wiki sagt, dass eine runway eine einzige Linie ist und nicht zwei (wie das bei Strassen, Wegen oder Wasserwegen usw. bspw. total normal ist, dass die aus mehreren Linien bestehen).
Edit:Typo
Gut, dann solten doch aber zumindest die Editor-Software nicht zum Flächenmappen einladen oder sogar eine Warnung ausgeben.
Wenn ich jetzt darauf beharre, dass die Landebahn als ein Objekt dargestellt wird, bleibt mir ja nur surface=mixed oder surface=grass;paved,grass oder eine multilinestring-Relation.
Es gibt kein guter Grund, eine Flugzeugpiste nicht als Fläche zu mappen - est ist ja doch letztendlich eine Fläche? (weder Beton oder Grass oder Eis oder was auch)
Das ist aber nicht wirklich die Frage - es geht eigentlich darum, wie man eine Piste mappt die aus verschiedenen Teile besteht, wie in diesem Beispiel ein Teil Gras und ein Teil hartbelegt. Wichtig dabei ist, das irgendwo die Gesamtlänge gegeben ist - Länge is die erste und weitaus wichtigste Eigenschaft einer Flugzeugpiste.
Könnt Ihr Euch bitte mal einigen? Brauchen wir jetzt Lösungen für offenen Linien, Flächen, eine Mischung oder eventuell beides? area:aeroway=* gäbe es ja auch noch.
Im Endeffekt geht es ja darum ein Objekt zu definieren, was aus mehreren Teilen mit unterschiedlichen Untertags besteht.
Ich verstehe ja, dass die Länge am wichtigsten ist, allerdings ist mMn der Belag der Piste doch schon interessant und es macht einen Unterschied of nur ein Drittel oder zwei Drittel der Gesamtlänge asphaltiert sind.
Wir sind uns ja einig, dass wir uns nicht einig sind. 
Wo wir uns einig sind (glaube ich), dass area und Flächen NICHT unser Problem ist. Siehe die beiden letzten Beiträge von Jan und mir.
Ich würde hier ganz pragmatisch herangehen und überlegen, welche Information die Wichtigste ist. Die Start- und Landebahn in zwei Abschnitte zu teilen, halte ich für problematisch. Daher würde ich sie nicht in zwei Linienabschnitte aufteilen wollen.
Aus diesem Grunde würde ich lieber surface weglassen, als die Piste in zwei Abschnitte zu teilen. Oder eben surface=asphalt;grass eintragen.
In Sachen Flugplatz- und Flughafen-Tagging ist OSM tatsächlich noch nicht sonderlich ausgereift. Was auch daran liegen mag, dass hierfür einiges an Spezialwissen notwendig wäre. Und ich glaube kaum, dass sich Flieger bezüglich Informationen über die Länge und die Beschaffenheit von Landebahnen wohl kaum auf Infos verlassen werden, die jeder beliebig ändern kann. Daher habe ich auch kein Problem damit, dass in an dieser Stelle OSM nicht so detailliert ist, wie z.B. bei Straßen.
ich hab mich jetzt dazu entschieden, den Gras-bewachsenen Teil zu löschen (was allerdings die inkonsistenz zw. highway vs aeroway nicht löst)
Grund: auf den verfügbaren Luftbildern ist die Gras-Piste wenig bis gar nicht mehr erkennbar. Kann daran liegen, dass die Betonpiste irgendwann die letzten Jahre verlängert wurde und dadurch die start/lande-bedingungen verbessert/verkürzt wurde und die “Verlängerung” da wieder zuwächst (ursprünglich war das da komplett Rasen).
Alternativ wäre glaube die zweitbeste Lösung gewesen, surface am way wegzulassen und an die area drumrum zu packen. Das wertet dann allerdings wahrscheinlich niemand aus…
Fun-fact: mein Benutzerbildchen hier … ist eben jener Flughafen+gpx