Hallo hackthemap,
ich habe das mal (weil Du dich auf meine PN nicht gemeldet hast) hiermit:
changeset/71382329
auf lit=yes geändert.
Kleiner Hinweis, ggf. auch mal abends/nachts schauen, ob beleuchtet wird... ;-)
Schöne Grüsse
sh

rückgesetzt in:
changeset/71155345

rückgängig gemacht in:
changeset/71155216

rückgängig gemacht in:
changeset/71154912

rückgängig gemacht in:
changeset/71154816

zurückgesetzt in:
changeset/71154730

zurückgesetzt in:
changeset/71154631

zurückgesetzt siehe:
changeset/71154532

zurückgesetzt siehe Änderungssatz: changeset/71154375

Denke auch.
"... kurzes Stück ..."
Naja, es sind hier nicht nur 10m wie bei einer Fussgängerinsel (traffic_claming), sondern immerhin fast 150m ;-) Von daher hätte ich nichts dagegen die Spuren bei Gelegenheit zusammenzulegen.

"und ein Spurwechsel dazwischen ausgeschlossen ist" na das hat doch für diesen Sachverhalt keine Relevanz, oder doch?

„auf Mitte zieht“ ... Kompromisse ... Knicke.

Interessanter Punkt, man könnte die Position von Linie way/332873359 belassen und an dieser das Merkmal "placement:forward=middle_of:1" ergänzen, sodass kein weiterer Knick in dieser Linie entsteht und für die Gegenrichtung gibt es derzeit sowieso eine Rundung die dann etwas stärker ausfällt, was aber nicht stören sollte.

Aber, da es auch nicht so wichtig ist, hatte ich damals auch nur auf die Schnelle paar fixme's verteilt...

Freut mich, dass es Dir auch Spass macht Spurmapping an die physischen OTG Begebenheiten anzupassen. :-)
Was hältst Du von dem Vorschlag ohne Knicke und aber mit „placement:…“?

PS: Lese Emails sehr selten, falls Du mal schneller eine Antwort von mir (unter meinen Änderungen auf einen Deiner CS-Diskussionskommentare) lesen wollen würdest, schick' mir einfach gerne noch eine PM hinterher nach, oder letztere ausschließlich ;-)

Gut so, ... :-)
Ich wollte eigentlich auch keine Rollen für die neu hinzugefügten Mitglieder vergeben. Ziel von diesem CS war es hauptsächlich weitere osm-Wegstücken in die genannte Relation aufzunehmen, was m.E. auch geklappt hat. Siehe auch hier* derzeit drittletzte Spalte (2019-05-24T19:59:55Z 70597986)

* http://osm.mapki.com/history/relation.php?id=7972271

Schöne Grüsse

Doch war Absicht.

Ich wollte damit klar stellen, weil der Schlagbaum geöffnet ist, dass es keine Blockierung für irgendeine Verkehrsart gibt, oder welche Merkmale benutzt Du bei einer offenen Schranke?

Man könnte es auch ähnlich mit dem Erfassen der physischen Position eines Verkehrszeichens neben des osm-Weges sehen.

Wenn Du magst, ergänze gerne nach eigener und/oder allgemeiner gängiger Art die logische Funktion auf der 2D-Navi.-Linie.

