Es geht um Relation relation/6865722

sorry, Vergessen.

Sven

Ich hänge mich mal hier rein...wäre es nicht besser, das Ding u.a. als Relation type=building (osm.wiki/Relation:building) zu erfassen, bzw. nach osm.wiki/Simple_Indoor_Tagging

Gruß,

Sven

Hei... nö... lass das mal alles so... Ich schaue mir das Abend mal genauer an... Im Bereich der Otto-Nuschke-Straße grenzen ja zwei residentials aneinander. Die kann man durchaus auch verschmelzen... Mein Kommentar war ehr für die zukünftige Arbeit gedacht...Mit JOSM und dem Filterwerkzeug bekommt man das hin... Lass dich nicht beirren... Grüße,

Sven

Hei,

Ich freue mich daß du in Calau Daten ergänzt... um den städtischen Bereich hatte ich mich kaum gekümmert. Ich habe aber eine kleine (aber wichtige) Bitte. vermeide es, Landuse (z.B. landuse=residential) mit Straßen zu verkleben. Führe die Landuse-Bereiche bitte parallel zu den Straßen... Das hat einen einfachem, aber wichtigen Grund: wenn Straßen und Landnutzungen miteinander verklebt sind, ist es sehr aufwendig, wenn man bestimmte Dinge nur an den Straßen ändern will.
Das wird auch u.a. im Forum so gesehen... Siehe darüberhinaus auch osm.wiki/User:Frederik_Ramm/Fl%C3%A4chenverklebung

Damit leistet du einen großen Dienst, damit auch anderen Mappern die Arbeit erleichtert wird.

Bei Fragen kannst du mich gerne anschreiben.

Grüße,

Sven

Hei, und willkommen bei OSM.

du verdient meinen großen Respekt, gleich bei den ersten Edits sich mit iD an Wanderwegsrelationen zu wagen... Toll!

Es gab ja schon eine Relation, die ich mal angefangen hatte: relation/7945019, die hattest du auch anscheinend weiterbearbeitet. Die Lücken hab ich noch geschlossen, da mussten noch Wege gesplittet werden...

Im Zuge der Bearbeitung ist nun auch die Relation relation/8420865 entstanden, iD macht gelegentlich komische Singe, ohne daß der Nutzer was mitbekommt.

Meine Frage ist nun, macht der Urstromtalweg diese Schleife durch den Wald östlich des Friedhofs Baruth?

unterstützende Grüße aus dem nachbarlichen Lübben,

Sven

Ich habe beide Probleme beseitigt.

Hei,
zwei Dinge zur Relation relation/227602

1. source:name der Relation: der Brandenburg-Viewer ist eine verbotene Quelle, er darf nicht genutzt werden.
2. indem nun die beiden Outer-Flächen an mehr als einem Punkt aneinander grenzen, ist nun der Geometriefehler "Duplicate Segment in Relation" entstanden.

Das erstere muß zwingend raus, da gibt es keinen Disskusionsspielraum, wir haben keine Nutzungrechte!
Das zweite lässt sich heilen, indem die beiden Outer zu einer Fläche verschmolzen werden...

Sven

Hei,

danke für den Hinweis... Ich war mir zunächst da noch nicht 100%ig sicher, aber du hast recht... Bereinige ich noch... Ich taste mich ja an das einheitliche Tagging, wie es die Holländer machen, heran und komme gut voran. Die Seite heran...https://knooppuntnet.nl/en/networks/de/rcn bietet eine recht gute Auswertung und warum soll man die nicht nutzen.

Ich stehe dazu auch im Austausch mit User hfwri.

Grüße,

Sven

Ja, ich weis, daß die Basis schon älter ist... Wir haben leider keine aktuellen Luftbilder und diese Bergbaufolgelandschaft gerade hier verändert sich zur Zeit noch ständig...

Danke fürs Verständnis,

Sven

Hei, ich würde vorläufig keine größere Energie in die Erfassung des Bereiches des Cottbussser Ostsees verschwenden. Das ändert sich alles noch ziemlich stark, vor allem im Zuge der Flutung...

