Ändern vorhandener Einträge am Beispiel "Schleusen"

Moin,
ich bin blutiger Anfänger als “Mapper” und versuche gerade, meine Ortskenntnisse als Freizeitkapitän in Form von Seamarks für OpenSeeMap beizusteuern. Bisher habe ich hautpsächlich fehlende Informationen ergänzt oder kleine inhaltliche Änderungen vorgenommen.

Nun stoße ich aber zunehmend auf vorhandene Einträge, die von den Wiki-Vorgaben abweichen. Nehmen wir mal als Beipiel eine Schleuse.

Das Mapping einer Schleuse ist hier klar beschrieben: https://wiki.openstreetmap.org/wiki/DE:Key:lock
Die Schleuse ist damit erst mal eine Linie als Teil des Wasserweges (lock=yes und waterway=canal). Zusätzlich kann die Fläche der Schleusenkammer getaggt werden, und zwar mit natural=water und water=lock.
In wenigen Fällen ist die Schleusenkammer zusätzlich mit lock=yes getaggt, was nach dem Wiki falsch ist und beim Rendern einer Seekarte dazu führen kann, dass der Schleusenname doppelt angezeigt wird (einmal für die Schleuse selbst und einmal für das Schleusenbecken).

1. Frage: Spricht etwas dagegen, solche Einträge an die Vorgaben laut Wiki anzupassen und den falschen Tag lock=yes zu löschen? Es sind wie gesagt wenige Einzelfälle.

Nun kann das Schleusenbecken zusätzlich noch mit seamark:type=lock_basin getaggt werden, was im Wiki allerdings als überflüssige Redundanz angesehen wird. https://wiki.openstreetmap.org/wiki/Tag:seamark:type%3Dlock_basin
In Deutschland und einigen Nachbarländern haben Mapper das aber trotzdem knapp 1000 Mal so gemacht. Allerdings wurde der Tag für die Schleuse selbst (also die Linie) verwendet und nicht für das Schleusenbecken (die Fläche), was nach diesem Wiki-Eintrag falsch ist: https://wiki.openstreetmap.org/wiki/Item:Q6969

2. Frage: Sollte hier nicht der Wiki-Eintrag an die Wirklichkeit angepasst werden und wenn ja, wie könnte man das erreichen?

P.S. Ich hätte die Frage gerne im OpenSeaMap Forum gestellt, aber das scheint tot zu sein.

Gruss aus der Hauptstadt,
Gerhard

Wenn Du es besonders sorgfältig machen willst, kannst Du ggf. auch die englische tag-Seite noch ansehen.
Auf der deutschen Seite fällt mir auf, dass die Schleuse aus einer Kammer mit 2 Toren besteht. Ist das so, dass man bei mehrstufigen Schleusen (insbesondere solche, wo die Stufen nicht unabhängig sind) von mehreren Schleusen spricht?

