Warum man Wege "fragmentieren" sollte..

Communities Deutschland (Germany)
1

Im Beitrag

http://forum.openstreetmap.org/viewtopic.php?pid=476125#p476125

wir bemängelt, das ein User so “böse” war und Wege in kleine Fragmente aufteilt.

Dies ist eine Methode, die meine Unterstützung findet, und die ich auch meinen Auszubildenden nahelege.
(Aus technischer Sicht, nicht aus den moralischen Beweggründen im Nachbarthread)

Wenn ich, auch beruflich, Kartographische Karten zeichne, dann fange ich an Kreuzungen immer neue Linienzüge an.

Aber warum?

Weil weiterverarbeitende Software dann mehr damit anfangen kann. Hat man ein Netz, in dem die Linienzüge immer nur
von Knoten zu Knoten gehen, kann man daraus relativ einfach Topologien erzeugen.

Hat man Linienzüge, die sich überschneiden, also z.B. wie ein P oder ein kleins Alpha ausschauen, dann führt das, vor allem
bei Flächenberechnungen zu Fehlern, bzw. je nach Software kann man aus den Daten gleich gar keine Flächen erzeugen.

D.h. man muß nacharbeiten, Linien auftrennen, umhängen etc. und hat somit die dreifache Arbeit, als wenn man es gleich
vernünftig gemacht hätte.

Mit Linienzug meine ich übrigens Polylinien, an deren Anfangs- und Endpunkten dann andere Polylinien anschließen (können)

Wenn sich die Eigenschaften auf der Linie ändern, macht es natürlich Sinn, diese noch detaillierter zu segmentieren.

Bei uns im Betrieb ist es zudem üblich, nach ca. 150m eine neue Linie zu beginnen, damit, wenn die Daten aus der DB in
Projektbezogenen Einzelzeichnungen ausgelesen werden, keine Monsterlinien erzeugt werden, die weit über das Ziel hinausschießen…

Also, aus technischer Sicht: trennt, bei höhengleichen Wegen, die Linienzüge an den Kreuzungspunkten auf.

S.

2

+1

3

Diese Anforderung kann man bei so ziemlich jeder Software für OSM, die mir spontan so einfällt, getrost vergessen.
Probleme machen nur Monsterwege oder -relationen mit zu vielen Knoten/Wegen(!). Die Länge spielt keine Rolle.

4

… nur das Länge und vielen Knoten oft - aber sicherlich nicht notwendig - mit einander “verknüpft” sind…

5

Um mal eine relativ weit verbreitete Software als Gegenbeispiel zu nennen…

Kann Mapnik ohne Vorverarbeitung erkennen, dass zwei aufeinanderfolgende Strassenstücke zusammengehören und gemeinsam beschriftet werden sollen? Ich kenne nur Mapserver halbwegs gut und ich wüsste nicht wie ich dem das beibringen sollte.

Das führt dazu, dass ein Strassenname nicht gerendert wird, falls die Beschriftung länger ist als so ein Stück Strasse zwischen den Kreuzungen. Oder es tritt der gegenteilige Fall ein: Eine Strasse wird zu häufig beschriftet, weil ich ihm zwar sagen kann, dass ich die Schrift nur alle 5cm haben möchte, der Renderer aber bei jedem Stück neu beginnt.

Das kann man sicher lösen, irgendwie… Nur tun müsste das einer :wink:

Grüße, Max

6

Das sind aber Anforderungen, die im “Großen Gis”, also ArcGis und Co. eine Rolle spielen und da im speziellen um bestimmte Anforderungen z.B. der Netzwerkanalyse ( z.B. ArcGis- Erweiterung Network Analyst).

Das erfordert aber das in einem Gebiet Flächendeckend z.B. lineare Objekte Vollständig erfasst sind. Mit OSM-Daten ist das aber nicht so einfach möglich zu machen… Der Interpretationsspielraum ist zu Groß, die Datendichte ist in den Gebieten viel zu unterschiedlich. Hinzu kommt, daß die Datenstruktur doch etwas einfacher ist, als das, was man vom “Großen Gis” her kennt, wenn man sich die OGC-Datentypen anschaut.

Dieses auf OSM umsetzen zu wollen halte ich für Falsch.

Wegfragmentierungen ergeben sich automatisch, wenn unterschiedliche Routen, Wanderwerge, Radwanderwege, Geschwindigkeiten, Straßenbelagsarten ect. erfasst werden. Das und Nur das sollte meiner Ansicht nach Kriterien für eine Wegtrennung sein.

Eine Pauschale Wegtrennung an jeder Wegkreuzung lehne ich grundsätzlich ab und sehe keine Notwendigkeit.

Sven

7

-1

