Hallo Peter,

warum eigentlich protect_class=22? Diese Weltnaturerbeflächen sind doch in der Regel Totalreservate, also protect_class=1. Das ist hier im Grunsin (auch Weltnaturerbe) auch so.

protect_class=22 sind für mich eher geschützte Denkmalbereiche wie z.B. way/234818730

Ich bin durch die Disskussion im CS changeset/117206333 drüber gestolpert...

fragende Grüße,

Sven

@user_5359 Flüchtigkeitsfehler ...kenne ich... :)

@user_5359: du meinst sicherlich node/9558630002

Sven

Ich hole das mal wieder hoch und setze es auf die Tagesordnung... Der Geometriefehler ist noch immer nicht beseitigt! Ich würde dringend und Zeitnah (!!!) darum bitten das zu lösen. (=Wochenfrist)

Bei diesem Relationsgeschachtel in dem Bereich sieht keiner mehr durch. Da kann ich selbst als 100%-JOSM-Nutzer nicht mehr durchsehen und nur noch raten, was der "Künstler" damit gemeint hat.

Alternativ bitte ich um Rückmeldung und ich vereinfache das nach meiner Sichtweise...

etwas knatschige Grüße,

streckenkundler

Nun, es gibt nach dem lokalen Revert die Funktion "Auswahl hochladen". Für die ehemals quadratische Geometrie (ich kann mich beim OSM-Inspektor auch daran erinnern) muß dann das genutzt werden. Beim Reverter muß man aber immer mit extremen Fingerspitzengefühl rangehen... bei solchen Sachen lieber einmal mehr schauen, in Zweifelsfall Hilfe suchen und nicht schnellschnell...

Ich habe mir dieses CS mal revertet... Das Ergebnis ist, daß ich für die 19a nun die alte Geometrie und die neue übereinander habe. Die neue liegt 100% Deckungsgleich mit dem DNM... Das Thema hatten wir neulich... Die Historie kann erhalten werden: Stichwort "Geometrie ersetzen"