genau, abgesehen von möglichen aber nicht sehr wahrscheinlichen Problemen beim Rendering der Namen ist es m.E. ein grundsätzlicher Fehler, zweimal dieselbe Schleuse zu taggen (wobei das ein allgemein bestehendes Problem ist, das z.B. auch bei place auftaucht, und wo man sich auch auf den Standpunkt stellen könnte, dass das trotzdem korrekt ist, weil sich aus den Daten ergibt, dass es dieselbe Schleuse ist, von der einmal der waterway und einmal die Fläche getaggt ist (weil der waterway innerhalb der Fläche liegt). Das ist aber soweit ich weiß nicht vollständig geklärt wie “wir” das sehen. Es gibt zwar die Regel "Ein Ding sollte einem OSM-Ding entsprechen, aber man könnte da ja sagen, ein Ding ist die Schleusenkammer und eins der waterway innerhalb der Schleuse (also ein Attribut auf dem Waterway, dass dieser Teil innerhalb der Schleuse liegt). Diese Regel hilft also m.E. nie in solchen Fällen, um das logisch zu lösen.

Ich finde es gut, dass Du die Frage hier stellst und es nicht einfach änderst.

die seamark-tags finde ich grundsätzlich merkwürdig, weil der Schlüssel sagt es ginge um Seezeichen, aber die Tags wollen oft ganz andere Dinge repräsentieren als Seezeichen. Die allgemeine Einstellung dazu ist glaube ich, dass man diese Spezialisten parallel werkeln lässt und die “Spezialtags” nicht anfasst, außer man ist selbst ein seamark-mapper :wink:

Grundsätzlich ja, sollte man machen wenn die Seite nicht die Praxis beschreibt. Um das abzuchecken ist eine Diskussion im Forum oder auf der Mailingliste, ggf. auch auf der Diskussionsseite im Wiki, der geeignete Weg, Meinungen zu sammeln bzw. zu sehen, ob es Vetos gibt.

Eine mehrstufige Schleuse ist mir noch nicht unter gekommen, kannst Du mir ein Beispiel nennen? Was hier oft vorkommt, sind Schleusen mit mehreren Kammern die dann natürlich den gleichen Schleusennamen haben.

Gibt es eine allgemeine Spielregel, Einträge von anderen die offensichtlich falsch sind zu ändern oder zu löschen?

Danke für die Tipps!

…mehrstufige schleusen nennt man auch “schleusentreppe”.

https://de.wikipedia.org/wiki/Schleusentreppe

… habe inzwischen auch welche gefunden, z.B. in Frankreich. Das ist dann aber auch eine Schleuse mit mehreren Kammern.

Es kommt, wie dieterdreist schon andeutete, ein wenig drauf an, wie man „falsch“ definiert :slight_smile:

In diesem Fall finde ich es aber ebenso falsch wie du. Die Schleuse als abstrakte wasserbauliche Anlage wird durch den Way in der Gewässerlinie abgebildet (mit lock=yes und name=*). Eine explizit gemappte Schleusenkammer „ist“ nicht die Schleuse und trägt daher auch nicht den Namen der Schleuse. Nur wenn sie innerhalb der Gesamtschleuse einen Namen hat, so was wie „Südkammer“, kann der da natürlich dran.

Tagginglogisch besagt natural=water „Dieses Polygon umreißt eine Wasserfläche“ und water=lock „Diese Wasserfläche ist eine Schleuse“, da finde ich es reichlich unnötig, mit lock=yes nochmal die Aussage „Hier geht es durch eine Schleuse“ zu coden.

Man könnte die gesamte Anlage theoretisch auch als Relation erfassen. Dann kommt der Name der Schleuse an die Relation und die dazugehörigen Objekte mit ihren spezifischen Rollen alle da rein. Das wäre datenlogisch am saubersten, aber auch am aufwendigsten und pflegeintensivsten (immer an den nächsten Bearbeiter denken).

Grundsätzlich gehen wir immer davon aus, dass der Vormapper es nur gut gemeint hat. Im Zweifelsfall suchst du dir aus der Chronik des Objekts den Changeset raus, in dem die fragliche Änderung angebracht wurde, und sprichst deine Frage in einem freundlichen CS-Kommentar an. Hier im Forum fragen ist natürlich auch nie verkehrt :slight_smile:

–ks

So werde ich es machen, danke für den Hinweis!

Moin moin,

ich komme aus der gleichen Ecke wie Farbfan - kurz zum Hintergrund: es geht tatsächlich um die Darstellung von (im speziellen Fall Schleusen-) Elementen auf einem Nautical Chart, also einer primär Seekarte, und zwar konkret auf den von Sven Schönhoff betreuten Seekarten im AT5-Format https://wiki.openstreetmap.org/wiki/DE:AT5-OpenSeaMap-Chart_for_Lowrance_Simrad_B%26G, wie sie auf Kartenplottern der Navico-Gruppe (Simrad, Lowrance und B&G) Verwendung finden…

…von daher würd ich sagen, wir versuchen uns hier zumindest als seamark-mapper :wink:
Das eigentliche Problem ist, daß es speziell für Schleusen (und ähnlich für Häfen und Brücken) interessant wäre, die in OSM schon vorhandenen Zusatzinformationen (z.B. Betriebszeiten, Telefonnummern, Funkkanäle etc.) auf dem Kartenplotter anzuzeigen. Damit das funktioniert muß beim Erstellen der AT5-Karten ein entsprechendes Objekt erzeugt werden, was auf dem Plotter dann ein anklickbares Symbol ergibt, das eine Seite mit den Zusatzinfos aufruft. Bisher hat Sven das nach seiner Aussage für Schleusen so implementiert, daß er das tatsächlich aus ‘seamark:type=lock_basin’-Objekten macht, nach dem wiki wäre aber ausgerechnet dieses a) für Linien (also den waterway innerhalb der Schleuse) prohibited und b)generell zumindest nach dem englischen wiki redundant und überflüssig - wobei ich letzteres Argument etwas merkwürdig finde, weil seamark:type=gate für die Tore der Schleuse offenbar schon verwendet werden soll.

