Oh... wie ist das denn passiert?

Wenn ich mich erinnere, hatte ich ein kleines Upload-Problem gehabt...

Danke.. Ich repariere es...

Sven

Ach ja, vergessen... Es gab im Forum auch die Nachfrage nach der Korrektheit (Nutzungserlaubniss) der genannten Quelle: http://www.radverkehr.sachsen.de/5800.html

Sven

Hei. Mit der Relation relation/1705155#map=11/50.9736/12.5114&layers=N hast du eine Sammelrelation mit zwei Tochtersammelrelationen erstellt. Soweit ist das erst mal nicht wirklich schlimm. Die Folge ist nun aber, daß mit CS changeset/44008996#map=13/50.9902/12.5755&layers=N einer der beiden Tochtersammelrelationen ( relation/1705154 ) die Eigenschaften network=rcn sowie route=bicycle gesetzt wurden. Das hat zir Folge, daß diese beiden Eigenschaften nun anscheinend in bestimmten Auswertungen an die Mitglieder dierser Relation vererbt werden. Ein Designproblem, beim Anwenden von Sammelrelationen.

Wir sollten eine Lösung finden, daß diese Sammelrelationen aufgelöst werden können, in dem durch geeignetes Tagging an den Radwanderrouten selbst entsprechende Auswertemöglichkeiten (OverpassTurbo) möglich sind. Vergleiche Forum:
https://forum.openstreetmap.org/viewtopic.php?pid=624447#p624447

Gruß,

Sven

Hei,

mit dem Setzen von network=rcn sowie route=bicycle hast du der ganzen Sammelrelation relation/1705154 diese Eigenschaft gegeben.
Welchen Zweck hatte das? Da die genannte Relation eine Sammelrelation uat, wird nun in bestimmten Auswertungen ( z.B. https://cycling.waymarkedtrails.org/#?map=13!51.2744!14.1622) allen Tochterelationen diese Eigenschaft mitgegeben... Das ist ein Designproblem von Sammelrelationen. Wir sollten eine Lösung finden, diese Sammelrelationen aufzulösen.

Vgl. Forum: https://forum.openstreetmap.org/viewtopic.php?pid=624447#p624447

Gruß,

Sven

Bist du dir sicher, daß zwischen diesen beiden Häusern eine natürliche Quelle ist?
Sven

Es es waren die Admin-Grenzen Zehlendorf und Nikolassee (AL10) sowie die PLZ-Grenze 14163 und 14165 defekt, da Grenzsegmente fälschlicherweise verschmolzen wurden.

ist nun behoben.

Gruß,
Sven

Hei,

ich habe eine kleine Bitte... Vesuche bitte Grenzen ausschließlich mit JOSM zu bearbeiten. Potlatch und iD können mit solchen Dingen nicht gut umgehen. Die Grenze Zehlendorf/ Kleinmachnow ist z.Z. kaputt...
http://tools.geofabrik.de/osmi/?view=areas&lon=13.24079&lat=52.41533&zoom=14
Bitte hier nichts machen, ich repariere gerade...

Danke,

Sven

Da der süddresdener Bereich ja quasi deine Hausecke ist, hast du diese komischen Änderungen im Blick, und auch gut dokumentiert und um Hilfe gerufen. Ich hab das im Forum schom mitverfolgt. Daß sich mal ein OSMI-Changeset von mit dahin "verirrt hat" ist reiner Zufall. mit war auch nicht gleich bewußt, daß gerade da diese bewusste Ecke ist...

Sven

Grundsätzlich hast du recht. Nur ist das diesige, meinige Changset außerhalb meines Hauptmappingbereiches. Es beinhaltet auch ausschließlich technische Korrerkturen der Geometrie, keine, vor dir angesprochenen inhaltlichen. Diese Trennung von inhaltlichen unt technische Korrekturen und Ergänzungen werde ich auch weiter so machen, vor allem in Gebieten mit begrenzter oder keiner Kenntnisse.

Sven

Hei.

denkst du auch noch an dieses Changeset hier?

Danke...

Dann kann ich das als erledigt markieren.

Sven

Grundsätzlich habe ich nichts gegen diese Information... Ich fand nur keine Doku im Wiki... Dies bitte nachholen, ggf. könnte/ sollte das auch im Forum der Mailing-Liste thematisiert werden. Relevant ist, daß die Quelle des LOCODE entsprechend des Taggings im OSM-Wiki dokumentiert wird...

Zu mindestens die Grundinformationen mit Verweisen auf Wikipedia, bzw. auf http://live.unece.org/cefact/locode/welcome.html sollten erfolgen. (ich hoffe, die Seite http://live.unece.org/cefact/locode/welcome.html ist Lizenzkonform...)

Sven

Hei,

was denn ref:LOCODE für ein Tag, den due einträgst... Es ist im Wiki nicht dokumentiert.

fragt Sven

erledigt.

Bitte in dieser Ecke MP-Konstrukte aus zusammengesetzten Outer-Linien beachten, bei denen zu allem Übel auch highway=irgendwas und sonstiges verwendet werden. Das MP relation/3541679 ist defekt... Das ist aber nicht primär dein Fehler sondern eine grundsätzliche Tagging-Krankheit eines Users in der Ecke. Ich versuche das MP zu reparieren und entsprechende Elemente aus der Relation zu entfernen.

Sven

Hei,
source und source:id zu entfernen reicht nicht. Die Daten als solches sind immernoch drin.
Die Daten stammen in der Version 1 aus einer illegalen Quelle, vgl.

http://osm.mapki.com/history/way.php?id=289259692

bzw.

http://nrenner.github.io/achavi/?changeset=43709780

Die Daten müssen vollständig (incl. Geometrien) entfernt werden. Geschieht dies nicht, machen wir uns als OSM unglaubwürdig und es schmälert extrem unsere Glaubwürdigkeit, ehrlich mit Lizenzen umzugehen.

Sven

Hei,

brandenburgische Geodienste dürfen NICHT fürs Mapping in OSM verwendet werden. Diese Datenquelle ist nicht Lizenzkonform und due entsprechenden Daten müssen enfernt werden.

vgl. auch Forum:

https://forum.openstreetmap.org/viewtopic.php?id=56403

Eine Meldung an die Licence-Working-Group geht raus.

Sven

Hei,

hast du alle 1507 Hochstände vor Ort geprüft, ob sie verschließbar sind oder nicht?

Respeckt...
:(

Sven

Hei, noch eines: bitte bei lock=yes dann lock_name verwenden (vgl. Wiki). habe vier geändert. changeset/43444367#map=12/51.9458/13.9614

Sven

es sollte im Kommentar natürlich lock_name heißen...

Sven

Hei,

ein Teil deiner Edits ziehen nun Nachbearbeitungen nachsich... Warum hast du dich denn nicht an das Wiki gehalten?

osm.wiki/DE:Key:lock

Anstatt einer neuen Linie hättest du die waterway-Linie aufsplitten müssen, und an dieser dann lock=yes und lock_name=* vergeben müssen...

Änderst du das bitte?

Danke,

Sven