barrier und landuse am selben Way

Und die Hecke ist an keiner Stelle unterbrochen (zB am Eingang)?

Das hing/hängt von den Schlüsseln ab, die du der Fläche mitgibst, area=* funktioniert in beide Richtungen.

Da wir keinen eigenen Flächendatentyp haben, müssen wir uns mit area=* behelfen, oder dem Auswerter die Wahl lassen. Bei vielen Renderern kommt osm2pgsql zum Einsatz, das bei geschlossenen Linien Anhand der Schlüssel entscheidet ("natural=* ist eine Fläche, tunnel=* ist ein Strich, barrier=* Strich, hier die linear/polygon in der 4. Spalte). Wenn osm2pgsql anderer Meinung ist als du, kannst du ihn mit area=yes/no zu deiner Ansicht überreden. Der Renderer könnte das dann nochmal umdeuten und aus seiner “flächen-Tabelle” im Bedarfsfall nur den Umriss holen. Das tun aber nur wenige.

Edit: Hab grad nochmal nachgesehen, weil mich “barrier=* Strich” verwirrt hat. Der osm2pgsql-Style, der von unserem Mapnik verwendet wird, hält barrier=* tatsächlich für einen Strich, hat aber auch eine Render-Regel für flächige Hecken. Die kommt dann zum Zuge, wenn jemand entweder mit area=yes den Heckenring zur Fläche macht, oder der Weg aus anderen Gründen als Fläche interpretiert wird. Letzteres war hier der Fall, weil die Regel “landuse ist eine Fläche” gewonnen hat.

Würde ich annehmen.

Am Eingang ist ein barrier=gate, das auf einem shared node des highway=service und des fraglichen barrier=hedge sitzt.

–ks

BTW: Diese Way-Links (siehe Beitrag 1 oben) funktionieren bei mir gar nicht mehr, es wird nicht zu dem Objekt gescrollt. :frowning:
(Win-7, FF)

“Gelöscht vor etwa 13 Stunden”

Hab ich versemmelt, der Way wurde ja zugunsten eines Monopolys gelöscht. Siehe im PS unter #1.

–ks

versemmelt heisst: das Problem der Nichtanzeige existiert nicht? So ganz klar ist mir nicht, ob das Problem für Dich gelöst ist…

P.s.: Wobei ich es oft auch begrüssen würde gelöschte Wege direkt in der Karte zu sehen.

  • Das Problem der falschen hedge-Anzeige im Mapnik-Rendering ist per Workaround gelöst (barrier=hedge als Element, landuse als Monopolygon daraus).
  • Das Problem der Nichtanzeige des in #1 genannten Ways wurde durch die Lösung erzeugt (weil ich nicht den dort verlinkten Weg, sondern einen neuen, infolge der vorübergehenden Zwei-Wege-Lösung darauf liegenden Way zum barrier=hedge erklärt habe).
  • Versemmelt hab ich, daß aufgrund dieses Vorgehens mein eigener Link nicht mehr funktioniert.

–ks

Ich hätte die Hecke - wie vermutlich tatsächlich - rechts und links des Weges enden lassen. Das barrier=gate ist doch bestimmt in ein barrier=fence (type=metal oder wood). Dann kann die Relation entfallen.

Im Süden sieht es aus wie ein Stück Zaun über der Wiese. Hecke ist wohl eher eine Baumreihe (mit Zaun?)

Taggen für den Renderer.

MP mit 1 Element?

BTW, access=yes am gate?

Noch was: da folgt ein Service-Weg auf einen Track. Routingtechnisch ein Problem.

+1

Ist ja IMO eh keine Relation.

Und gerade dies denke ich nicht.

OK, erst jetzt ist mir bewusst, dass landuse=residential und barrier=hedge an dem geschlossenen way waren? Aber beeinflusst der landuse-Tag dies? Wohl kaum!??

Im englischen wiki steht:

Aber wie ich eben sehe, hat sich das Thema anscheinend eh erledigt!

Am Zugang die Hecke aufgtrennt, MP-Relation angepasst. Ist zumindest kein Taggen für einige Renderer, wie zuvor.

Ähnliches sollte man auch mit der allotment-Fläche getan werden, die muss ja auch einen Zugang haben.

Hi,

https://www.openstreetmap.org/browse/relation/5238612
https://www.openstreetmap.org/browse/relation/5238614

OSMI meckert hier intersections an.
IMO ist eine MP-Realtion hier nicht angebracht, oder?

Irrläufer

Laut taginfo gibt es exakt 3000 Objekte, die mit “barrier=hedge” und “landuse=*” getagt sind.
Wie Mapnik korrekt darstellt, muss man dies als eine flächige Hecke mit der entsprechenden Nutzung interpretieren.
Vermutlich ist in allen Fällen gemeint, dass die Fläche keine Hecke ist, sondern davon umgeben wird.
Dafür sollte man zwei OSM-Objekte verwenden.
Jede Kombination von zwei realen Objekten in einem OSM-Objekt führt zu Widersprüchen, wenn eines davon einen Namen erhält.

Früher war “fenced=yes” als Attribut einer Fläche verbreitet. Dies würde Fehlinterpretationen ausschließen.
Inzwischen hat sich “barrier=fence” durchgesetzt und es gibt >90 000 Kombinationen mit “landuse=*” :frowning:

Gibt’s da keine Meinungen dazu?
Im Wiki finde ich noch als gutes Argument:

Wobei ich mir grad unsicher bin, ob das im Rendering nicht ähnliche Probleme macht.

Einen fiktiven Zugang (path) zugefügt, Rest wie gehabt.

Bei barrier=fence hätte man das Problem im speziellen Fall des Mapnik-Stils auf osm.org nicht. Der kennt nur flächige Hecken. Bei anderen Flächen mit barrier=* macht er die Umrandung grau. Würde man das ändern, gäbe es einen Aufschrei, falls z.B. die häufige Kombination “barrier=wall + landuse=cemetery” mauergrau gefärbt würde…

Das grundsätzliche Problem “Fläche mit ringförmigen Hindernis oder flächiges Hindernis” bleibt natürlich und zwingt den Renderer zum raten, was der Mapper wohl gemeint haben könnte.

Das Argument funktioniert anders rum genauso gut oder schlecht: Wenn jemand Hecken sucht, möchte er nicht auch noch alle Zäune durchsuchen. Es gibt ja sicher Auswertungen, die Hecken nicht in erster Linie als Barriere für Menschen begreifen, sondern z.B. als Lebensraum für Tiere. Die möchten nichts mit Zäunen zu tun haben.

Grüße, Max

Ok, irgendwas is ja immer :wink:
Allerdings: wenn ich Hecken suche, würde ich natürlich auch nach fence_type suchen.