Im Wiki steht dass es beide Varianten gibt, und dass die “moderne” Variante mit area:aeroway stark zunimmt.
Gerendert wird es glaube ich noch nicht.
https://wiki.openstreetmap.org/wiki/Tag:aeroway%3Drunway
Ob man das Pushen der neuen Variante durch MapRoulette als zulässig annimmt möchte ich nicht beurteilen.
Diese Geschichte ärgert mich schon lange. Für mich zählt es, jede Piste EINMAL zu mappen; also ein aeroway=runway und dann dazu ein area:aeroway=runway finde ich unkorrekt; eben wenn es von sonstige empfohlen wird. Es steht quer auf dem Grundprinzip “Each element in the landscape should be mentioned one and exactly one times in our database.”
Dagegen siehe ich kein Grund, eine Piste nicht als Fläche zu mappen, also als “way”, mit “aeroway=runway” plus “area=yes” plus noch weitere. Hierüber rezent noch diskutiert im changeset 121745909, mit einem/eine der/die das Wiki fur hartes Gesetz nimmt, was es mMn nicht is.
Die Empfehlung wegens MapRoulette is für mich komplett falsch, und sollte nicht sein. Mir scheint, sie is ein wichtiger Grund des Zuwachses dieses lächerliche “area:aeroway=runway”-Tags - lächerlich wegens ganz komplett total überflussig. Ich zähle etwa 1000 in Europa alleine - 1000 unnötige Einträge in unsere Database.
Die neue Variante ist halt äquivalent zum Straßenflächenmapping (area:highway) mit all seinen Vor-und Nachteilen.
Es hat aber mW. kein abgestimmtes Proposal dazu gegeben.
Die Äquivalenz mit Straßen/Eisenbahnen geht nicht wirklich auf: Straßen und Eisenbahnen lassen sich zusammennimmen zu Routes, das gilt aber nicht für Runways.
Abgesehen davon, dass eine Maproulette Aufgabe mit diesem Inhalt in meinen Augen ein (offensichtlicher und nicht zulässiger) „Trick“ ist, um keinen automatischen Edit zu beantragen sondern das mit einer kleinen Gruppe Freiwilliger ohne Diskussion durchzuziehen, funktioniert die „Regel“ des einen Features das von einem OpenStreetMap Element repräsentiert wird, nicht wirklich, es gibt keine Features in der Realität, sie entstehen erst durch Interpretation, und wenn ein „Feature“ die Rollbahnoberfläche beschreibt, und ein anderes die Rollbahn, dann ist die Regel nicht unbedingt verletzt.
Wenn ich ein building=yes mappe beschreibt das das gesamte Gebäude (Volumen inkl. Dach, natürlich nur näherungsweise). Wenn jemand dann ein Dach extra mappt, ist das völlig ok, das Dach ist nach deiner Zählweise dann aber doppelt gemappt, weil es im building=yes auch schon dabei war…
Das verstehe ich nicht, caro Dieter, non capisco 
!
Wenn hier eine Fabrik steht, und dort lauft ein Bach, was ist daran zu interpretieren? Die Fakten sind was sie sind, wir haben uns die Aufgabe gestellt, sie in eine Geo-Datenbank zu registrieren. Nicht mehr, nicht weniger.
Und nein, auch das Dach sollte einmal und nur einmal in unsere Datenbank sein, und ist schon da, als Teil des Hauses. Oder mappen wir ab jetzt Fenster, Türen, Dächer, usw. separat? Was meinen wir dan noch mit ein “Haus”?
man kann Fenster, Türen und Dächer auch separat mappen, klar, und wenn man das tut wird man building=* nicht weglassen.
Wir mappen auch sonst building:parts ohne dass building deshalb überflüssig würde, oder area:highway ohne dass highway deshalb gelöscht werden sollte. Oder man mappt einen Bordstein, obwohl der doch Teil der Straße ist und im highway auch schon enthalten wäre
Wenn man eine Stadt mappt (node mit place=town), sind deren Stadtviertel dann darin enthalten?
Was die Features angeht, den Bach oder die Fabrik, solange das in allen Sprachen gleich gesehen und definiert wird, funktioniert alles wunderbar, aber wenn in einer Sprache Unterscheidungen gemacht werden die es in einer anderen nicht gibt, wird es schwieriger denen überhaupt den Sinn einer Unterscheidung näherzubringen. Beispiele die mir spontan einfallen sind z.B. “Stall”, “Schloss”vs”Burg”, Grab (tomb und grave) und sicher noch viel mehr (erst recht wenn man Sprachen ansieht die sich weniger ähnlich sind als Deutsch und Englisch)
Dann reicht doch auch ein node mit planet=earth oder? SCNR
Was auch immer du als Feature definierst, jeder Mapper wird es in unterschiedlicher Detailstufe definieren und in der Datenbank benötigen. Wenn ich die Tür nicht separat erfasse, wie soll ich dann die Lage der Tür erfassen? Woher soll ich als Anwender wissen, wie ich in das Haus rein komme oder als Lieferant meine Ware abgeben soll?
Okee, über Dächer und Türen und Fenster schweige ich.
Aber in Sachen Rollbahnen/Pisten/Runways bleibe ich dabei: nur EIN MAL in unsere Database eintragen, bitte. Das ganze area:aeroway=runway ist überflussig, bringt zero/nihil/null-komma-null Mehrwert.
Hallo zusammen ich muss das Thema leider noch mal aufwärmen, weil ich da jetzt auch reingetreten bin. Laut Wiki soll die Mittellinie der Bahn als areoway=runway gemappt werden und wer die Fläche mappen mag als area:areoway=runway. Dementsprechend wollte ich jetzt wenigstens die Runways die als Flächen gemappt sind aber nicht mal ein area=yes haben danach korregieren. Dabei ist mir jetzt aufgefallen, dass es diese maproulette challange gab um das zu vereinheitlichen. Danach hat aber ein User genau diese Änderungen (in fast allen Fällen die ich bearbeiten wollte) wieder zurück geändert und die runway Mittellinien wieder gelöscht.
Ich finde es noch problematischer als eine unabgestimmte maproulette challange, wenn ein User genauso unabgesprochen(?) entgegen der Dokumentation alle Sachen wieder zurück ändert und Arbeit anderer löscht.
Eine Vereinheitlichung fände ich ja wünschenswert, aber undokumentiert/unabgesprochen auf eigene Faust finde ich das nicht so optimal.
Zum Thema, “area:aeroway=runway ist überflüssig”:
Überall sagt die Doku, dass die runway als Linie und nicht als Fläche gemappt wird. Demenstsprechend finde ich es ein bisschen komisch, wenn Korrekturen von diesem Vorgehen wieder zurück gesetzt werden und die Runway als zentrale Linie gelöscht wird. Zumal nur mit der Runway als zentrale Linie Taxiways richtig verbunden werden können (z.B. für Routing).
Gleichzeitig denke ich, dass bei solchen großen Flächen wie Start/Landebahnen immer wieder Menschen das verlangen haben diese als Fläche zu mappen. Das finde ich nicht falsch, weil es einfach große Objekte sind, die an andere Flächen wie Taxiways oder Vorfelder angrenzen/verbunden sind. Natürlich könnte ein Renderer jetzt die Breite der Runway beachten, aber nicht alle runways sind mit einer Breite getaggt, weil es wahrscheinlich einfacher ist eine fläche zu mappen, als die Breite heraus zu finden. Außerdem sind nicht alle Runways rechtwinklich abgeschlossen. Von daher finde ich area:aeroway=runway für die Fläche keinen schlechten Kompromiss um zwischen der Mittellinie und der Fläche zu unterscheiden.
Und es ist auch nicht so, dass Mittellinie+Fläche jetzt einzigartig für Runways wäre. Bei Flüssen machen wir das ja auch so.
Jedenfalls, nur weil man persönlich area:aeroway=runway überflüssig findet, finde ich es keine gute Praxis die Arbeit anderer Menschen, die das für sinnvoll halten, zu löschen.
Auch das Argument, dass eine Fläche oder die Mittellinie als zusätzlichen way kostbaren Platz in der Datenbank verschwenden würde finde ich sehr übertrieben. Mit dem Argument könnte man einfach jedes genauere Mapping in OSM verbieten. Das wiederspricht meiner Meinung nach der Philosophie von OSM.
Jedenfalls, nur weil man persönlich area:aeroway=runway überflüssig findet, finde ich es keine gute Praxis die Arbeit anderer Menschen, die das für sinnvoll halten, zu löschen.
+1
es gibt ja auch Landebahnen die nicht rechtwinklig sind (ob die das auch offiziell nicht sind oder ob man da nur die kleinste Breite angibt weiß ich allerdings nicht, und theoretisch könnte man die auch noch mit Breitenangaben auf den Endpunkten abbilden, sofern die Seiten wenigstens linear sind)
Löschen - und damit Informationsverlust - geht gar nicht. Die entsprechenden Changesets sollten revertiert werden.
Wo findet man denn dieses Grundprinzip beschrieben?
Wenn Du also einen natürlichen Fluss hast, det als Linie abgelegt ist und Du zeichnest an einer gewissen Stelle die Wasserfläche ein würdest du dann f<r dieses Stück die Linie löschen?
Hallo, guten Abend!
Schaue mal hier:
https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element
Es gibt aber Ausnahmen! Wie so manches im Wiki ist dies keine feste Regel, eher “gute Praxis”.
Aber im Fall einer Start/Landebahn sehe ich keinen Grund fuer Ausnahmen. Alle relevante Infos gehen perfekt im aeroway=runway hinein, die area:runway ist MMn voellig ueberfluessig und damit eine Verschwendung von Ressourcen.
Ueber Fluesse habe ich ueberhaupt nix zu sagen
Herzlich,
Karel A.J. ADAMS
----- Mensagem de Skinfaxi via OpenStreetMap Community Forum <community@noreply.openstreetmap.org> ---------
Ja Danke.
Die Wikiseite hinterlässt einen mit einem ungläubigen “thats it”?
Im Gesicht.
Mittlerweile scheint es ja eher die Regel als die Ausnahme zu sein, Dinge aus verschiedenen Blickwinkeln zu betrachten und dadurch Daten doppelt und dreifach zu hinterlegen. Was ist jetzt das eine Objekt? Die Bushaltestelle mit Sitzbank, wartehäuschen und Papierkörbe oder der Papierkorb mit Deckel, separater (fandabstellmöglichkeit 7n dem man aber keine Binden entsorgen darf der zufällig neben einer Bushaltestelle steht…
Die Diskussion sollten wir in diesem Thread nicht weiterführen weils das Ursprungsthema kapert.
Diese sogenannte Diskussion sollte nicht nur nicht weitergeführt werden, sondern beendet werden, weil es sich - wie hier üblich im Forum - um weitestgehend profilneurotisch-nerdiges Gelabber und endlose Korinthen-Kackerei handelt …
Siehe das Doppelhaus-Thema oder den Mini roundabout Komplex 
https://wiki.openstreetmap.org/wiki/DE:Ein_Objekt,_ein_OSM-Element
Ist doch hiermit fast alles gesagt!
Typisch Peer
@Peer_van_Daalen wenn du nichts zu den genannten Themen beitragen kannst oder willst, ist das Ok. Dann halt dich aber bitte auch einfach raus und spar dir diese unangemessenen Offtopic-Beiträge, in denen du wieder mal nur über die Community lästerst. Danke.
Schaue mal hier:
https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element
Es gibt aber Ausnahmen! Wie so manches im Wiki ist dies keine feste Regel, eher “gute Praxis”.
es ist schon eine feste Regel, aber sie bringt konkret nichts wenn es um Entwicklung von neuen tags geht, weil wir selbst festlegen was ein tag bedeutet. Wenn ein tag die Straßenfläche beschreibt, und einer die Straße als Verbindung, dann ist das kompatibel mit der Regel, 2 Objekte die jeweils einen definierten Teilaspekt beschreiben.
Wenn man z.B. behauptet, highway=secondary mit bridge=yes beschreibe eine Brücke, dann wäre man_made=bridge doppelt, aber wenn es einen Weg auf einer Brücke beschreibt, nicht.
Oder atm=yes bei einer Bank. Wenn das nur aussagt dass die Bank mind. 1 atm hat, dann ist es kein Fehler gleichzeitig einzelne atms dort zu mappen. Die Bedeutung definieren wir.
Ich habe oben schon mal beschrieben warum ich es nicht überflüssig finde. Und ob jetzt ein paar byte in der Datenbank resourcen verschwenden, oder die renderer, die sich zur richtigen Darstellung der Fläche für jede Zoomstufe die Breite neu berechnen müssen kann man streiten. Aber wenn der Renderer mit area:aeroway=runway eine Fläche malen könnte, aber keine stimmige Fläche malen kann, wenn die Breite nicht an der runway steht, dann gehen uns Informationen verloren, wenn wir aufs Flächenmappen verzichten.
Ich finde es halt einfach ungeschickt, wenn du regelmäßig anderer Arbeit entgegen der Dokumentation änders, nur weil du der Meinung bist, dass etwas überflüssig ist. Das führt einfach nur dazu, dass immer wieder andere Menschen es nach der Doku korregieren wollen, weil sie drüber stolpern, und du es danach wieder zurück änderst. Und das ganze hin und her ist die wahre Resourcenverschwendung und sorgt nebenbei für ständig inkonsistente Daten und frustration auf allen Seiten.