...und natural=heath sollte wirklich nur dort angewendet werden, wo auch echte Heidelanschaft ist. Das ist hier wohl nicht der Fall, es dürfte spärlich bewachsens Grasland mit einem hohen Sand-, Moos- und Flechtenanteil sein, aufgrund der bergrechtlichen Sperrung des Gebietes, kann man aich aber kein Bild vor Ort machen.

Sven

Da war kein Problem... Alles bestens... ich hab nur die vor dir erfasste nördliche Insel zur Relation des Sees hinzugefügt...
Sven

Hei... kein Problem... sollte was mit der admin-Relation sein, sehen wir das morgen... Danke, das hab ich im Blick. Sven

Hei,

Es hat sich meiner Ansicht nach bestätigt, daß das Entstehen dieses Multipolygon auf eine Uneigenheit (besser Fehler) von iD zurückzuführen ist und nicht auf einen Bedienfehler des Anwenders (was mich auch gewundert hätte). Der User
"AB-inf-x-chg-AB" hat das Verhalten nachgestellt, analysiert und ins Forum geschrieben. Wenn du dir es durchlesen willst: https://forum.openstreetmap.org/viewtopic.php?pid=726609#p726609

iD ist übrigens bekannt, gelegentlich Probleme zu bereiten. Mach dir da aber keinen Kopf... Wenn du tiefer einsteigen möchtest, kannst du dir auch mal JOSM anschauen...

Ansonsten fröhliches weitermappen... und wenn du Fragen hast... du weist ja, keine Scheu... :)

Viele Grüße,

Sven

PS: ich werde den Fehler nun beseitigen...

Hei,

vielen Dank... das scheint meine Vermutung zu bestätigen, daß du keinen Fehler gemacht hast, sondern der Fehler bei iD zu suchen ist. Bitte verändere das genannte Objekt in nächster Zeit nicht...
Ich melde mich, wenn ich was neues weiß.

Danke und Grüße,

Sven

Ergänzung: meine starke Vermutung ist hier, daß iD das hier sebstständig und ohne dein Wissen gemacht hat. Über eine Aussage und Antwort deinerseits würde ich mich sehr freuen!

Grüße, Sven

Hei, bei deinem Changeset brauche ich mal dringen deine Hilfe. Dazu habe ich habe nur interessehalber ein Frage zu einem Objekt, das in diesen Changeset angelegt worden ist: relation/9027270/history#map=16/51.8502/14.2266
Hast du das bewusst als Relation angelegt?

Wir haben nämlich im Forum eine Disskussion https://forum.openstreetmap.org/viewtopic.php?id=64439 über die Anwendung von Multipolygonrelationen wie hier, deren Notwendigkeit, ect... Da kam u.a. die Aussage auf, daß iD sowas manchmal selbstständig macht, ohne Wissen des Nutzers... in dem Fall hier wäre die Anwendung eines MP's absolut nicht nötig... Ich selbst kenn iD überhaupt nicht ind kann mir über dessen Verhaltensweisen kein Urteil erlauben.

Danke für die Hilfe...

Sven

Gemäß History von 9 Jahren von User Udo_O gesetzt (changeset/1067629) und in meinen Augen klassischer Fall von Mappen für den Renderer (OpenCycleMap). Auch ohne Ortskenntnis ist das Luftbild m.E. eindeutig.

Sven

Danke

Hei, ich bezweifle stark, daß die von dir hier erfassten Flächen echte, genutzte Wiesen sind. Im Luftbildvergleich sieht man, daß es überwiegend kleinflächige Kahlschläge mit Wiederaufforstung sind... Solche Dinge niemals nach Luftbild und ohne zusätztlcher Vorortkentnis mappen, erst recht nicht in der Lieberoser Heide, die eh in der normalen Zugänglichkeit berschränkt ist.

Ja, mach das...

Dinge wie amenity=school, leisure=sports_centre brauchen m.E. nicht aus residental ausgeschnitten zu werden. und residental kann ruhig auch an Hauptstraßen unterbrochen werden...
Ich selbst würde residental auch nur für die Wohnbereiche verwenden... Dann werden aus einem Residental vielleicht 7-8 oder mehr... und weitestgehend ohne Relation... Ich weiß, jetzt im Nachhinein ist das extrem aufwendig... Man hat irgendwann aber eben keine andere Chance mehr...

Sven