Ich hatte ein Video von user:abrensch im Hinterkopf, als er bei Minute (13:25 https://tinyurl.com/y3b89c5p) dazu etwas sagt.

Grüsse

Geändert in CS:
https://overpass-api.de/achavi/?changeset=69568346

Hallo Mario,
.
vielen lieben Dank für die ausführlichen Erläuterungen.
.
Ich habe das jetzt so verstanden, wenn also Auswerter einer Grenzgebiets-Relation nicht schlau genau sind und die Fläche nicht unter der Bezugnahme der entsprechenden Rollendefinition der Relationsmitglieder modellieren können, dann diese Rathaus/Bürgerhaus-Linien als „inner“-Flächen unsinnigerweise ausgeschnitten werden. – Das wäre in der Tat suboptimal.
.
Ja, mein erster Gedanke war soeben, dann auch für amenity=townhall anstatt einer Linie(Fläche) einen Punkt zu verwenden.
.
Du hast Recht mit der noch weiteren Option als Nebenlösung, die POIs office=government (der eher neueren/zusätzlichen Erfassungsart) zu verwenden, ja dann eben auch ausschliesslich als Punkt-Element.
.
Das könnte dann nämlich nicht nur für admin_level=8 (lat-lon des Gemeindeamtes), sondern auch für admin_level=6 (lat-lon des Landratsamt) interessant sein...
.
Ich sehe Einbindung von punktförmigen Objekt in Grenzgebietsrelation aber jetzt bereits etwas kritisch, denn es könnte ja jederzeit ein anderer Benutzer aus Punkt wieder eine Linie(Fläche) machen.
Man sollte dann wenigsten so etwas wie eine Notiz an dem Punkt-Objekt (amenity=townhall / office=government) hinterlassen (z.B. note=Bitte dieses Objekt punktförmig belassen, solange dieses Objekt als Mitglied einer Rolle („townhall“ oder „office“) in der Grenzgebietsrelation eingebunden ist)
.
Das heisst, wenn ich für die Zukunft diese ausschliesslich punktförmigen Objekte als Mitglieder mit Rolle (bspw."townhall" / "office") der Grenzgebiets-Relation (inklusive note=“text siehe oben“) hinzufüge, dann würdest Du es nicht mehr revertieren?
.
Ich gebe Dir auch Recht, dass das dann schon ggf. als so eine Art Sammelrelation oder site-Relation (die ich persönlich nicht so mag) gewertet werden könnte. Aber da wir uns ja hier bei Grenzrelationen sowieso schon in der osm-Grauzone (bzgl. on-the-ground Erfassung) befinden, kommt es dann darauf m.E. auch nicht mehr an…
.
Viele Grüsse
sh

Hallo Mario,
.
"bitte unterlass es, Rathäuser als Mitglied zu Grenzrelationen hinzuzufügen."
.
Warum?
.
Etwa aus diesen Grund:
"Es sind für Linien nur die Umrisse mit der Rolle "outer" bzw. "inner" definiert."
?
.
Du beziehst Dich auf diesen wiki-Artikel?:
osm.wiki/Relation:boundary
.
Schöne Grüsse
sh

Hallo Jan,
.
ich habe das hier nur rein zufällig gelesen. Ich leite Dir mal eine ältere PN weiter, die dazu ein paar mehr Info's enthält. Aber vielen Dank schon mal vorab für's Aufspüren dieses Umstandes.
.
Grüsse
sh

Soeben erst zufällig gelesen - gern geschehen ;-)

Hallo aseere4c26,
Deine Beschreibung klingt so, als ob Du das von mir gelöschte Objekt (die von mir gelöschte Fläche: way/388659493 "Stadtteil" von Seligenstadt "Klein-Welzheim") als verwaltungstechnische Einheit siehst. Wäre es dann vielleicht eine Option, dieses Objekt in eine der Kategorien einzuordnen die boundary=administrative[1] bietet?

Nur nebenbei, ich habe generell nichts dagegen das Objekt wiederherzustellen würde es ggf. nur anders einordnen wollen.

Viele Grüsse
sky-hub

[1] osm.wiki/DE:Tag:boundary%3Dadministrative

OK

Ich verstehe die Abweichung / das Problem ("Suchfehler") derzeit nicht so recht. Könntest Du mir das erklären, oder es mir eventuell zur Veranschaulichung an einem Beispiel zeigen? Ein Beispiel idealerweise in der Gegend an einem der beiden Siedlungsplätze (Klein-Welzheim oder Froschhausen) für die ich Änderungen vorgenommen habe…

Meine Intension mit den Änderungen war eigentlich nur der alten OSM-Faustformel „One feature, one OSM element“ nachzugehen ;)
Es gab nämlich für ein und dasselbe reelle Objekt (place mit Name „Klein-Welzheim“) zwei OSM Elemente:
node/4514014148
way/388659493

Hallo aseerel4c26,
.
meinst Du diesen CS-Kommentar aus V1: "node in polygon geändert, um Suchfehler von Nominatin zu beheben. Der Umriss des suburb ist nur angenähert. Siehe: https://github.com/twain47/Nominatim/issues/231

Bearbeitet vor etwa 2 Jahre von dsp77
Version #1 · Änderungssatz #36259479"
?
.
Viele Grüsse
sh