ja anderes Thema, aber gleiches Problem. Nur das man Relationen an Wege klebt und nicht landuse 
Voll dafür. Hab das “(ways)” direkt mal dazugepackt 
Liebe Grüße
Könnte man allgemeiner formulieren. Was ist mit Gebäuden? Sollte man die an Landnutzungs-Polygone kleben? Und was ist mit Gebäudeteilen (building:part) an Gebäude? Was ist mit Räumen und Korridoren (indoor=room/area/corridor) an Gebäude?
Ich würde sagen, da müsste das gleiche gelten. Wie auch mit landuse an roads erscheint es erstmal irgendwie bequem (u.A. weil JOSM einem das quasi vorschlägt) Gebäudeteile an Gebäude, Indoor-Räume an Gebäude (und dann ergo also auch Gebäudeteile an Indoor-Räume und gar Landnutzung mit Gebäuden mit Gebäudeteilen mit Indoor-Räumen) zu kleben, was dann aber dabei herauskommt ist ein unwartbares Durcheinander.
Ich habe es neulich versucht, ohne Verkleben hinzubekommen. Das ist mit JOSM quasi unmöglich sofern man nicht die geheime “nein, hier nicht verkleben!”-Taste kennt. Daher schlage ich vor, als ersten Schritt erstmal JOSM zu sperren!
Natürlich nur ein Scherz, aber ein Hinweis darauf, dass das Standardverhalten des Editors nicht unerheblich zu dem Problem beiträgt. In JOSM fühlt es sich “richtig” an, (quasi) übereinander liegende Nodes zusammenzuführen, unabhängig vom Typ der Elemente. Gab es da nicht sogar eine Warnung für?
Generell sollte gelten, dass nicht direkt miteinander zusammenhängende Daten keine gemeinsamen Nodes haben sollen. In einem Statement kann man ja Beispiele bringen was zusammenhängende Daten sind und was nicht. Ein Statement allein wird allerdings nicht viel bringen. Viel bringen würde, das Standardverhalten der Editoren anzupassen.
Manchmal hat man aneinander klebende Gebäude (on the ground) und die Grenze von residential und commercial oder industrial läuft genau dort, wo beide Gebäude sich berühren, an der Trennwand…
Leute, lasst uns erstmal mit den Grenzen der Landnutzung- und Naturflächen zu Potte kommen!
Sprich:
Wie sollen diese untereinander verbunden werden und wie sollen diese eben mit Ways NICHT verbunden werden.
Lasst uns bitte einen Minimalkonsens finden, bevor der große Wurf wieder einmal nicht gelingt.
Darauf aufbauend finden wir sicher auch weiter gehende Lösungen, z. B. bei den Gebäuden und Multipolygonen.
“Lieber den Spatz in der Hand, als die Taube auf dem Dach.”
JOSM ist übrigens eine feine Sache, nix abschalten bitte 
Häh? Was zusammenklebt hat doch automatisch “zusammenhängende Daten” Ne, im Ernst, ob was zusammen hängt oder nicht liegt doch schon sehr im Auge des Betrachters. Ich klebe landuse aneinander, buildings auch, Straßen sowieso. Ich klebe aber auch einen Fußweg an ein Gebäude (entrance=*) oder bei tunnel=building_passage (weil es das Wiki so sagt). Ich habe hier aber auch einen Kollege, der hat diverse landuse=residential um die Wohnhäuser “rumgemalt”. Das ist natürlich Quatsch.
Ich würde also bei der Formulierung von dx125 bleiben.
Ist das schon Insider wissen… Ich bin schon zu lange dabei 
aber es nervt schon a bisserl… wie oft man die Taste braucht… mir wären Layer Steuerung lieb… Wie man das aus CAD oder GIS Programmen kennt… um Sachen auf nicht fangbar zu schalten zu können
Man kann das zwar auch mit filtern machen, aber das ist mir zu umständlich/kompliziert 
“westnordost”, ich widerspreche Dir 
Ein Gebäude, dass als Fläche eingezeichnet ist, kann sehr wohl mit dem landuse verklebt werden, da es eine eindeutige Grenzlinie zwischen beidem gibt. So z.B. wenn eine Weide an eine Garagenwand grenzt. Das ist etwas Anderes als das Verkleben eines längliche-flächigen Objekts (einer Straße, eines Bachs), das lediglich als Linie in OSM eingetragen ist.
Das zwei aneinangergrenzende Objekte sich gemeinsame Nodes teilen, also verklebt sind, heißt nicht, dass sie sich Eigenschaften teilen. Es heißt nur, dass das die eine Fläche genau dort aufhört, wo die andere anfängt. Wenn zwischen Gebäude und Wiese keine Lücke ist, dann gehört da auch keine Lücke künstlich in die Datenbank gebastelt.
Die Grenze zwischen Wiese und Straße ist aber nie die Straßenlinie highway=, da die Straßenlinie in der Mitte der Straße eingezeichnet wird, währen die Wiese am Rand der Straße endet. Eine Verklebung zwischen Straße und Wiese dürfte insofern nur zwischen der Grenzlinie einer area:highway= und der Wiese gemacht werden.
Den Vorschlag von “dx125” finde ich gut.
Hm. Bin momentan mit Flächen im fernen Südosten beschäftigt, in erster Linie Mangroven, aber dann auch Wälder und weiter daran anschließende Gummibaum-/Ölpalm-Plantagen. Gerade zwischen Plantagen sind es mal kleine Bäche, die die Grenze bilden (falls man das überhaupt erkennen kann). Und das Bächlein erfasse ich da nicht mit “riverbank” im Gegensatz zu den breiten Wasserflächen in den Mangroven. Da verklebe ich in gewiss seltenen Fällen doch mal Plantage und Bach.
Hallo zusammen und ich bin leider beim Zerreden dabei Bitte bedenkt, dass es sehr wohl Ways gibt, die in der Realität an Flächen grenzen. Was ist mit Einfriedungen (Zäune, Mauern, Hecken), oder der als Way gezeichneten Bahnsteigkante, die den flächigen Bahnsteig abschließt? Manchmal grenzen Baumreihen eine Fläche ab, seltener sogar Entwässerungsgräben. Die Siedlungsfäche wird unmittelbar von der als Way gezeichneten administrativen Grenze begrenzt, sie verläuft nicht halb über den dahinterliegenden Acker.
Punkt 2 der Begründung kann ich absolut nachvollziehen, würde trotzdem widersprechen. Wer das so begründet, stellt sich auf eine Stufe derjenigen, die Flächen anpappen, damit es beim Rendern schöner aussieht. Punkt 1 muss maßgebend sein.
Gemeint sind doch Wege, Pfade, Straßen, Bäche, Flüsse, die - obwohl flächig - als Linie eingezeichnet sind und nicht grundsätzlich alle als Linie eingezeichneten Objekte. Vielleicht sollte man daher den Begriff “way” nicht verwenden, weil nicht klar ist, was damit gemeint ist: way im Sinne eines Weges oder way im Sinne einer Linie.
Lasst uns das doch erst einmal eingrenzen auf solche ways, die auch way heißen: highways, railways, waterways.
Also alles, wo wir mehrheitsfähig als Community dafür sind, es nicht zu verkleben mit Landnutzungs- und Naturflächen.
Das andere bitte ausklammern, evtl. auf später verschieben.
Step by Step.
@soilinvestigator83
Bei der Baumreihe gehe ich mit, die kann auf der Flächengrenze stehen, markiert sogar manchmal die Flächengrenze.
Beim Wassergraben wächst beiderseits fast immer Gras, es sei denn der verläuft im vollversiegelten Bereich, zum Beispiel in der Stadt.
Auf dem Lande liegt der Wassergraben bei exaktem Mapping relativ mittig in einem schmalen Grasstreifen, auch wenn der beiderseits nur 1 Meter breit ist oder weniger. Das ist wie mit den Grasstreifen am Ackerrand, zur Straße hin, bis zum Straßen-RAND ( ! ). Wenn man exakt ist (und Lust hat), kann man das so mappen.
Der Acker oder der Wald (Bäume) sind aber definitiv nicht auf der Mittellinie des Wassergrabens, da ist normalerweise Wasser.
Dem stimme ich zu. Ein bisschen OT: In meiner Gegend stoße ich aber auch oft auf Bauerhöfe, bei denen das Wohngebäude und der Garten daran als landuse=residential erfasst sind, gerne auch mit Linie quer durchs Gebäude. Aus meiner Sicht ist es aber völlig normal, das ein oder mehrere Gebäude(teile) auf einem Hof bewohnt werden. Ich verschmelze dann den landuse=residential mit dem landuse=farmyard.
Erst einmal ist irgendwie wie … naja. Aber ist okay, lasst einfach Punkt 2 raus, der ist Nonsense. Punkt 1 reicht als Begründung völlig aus. Wenn das Proposal hilft eine Selbstverständlichkeit bezogen auf Verkehrswege durchzusetzen wäre das super. Wie wird das eigentlich international gehandhabt? Gibt es in anderssprachigen Communities ähnliche Diskussionen? Wie wird da vorgegangen?
In NL ist Verkleben von highways und landuse verpönt. Wenn es doch vorkommt, klagt das Forum über urlaubende Duitsers… 
Hallo,
hier wird künstlich etwas zum Problem gemacht, wo gar keines besteht.
Mir stellt sich die Frage, um was für wichtige Informationen würde es sich den größtenteils handeln,
wenn die Verklebung aufgehoben wird? Der 1m breite Grasrand und zugewachsene Entwässerungsgraben
zwischen Straße und Feld der je nach Jahreszeit als Gras oder Blumenbiotop für Insekten gemappt wird?
Hat OSM so viele Mapper um das flächendeckend Umzusetzen und zu warten?
Alle Straßen als Fläche zu mappen halte ich ebenfalls für Utopie, es wird ja nicht einmal gemacht,
dort wo es unbedingt notwendig ist koplizierte Straßen oder Kreuzungsverläufe abzubilden.
Die Relationen öffentlicher Verkehrsbetriebe werden ja nicht regelmäßig zerstört weil irgendetwas Verklebt ist,
sondern weil diese sich ständig ändern und immer wieder angefasst werden müssen.
Dazu kommt noch das das ganze äußerst kompliziert gehandhabt wird und für einen normalen Freizeitmapper nicht nachvollziehbar ist.
Dabei stelle ich mir z.B. die Frage, warum muss überhaupt gemappt werden, wo der Bus entlangfährt,
99,8 % der Anwender werden vermutlich nur wissen wollen, wo sie Ein- und Aussteigen müssen um von A nach B zu kommen.
Sinnvolle ÖPNV-Karten lassen sich sicher auch nur anhand von gemappten Haltestellen generieren, Schematisch, oder als Routing-Anwendung.
Eine Echtzeit Anzeige wo der Bus sich gerade befindet, lässt sich so und so nur über das Einbinden der GPS-Signale des Busses gewährleisten,
falls das überhaupt existiert.
Das Problem ist nicht die Verklebung, sondern das zunehmende Verlassen des abstrakten Mappens,
das verkomplizieren aller key und value, das ständige aufstellen neuer Regeln schreckt neue Mapper ab,
bzw. ist für den Mapperschwund verantwortlich.
Auf der einen Seite werden Firmen, die OSM nutzen wollen,
um ihren Fahrern die Einfahrten von Wohngrundstücken leichter zu finden (das wäre eine praktische Nutzung)
ständig verunglimpft, auf der anderen Seite sollen Regeln aufgestellt werden um etwas mappen zu können,
für das es selbst langfristig gesehen kaum Anwender geben wird.
Da beißt sich irgendwas, das ist wohl ein Wohlstandsproblem bei OSM in Deutschland.
Grüße von Lutz
Ist es aber auch, da die Wartung der Daten erschwert wird und viele übereinander liegende Linien gerade bei Anfängern die Gefahr vergrößern, Dinge durcheinander zu wirbeln. Und ja, Relationen werden dadurch, meist aus Versehen, beschädigt. Da kann es vorkommen, dass zwei Grenzen, zwei Landflächen und ein Feldweg nur als eine Linie dargestellt werden (daran ist kein Editor schuld). Wenn der Bearbeiter dann nicht darauf achtet, weil er es vielleicht nicht weiß, gehen gern mal Relationen zu Bruch und das verursacht wieder Mehrarbeit.
Dies liesse sich nach meiner Auffassung durch eine einfache Richtlinie verbessern. Man könnte diese z.B. in die Good Practices (https://wiki.openstreetmap.org/wiki/Good_practice) einbinden.
Dabei geht es nicht um Grasränder an Straßen oder ähnliches Micromapping, sondern um eine Vereinfachung für die von Dir erwähnten neuen Mapper und auch diejenigen, die sich tiefer in das Thema OSM gegraben haben und den Versuch gestartet haben, die Daten langfristig nutzbar zu halten. Kurz gesagt: es käme allen zugute.
Das sehe ich nicht. Ich finde eher, dass es ganz natürlich ist, dass neue Tags entstehen und diese auch verfeinert werden. Am Anfang von OSM hat man noch nicht die Notwendigkeit für gewisse Dinge gesehen und stellt später fest, dass etwas vielleicht doch besser anders angegangen werden sollte.
naja doch… solange alles so bleibt wie es ist ist es kein Problem klar, aber wenn z.B. eine Kreuzung zu einem großen Kreisel umgebaut wird mit ein- und Ausfahren usw. dann geht es los mit den Problemen… das alles auseinander zu würgen… da ist schon einfacher wenn die landuse extra ist. Wenn auch noch die Relationen weg sind wäre noch besser 
Seh ich auch so… oft genügen die Platformen… wenn mal beim Routing was schief geht braucht es nur eine Stop_position… manchmal einen Via-Punkt und man könnte sich die ganzen Wege in der Relation sparen. Role=via fehlt mir noch
Gruß Miche
Seh ich auch so … mit der zusätzlichen role=via ließen sich sogar (Sight-Seeing-)Busse beschreiben, die zwischen den Haltestellen nicht den kürzesten Weg nutzen.
Einziges Manko:überrede mal die Renderer eine Routing-Engine anzuwerfen um ÖPNV-Routen auf ihrer Karte zu hinterlegen, und Routing-Engines ein ÖPNV-Profil zu erlauben
… aber das ist ja schon wieder ein anderes Thema.
dann gibt es halt eine Pre-Prozess der mit den Relationen Routing macht und GPX-Dateien o.Ä. zum Rendern erzeugt.
https://mg.guelker.eu/blog/2020/gps-spur-openstreetmap.html
, aber zurück zum Thema
Die Regel mit dem Nichtverkleben von Weg- und Straßenlinien mit angrenzenden Flächen ist eine, die ich schon sehr lange hier aus dem Forum kenne. Es handelt sich also lediglich um eine Klarstellung, einer schon lange von der in meiner Wahrnehmung von der breiten Mehrheit der Mapper praktizierten und zudem auch logischen Vorgehensweise, damit endlich diese Streitereien aufhören.
Das hier nichts künstlich zum Problem gemacht ist, merke ich daran, dass mir dieses Thema hier im Forum schon seit Beginn meiner Mitwirkung immer wieder begegnet. Und ich merke es tagtäglich beim Mappen, wenn mir solche Verklebungen es deutlich erschweren, die Kartendaten zu verbessern.
Ich gehöre zu den Menschen, die OSM als Fußgänger und Trail-Runner nutzen und ich liebe es, dafür ein detailliertes und präzises Kartenbild vor Augen zu haben. Daher ist es mir nicht egal, wenn der Acker laut Kartenbild mitten auf dem Weg endet. Gerade weil ich nicht nur auf den breiten “Forstautobahnen” unterwegs sein will, sind Details interessant, die den Autofahrer weniger interessieren. Da ist von Interesse, ob die Wiese eingezäunt ist oder nicht. Da ist von Interesse, ob es neben der Straße einen breiten Graststreifen gibt oder ob der Acker 20cm neben dem Weg beginnt. Da hat OSM inzwischen in gut gepflegten Regionen eine Qualität erreicht, die Google-Maps nie erreichen wird. Es ist kein Zufall, dass es zwar tausend Navi-Apps auf Basis von Google-Maps gibt, aber praktisch alle brauchbaren Wander-Apps OSM nutzen.