Es ist technisch leicht umsetzbar, längere Wege an Verzweigungspunkten aufzutrennen, wenn man eine feingranulare Topologie braucht. (Habe da einschlägige Erfahrung aus der Aufbereitung von OSM-Daten in der Navilösung Graphhopper, wo genau sowas gemacht wird um die Topologie für die Navi-DB zu erzeugen).

Es ist aber nicht machbar, ohne Grund aufgetrennte aber eigentlich logisch zusammengehörende Wegstücke wieder zusammenzufügen. Damit geht eine Information verloren “dies ist die durchgehende Straße”. Die üblichen Kartenrenderer versuchen dann, jedes Wegstück einzeln zu beschriften, was zu einer sinnlosen Flut von wiederholten Texten oder zum kompletten Verschwinden langer Namen aus scheinbarem Platzmangel führen kann. Dieses Problem kann zwar auch beim Auftrennen von Wegen für route relations auftreten, sollte aber möglichst gering gehalten und nicht noch grundlos verstärkt werden.

bye, Nop

8

Das handhaben wir normalerweise nicht so. Wo es möglich ist, versuchen wir, ein Objekt in der Realität durch ein Objekt in OSM abzubilden und nicht durch 10.

Dieser Satz ist für mich unverständlich. OSM-Daten liegen bereits als Topologie vor, man muss nicht erst noch eine daraus erzeugen. Nur dann, wenn man die Topologie aus OSM entfernt, indem man z.B. OSM-Daten in ein Shapefile wandelt, muss man für eine topologische Weiterverarbeitung wieder neu eine Topologie erzeugen. Das kann ja hier aber nicht gemeint sein?

Auch das verstehe ich nicht. Weiter oben sprichst Du von (wie ich doch annahm) Straßen-Kreuzungen. Niemand jedoch will aus Straßen Flächen berechnen. Flächengeometrien hingegen würden auch in OSM niemals die Form eines p oder eines α zeichnen.

Verstehe ich nicht.

Kann ich nicht unterschreiben - macht für mich technisch keinen Sinn. Eine solche Aufteilung an Kreuzungspunkten kann bei Bedarf von der weiterverarbeitenden Software vorgenommen werden (osm2pgrouting zum Beispiel macht das, oder FME auf der Kaufsoftware-Seite).

Bye
Frederik

9

Der “Maplex label engine” in ArcGIS kann das (Placement Properties/Label Density/Connect features)

10

gelöscht…

Ab 10.1 sollte Maplex inclusive sein…

11

Es ist wesentlich einfacher, Wege aufzuteilen, als sie zusammenzufügen (automatisiert).

12

Doch, unter anderem. Ich betrachte nicht nur die OSM-Welt, sondern auch die normale "Vermessungs"welt

Ich komme wohl eher aus der CAD-Ecke, da geht sowas nicht so einfach. Und FME kaufen und benutzen(lernen), nur um einfach vermeidbare Zeichenfehler auszubügeln ist für
den normalen Büroalltag eps übers Ziel hinausgeschossen.

S.

13

Sorry Jungs, mein Fehler, ich habe eher an die “große/allgemeine” GIS/CAD-Welt und nicht nur an OSM gedacht, als ich meinen Beitrag schrub.

Warum? Wehret den Anfängen. So mag es hier vielleicht manchen Rookie geben, der fleißig OSMt, sich, weil es Spaß macht,
den passenden Beruf dazu sucht und dann die Welt nicht mehr versteht weil “normale” Dinge plötzlich nicht mehr funktionieren.

z.B. AutoCAD. Das meckert nur, wenn sich Linien kreuzen und bricht ab. Also nochmal auftrennen, verbinden etc. nochmal Topologie bilden… (dreifache Arbeit…)

Zum Punkt Flächenbildung aus Straßen: Warum nicht, dann erhält man relativ schnell und Einfach z.B. die Flächen der Baublöcke…

Das bemängelte Labeling wegen zu vieler Segmente betrachte ich als Taggen für den Renderer…

Gute Nacht,

S.

14

Ein gerne verwendetes Argument, aber es ging um eine doch recht weit verbreitete Anwendung :wink:

Wege an jeder Kreuzung spalten kann ich mit vielen Programmen erledigen. Darunter auch kostenlose, open source und wenn mir keines davon gefällt, gibt es gut dokumentierten Algorithmen zum selber nachbauen, schliesslich muss jeder Router das machen.

Programme, die Wege vereinen (Arcgis habe ich erfahren, kann das), z.B.(!) weil ich sie für z.B.(!) einen Renderer vereint brauche, sind eher selten. Sollte sich das ändern, kann man auch über anderes Taggen nachdenken, aber zur Zeit sehe ich da wenig Angebote.

