Das stimmt ja mal hinten und vorne nicht.
osm.wiki/DE:Points_of_interest#POIs_in_OpenStreetMap
osm.wiki/DE:One_feature,_one_OSM_element

The wiki can be changed but there should be discussions about it and first of all these runway sections needed to be added in the first place. There have been suggestions a long time ago: osm.wiki/Talk:Aeroways#Sections_of_a_runway
I suppose that those guys just tagged the runways in a way they thought was appropriate. Did you have a look at this at a global scale?
'observe how things are done' - of course. That is still my suggestion to new members and most of the time it is the right way to go but what I did not mean was observe how things were done 5 years ago. There are a lot of deprecated features that might not be wise to use anymore. Keep in mind as well that OSM if full of errors.
Back to the runway sections. In my opinion these ends are part of 'both' runways as you would call it, because in emergency use of a runway they may serve as overrun areas. That is to say that all sections might be used in both directions, but some only in emergency use of a runway which is still a valid use.

Just so that you don't get me wrong, 'new user' was not supposed to sound negative.

To be honest this blast_pad and displaced_threshold thing was not widely spread. I stumbled about it at some point of time and I then added way more than there have been before to airports around the world. There is no rule for these appendixes of runways but they are officially part of the runway, that is why I added them as ways and not as nodes.
The wiki says that runways should be tagged with both numbers. I know that some runway ends have been tagged only with one number but there were just a minority on a global scale.
If you don't know taginfo, check it out. You can display the tags on a map if you click on 'Overpass Turbo' in the top right. It is a cool and very useful tool. https://taginfo.openstreetmap.org/tags/?key=runway&value=displaced_threshold#overview

1. OSM will never be accurate enough for air traffic.
2. There is the rule that for one physical object there should only be one element in OSM.
Have a look at the wiki: aeroway=runway

Your account is quite new so I suppose that you are new to OSM. Some new members tend to make drastic changes to the data because they think that things are done wrong, but usually those changes to more harm than good. To begin please observe how things are done and check the wiki if you are not sure. You also have the option to ask on your local mailing list or the forum.

I fixed some things but I don't see why thresholds and blast pads should not carry the full name of the runway.

Joa, könnte man so sagen. Danke für den Hinweis. Die Regel ist ja aber eindeutig erkennbar, ich werde es kurz anpassen.

Hi, definitively no import here. Sorry if I made a mistake. I did only delete airports tagged as nodes and polygons at the same time, but prior to that I copied the information form the node to the existing polygone. Maybe I oversaw those brackets. I don't think that I did copy that info from wikipedia including brackets. Please fix this if you know better.

OSM is a database, not a map. You can render a map from this database and that is what Mapnik does. There are a ton of things that are not rendered by Mapnik at all. But those might be rendered by others. Just because Mapnik does not render parking_positions you should not tag them incorrectly to show up in Mapnik.
Just continue reading the site I showed you: "Don't deliberately enter data incorrectly for the renderer." This is what you are doing.

Tagging for the renderer is commonly disliked in OSM. This means that you should not use tags to make things show up on a specific map. If you want a certain thing to show up on a map then you need to create your own map with your own renderer. Just because nobody did notice before does not make it right. There is a tag for parking positions so there is no need to use a wrong one.
osm.wiki/Tagging_for_the_renderer

Hi, why do you keep tagging parking_positions as taxiways?

@FreedSky: I don't know to whom you are referring to as "you" and "he" and I don't think that "the definition" exists.
@Austin Zhu: If you have read a lot of books then you certainly know more about this topic than I do, I only got my info from Wikipedia. I still would not consider these areas as part of the runway but if you do that is fine for me as long as you don't just want them to be rendered in grey.

Please keep in mind that we are not supposed to map for the renderer. That means that we shall not map something to make it look better on a certain map.
When there is no tag for a certain feature then you should not use a different one just to make it show up on a map.
I have had a look at hundreds of airports in OSM and I can tell you that blast pads or overrun areas are generally not mapped at all. By mapping the grass around them you could achieve some sort of rendering. You can find this way of mapping at different airports. A different approach might be to tag it as aeroway:overrun, this is not documented but used on 70 ways in OSM.

