Danke... Dann haben wir einen dritten Honeypot... die beiden admin-Grenzen bei mir vor der Haustür http://tools.geofabrik.de/osmi/?view=areas&lon=14.10447&lat=51.90265&zoom=11&overlays=duplicate_node,single_node_in_way,duplicate_segment,way_in_multiple_rings,intersection,intersecting_segments,ring_not_closed,touching_rings,role_should_be_inner,role_should_be_outer,inner_with_same_tags,ways
sind zwar auch touching Rings, sind aber auch korrekt...

Danke für die Bestätigung meiner Vermutung.

Sven

Hier der korrekte Link zu OSMI: http://tools.geofabrik.de/osmi/?view=areas&lon=13.12714&lat=52.52752&zoom=18&opacity=1.00&overlays=duplicate_node,single_node_in_way,duplicate_segment,way_in_multiple_rings,intersection,intersecting_segments,ring_not_closed,touching_rings,role_should_be_inner,role_should_be_outer,inner_with_same_tags,ways

Hei,

eine Frage zur Relation relation/8523179 Die hat an zwei stellen touching Rings in Relation
http://tools.geofabrik.de/osmi/?view=areas&lon=13.14782&lat=52.47624&zoom=13&opacity=1.00&overlays=duplicate_node,single_node_in_way,duplicate_segment,way_in_multiple_rings,intersection,intersecting_segments,ring_not_closed,touching_rings,role_should_be_inner,role_should_be_outer,inner_with_same_tags,ways
Das muß kein Fehler sein, ich wollte aber nur mal nachfragen, ob das Korrekt ist, da du da den Überblick hat.

Grüße,

Sven

Hei,

bist du dir sicher, daß type=multipolygon hierfür korrekt ist? ist denke nein... Das verursacht einen Geometriefehler: http://tools.geofabrik.de/osmi/?view=areas&lon=13.18608&lat=52.07960&zoom=9&overlays=duplicate_node,single_node_in_way,duplicate_segment,way_in_multiple_rings,intersection,intersecting_segments,ring_not_closed,touching_rings,role_should_be_inner,role_should_be_outer,inner_with_same_tags,ways

Schau dir nochmal die Möglichkeiten von Relationstypen an... Hierfür wäre bestimmt type=site besser geeignet...

Es gibt übrigens im Forum wieder einen ausführlichen Beitragsbaum zur MP-Verwendeung. https://forum.openstreetmap.org/viewtopic.php?id=64439

Sven

Weil ist es durch Zufall gefunden habe:

https://www.mapillary.com/map/im/VaB3GkXupFyj7HB6fR4QGA

Ansonsten kann ich nichts dazu sagen.

Sven

Hej, thanks for fixing the relation. I was already watching this for a few days. I was hoping that the user @ulamm would fix this. I had pointed this out to him several times. See also changeset/65747806
He makes also strange additions ref=GKZ:123 rather than ref:fgkz=123...
Also the Relation relation/7650564 is very bad... the usage of river-lines in a boundary-relation is often the reason for geometry errors.

Thanks,

Sven

Hei... da du bisher nicht reagiert hast.... ich beabsichtige diese Edits zurückzusetzen.

Streckenkundler

Hei... Ich wollte gerade fragen, wie du drauf kommts, das daß mal ein Bahnhof war... Aber Wikipedia weiß es... Es ist jener hier...https://de.wikipedia.org/wiki/Bahnhof_Beeskow#Alter_Bahnhof bevor es die Spreebrücke gab...

Danke für den Aha-Effekt... Wieder was gelernt...

Sven

Falls eigene Kartenanwendung benötigt, bitte https://umap.openstreetmap.fr/de/ oder ähnliche benutzen und eigene Karten erstellen.

Bitte keine weiteren Edits und erst Disskutieren: https://forum.openstreetmap.org/viewtopic.php?pid=731209#p731209

Hei,

