Androhung von Benutzersperren für Verklebe-Ideologie

miche101 · 2021-01-21T12:45:08.000Z

dx125:

mit linienförmig gezeichneten Wegen.
Alle ways wie z.B. highways, railways, waterways sind betroffen, soweit sie linienförmig gezeichnet sind."

Erst als Wegen bezeichnet und dann als ways… könnte man noch verbessern

Objekte die als Achse erfasst werden wie z.B. highways, railways, waterways, usw. , soweit sie linienförmig gezeichnet sind.

dx125 · 2021-01-21T13:05:01.000Z

@=miche101
“mit linienförmig gezeichneten Wegen (ways).
Alle ways wie z.B. highways, railways, waterways sind betroffen, soweit sie linienförmig gezeichnet sind.”

Wir setzen da noch" ways" in Klammern hinzu.
Für mich ist das dann eindeutig.
Nicht unnötig ver-komplizieren.

miche101 · 2021-01-21T13:05:50.000Z

ToniE:

Aber das ist ein anderes Thema und muss hier nicht weiter vertieft werden.

ja anderes Thema, aber gleiches Problem. Nur das man Relationen an Wege klebt und nicht landuse

Negreheb · 2021-01-21T13:44:58.000Z

dx125:

"Die deutsche OSM-Community spricht sich für folgende Empfehlung aus:

Die Grenzen von Landnutzungs- und Naturflächen können sich mit jeweils angrenzenden Landnutzungs- und Naturflächen an der gemeinsamen Grenzlinie die Nodes teilen.

Die Grenzen von Landnutzungs- und Naturflächen sollen sich KEINE Nodes teilen mit linienförmig gezeichneten Wegen (ways).
Alle ways wie z.B. highways, railways, waterways sind betroffen, soweit sie linienförmig gezeichnet sind."

Voll dafür. Hab das “(ways)” direkt mal dazugepackt

Liebe Grüße

westnordost · 2021-01-21T15:12:11.000Z

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.

dx125 · 2021-01-21T15:36:34.000Z

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

GerdP · 2021-01-21T17:06:51.000Z

westnordost:

Generell sollte gelten, dass nicht direkt miteinander zusammenhängende Daten keine gemeinsamen Nodes haben sollen.

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.

miche101 · 2021-01-21T17:23:15.000Z

westnordost:

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!

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

Galbinus · 2021-01-21T17:27:51.000Z

“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.

Bernhard_Hiller · 2021-01-21T17:30:06.000Z

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.

soilinvestigator83 · 2021-01-21T17:56:35.000Z

dx125:

Galbinus:

Jetzt können wir uns wieder dem andren Thema, den Verklebungen, zuwenden und es wäre aus meiner Sicht wünschenswert, wenn es dazu in absehbarer Zeit eine verbindliche Regelung gäbe.

+1

Linienförmig gezeichnete Ways sind IMMER flächig “on the ground” und NIEMALS reicht die an den Way angrenzende Fläche bis zur Mittellinie der Way-Fläche. Wir zeichnen nur die Mittellinie der Way-Fläche, den Rest besorgt der Renderer, ggfs. unter Zuhilfenahme einer Way-Breitenangabe bei Way-tags.
Der Grund, weshalb wir es so oder so ähnlich beschließen sollten:

Sachliche Richtigkeit/ Fakten

Wartbarkeit der Karte und der Daten

So, nun könnt Ihr das Ganze wieder jahrelang zerrrrr-reden…

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.

Galbinus · 2021-01-21T18:23:51.000Z

soilinvestigator83:

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.

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.

dx125 · 2021-01-21T18:48:16.000Z

soilinvestigator83:

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.

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.

GerdP · 2021-01-21T19:18:03.000Z

dx125:

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…

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.

soilinvestigator83 · 2021-01-21T19:56:49.000Z

dx125:

Lasst uns das doch erst einmal eingrenzen auf solche ways […]

Beim Wassergraben wächst…

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?

smootheFiets · 2021-01-21T22:29:26.000Z

soilinvestigator83:

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…

lutz · 2021-01-22T08:56:28.000Z

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

highflyer74 · 2021-01-22T09:29:51.000Z

lutz:

Das Problem ist nicht die Verklebung

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.

lutz:

das verkomplizieren aller key und value, das ständige aufstellen neuer Regeln

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.

miche101 · 2021-01-22T09:48:48.000Z

lutz:

hier wird künstlich etwas zum Problem gemacht, wo gar keines besteht.

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

lutz:

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.

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

ToniE · 2021-01-22T10:18:58.000Z

miche101:

lutz:

hier wird künstlich etwas zum Problem gemacht, wo gar keines besteht.

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

lutz:

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.

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.