No it is not. Here is my proof:
1. These runways have a length of 3800 m wich is the length without the blast pads. Lengh with blast pads is 4000m -> https://en.wikipedia.org/wiki/Shanghai_Pudong_International_Airport
2. Quote from wikipedia: The runway thresholds are markings across the runway that denote the beginning and end of the designated space for landing and takeoff under non-emergency conditions.
The runway is the surface from threshold to threshold, which typically features threshold markings, numbers, and centerlines, but not overrun areas at both ends.
-> https://en.wikipedia.org/wiki/Runway#Sections_of_a_runway

Ja, klar, mein Fehler. Habe es korrigiert. Danke :-)

Moin, die lange Version kannst du gerne unter official_name=* eintragen. Bei name=* wird in OSM eben dieses Schema verwendet. Steht auch so im Wiki.

Moin,
ich habe diesen Änderungssatz rückgängig gemacht, weil er überwiegend falsche Änderungen enthält.
Der Name ist so korrekt wie er jetzt wieder ist und die Gebäude haben in der Relation nichts verloren.

Moin, ich antworte mal in gleicher Reihenfolge auf deine Stichpunkte.
- guter Hinweis
- alles klar, war mir so nicht bewusst, sehe ich natürlich ein
- Mir war nicht bewusst, dass die Vogelperspektive von Bing nicht genutzt werden darf, gut dass ich das bisher auch nicht getan habe.
- Ich bin dennoch der Meinung, dass dort zu viele Gebäudeteile sind. Wenigstens auf den beiden Seiten des Überganges würde ich nur ein Gebäude einzeichnen.
- Ich habe im Brangenbuch keine weiteren Firmen mit 14-20 gefunden, daher hatte ich die Node gelöscht. Ich habe mich hier auf die Firmen in 21-22 bezogen.
- Stimmt.
- Ich hatte erstmal nicht vor viel in Berlin zu tun. Ich habe nur die OVs in eine bereits vorhandene Relation eingefügt, wollte dabei diesen OV nur einmal einfügen. In wie fern ALKIS-Daten verwendet werden dürfen, damit habe ich noch nicht befasst. Ist aber gut zu wissen. Danke.

Noch als Hinweis: Die beiden Firmen, dich ich im Südosten eingezeichnet habe, haben beide die Hausnummern 21-22.

Ich kenne mich mit diesem OV selber nicht aus. Ich bezweifle aber, dass alle diese Gebäude zum THW gehören. Das wäre einfach zu groß. Auf der Seite vom OV steht, dass sie sich auf dem Gelände der Firma Piepenbrock befinden. Daher halte ich es auch für Sinnvoll, den OV nur als node einzuzeichnen.
Ich habe jetzt mal recherchiert, welche Firmen sich in den Gebäuden befinden und diese dann eingetragen. Die Gebäude habe ich bearbeitet, da man auf den Luftbildern eindeutig sehen kann, dass die Umrisse sich verändert haben. Siehe Zickzacklinie. Die Trennung von 14-20 und 21-22 habe ich beibehalten, allerdings habe ich die restlichen Gebäude vereinigt und 3D-Gebäude gebastelt.
Änderungssatz: 48226416

Could you please stop tagging parking positions as taxiways. One of the top rules of OSM to NOT use wrong tags in order to make something show up on a map.
If something does not show up on the map it is because the makers of that map don't want it to show up. Mapnik does not show parking_positions.

Ich habe vor längerer Zeit nur dafür gesorgt, dass die einzelnen Ortsverbände in der Relation sind. Eingefügt habe ich i.d.R. das jeweils mit Adresse vorliegende Objekt. Es kann sein, dass ich bei einigen auch erst die Adresse eingefügt habe, das kann ich nicht genau sagen.