ich kenne die Steinitzer Treppe persönlich... Da steht aber nirgends "DA/DN-125" , weder auf der Infotafel, noch auf einem anderen Schild.

Das hat im Namen nichts zu suchen. Bitte aus dem Namen entfernen und (bei bedarf) einen eigenen Namensraum verwenden. Im Zweifelsfall in den offiziellen Kanälen (Mailingliste, Forum) nachfragen. Das betrifft auch die anderen geänderten Objekte...

Danke.
streckenkundler

Nochmal... innerhalb eines Teileinzugsgebietes haben alle Standgewässer die selbe Nummer, alle Fließgewässer jeweils eine Eigene...

mit der Gewässerkennzahl für Fließgewässer kannst du ein wasserwirtschaftliches Gewässer eindeutig identifizieren (auch wenn dieses gebräuchlich unterschiedliche Namen hat). Mit Gewässerkennzahl für Standgewässer kannst du nur alle Gewässer innerhalb eines Teileinzugsgebietes identifizieren, egal, ob es ein Gewässer ist, oder 25 sind. Für eine genauere Identifizierung bedarf es weiterer Identifikatoren. Darum ist auch deine Schreibweise ref=GKZ:xx grundlegend falsch, weil es nun keinen weiteren Identifikaton zulässt...

Die Rolle "tributary" ist absoluter Quatsch. alleine aus der Zeichenrichtung des Objektes ergibt sich alles nötige... Siehe https://www.kompf.de/gps/rivermap.html . Alleine aus den geometrischen Verbindungen der Gewässerachsen heraus ergibt sich der Zusammenhang, zu welcher Flußgebietseinheit was gehört.
Alles ohne Relationen in entsprechende Rollen. Wo im Wiki ist "tributary" überhaupt erwähnt... ich habe nichts gefunden... würde man damit anfangen, kannst du mit der Elbe beginnen. Ich warne aber extrem davor... das gibt auch wieder unbeherrschbare MP-Monster. Bei einer sauberen Erfassung am Objekt kann man selbst den Sinn und die Notwendigkeit für die überwiegenden Relationen type=waterway in Richtung Sammelrelation hinterfragen!!

Gewässenamen. Das für OSM nicht nutzbare Gewässershape (Version 4.2 v. 7.11.2016) für Brandenburg listet 32542 erfasste Gewässerabschnitte (bzw. 2917 Gewässer) für Basis-DLM10 auf. Jeder einzelne Abschnitt hat mindestens ein Name; auch wenn das Ding schlicht nur Graben "1/27/02" heißt... Die Gewässerkennzahl des Fließgewässers dient lediglich der standardtisierten Zuordnung zum jeweiligen Einzugsgebiet... und nur mit den EZG-Grenzen funktioniert das Ganze.

streckenkundler

PS: Relation relation/7650564 ist immernoch kaputt...

Ach noch eines...

Im meinen Augen sollte die Gewässerkennzahl bei Fließgewässern und Standgewässern unterschieden werden, da sie unterschiedliche Bedeutungen haben... Bei Standgewässer ist es lediglich die Nummer des Teileinzugsgebietes in dem es liegt und alle Standgewässer innerhalb dieses Teileinzungsgebietes haben die selbe Nummer, ob diese groß wie ein See sind oder klein wie ein 20m² großer Tümpel sind.
Bei Fließgewässer ist dies anders. Da hat jedes Gewässer von der Quelle bis zur Mündung seine eigene Nummer, für die Spree ist es z.B. 582 und bei Fließgewässern ist es egal, daß dieses mehrere Einzugsgebiete durchfließt.

streckenkundler

Ich glaube kaum, daß die Gewässerkennzahl jemals gerendert werden wird... Dafür ist diese auch nicht da und daß die Abfolge von Gewässerkennzahlen nicht immer der Abfolge von Namen entspricht, sollte hinlänglich bekannt sein.

