Hei...

Das stimmt nur zum Teil...In der Hauptstraße 51 ist ein Teil des Katasteramtes...

Ich bin aus Lübben.

Sven

Ergänzend zu den Grenzen innerhalb BR Spreewald... maßgebend sind die Grenzen wie die hier: https://bravors.brandenburg.de/de/verordnungen-212889 beschrieben sind!! Ich hab das stichprobenartig verglichen, es sieht mir so aus, daß das mit dem Originaltext übereinstimmt.
Maßgebend ist das deshalb, weil das Ganze einigungsvertragsbedingt nun Landesgesetz ist... Da wird in absehbarer Zeit nicht daran gerüttelt... So sind auch die Grenzbeschreibungen darin maßgebend, also es werden nach und nach die Grenzen anhand dieser Original-Beschreibung korrigiert... Man ist nur noch nicht soweit, als daß man all diese Fehler bereinigt hat. Das heißt, daß die "offiziell" verfügbaren und zu sehenden Grenzen u.a. der NSG's innerer Unterspreewald und Kockot, die du an die offiziellen Grenzen angepasst hast, nicht der o.d. Verordnung (nun Landesgesetz) entsprechen, also defakto in Teilen falsch sind. Das betrifft auch andere Regionen Brandenburgs, vereinzelt sind sogar ganze NSG's und so nichtig...
Was deine Änderung betrifft... Ich möchte, daß die ursprünglichen Grenzgeometrien der beiden Gebiete in der von mir erfassten Form wiederhergestellt werden. Wenn du Änderungen an Grenzgeometrien innerhalb des Spreewaldes beabsichtigst, bitte mich unbedingt vorher kontaktieren. Ich habe hier einen sehr guten Überblick...

Sven

Also Osmand rendert auch NSG's wenn sie ausschließlich nach dem boundary=protected_area - Schema erfasst sind.... Sowohl NSG, als auch Totalreservate... bei letzteren würde ich mit eine anderes Rendering wünschen, zur Unterscheidung.

Sven

Aber bitte äußert vorsichtig mit den Grenzen von ProtectedPlanet umgehen... die sind zum Teil erheblich in ihren Geometrien veraltet. Die sind irgendwann mal vor Jahren gemeldet worden, aber keiner aktualisiert die Daten...
In Brandenburg haben sich in dem letzten 1 1/2 Jahren einige NSG-Grenzen geändert: Oft waren es Digitalisierungsfehler oder Lageanpassungen, ect. Neue Grenzen kommen in der Regel vierteljährlich.
Beispiel:
Das NSG Heideseen ist dort mit der ungültigen Grenze drin. So, wie die Grenze in OSM drin ist, entspricht sie der Rechtsauslegung des Umweltministeriums und entspricht der textlichen Grenzbeschreibung der Biosphärenreservatsausweisung 1990, die ich im Original zu Hause habe. Die NSG-Grenze des NSG Heideseen wurde im Sommer letzten Jahres korrigiert.

Bei der Grenze des Inneren Unterspreewaldes dürften auch noch Fehler sein, die aber bisher nicht korrigiert sind. Ich muß nochmal nachschauen, aber ich hatte die Grenze auch nach Grenzbeschreibung erfasst. Das betrifft übrigens alle Grenzen im Reservat. Bitte keine Grenze nach ProtectedPlanet verändern!!!

Ich habe dienstlich viel mit der Verarbeitung solcher Grenzen zu tun.

Sven

Hei. Warum hast du denn die Relation aufgelöst? Es fehlt nun der Zusammenhang zu den auch erfassten Totalreservaten/ Naturentwicklungsgebieten im Unterspreewald. In ähnlicher Weise sind alle Naturschutzgebiete im Biosphärenreservat Spreewald erfasst. Quelle ist die textliche Beschreibung der Grenzen aus der ursprünglichen Verordnung.

Sven

PS: leisure=nature_reserve betrachte ich mittlerweile als Tagging für den Renderer Andere Renderer beweisen, daß es ohne geht...