Danke für die Einschätzung - wäre dieses Forum hier der geeignete Ort für eine solche oder sollte man das ggf. noch an einem anderen Unterforum aufziehen? Oder doch parallel auf der Mailingliste?

ich finde das beschriebene Tagging auch nicht passend, allerdings würde ich auch widersprechen, dass lock=yes auf einem waterway ein Objekt ist, welches eine Schleuse abbildet. Es ist vielmehr, ähnlich bridge=yes bei Straßen, ein Attribut des Wasserwegs, dass er sich dort in einer Schleuse befindet. Die Schleuse ist da impliziert aber nicht explizit abgebildet. Wenn man den waterway dort nochmal splitten müsste, weil z.B. eine Eigenschaft sich in der Schleuse ändert, dann würden dadurch daraus nicht 2 Schleusen.

eine Relation braucht man dafür eher nicht, ein umschließendes Polygon könnte aber Sinn machen, ggf. gehören da noch mehr Teile dazu, z.B. das Häuschen vom Schleusenwärter (so es ihn noch gibt), bzw. die Anlagen, um die Schleuse zu bedienen, und evtl. weiteres Betriebsgelände.
Als tag ggf. so was wie man_made=lock oder waterway=lock.

Das ist richtig.

O bitte nicht! Damit bekommst du spätestens dann ein Problem, wenn innerhalb der Schleusenanlage noch etwas ist, das betriebstechnisch gar nicht zur Schleuse gehört (z.B. ein Leuchtfeuer). Überhaupt sollen Polygone in OSM etwas auf dem Boden Befindliches abbilden (Waldrand, Seeufer, Mauer, Zaun), aber nicht einfach nur andere Objekte inhaltlich zusammenfassen.

Und genau dafür wäre eine Relation ideal. Die Relation ist type=lock, die Elemente haben dann Rollen wie basin, fairway, operators_house etcetera. Das bildet präzise ab, a) was zur Schleuse gehört und was nicht und b) welche Funktion es in der Schleuse hat.

Wohlgemerkt, ich fordere keine Relationen für Schleusen, ich merke nur an, dass das datentechnisch die sauberste Abbildung der Anlage in OSM wäre.

–ks

