Maßnahmen gegen Fragmentierung von Straßen?

Communities Deutschland (Germany)
1

Heyho,

gestern bin ich nach Längerem mal wieder ein paar Stunden draußen Craftmappen gewesen. Dabei habe ich z.B. via StreetComplete mehrere Straßen aufgespalten, um surface=* akkurat setzen zu können.
Je präziser das getan wird, und je mehr solcher Attribute zusammen kommen, desto mehr werden vor allem lange Straßen fragmentiert.
Letztendlich führt das dazu, das einige der Infos zu dieser Straße (v.a. der Name) in OSM redundant vorhanden sind, und gleichzeitig aber eine Beziehung zwischen den einzelnen Fragmenten (die über Konnektivität und Namensgleichheit hinaus geht) nicht repräsentiert wird.

Da mir das bereits öfter störend aufgefallen ist, zum Beispiel bei der Suche eines Straßennamens in OsmAnd oder openstreetmap.org (Bsp. https://www.openstreetmap.org/search?query=lerchenauer%20stra%C3%9Fe%20m%C3%BCnchen#map=19/48.17651/11.55794)), würde mich interessieren, ob es eine (halbwegs etablierte) Möglichkeit gibt, dieser Fragmentierung (z.b. über Relations) entgegenzuwirken?

Beste Grüße und ein schönes Wochenende,
dial25osm

2

Führt übrigens auch dazu, dass auf vielen Karten der Name der Straße gar nicht mehr angezeigt wird, weil keins der Fragmente lang genug ist, um ihn reinzuschreiben.

3

Stimmt, das ist mir noch gar nicht aufgefallen.
In meinem verlinkten Beispiel bekomme ich für eine Straße >30 Segmente. So lässt sich der Verlauf einer Straße nur schwer nachvollziehen.
Klar, da gibt’s ausgefeiltere Query-Möglichkeiten etc., aber das Grundproblem bleibt ja bestehen.

4

Wir hatten dazu mal was in https://github.com/openstreetmap/openstreetmap-website/issues/866 diskutiert, aber das ist ziemlich im Sande verlaufen.

5

Gab es da nicht auch mal einen Vorschlag in einer zukünftigen API-Version bei Attributen an einem Weg von-bis Nodenummern angeben zu können für die dieses Atribut gilt statt für den gesamten Weg?

6

Ja, Vorschläge in die Richtung gab es auch schon mal: https://wiki.openstreetmap.org/wiki/API_v0.7#Segments_.28instead_of_fragmented_ways.29

7

Am besten fragt ihr da mal bei den Freunden in der EWG nach: https://wiki.osmfoundation.org/wiki/Working_Group_Minutes/EWG_2022-01-24#OSM_data_model_changes

8

gerade weil das so ist dass Straßen immer mehr fragmentiert werden, sollte man das beim Rendern von Straßennamen soweit es geht berücksichtigen. Vielleicht sollte osm2pgsql zusätzlich (z.B. im roads layer) die linearen Objekte mit gleicher Klasse und Namen als zusammengesetzte Kopie speichern, oder gibt es das schon?

9

Mit nur etwas Aufwand erkennt ein Renderer Linien die aneinandergrenzen und den gleichen Namen haben und fügt diese zusammen vor dem Setzen der Labels. Zumindest dafür brauchen wir aus meiner Sicht in den OSM Daten nichts ändern.

10

Es gab mal die Bestrebung, alles, was zu einer Straße gehört, in einer Relation zusammenzufassen, name=(Straßenname), type=street - das war vor allem dafür gedacht, um seperat eingezeichnete Bürgersteige als zu der Straße nebenan zugehörig zu kennzeichnen, ohne sie mit einem eigenem name= zu versehen. Das hat sich allerdings nicht durchgesetzt.

11

Kurze Antwort: Das willst du nicht.

Denn was dann ja passieren würde ist das du 50 Straßenschnipsel und 50 Relationen hast die je nach Attribut vereinheitlichung die Straßenschnipsel zusammenfasst. D.h. alle surface=asphalt sind in Relation A, Alle mit surface=paving_stones sind in B, alle mit lit=yes sind in C alle mit lit=no sind in D, alle mit sidwalk=left sind in E,
alle mit sidewalk=right sind in F, alle mit sidewalk=both sind in G.

Das ist ein höllen Chaos was da dann kommt.

Und in anbetracht dessen das schon im vergleich simple multipolygon relations für den average mapper kaum handhabbar sind rate ich davon ab.

Dagegen ist das splitten und attribute ändern eine kleinigkeit und für jeden zu verstehen.

Flo

12

Ja, klar, das kann man machen. Ich sag ja nur, wer in der Henriette-Obermüller-Straße wohnt und sich wundert, warum der Name auf openstreetmap.org nicht mehr angezeigt wird nachdem er sie in 50 Schnipsel aufgeteilt hat, der muss dann halt einen Patch für den openstreetmap-carto-Style schicken.

13

Vielleicht machen sie für Namen eine Ausnahme, aber OpenStreetMap carto wollen möglichst wenig postprocessing an den Daten machen, einerseits um Fehler in den Daten nicht zu verstecken und das Rendering nachvollziehbar zu haben, andererseits auch um die Ressourcen effizient einzusetzen.

14

Hallo,

Wenn ich Karten drucken möchte, die etwas besser als “durchschnittlich” sind, passe ich den Kartenstil (Rendering-Engine Mapnik mit PostgreSQL als Datenquelle) so an, dass Straßen mit gleichen Attributen wieder zusammengefügt werden. Denn selbst wenn es beim Mappen einen Anlass gab, die Straße zu teilen, z.B. abweichende turn:lanes=*, heißt das noch lange nicht, dass das Attribut für meinen Kartenstil relevant ist. Wenn der Stil nur highway, ref und name auswertet (bzw. auf dem Linienlayer sogar nur highway, auf dem Beschriftungslayer nur ref und name), kann ich die Stücke wieder vereinigen.

Beispiel (vereinfacht):

Vorher:


SELECT way, highway
  FROM planet_osm_line
  WHERE highway IN ('trunk', 'primary', 'secondary', 'tertiary', 'unclassified', 'residential', 'living_street', 'pedestrian');

Nachher:


SELECT ST_Union(way), highway
  FROM planet_osm_line
  WHERE highway IN ('trunk', 'primary', 'secondary', 'tertiary', 'unclassified', 'residential', 'living_street', 'pedestrian')
  GROUP BY highway

In den meisten Kartenstilen sind die SQL-Abfragen länger, weil mehr Attribute von der Datenbank abgefragt werden und somit wird auch das GROUP BY komplizierter. Aber das Prinzip ist dasselbe.

Wer mit Tilemaker Vektortiles erzeugt, kann optional Linien vereinigen, wenn sie dieselben Attribute im Vektortile haben (das Vektortile enthält nur ausgewählte Attribute).

Das Problem ist auf Seite der Datenkonsumenten zu lösen. Konzepte mit Relationen in OSM werden erfolglos sein.

Viele Grüße

Michael

15

Hallo zusammen,

eine wichtige Maßnahme gegen Fragmentierung ist in meinen Augen auch, wenn highway-Abschnitte nicht mehr Teil von outer- und inner-Segmenten von MP-Flächenrelation sind… Da gibt es landstrichweise viel zu tun. Hier die Abfrage für Sachsen: https://overpass-turbo.eu/s/1fMJ Brandenburg liefer das keine Egebnisse mehr. Die wenigen highweay-Segmente als inner-Rollen haben keine lange Halbwertzeit mehr.

Sven

16

Was auch zur Fragmentierung beiträgt, ist das notwendige Aufteilen der Straße, speziell in Wohngebieten, je nach sidewalk = left /right /both in einzelne Abschnitte. Aber was soll man machen?

Die schlechte Alternative wäre, parallele Straßen-begleitende Fußwege OHNE bauliche Trennung zur Straße, alle separat einzuzeichnen.

Dies war ursprünglich so und habe ich gerade massenhaft behoben im Städtchen Premnitz im Westhavelland.
Zusätzlich verliefen diese Fußwege dort dann auch noch oft ohne Straßenquerung “immer nur um den Block herum” …

17

Dass nachgerade die Sidewalks an der Fragmentierung die Schuld tragen, das les ich hier oft. Als ambitionierter Sidewalk Mapper kann ich sagen, dass ich selten splitten muss deretwegen. Es ist nämlich alles schon so zersplittet, dass ich eher Mühe habe, die Segmente alle zu erwischen. ZB sind mir schon 30cm lange Highway Primary Stücke untergekommen. Es gibt da so viele Gründe und es geht gar so einfach.

Zur Darstellung der Namen: Waymarked Trails kreiert für Pisten eine Art Pseudorelation. Weil Lonvia ja sonst nur Relationen auswertet, aber Pisten kaum als solche erfasst sind, sondern als Wege. Das funktioniert halbwegs, als Startpunkt fürs Labeln vielleicht brauchbar, sollte jemand sich hervortun wollen.

18

Sobald wir alle Straßen- und Wegeflächen als Area kartiert haben, erübrigt sich die Erfassung der Bodenbeläge auf linearen Ways (da das ja dann mathematisch aus den Schnitten von Areas und Ways berechnet werden kann, wieviel % meines Weges über Asphalt/Gras/etc. laufen) :smiley:

19

Diese Abfrage liefert ein interessantes Nebenprodukt, die mir jetzt das erste Mal aufgefallen ist, dafür aber gleich zweimal an ganz verschiedenen Stellen:
Ausgangspunkt (bzw. Fläche) waren offensichtlich platzartige Flächen (aber keine Plätze im eigentlichen Sinn) die mit highway=service aber als Fläche getaggt waren. Um Rasenflächen oder sogar Tankstellendächer mittendrin sichtbar zu machen, wurden diese “ausgestanzt”, also ein MP mit einem outer und ein oder mehreren inner draus gemacht. Soweit so gut.
Dabei waren aber sowohl die Relation wie auch das outer jeweils mit highway=service gemappt, also quasi doppelt. Aufgefallen war es mit im Rendering (osm-carto), weil:

  • das outer wird schön als way highway=service gerendert
  • die Fläche wird dadurch größer gerendert (durch die Breite der Straße)
  • damit werden die outlines angrenzender Gebäude überdeckt

In einem Fall enthielt das Multipolygon sogar noch zusätzlich das Tagging area=yes (seit wann muss man denn zusätzlich mappen, dass Polygon eine Fläche ist?)
Ob es nun ein technischer Fehler eines Editors oder ein Fehler des Bearbeiters war vermag ich nicht zu beurteilen. An iD lag es jedenfalls nicht, in zwei näher betrachteten Fällen handelt es sich um erfahrene, teils bekannte Mapper, die JOSM benutzt haben.

Ich habe mal das überflüssige area=yes am Multipolygon sowie die überflüssigen highway=service am outer entfernt. Wobei mir das mit dem Loch für das Tankstellendach noch immer nicht gefällt, bin mir aber noch nicht schlüssig, wie ich das lösen soll.

20

Ich bin dafür, statt die Segmentierung zu bekämpfen den Umgang der Editoren damit zu verbessern. Zum Beispiel so:

  • Mit einem Dreifach-Klick alle angrenzenden Linien markieren bis dort, wo Linien abzweigen.

Oder:

  • Durch Drücken eines Shortcuts immer die jeweils nächste Kante mit zur Auswahl hinzunehmen, je nach Shortcut in aufsteigender Richtung der zuerst ausgewählten Kante oder in absteigender oder in beiden Richtungen, bis man an einem Abzweig angelangt ist.

Oder:

  • Mit einem Shortcut und Klick auf die erste Kante, dann Klick auf eine entferntere Kante eine Route zwischen den Kanten markieren. Dafür reichen an Abzweigungen ganz einfache Routingregeln (z. B. weiter geroutet wird über die Kante, wo die meisten Eigenschaften übereinstimmen).