[Talk-de] Abstraktionsgrad, Erfassen von Spuren etc.

Mario Salvini salvini at t-online.de
Mi Jan 21 17:02:57 UTC 2009


sehr schön geschrieben. deshalb sollten für Lanes via Relation+Tags 
erfassen.

Hatto von Hatzfeld schrieb:
> Hallo, Leute!
>
> Hier etwas, was ich schon länger loswerden wollte, aus aktuellem Anlass und
> wegen des regnerischen Sonntags aber nun endlich schreibe:
>
> Nach einiger Beobachtung sehe ich jetzt in einigen Aspekten dessen, was und
> wie inzwischen von engagierten Mappern erfasst, OpenStreetMap in einer
> gewissen Krise - wobei ich unter Krise, gemäß dem Ursprung dieses Wortes,
> eine sich verschärfende problematische Situation verstehe, die zu einer
> Entscheidung drängt:
>
> Da gibt es einerseits - auch in Deutschland - noch viele Gebiete, in denen
> höchstens die Überlandstraßen erfasst, innerörtliche Straßen aber kaum zu
> finden sind [1]. Andererseits ist an bestimmten anderen Stellen, vor allem
> in Städten, schon so viel gemappt, dass Mapper sich schon daran gemacht
> haben, dort jedes einzelne Haus, jede Kneipen und jeden Recycling-Container
> zu erfassen [2] ... oder jedes Gehege im Zoo [3], jeden Fußweg auf einem
> Friedhof [4] oder jedes Becken einer Kläranlage [5]. Es ist auch nichts
> dagegen zu sagen, wenn Mapper sich auf diese Weise (oder auch z.B. durch
> das Erfassen von Hausnummern) um größere Detailtreue in ihrer Umgebung
> bemühen, falls es ihnen nicht möglich oder zu aufwändig ist, sich in noch
> wesentlich weniger erfassten Gegenden zu betätigen.
>
> Problematisch wird das Ganze, wenn die Abstraktionsebene des Projektes
> verlassen wird. Das geschieht z.B., wenn einige bereits damit beginnen,
> einzelne Spuren einer mehrspurigen Straße getrennt zu erfassen (obwohl
> diese Teil einer Fahrbahn sind und man real zwischen den Spuren durchaus
> wechseln kann). Ein Beispiel, auf das ich heute gestoßen bin, ist die A 559
> bei Köln [6]. Das Ergebnis des Renderns ist durchaus unbefriedigend, und
> man kann das hier auch nicht dem Renderer zuschreiben.
>
> Bei OpenStreetMap gibt es, wie man aus der Entstehung und auch aus der noch
> (!) überwiegenden Praxis erschließen kann, folgende Abstraktion: Jeder Weg
> (ob Straße, Rad-, Fußweg etc.) wird in der Datenbank grundsätzlich als
> Polygonzug [7] erfasst, unabhängig von der physikalischen Breite des Weges
> oder der Anzahl seiner Fahrspuren, also nicht als Fläche. Das ist auch eine
> gute Wahl, wenn man sie von der Nutzung der Daten her betrachtet: Es geht
> bei den Wegen um die Verbindung zwischen Orten.
>
> Für das Visualisieren (Rendern) ist z.B. das (bei unseren Datenquellen zudem
> immer recht ungenaue) Mappen einzelner Spuren eher kontraproduktiv, wie das
> obige Beispiel [6] zeigt - die zusätzlichen geokodierten Nodes haben eine
> Pseudogenauigkeit, deren wahre Ungenauigkeit visuell nun deutlich
> hervortritt. Und selbst wenn der Renderer nun noch die Information bekäme,
> dass es sich um eine gemeinsame Fahrbahn (und Brücke) handelt und der
> Wechsel zwischen den Spuren erlaubt ist, dann ist gegenüber einem einfachen
> Polygonzug (way), der mittels zusätzliche Tags mit der Information über die
> Zahl der Spuren versehen ist, keinerlei Informationsgewinn zu verzeichnen;
> es ist nur die Sache für die Renderer und die Routingsoftware erschwert.
>
> Nun mag mancher erwidern: Wir mappen doch nicht für die Renderer und Router.
> Da ist etwas Wahres dran; es wird aber zu oft als Totschlagargument
> gebraucht. Es trifft vor allem zu, wenn jemand versucht, Bugs oder auch
> Unzulänglichkeiten der Renderer beim Mappen auszugleichen - da ist es
> besser, "richtig" zu mappen und die Darstellung dann der jeweiligen
> Software zu überlassen. "Richtig mappen" heißt aber nicht, jeden Bordstein
> und jede Linie zwischen zwei Fahrspuren derselben Fahrbahn in ihrer Lage zu
> erfassen, sondern den Zweck von OpenStreetMap zu beachten. Der liegt nun
> mal in einer Karte, zu deren Abstraktionsgrad nun einmal gehört, einen Weg
> (Straße) als Verbindung (Polygonzug) zu erfassen und diese Information (wo
> ist A und B und wie komme ich von A nach B) möglichst gut darzustellen (sei
> es als Karte oder per Routingsoftware oder wie auch immer). Und wenn z.B.
> die Breite oder Zahl der Spuren (einschließlich ihrer Abbiegemöglichkeiten)
> einer Straße in diesem Rahmen eine sinnvolle Information sind, dann sollte
> man sie als Eigenschaften (Tags) der entsprechenden Straße zuschreiben. Das
> ist dann der richtige Abstraktionsgrad - im Gegensatz zur Pseudogenauigkeit
> von in die Gegend gesetzten Nodes mehrerer Spuren.
>
> Um schließlich noch ein Beispiel zu ergänzen: Für kontraproduktiv halte ich
> es auch, wenn jeder zu einer Straße parallele Radweg als eigener Polygonzug
> (Way) gemappt wird und man dann eventuell jeden abgesenkten Bordstein, über
> den man vom Radweg auf die Fahrbahn wechseln könnte, erfassen will. Da
> sollte man sich immer fragen, wer denn diese Information nutzen kann: Kein
> Radfahrer wird doch je auf einer Karte nachschauen, wann denn ein solcher
> Bordstein kommt. Und für die Routenplaner genügt es, wenn an den Kreuzungen
> erfasst ist, wie man in welche Richtung weiterfahren kann. Überhaupt genügt
> es (und mehr wäre eine Überforderung!), wenn eine Karte oder eine
> Navigationssoftware mir einen recht guten Weg (im Sinn der Folge von
> Straßen, die ich fahren oder begehen muss) angibt - wo ich als Radfahrer
> dann genau fahre (auf einem nicht vorgeschriebenen Radweg oder auf der
> Fahrbahn bzw. als Fußgänger auf der linken oder der rechten Straßenseite),
> das entscheide ich auch in Zukunft immer noch besser vor Ort.
>
> Die Frage, wer denn die Information nutzen kann und wird, hängt übrigens eng
> mit der zusammen, wer sie später pflegen wird. Daten, die niemandem helfen,
> werden auch kaum von jemandem gepflegt; sie können, wenn sie einmal
> überholt sind, nur noch verwirren. Bei manchen Ideen, was man alles wie
> mappen könnte, sollte etwas mehr Realismus über eine nachhaltige Erfassung
> und Pflege der Daten einkehren.
>
> So, das war's fürs Erste :-)
>
> Gruß,
> Hatto
>
>
> [1] Beispiel: http://www.openstreetmap.org/?lat=50.3247&lon=6.8348&zoom=13
> [2] Beispiel: http://www.openstreetmap.org/?lat=50.1495&lon=8.68262&zoom=17
> [3] Beispiel: http://www.openstreetmap.org/?lat=50.96131&lon=6.97687&zoom=17
> [4] Beispiel: http://www.openstreetmap.org/?lat=50.13756&lon=8.68999&zoom=1
> [5] Beispiel: http://www.openstreetmap.org/?lat=50.99105&lon=6.97966&zoom=16
> [6] http://www.openstreetmap.org/?lat=50.91985&lon=7.02348&zoom=17
> [7] http://de.wikipedia.org/wiki/Polygonzug
>
>
> _______________________________________________
> Talk-de mailing list
> Talk-de at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>   





Mehr Informationen über die Mailingliste Talk-de