Grüße, Max

15

Kann mir nicht vorstellen, dass es dafür keine Lösung gibt. Wenn ich mit “autocad line break intersection” such, finde ich haufenweise Lisp-Scripte. Kenn mich natürlich gar nicht aus damit, aber vielleicht fragst du einfach mal in einem anderen Forum oder den Hersteller. Oder schnapp dir einen Lehrling/Student/, der dir die OSM-Daten vorher aufbereiten.
AutoCad-Probleme als Argument zu verwenden, warum man jetzt in OSM irgendwelche Wege splitten will, halte ich ehrlich gesagt für ziemlichen Unfug.

16

@Slartir
Aufteilen von Wegen (hier als Fragmentieren genannt) ist an sich in OSM nicht ungewöhnlich. Unterschiedliche Wegeeigenschaften oder Routen sind notwendige Gründe einen Weg aufzuteilen.
Aber ohne Grund Wege aufzuteilen halte ich für falsch, da es für Mappern, Renderer, usw. die Arbeit unnötig erschwert.
Wir mappen eigentlich für OSM und nicht für die GIS/CAD/AutoCAD-Welt
Grüße Andreas

17

Meine Meinung…

Also ich messe, um eine möglichst reales Abbild der Erde zu bekommen. Das mappen kommt momentan leider zu kurz.

Nach wie vor bin ich aber der Meinung, dass es zukünftige Arbeit erleichtert, wenn man von Beginn an die Linien aufgetrennt
erfasst.

In meinen Augen ist es dann einfacher, den einzelnen Abschnitten die jeweiligen Eigenschaften zuzuweisen, sie in neue Relationen
aufzunehmen etc.

Gerade für Relationen, soweit ich damit zurechtkomme, halte ich das für einfacher, weniger arbeitsintensiv.
Ein kleines Einzelstück einer neuen hinzuzufügen kommt mir leichter vor, als eine lange erst aufzutrennen, die alte umzuarbeiten und dann noch die neue
zu ergänzen. (Wenn z.B. ein neuer Wanderweg teile eines vorhandenen nutzt.)

Aber nachdem ich eine Nacht darüber geschlafen habe, bin zu dem Schluß gekommen, dass ich wohl schon zu lange Vermesser,
und mit wohl langsam beginnenden Altersstarrsinn manch “neumodische” Methoden nicht gutheißen will…

Andererseits ist es wohl meiner Beruflichen Tätigkeit geschuldet, dass ich die Linien auftrenne. Wir betreiben im Büro sozusagen “Micromapping”
d.h. wir erfassen alle Details vor Ort. Straßen werden nicht als einzelner Linienzug gemessen, sondern setzten sich aus vielen kleinen
Einzelelementen zusammen. Zum einen schon mal die Fahrbahnränder. Die sind wiederum aufgeteilt in Hochbord, Mittelbord, Niederbord,
dann kommen Grünflächen dazwischen, Belagswechsel werden erfasst etc. Wenn man gewohnt ist, so zu messen und zu zeichnen, kommt einem
die Arbeitsweise “ich zeichne mal ein P weil die Straße ja so verläuft” eps befremdlich vor.

S. der sich jetzt nicht hinsetzt und vorhandene OSM-Linien aufsplittet, sie aber, so er neue zeichnen wird es so machen wird…

18

Manche Dinge werden erleichtert (z.B. Routenbildung), andere erschwert (z.B. Änderung von Straßenattributen).

19

Kommt auf die Software und deren Einsatzgebiet an. Ich kann mit fragmentierten Wegen weniger anfangen, die Weiterverarbeitung wird für mich und meine eingesetzte Software aufwändiger.

So lange sich die Wegbeschaffenheit nicht ändert und ein Weg in der Realität auch zusammengehörend bzw. weiter verlaufend erscheint, teile ich an Kreuzungen eben diesen nicht auf - sondern zeichne den Weg durchgehend ein (und nur ein abzweigender Weg ist separat). Das bildet die Realität IMO auch besser ab…

An Knotenpunkte aufteilen ist zudem auch nix, was eine Software die das wünscht nicht auch selbst als Zwischenschritt einlegen könnte. Das ist automatisiert machbar. Dagegen ein Erkennen welche aufgeteilten Wegstücke da draußen eigentlich einen einzigen Weg abbilden ist nicht immer automatisiert machbar.

20

Die Automatisierung der Trennung bekommt an der Stelle Schwierigkeiten, an der das Segment Attribute hat, die sich auf das gesamte Segment beziehen und nicht linear verlaufen (Durchschnittswerte). Ich kann mich aber nicht daran erinnern, dass wir so etwas mappen, daher sollte das keine Probleme machen.