https://openstreetmap.org/copyright | https://openstreetmap.org |
Copyright OpenStreetMap and contributors, under an open license |
https://openstreetmap.org/copyright | https://openstreetmap.org |
Copyright OpenStreetMap and contributors, under an open license |
Donau-Oder-Kanal gibt es nur einen, nicht I, II, III. Dass nur noch Fragmente übrig sind, ist ein anderes Thema.
Den Kanal als solchen gab es nie, denn er wurde nicht fertiggestellt, nur die vier Becken, welche die Bezeichnungen "Donau-Oder-Kanal Becken I" ff. (II, III, IV) tragen, welche auch von der Stadt Wien (siehe https://www.wien.gv.at/freizeit/baden/natur/naturbadegewaesser.html) und der Wassergenossenschaft von Teil IV (siehe http://www.dok4.info/wsg_archiv/chronik.php) verwendet werden. Eine sinnvolle Beschriftung, welche diese mehrfach verwendete Nummerierung berücksichtigt, könnte daher mit Verwendung des Wortes "Becken", also nach dem Schema "Donau-Oder-Kanal Becken II", etc. erfolgen.
Ich seh das wie derloris. Die Becken sind eigenständige Wasserflächen mit sehr unterschiedlichen Eigenschaften und es sind auch offiziell und umgangssprachlich eigene Namen dafür in Verwendung (weitere Beispiele https://www.ots.at/presseaussendung/OTS_20170719_OTS0023/abkuehlung-in-den-naturbadegewaessern-der-millionenstadt , https://infothek.donauauen.at/fileadmin/Infothek/3_GeschichteNPDA/32_GeschichteNPDAabErricht/321_GeschichteNPDAGmbHMedien/3216_Wege_Freizeitnutzung/32163_Baden_Boot/04_00657_BadenBootZeltimNPDA_2012.pdf ). Da diese Namen auch zur Orientierung sinnvoll in OSM eingetragen gehören, würde ich Folgendes vorschlagen: Wir setzen die entsprechenden name tags auf die Becken und erstellen für das Gesamtprojekt eine Relation mit dem Hauptnamen. (Über den Relationstypen kann man streiten... ich würde site nehmen, weil water*way* nicht wirklich passt, aber mit dem wäre ich auch einverstanden).
Wenn man das, was vom Donau-Oder-Kanal noch übrig ist, als eine Menge von Teichen mit unterschiedlichen Eigenschaften ansieht, dann bitte type=cluster. Mein Proposal dafür hab ich genau für solche Fälle erstellt.
type=cluster hat nicht besonders viele Anhänger gefunden bisher (ums vorsichtig auszudrücken) und ist auch nicht passender als site. Als MP wäre auch noch eine Möglichkeit - die Eigenschaften der Becken werden ja auf den Ways gemappt. Spricht dagegen irgendwas?
Bei einem MP müsstest du natural=water zusätzlich auf die Relation setzen, womit die Wasserflächen doppelt gemappt wären, was zu eigenartigem Rendererverhalten führen kann. Außerdem ist das keine grundsätzliche Lösung zum Zusammenfassen von Objekten, weil z.B. Nodes (POIs) als members nicht erlaubt sind.
Das Proposal für type=site wurde schon oft geändert und hat sich durch den Wegfall der Rollen inzwischen type=cluster angenähert, aber site verlangt immer noch ein main-tag und wird immer noch vorwiegend für Institutionen verwendet. Im Proposal steht im Moment sogar explizit, dass man für natürliche Objekte type=cluster verwenden soll.
Ich würde auf die MP-Relation nicht natural=water taggen - das ist ja nicht das definierende Feature in diesem Fall - sondern waterway=canal. Gibt auch noch ein paar andere, eher zweifelhafte Alternative (z.B. man_made=waterway). Dass es kein perfektes Schema in diesem Fall gibt, ist auf Grund der speziellen Umstände klar.
Das mit "natural objects" steht seit 2015 in dem site-Proposal als cluster noch eine Chance auf Umsetzung hatte - das würde heute wohl kaum mehr jemand reinschreiben. In diesem Fall geht es aber ohnehin um ein künstlich geschaffenes Objekt (die Schreibweise der Keys wie natural und die Unfähigkeit der Community diesbezüglich ist da ja zweitranging - darauf bezieht sich keines der 2 Proposals sondern auf den Wortsinn).
waterway=canal geht nicht auf Flächen, nur auf Linien.
Es ist nicht vorgesehen, "gehen" tuts schon und mit der entsprechenden Role is es auch klar und sollte keine Probleme machen, aber ideal is es nicht.
Was schlägst du vor?
Redest du noch von einem MP? Da gibts als Rollen nur "outer" oder "inner". Dass ich zum reinen Zusammenfassen eine Cluster-Relation bevorzuge, hab ich eh schon geschrieben. Wenn es aber waterway=canal werden soll, bietet sich eine Multilinestring-Relation an.
Jein, ich hab mich verschrieben. Entweder MP mit waterway=canal als Key (und outer Roles) oder waterway-Relation mit waterbody Roles.
Die Cluster-Relation passt am wenigsten von allen Varianten, wie du eigentlich selbst schon beschrieben hast.
Nachdem ich selber der Proponent des cluster-Proposals bin, maße ich mir an zu wissen, wofür es passt. ;-) Also für eine Relation, die nur type=*, name=* und die members enthält, passt es am besten. waterway=* als Flächen, naja, das ist so ähnlich wie highway=motorway mit area=yes: Da kann man nur beten, dass alle Anwendungen es ignorieren. Im Gegensatz zu area:highway=*, dessen Proposal nie fertig geworden ist, ist natural=water (+ water=canal) doch ein längst anerkannter Standard um die Fläche zu mappen, oder hab ich was übersehen?
Ich hab jetzt einmal die Beckennummern eingetragen
Ok, die Mehrheit ist ja eh für das Beschriften der Becken gewesen. Kann man dann die Note schließen?