[Talk-de] Routerh?rtetest - Topologie oder STVO?

Mi Jun 24 08:54:38 UTC 2009

Am Mittwoch, 24. Juni 2009 08:58:35 schrieb talk-de-request at openstreetmap.org:
> Moin,
>
> > Genau so sehe ich das auch. Auch ich verfolge den Thread aufmerksam weil
> > mich das Radrouting derzeit am Meisten besch?ftigt. Und das Heiko, ohne
> > den Mapper der den Radweg angelegt hat zu kontaktieren, einfach dessen
> > Arbeit l?scht finde ich auch nicht ok.
>
> ich m?chte anmerken, dass mir die Br?cke nicht geh?rt. Ich wende mich nicht
> dagegen, dass Heiko dort editiert und ?nderungen vorgenommen hat. Ich
> m?chte vorsichtshalber auch darauf hinweisen, dass Heiko in Karlsruhe schon
> eine Menge Verbesserungen zusammengetragen hat. Die Rheinbr?cke ist ein
> Spezialfall, da ist Streit vorprogrammiert.
>
> Aber ich sehe es so wie Sven, Martin und Du: Speziell an der Rheinbr?cke
> bin ich der Meinung, dass es bei getrennten Wegen bleiben sollte. Und das
> sollte Heiko respektieren. Wenn die Diskussion hier nicht dazu f?hrt, dass
> in Potlatch fleissig die Taste ?u? gedr?ckt wird, war sie, ?h, vergebens :)
> .
>
>
> Unabh?ngig von obigem Streitfalle m?chte ich gern ein paar Dinge loswerden.
> Openstreetmap ist IMO prim?r eine gewaltige Geodatenbank.
>
> Heiko m?chte, soweit ich ihn verstehe, gerne die Radwegesituation in
> unseren Daten verbessern. Das ist mehr als w?nschenswert. Dass er dabei
> nicht davor zur?ckschreckt, auch an kniffeligen Stellen die Finger in die
> Daten zu stecken, ebenfalls. Denn eine "Huch, nein, ich k?nnte ja was
> kaputt machen"-Mentalit?t f?hrte sicher nicht dazu, dass das Projekt
> weiterkommt.
>
> Vor diesem Hintergrund stellt sich die Frage, was wir prim?r abbilden
> wollen: Die Topologie ("Hier ist ein extra Radweg") oder die STVO ("Hier
> ist ein stra?enbegleitender Radweg"). Da ich das Projekt viel mehr als
> Geodatenbank und weniger als nur ein (Sta?en)kartenprojekt auffasse, komme
> ich zu dem Schlu?, dass prim?r die Topologie und sekund?r die STVO
> abgebildet werden sollte.
Wahrscheinlich wollen OSM viele gerade als Straßenkartenprojekt sehen.
Vermutlich war das gerade zu Beginn von OSM so und daraus resultiert dann auch 
der Name: Openstreetmap.
Und die Motivation in das Projekt einzusteigen ist vielfach die Karte zu 
ergänzen, weil sie auf der gerenderten Karte  fehlt oder aber in der 
Navikarte, mit der man seine ersten Erfahrungen gemacht hat.
Später erfährt man im Umgang und in der Praxis, das OSM für mehr gedacht ist 
als nur für die üblichen Karten und Navigationsaufgaben.
Das ist vielleicht ein prinzipeilles Problem, das diese beiden Ansätze schwer 
bis unmöglich zu vereinen sind.
Vielleicht sollte man sie trennen.
>
> Unsere Daten verfeinern sich immer mehr. Manche beschreiben das mit
> "Zum?llen der Datenbank". 
Da muß man wohl ins Detail gehen.
Ich habe diesen Ausdruck schon benutzt und will auch erklären was ich damit 
meine:
Das Anlegen von Wege, beispielsweise.
Es wird mit unseren Geräten und unseren Methoden nur eine relative Genauigkeit 
geben.
GPS ist heute auf im besten Fall 3m genau, das wird auch durch Gallileo nicht
so viel besser (außer man verwendet spezielle Antennen, DGPS und soweiter).
Wenn ich auf diesen relativ ungenauen Spuren weiterarbeite und das tun wir, 
dann kann sich der Fehler schnell vergrößern.
Wald Häuser und dergleichen führen auch bei SirfIII Empfängern zu 
Verfälschungen.
Trotzdem meinen manche es würde Sinn machen alle 5m von Hand einen Knotenpunkt 
für einen Weg setzen zu müssen.
Doppelte POI's sind ebenso etwas was man als zumüllen ansehen könnte.
> Ich sehe dem relativ gelassen entgegen. Im Falle 
> eines stra?enbegleitenden Radweges hei?t das, dass jemand auch den
> Gr?nstreifen zwischen Fahrbahn und Radweg einzeichnen k?nnen soll. Eine
> gute Sache, trotz der Fragen (speziell bez?glich des Renderings) die das
> aufwirft.
Es stellt sich am Ende nicht die Frage was ist mapbar, sondern wieviel und 
welche Information ist noch hilfreich.
Vielfach hat unsere Karte weiße Flecken, aber an anderen Stellen ist sie schon 
so unübersichtlich, das man sich in ihr nicht mehr zurechtfindet.
Da wird dann gerne das Argument gebracht, das ist Sache der Vorverarbeitung 
oder des Renderers.
Aber wie umständlich sollen Regeln für Renderer werden, wer sieht da noch 
durch.
Und selbst wenn, das Schema verändert sich laufend, wie man es dann auch 
rendert, es ist immer nicht so wie man es sich eigentlich wünscht.
Genauso ist das mit Karten für Navigationsgeräte.
>
> Ich pers?nlich komme daher zu dem Schluss, dass in einer Geodatenbank die
> Topologie wichtiger ist als die STVO, die wie eine Glasglocke ?ber die
> Topologie gest?lpt ist. Relationen sind eine umst?ndlich zu handhabende
> Sache.
Das ist das größte Problem mit ihnen, die Idee finde ich soweit sehr gut.
Das gilt auch für OSM, sehr gute Idee aber wenig strukturiert und sehr 
umständlich anzuwenden, selbst für Leute die das schon Jahre machen.
> Dennoch tendiere ich aus obigen Gr?nden dazu, dass die STVO durch 
> eine Relation zwischen dem Radweg und der Stra?e abgebildet werden sollte,
> so ?hnlich wie das ja auch bei Abbiegeverboten gehandhabt wird.
> Ich bin daher auch kein Freund davon, einen Weg zu zerhaken, nur um eine
> Geschwingigkeitsbeschr?nkung (oder auch eine einfache Br?cke) zu
> modellieren. W?re die Unterst?tzung f?r Relationen in unseren Editoren
> besser, w?rde ich f?r die im Verlaufe der Diskussion schon erw?hnten
> "Segmented Tags" pl?dieren (mit denen k?nnten ?brigens auch
> stra?enbegleitende Radwege recht gut beschrieben werden, aber das
> vielleicht besser nur am Rande ;-) .
Das ist glaube ich ein guter Denkansatz.
Ich glaube auch das das in den meisten Fällen ein vernünftig zu handhabendes 
Konstrukt sein könnte.
Aber bisher traue ich mich nicht an Relationen, das Prinzip ist mir in etwa 
klar, aber wiederum um nicht anderer Leute Arbeit zu zerstören verändere ich 
an Dingen wo Relationen dranhänge nichts.
Also verbessere oder berichtige ich da auch nichts.
Was natürlich eigentlich wieder wünschenswert sein müßte.
>
> Jeder von uns mappt, ob er will oder nicht, nat?rlich auch f?r "den Router"
> und "den Renderer". Dagegen ist erstmal nichts einzuwenden. Aber die
> Comsumer sollten IMO nicht zur obersten Maxime beim Mappen werden.
Die Consumer sind auch diejenigen die in das Projekt gegebenenfalls einsteigen 
und mitmachen, weil sie sehen: oh ich tu etwas berichtigen oder hinzufügen 
und schon kann ich und andere es wieder verwenden.
Das ist der entscheidende Punkt der Motivation: Verwendbarkeit!
Verwendbarkeit ist die beste Werbung und die beste Vorraussetzung dafür das 
unser Projekt weiterlebt.
Sehr abstrakte Ziele motivieren vielleicht Einzelne, aber das ist nicht 
wirklich das was man anstreben sollte.
> Ob 
> Mapnik Osmarender, openrouteservice.org, gosmore oder Navit heute mit
> unseren Daten zurechtkommen oder nicht, ist zweitrangig.
Aus den genannten Gründen ist es nicht zweitrangig, einheitliches 
Radwegmapping, aber sicher eine wichtige Vorraussetzung.
> Das lernen die 
> schon noch. Und zwar umso schneller, je einheitlicher das Radwegemapping
> umgesetzt wird.
>
> Wer eine Verbesserung erreichen m?chte, muss sich mit einer Reihe von
> Leuten zusammensetzen, die eine halbwegs einheitliche Vorgehensweise
> erarbeiten, vorschlagen und aktiv in den Daten und (vor allem) den
> Consumern umsetzen k?nnen. Genau so haben wir es in Karlsruhe mehrfach
> gemacht (komplexe Kreuzungen, Hausnummern, ?PNV) und andere haben es
> ?bernommen.
Und das ist ein guter Weg.
>
> Ich glaube ehrlich gesagt kaum, dass ein solcher Vorschlag zur Modellierung
> von Radwegen zu Zusatztags an Trunks raten w?rde. Aber ich lasse mich da
> gerne vom Ergebnis eines Workshops ?berraschen. Es sei denn, Heiko w?re der
> einzige Teilnehmer ;-) .
Speziell an Trunks vielleicht nicht sonst halte ich es für effizient und 
einfach durchzuführen und ausreichend genau in vielen Fällen.
>
>
> HTH und sch?nen Abend,
>
> ce

Gruß Sven S.