Hei... Jetzt ist es wieder so, wie es falsch ist... :(
eine Relation type=multipolygon mit zwei aneinandergrenzenden Outer-Linien; =duplicate Segment in Relation...

http://tools.geofabrik.de/osmi/?view=areas&lon=13.41363&lat=52.55121&zoom=18&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

Der Relationstyp type=multipolygon ist hier für das Gebäude definitiv falsch. Entweder es wird danz auf eine Relation verzichtet (beide Flächen werden Verschmolzen, auf die Relation wird ganz verzichtet und die Tags kommen an die Linie oder es wird mit type=building gearbeitet, mit einer Fläche, die beide Gebäudeteile umfasst, an diese kommt building=commercial, und die beiden Teilflächen mit der Rolle "part" und für jeden part das jeweilige building:levels

So, wie es jetzt ist building:levels unbestimmt und für 3D nicht auswertbar...

Sven

Hei,

ich habe bei der Relation type=multipolygon und type=building geändert... Ich habe also eigentlich nur abgekürzt...

Mir scheint, daß type=building für viele 3D - Gebäudeerfassungen geeigneter ist, als type=multipolygon. Vergleiche osm.wiki/Relation:building

Sven

Hei.
nature_reserve nur für echte Naturschutzgebiete ist richtig. Trotzdem dürfte das bei der Eiche hier einen Informationsverlust darstellen... stattdessen wäre denotation=natural_monument hier angebracht, wenn der Baum als Einzelobjekt geschützt ist.

Sven

Hei,

eine riesengroße Bitte!

Verändere und arbeite mit iD nach Möglichkeit Niemals administrative Grenzen... iD ist dafür äußerst ungeeignet, gerade wenn man frisch anfängt. Dazu bitte stets JOSM nehmen und dann stets darant achten, daß der Ring der Grenzrelation geschlossen ist... Das erfordert auch etwas Einarbeitungszeit.
Es ist jetzt kein Beinbruch, aber mangels Kenntnisse in dem Gebiet habe ich im Forum mal gebeten, daß sich das ein anderer mal anschaut...

https://forum.openstreetmap.org/viewtopic.php?pid=679219#p679219

Danke,

Sven

Ich hab mal die Geometrien repariert, wie ich es für richtig halte... Vielleicht magst du mal rüber schauen?

changeset/55057664

Ach ja. im Forum habe ich das auch mal angesprochen, vielleicht findet sich jemand, der am BER auch noch bessere Kenntnisse hat.
https://forum.openstreetmap.org/viewtopic.php?id=60895

Danke,

Sven

Hei.

du hast im guten Glauben editiert, aber üble Geometriefehler produziert...
Bei solchen komplexen Geometrien ist iD reichlich ungeeignet... Da ist JOSM zu empfehlen...

Sven

Ich habs auch nur über OSMI gesehen, weil ein selfintersection of way - Fehler war...

Aber Nun... das passiert schon mal...

Sven

Nachtrag:
Dieses Changeset: changeset/54955914 enthält die angesprochene Wiederherstellung.

Sven

Hei,

du hattest versehentlich das residental way/23767918 quadratisch gemacht... nach etwas hin und her, habe ich die residental-Fläche in ihrer ursprünglichen Geometrie widerhergestellt...

Alles andere dieses Changesets ist unangetastet.

Sven

Hei,

ich glaube, den Abzweig zum Paddenpfuhl kannst du auch mindestens auf disused setzen... Spurweite ist übrigens 900mm.

Sven

Hei... Bitte passe peinlich genau auf, was Merkaartor beim Editieren vom Multipolygonen produziert... im Beispiel vom MP relation/3097052 hattest du an der Relation landuse=forest;farmland erfasst. Ich vermute aber ganz stark, daß das so nicht gewollt war.
Ich kenne Merkaartor dahingehend aber nicht.

Ich habe das MP entsprechend geändert...

Gruß,

Sven

Ja... das sehe ich ganz genau so... Planfeststellung ist schön und gut und kann eine gute Quelle sein... wie gesagt kann... wenn der Plan entsprechend umgesetzt wäre...

Eigentlich ist die Frage jetzt nur noch: existiert der Damm zwischen Göttinsee und Havel so in der Form, wie man ihn auf Luftbildern erkennen kann, ja oder nein... Wenn ja, kann die Note geschlossen werden. Wenn nein, bedarf es Recherche vor Ort.

Gruß, Sven

Hei... bezüglich deiner note=* node/61275419

Wir mappen nicht für den Router. Wir mappen die reale Situaton, in dem Beispiel den realen Straßenverlauf. Ich bin gegen solche Verbiegungen, bloß um irgend einem Router gerecht zu werden, der Daten nicht korrekt auswerten kann... Wir können das auch allgemein thematisieren (Forum, Mailing-Liste) da wird aber auch kein anderes Ergebnis bei rauskommen.

Diese eine Sache werde ich Zeitnah wieder ändern. Bitte beachte diesen Mappinggrundsatz!

Sven

Hei... bezüglich deiner note=* node/1078623293

Wir mappen nicht für den Router. Wir mappen die reale Situaton, in dem Beispiel den realen Straßenverlauf. Ich bin gegen solche Verbiegungen, bloß um irgend einem Router gerecht zu werden, der Daten nicht korrekt auswerten kann... Wir können das auch allgemein thematisieren (Forum, Mailing-Liste) da wird aber auch kein anderes Ergebnis bei rauskommen.

Diese eine Sache werde ich Zeitnah wieder ändern. Bitte beachte diesen Mappinggrundsatz!

Sven

Hei... bezüglich deiner note=* node/27271501

Wir mappen nicht für den Router. Wir mappen die reale Situaton, in dem Beispiel den realen Straßenverlauf. Ich bin gegen solche Verbiegungen, bloß um irgend einen Router gerecht zu werden, der Daten nicht korrekt auswerten kann... Wir können das auch allgemein thematisieren (Forum, Mailing-Liste) da wird aber auch kein anderes Ergebnis bei rauskommen.

Diese eine Sache werde ich Zeitnah wieder ändern. Bitte beachte diesen Mappinggrundsatz!

Sven