Was meinst du übrignes mit den Edits "Nonnenbach" und "Werbender Mühlbach"? Ich habe am "Nonnenbach" keine Edits und "Werbender Mühlbach" wird nicht gefunden.

Ungeachtet dessen halte ich die Rolle "tributary" auch bei Fließgewässern für Quatsch, Wozu soll diese dienen?

streckenkundler

ref:fgkz hat aber mit Abstand die meisten Verwendungen... Mit der Anwendung ref=GKZ:xx machst du zunächst einen entscheidenen Fehler: du verschiebt "GKZ" , was zum Key gehört in den Werte-Teil nach dem Gleichheitszeichen. Damit lassen sich solche Dinge nicht strukturiert abfragen. Das ist in meinen Augen Datenmüll. Den OSM-Konventionen nach werden Keys stets klein geschrieben. Das wird angewendet, warum abweichen?
Seen- und Fließgewässer solten trotz der Bildungsregeln der Gewässerkennzahl unterschieden werden, in den einschlägigen Verzeichnissen werden diese auch unterschieden, warum abweichen.

streckenkundler

Hei...
mit deinem Tagging hast du die Relation relation/7650564#map=9/53.9760/13.4100&layers=N geschrottet... Bitte mache solches Tagging nicht mit iD!!

Es gibt das generelle Problem, daß z.B. wie hier Gewässerabschnitte direkt in Grenzrelationen verbastelt werden und einige Editoren damit nicht sauber umgehen können. Bitte überdenke auch deine Taggingweise ref=GKZ:xx Das gkz kann klein geschrieben werden und muß vor das Gleichheitszeichen.als etabliert kann man ref:fgkz=* ansehen Warum davon abweichen?

Siehe: https://taginfo.openstreetmap.org/search?q=GKZ#keys

streckenkundler

Was haben die Rollen "influent" und "tributary" in der Relation http://osm.mapki.com/history/relation.php?id=216440 zu sagen? Die sorgen nun dafür, daß der Tollensesee trockengefallen ist...
Ich hab auch im Forum nachgefragt: https://forum.openstreetmap.org/viewtopic.php?pid=730977#p730977

streckenkundler

Hei... wie man es richtig macht, da streiten sich die Mapper und es werden sich auch in absehbarer Zeit keine Lösung finden, zu unterschiedlich sind die Vorstellungen der Datenstrukturen...
In Berlin ist ja vieles, was als simple Fläche abgebildet werden kann über Relationen gelöst, was eine einfache Bearbeitung sehr erschwert. Eine nachträgliche Bearbeitung (z. B. area:highway) ist so sehr erschwert. Solange es da keine einvernehmliche Lösung gibt, wird man auch mit überlagerten landuses leben (müssen). Ein Ausschneiden befürworte ich in innerstädtischen Bereichen nicht, das führt sehr oft zu Geometriefehler, die oft schwer oder nur durch Löschung und Neuerfassung zu reparieren sind.

Grüße, Sven

Vielen Dank... in Sachen Relationen ist das ja immer so eine Sache... Gelegentlich bereinige ich ja auch in Berlin Geometriefehler, manchmal stoße ich aber an die Grenze einzuschätzen, was richtig ist...
Die Disskussion im Forum https://forum.openstreetmap.org/viewtopic.php?pid=730182#p730182 und die Abstimmung zu Grundsätzen der Verwendung und nicht Verwendung kennst du?

Grüße, Sven

Hei,

bei diesem CS hast du versehentlich einen Geometriefehler verursacht, uns zwar hier: osm.org/?mlat=52.50584&mlon=13.51303#map=17/52.50584/13.51303

OSMI: http://tools.geofabrik.de/osmi/?view=areas&lon=13.51292&lat=52.50566&zoom=18&opacity=0.94

Es überschneiden sich ein Inner- und ein Outer-Element einer Relation.
Magst dur dir das mal bitte anschauen?

Danke,

Sven