Bleibt trotzdem die Frage, wie ich OSM erkläre, dass die beiden unterschiedlichen “Flächen” verbunden sind?
Können womöglich, aber nicht unbedingt dürfen:
Von daher kann es je nach Einzelfall durchaus geboten sein, nicht auf ganzer Strecke zu verbinden. Routern ist es vermutlich eh schnuppe, denen muss man eher die Ecken anbinden (wo hier die Hilfswege lustlos enden … Man muss übrigens nicht JEDE Hilfslinie benamsen … 
)
Werden die von Routern berücksichtigt?
area:highway=* soll gar nicht routingfähig sein. Das ist der große Unterschied zu highway=* + area=yes (das für frei routingfähige Flächen da sein soll und soweit ich weiß keine linearen highway=* enthalten sollte).
Nein, soll gar nicht.
area:highway soll immer in Verbindung mit einem linearen Way gemappt werden, über den dann geroutet werden kann.
Es ist quasi nur eine “Ausschmückung” so ähnlich wie bei river+riverbank.
Habe aber die Hoffnung aufgegeben, dass das Konzept vom allgemeinen Mapper verstanden wird. 
OT (vielleicht eigenes Thema?)
Das Problem ist ganz einfach (OSM gemacht):
highway=pedestrian als area=yes obwohl highway=* nur abstrahierte Linien sind statt Flächen.
Deshalb sollte area:highway=* verwendet werden. Dort kommen Flächen an Flächen mit darüber liegenden highway als als Linie zum routen.
Dort wurde zum Routen z.B. https://www.openstreetmap.org/way/385505185#map=19/50.83317/12.92395 angelegt. Jetzt noch area=yes zur area:highway=pedestrian (wird dann zwar auf OSM Standart nicht mehr dargestellt) ist aber richtiger.
Das Problem in diesem Thema ist aber Verkleben von hw und z.b. natural / landuse
Hallo,
gibt es in diesem Thema mittlerweile einen Konsens? Ich habe den Thread gelesen, aber das Thema scheint eingeschlafen zu sein. Den Entwurf für einen Konsens im Wiki finde ich sehr gut.
Da ich gerne in NVP/MV mappen und für ein paar Orte die Daten aktuell halten würde, wäre es toll, wenn der Konsens nun gilt. Da rund um Stralsund sehr viel Flächen mit Straßen verklebt sind, würde ich das auflösen, damit ich die OSM-Daten aktuell gehalten werden können. Es wäre sehr demotivierend, wenn dann anschließend ein anderer User wieder verkleben würde.
Ein Problem, dass ich mit geklebten Flächen, die ich auflösen möchte, habe ist, dass der iD Editor diese Nodes nicht trennen kann. Das liegt daran, weil der Node Teil einer Relation ist. Z.B.: https://www.openstreetmap.org/node/1193467163
Ist das nicht eine Motivation, dass dieses Mappen nur dazu dient, dass der Renderer keine weißen Flecken mehr darstellt? Das klingt für mich sehr nach Mapping für den Renderer.
Wird Mapping für den Renderer nicht sowieso schon bestraft oder hier beim Kleben nicht?
Es gab eine Mehrheit für das Nicht-Verkleben, aber keinen Konsens. Die Abstimmung über Regeln war damals knapp gescheitert, teils an Formfehlern/Formulierungsfehlern.
Im Küsten-nahen MV sind ganze Landstriche ziemlich hoffnungslos verklebt. Das Schließen von weißen Flecken ist auch gar nicht das Problem, und auch nicht pauschal als Mappen für den Renderer zu bezeichnen. Man kann das auch sehr gut ohne Verklebungen von Flächengrenzen an Wege hin bekommen, wenn man WILL.
Ist aber mangels Willen oder Können Alles erst einmal verkleistert und getackert, kriegt man es mit ID kaum wieder gelöst.
Das ist selbst mit JOSM noch eine undankbare Arbeit.
Das geht, wenn man den Knoten und die Fläche/Linie, die man trennen möchte, gemeinsam auswählt (Shift-Tast gedrückt halten).
Also im Beispiel oben:
- Das “landuse=farmland” auswählen
- Shift-Taste drücken und halten
- Den Knoten auswählen
- Shift-Taste loslassen
- Taste “d” drücken (oder Rechtsklick auf den Knoten und “Trennen” auswählen)
Der entsprechende Knoten des “landuse=farmland” ist jetzt von der Straße und dem “landuse=residential” getrennt.
Danke für den Tipp. Ich bekomme das so hin.
#edit:
ich habe mal ein Ticket dafür aufgemacht: https://github.com/openstreetmap/iD/issues/8303
Vielleicht kann der Hinweis in der Benachrichtigung, die sowieso angezeigt wird, mit drin stehen.
Übrigens enstehen bei einer korrekten und vollständigen Erfassung der Vegetationsflächen keineswegs “weiße Flecken”, s. z.B. diesen Ortsrand:
https://www.openstreetmap.org/#map=19/51.26399/9.57122&layers=D
… wenn man denn die Straßenflächen z.B. als landuse=grass erfasst. Das würde ich aber nicht als korrekt bezeichen.
… Naja … wers ganz, wirklich ganz genau haben will, kann das landuse=grass auch (später) noch der Läge nach teilen und innen die highways in 2D erfassen, die äußere Abgrenzung des Bankett zur landwirtschaftlichen Fläche ist dann aber immer noch korrekt.
Das halte ich tatsächlich für eine Unsitte, die allerdings auch daher kommt, dass man z.B. Forstwege im Wald auch einfach durch die Waldfläche hindurch führt, obwohl im Grund die Wegfläche keine Waldfläche ist. Und wir wollen sicherlich nicht damit anfangen, Waldflächen für jeden Forstweg in kleine Abschnitte aufzuteilen. Aber bei Straßen sollte eine Waldfläche meines Erachtens schon möglichst in eine Fläche rechts und eine links der Straße aufgeteilt werden.
Nicht nur die Acker- oder Waldfläche endet spätestens da, wo der Asphalt anfängt, das gilt gleichermaßen auch für Grünflächen zwischen Straßenrand und Waldrand. Diese Flächen enden auch dort, wo die Asphalt- oder der Schotterfläche anfängt. Wenn dadurch in hohen Zoom-Stufen ein schmaler weißer Korridor auf der Karte entsteht, halte ich das für keinen Fehler, da diese Fläche ja sogar bestensfalls optisch die Breite der Straßenfläche andeutet. (Detailmapper können diese Lücke ja mit area:highway=* füllen, auch wenn diese Flächen in den meisten Kartenbildern nicht angezeigt werden.)
Deswegen:
mit der landuse=grass-Fläche vom Ackerrand auf der einen Straßenseite bis zum Ackerrand auf der gegenüberliegenden Straßenseite ist meines Erachtens in der Sache keine korrekte Erfassung der Landnutzungsflächen und könnte im Grund nur einigermaßen passen, wenn die Straße eine Oberfläche aus Gras hätte.
Wenn man sich schon die Mühe macht, den Grünstreifen zwischen Acker und Straße mit landuse=grass zu erfassen, sollte man diese Flächen tatsächlich am Straßenrand enden lassen und nicht über die Straße hinweg zum gegenüberliegenden Feldrand ausdehnen.
Aber zugegebenermaßen sind Verklebungen von Landutzungsflächen mit Straßenlinien noch schlimmer, weil nur sehr aufwändig zu korrigieren und zu warten.
… Eben … dass das von mir vorgestellte Flächen-Model topologisch auch nur als ein (vereinfachter) Zwischenschritt betrachtet werden kann, dies ist mir bewusst.
Habe aber die Erfahrung genmacht, dass diese “Grundierung” der Flurstücksflächen der highways diese sehr zuverlässig vor “Verklebung” schützt
(Und ganz nebenbei ist ein realistisches und sauberes Kartenbild damit auch gewährleistet)
+1
Da hilft ein Blick nach oben (alternativ daheim auf der Couch ein Blick nach unten): Wenn man den Himmel nicht sieht, weil die Kronen über dem Weg geschlossen sind (oder man auf der Couch im Luftbild den Weg nicht sieht), dann ist die Fläche komplett mit der gewünschten Pflanze bedeckt … 
Zitat aus dem Waldgesetz:
Gesetz zur Erhaltung des Waldes und zur Förderung der Forstwirtschaft (Bundeswaldgesetz)
§ 2 Wald
(1) Wald im Sinne dieses Gesetzes ist jede mit Forstpflanzen bestockte Grundfläche. Als Wald gelten auch kahlgeschlagene oder verlichtete Grundflächen, Waldwege, Waldeinteilungs- und Sicherungsstreifen, Waldblößen und Lichtungen, Waldwiesen, Wildäsungsplätze, Holzlagerplätze sowie weitere mit dem Wald verbundene und ihm dienende Flächen.
Hervorhebung durch mich.
Ich weiß nicht, wie so Abstimmungen normalerweise ablaufen. Ist es möglich die damalige Abstimmung noch einzusehen? Geht das im Mailinglistenarchiv oder im Wiki irgendwo?
Würde es etwas bringen, die Form- und Formulierungsfehler zu beheben und eine erneute Abstimmung zu starten?
Oder was müsste man machen, um einen Konsens zu schaffen? Es wäre toll, wenn wir in dem Thema Verkleben alle an einem Strang ziehen und man - überspitzt formuliert - beim Bearbeiten nicht ständig an- und abklebt.
Hallo,
Über https://wiki.openstreetmap.org/wiki/User:Frederik_Ramm/Fl%C3%A4chenverklebung wurde nie abgestimmt. dx125 verwechselt es mit der Empfehlung zur Verwendung von Multipolygonen, der aus der n-ten Diskussion über den Multipolygon-Wahnsinn hier im Forum entstand. Über diesen wurde tatsächlich abgestimmt. Viele stimmten zwar der Forderung zum sparsamen Einsatz von Multipolygonen zu, lehnten ihn aber ab, weil er entweder zu konkret war oder zu viel Vorschriften machte, die nichts mit der Hauptfrage zu tun hatten. Die damaligen Diskussion im Forum zur Multipolygonfrage ist unter https://forum.openstreetmap.org/viewtopic.php?id=64439 zu finden.
Bezogen auf den Text von Woodpeck: Nochmal eine 14-tägige Diskussionphase hier im Forum und auf der Mailingliste Talk-de, dann könnte man schon über den Text abstimmen. Ich erwarte nicht, dass riesige Änderungsvorschläge während der Diskussion eintreffen, und schätze die Chancen für eine Annahme (75-Prozent-Quorum, wenn man die Proposal-Regeln anwendet) hoch ein.
Viele Grüße
Michael