Ich habe trotzdem das Gefühl, daß damit ein neuerlicher Import nun verschleiert ist... :(

du hast gelöscht und neu erstellt...

Ostring Nr. 19a:

alte Geometrie:
way/848077046/history#map=18/52.51093/13.72221&layers=N

neue Geometrie: way/1034599221

...und da ist nichts geteilt...

Ach, schreibt man keine CS-Kommentare mehr?

...und? Ein Import ist ausdrücklich nicht erwünscht und du importierst trotzdem...
Damit zerstörst du das Vertrauen, das in der Datenfreigabe liegt... Viele Dank :(

...diesen Abschnitt hast du gelesen?
osm.wiki/Brandenburg/Geoportal#Importe

Aufgrund der Geometrie und er frappierenden Überenstimmung mit Webatlas und Co. halte ich deine und vergleichbare Arbeitsweisen für einen blinden, plumpen und sturen Import ohne Validiätsprüfung mit aktuellem Luftbild...

No. You must write here! This is a generaly problem!

Hei,

ich antworte auf die PN besser im CS...

Der OSM-Datentyp Multipolygon funktioniert nur so, wenn damit Flächenbeziehungen dargestellt werden sollen, also inner vs outer. Einfachstes Beispiel ist ein See im Wald: See bekommt immer, Wald das outer. Der OSM-Datentyp Multipolygon funktioniert nicht bei dem Willen, alle Elemente die, wie hier zu einem Moor (=hier Springbruch) gehören, zusammenzufassen. Für mich ist das auch bisher ein stückweit unbefriedigend... eine richtige fundierte Idee zur Lösung habe ich aber leider auch nicht...

Eine meiner OverpassTurbo-Abfragen filtert alle Objekte von Typ Multipolygon heraus, die mehr als 1 Segment mit der Rolle outer haben. Diese Konstrukte sind überwiegend ersetzbar. Es gibt aber Ausnahmen: Das Outer der Insel im Senftenberger See: relation/5517607 muß in mindestens 2 Segmenten erfasst werden, da es sonst als 1 Segment >2000 Stützpunkte hat, das ist eine OSM-technische Grenze...

Was den Bredower Forst anbelangt, hat dieses MP noch immer 7 Outer: https://overpass-turbo.eu/s/1giI

Aber mit dem Proposal osm.wiki/Proposed_features/boundary%3Dforest(_compartment)_relations_(v3)#Proposed_tagging_changes böte sich zu mindestens da die Gelegenheit, daß mit type=boundary + boundary=forest + name=Bredower Forst zu erfassen.

Fürs Springbruch wäre auch sowas wie eine einfache Umgrenzungslinie mit place=locality plus vielleicht locality=* disskussionswürdig...

Sven

Erwischt!

...weil hier mal wieder stur, plump und blind Gebäudegeometrien aus Webatlas und/oder Gebäudeebene des Liegenschaftskatasters importiert wurden...
Einzig auf dem (groben) Luftbild der Jahre 1992-1997 ist da noch ein Gebäude zu sehen, danach nicht mehr.

Schön zu sehen auch gleich neben an an den Nebengebäuden Wismarer Straße 4a... , die nicht zum Luftbild passen, die importierte Situation ist die aus 2018 oder davor :(

Leute: eine Validitätsprüfung per Luftbild und noch besser VorOrt, wenn möglich ist gerade bei sowas zwingend erforderlich!

Hei,

wir sollten uns mal überlegen, wie man in solchen Fällen vorgeht... Wenn eine Route nur in eine Richtung ausgeschildert ist, daß ist in meinen Augen zu 100% ein Ausschilderungsfehler...

Ich habe bei mir in der Lausitz ähnliche Geschichten... Ich werde wohl "meine" Beschilderungsprobleme mal auf https://maerker.brandenburg.de/sixcms/detail.php?template=startseite stellen...

Viele Grüße,

Sven

Ich schaue mit die anderen Fehler noch mal an... bei 45-46 fehlte Rollen forward/backward... gerade hochgeladen...

So...

Route https://www.knooppuntnet.nl/en/analysis/route/8901644 wegen access=no, das ist die Brücke gesperrt,

Route https://www.knooppuntnet.nl/en/analysis/route/8941284 bekomme ich nicht gelöst, da fehlt aber sicher nur oneway:bicycle=no...

Rest ist bereinigt... Hetzt geht's nach Oberhavel...

Sven

Ja, ich habe mir einiges bereits angeschaut... Das Problem ist gerne das oneway=yes. Es mag ja auch nicht falsch sein, aber Knoppuntnet.nl hat hier für Radwege eine durchaus logische Auswertung der Geschichte. Da sieht man dann die Probleme... da muss man mal schauen, wie man das gelöst bekommt. Sven

Hallo Stefan,

irgendwas passt hier nicht... Ich hab mir gerade mal die Knotenpunktroute 2-27 angeschaut: https://www.knooppuntnet.nl/en/analysis/route/8899190

Hierbin ich der Meinung, daß es besser wäre, die begleitenden Wege separat zu erfassen... In weiten Teilen ist auch ein breiter Grünstreifen zwischen Weg und Straße. Alternativ müssen die Kreisverkehrbegleitenden Wege entgegen dem Uhrzeigersinn der Knotenrelation hinzugefügt werden. So , wie das jetzt ist, kollidiert das mit den oneway-Angaben. Schuldiges Element dürfte way/724728895 sein...

Im Netz Barnim scheinen noch einige solche Schnitzer zu sein...

fragende Grüße,

Sven

Schade, daß der Verursacher nicht reagiert... :(

Ich hab da ja auch schon herumeditiert...

Tja, das Problem ist auch folgendes...
Sämliche Elemente der Springbruch-Relation im Moment ist das Springbruch... Der Datentyp Multipolygon ist aber nur dafür da, alle beteiligten Elemente sinnvoll nach inner und outer zu sepatieren. Das MP ist nicht dafür da, eine "Sammelrelation" zu sein für alle Elemente, die wie hier zum Springbruch gehören.
So...
Man könnte jetzt eleganterweise type=site nehmen, aber da fehlt wieder eine gewisse "Renderingantwort" des Namens. Da kann ich sehr gut verstehen, daß für solche Konstrukte eine in meinen Augen durchaus gerechtfertigte adäquate Darstellung des Namens eines solchen Landschaftsteils fehlt...

Das ist z.B. vergleichbar mit dem Bredower Forst: relation/111221

Es ist ein MP mit >1 outer... Für mich fehlt eine Lösung, mit der ich eine Umgrenzungslinie um alles ziehe, diese entsprechend benamse, und den Landschaftstyp festlege, fertig... Polygonmitte =Name...

Eine Art Namensgeometrie...

...ist erst mal eine fixe Idee...

Sven

Hei,

bitte, bitte sowas nie und nimmermals einfach löschen! Es mag sicher so sein, daß es den Busbahnhof nicht mehr gibt, aber er sich weiterhin im Luftbild sichtbar: z.B. https://bb-viewer.geobasis-bb.de/?projection=EPSG:25833&center=421527.8331698978,5701215.175868563&zoom=14&bglayer=4&layers=25

Für solche Geschichten bitte IMMER die Lifecycle prefix anwenden!!!! osm.wiki/DE:Lifecycle_prefix

Ich werde das betreffende reverten und entsprechend mit den Lifecycle prefix versehen.

Danke,

streckenkundler

...Kein Problem, darum gibt dieses Rückmeldesystem... :)

Sven