ja, site-relation und so, ich verstehe das schon, nur skaliert das so schlecht zur Beschreibung der ganzen Welt. Die Funktionen ergeben sich normalerweise bereits aus der Beschreibung der Unterobjekte, die noch semantisch zu verknüpfen ist normalerweise überflüssig (z.B. gehen wir einfach davon aus, dass die Schienen in einem Bahnhof den Bahnhof bedienen, und haben nicht noch eine Relation die sagt, dieses Stück Schiene ist auch Teil des Bahnhofs, und zwar als Verkehrsweg.

Mit einem Polygon kann man auch sehr viel bereits ablesen, wenn auch eher heuristisch als explizit, und meistens sind die Dinge die dazugehören klar umgrenzbar (schwieriger wird es z.B., wenn der Parkplatz für etwas nicht direkt auf dem Gelände liegt, sondern noch andere Grundstücke oder Straßen dazwischenliegen, dann kann man so was mit einer Relation (z.B. site) und einer Rolle wie z.B. “dient”, also z.B: Parkplatz dient Supermarkt (oder ähnlich) abbilden. Nur kommt das so selten vor, dass es im Endeffekt dazu führt, dass vermutlich niemand das je auswerten wird :wink:

Vorteil des Polygons ist, dass man keine Dinge als member dazufügen muss, sondern sich die Zugehörigkeit automatisch räumlich ergibt, und das in einer standardisierten Weise, die bereits von vielen Anwendungen (automatisch) angewendet wird, und generisch unterstützt werden kann.

… auch bei Elementen, die gar nicht dazugehören, aber zwangsläufig mit drin sind – Beispiel siehe meinen letzten Post. Ich bin sehr entschieden gegen Gruppierungs-Polygone, die ja gar keine Geodaten sind, sondern nur etwas Inhaltliches ausdrücken. Dann können wir auch gleich anfangen, Straßen und anliegende Häuser einfach mit Polygonen zu umkringeln, statt an jedes Gebäude umständlich addr:-Tags zu setzen.

–ks

In der Tat macht es dort, wo Adressen zum kompletten Grundstück gehören und nicht zum einzelnen Gebäude, m.E. Sinn, das auch so zu erfassen, ist aber ein anderes Thema.

Elemente die nicht dazugehören sollten natürlich auch nicht mit drin sein. Ich wundere mich ein bisschen, dass wir beiden jetzt so eine Grundsatzdiskussion führen, wo Du für die site-Relation eintrittst. Natürlich ist “eine Schleusenanlage” (als Fläche oder Punkt oder Linie gemappt), durchaus ein Geodatum, genausoviel wie ein Museum oder ein Land oder eine Bergspitze (bei der Schleuse könnte man das “Betriebsgelände” nehmen, das gibt es AFAIK da normalerweise). “Inhaltliches ausdrücken” ist so allgemein, vielleicht verstehe ich einfach nicht, was Du gemeint hast. Kannst Du das vielleicht nochmal ein bisschen ausführlicher darlegen?

Ich hab ja schon einiges an Schleusen hier im Spreewald erfasst… Insgesamt finde ich aber das Tagging und das Wiki zu uneinheitlich und unvollständig… mal unabhängig von seamark* und Co.

Grundsätzlich setze ich bei größeren Schleusen- und Wehranlagen Relationen type=site ein, mit allen zugehörigen Elementen, daran kommt Name, Operator, ref, da das für alle Elemente und Teile einer Schleusen- und Wehranlage gilt. Ich halte das zunächst einmal für ausreichend.

Hier im Spreewald treten Schleusen in der Regel immer zusammen mit Wehranlagen auf, in der Regel auch mit Fischpässen. Es gibt zusätzlich Absperrungen per Balken, schwimmend auf dem Wasser, Poller und übers Wasser gespannte Sperrketten. Ein- und Ausstiegsstege, gerne mal schwimmend… Gelegentlich werden auch Wanderwege über diese Anlagen geführt. Es gibt stets Pegel im Ober- und Unterwasser… Als Schleusentypen haben wir Stemmtorschleusen (in der Regel 2 Tore im Oberwasser, zwei im Unterwasser; selten mal nur mit einem Tor im Ober- und Unterwasser). Bei beengten Verhältnissen werden hier auch Hubtorschleusen eingesetzt.

Ich hab es aber noch nicht geschafft, hier diese Schleusen- und Wehranlagen zu meiner Zufriedenheit einheitlich zu erfassen, auch wenn ich einige bereits recht detailgetreu habe. Ich stoße immer wieder auf neues, widersprüchliches und für mich offenes…

Offen für mich ist z.B., welche Angaben für ein funktionierendes Wasserwegerouting noch nötig wären: nicht access, aber name und Nummer an bestimmten Teilobjekten (waterway=lock_gate), um eine funktionierende Wegebeschreibung zu erhalten…

Wiki unterscheidet z.B. je nach Schleusengröße waterway=lock_gate als Punkt oder Linie… Was unterscheidet eine große von einer kleinen Schleuse? Würde im Routing ein linienhaftes waterway=lock_gate genauso funktinieren, wie als Punkt?

Hier im Spreewald sind die Schleusenkammern maximal 1,9m breit und 9m lang… Ist das groß oder klein? Ich finde diese Unterscheidung im Moment Quatsch. Richtiger wäre simples Tagging/ Detailiertes Tagging…

Was ist das richtige Tag für die Strömungspfeiler aus Beton im Hauptstrom, die Betonteile der Schleisenkammern… Ich setze hier building=weir ein… was besseres fällt mit im Moment nicht ein…

Ich beobachte aber auch, daß das OSM-Wiki, von zu wenigen Leuten in Bezug auf Schleusen bearbeitet wird und ich habe den Eindruck, daß lediglich 1-2 Leute ihre Meinung zum Tagging im Wiki manifestiert haben, wenn man sich die Versionsgeschichte im Wiki anschaut… Ich kann mich aber auch täuschen…

Fragen über Fragen…

Sven

Geodatum ist für mich alles, dessen Lage/Verlauf mit Geokoordinaten definiert wird und das Eigenschaften hat.

Die Schleusenkammern sind Geodaten. Das Schleusenwärterhäuschen ist ein Geodatum. Ein Wehr ist ein Geodatum, eine Leitmole ist ein Geodatum. Und jetzt kommst du mit:

Wenn ich dich richtig verstehe, willst du um die gesamte Anlage ein beliebiges Polygon ziehen und „Das alles hier ist die Schleuse Hintertupfingen“ an das Polygon taggen. Dann ist das Polygon aber selbst kein Geodatum, da die Eckpunkte/Teillinien dieses Polygons nichts abbilden, sondern beliebig sind, solange sie die Schleuse einschließen. Es kann eine Ellipse oder ein Rechteck sein. Dieses umgebende Polygon (nur um das geht’s mir, nicht um die Schleusenelemente darin) bildet dann nichts Physisches ab, sondern fasst nur alle realen Objekte, die sich innerhalb befinden, zur Schleusenanlage zusammen.

Das (nichts Physisches darstellen, sondern lediglich physische Elemente zusammenfassen) empfinde ich als falsche Anwendung eines Polygons, daher mein Beispiel mit den Straßen und Häusern, die man dann auch mit einem Polygon umreißen und sagen könnte: Alle Gebäude hierdrin gehören zur Straße, die auch hierdrin ist.

Oder ich hab deine Anregung komplett falsch verstanden. Kann auch sein.

–ks

Aber wie willst du das verhindern? Ein einfaches Polygon verfügt nicht über die Möglichkeit, Dinge “auszustanzen”, dafür bräuchtest du ein Multipolygon. Ind selbst mit diesem hättest du dann eine Art “Negativliste” all der Dinge, die nicht hinzugehören.

Eine site-Relation (oder spezifischer) würde hingegen die Dinge auflisten, die dazugehören.

Sehr klein. Die Kammer der Schleuse Berlin Spandau ist 115 m lang und 12,5m breit.

Routing-Funktionen habe ich noch gar nicht betrachtet, das wäre ein Thema fürs nächste Jahr, wenn das Boot wieder im Wasser ist.

Ja, natürlich ist das sehr Klein. Aber in meinen Augen kommt es auch nicht auf die Größe an, sondern wie Detailgetreu man eine Schleuse erfassen will.

Drei detailierte Beispiele, die für mich in der Summe fast alles haben, was ich so vor Ort vorgefunden habe und man Erfassen kann: https://www.openstreetmap.org/relation/2783521 und https://www.openstreetmap.org/relation/2796511 und https://www.openstreetmap.org/relation/2783331

Übrigens auch Beispiele, warum man meiner Meinung nach bei einer Detailierten Schleusenerfassung eine Relation mit allen Elementen einsetzen sollte und kein Umring-Polygon.

OT: Zum Glück sind unsere Schleusen so klein, daß verhindert, daß Sport- und Hausboote im Spreewald fahren, mit denen unsere Wasserprobleme in der Saison noch größer wären, als sie jetzt schon und in Zukunft zu erwarten sind.

Sven

beliebig sollte die Grenze natürlich nicht sein. Mal hier ein beliebiges Beispiel:

da es sich bei Schleusen um Ingenieursbauwerke handelt, gehen die eigentlich nie „beliebig“ in die Umgebung über, sondern sind die Kanten klar definiert, die Frage ist vielleicht, was dazugehört und was nicht, aber das muss man bei einer site-Relation erst recht.

Hier ein Foto von einem anderen beliebigen Beispiel, m.E. kann man da auch klare Grenzen erkennen, der gemähte Rasenstreifen am Rand gehört dazu, dahinter eher nicht.