[Talk-de] QA basierend auf kürzester Route

[Wolfgang W. Wasserburger]

Die Idee, einen Index zu berechnen, der die Längenabweichung von der
Luftlinie berechnet halte ich nur in der Ebene für tragfähig. Sobald
Barrieren (Gebirge, Flüsse, ...) ins Spiel kommen, kann man das vergessen.

Beispiel aus Österreich: von Neustift im Stubaital nach Ötz im Ötztal sind
es rund 10 km (Luftlinie), dem kann man aber nur zu Fuß oder per Ski
nahekommen. Die tatsächliche Straßenentfernung ist 110km. Das würde also
ewig als Fehler ausgegeben, auch wenn es sicher keiner ist.

Da halte ich die Variante, bestimmte, markante Stecken zu speichern
(eventuell auch Vergleichswerte aus Google, map24, ...) und laufend
durchzuchecken für tragfähiger.

lG aus jener Millionenstadt, wo der höchste Berg höher ist, als jener in
Holland oder England

Wolfgang


> -----Original Message-----
> From: talk-de-bounces at openstreetmap.org
> [mailto:talk-de-bounces at openstreetmap.org]On Behalf Of Frederik Ramm
> Sent: Monday, December 01, 2008 12:20 AM
> To: Openstreetmap allgemeines in Deutsch
> Subject: Re: [Talk-de] QA basierend auf kürzester Route
>
>
> Hallo,
>
> Florian Lohoff wrote:
> > Die idee die ich hatte war das man z.b. aus Navit den Routing Core
> > rausloest und identische routen jeden tag berechnen laesst. Jeden tag
> > vergleicht man dann die distanz - sollte die distanz um mehr als 5km
> > oder 5% zu oder abnehmen weiss man das sich fehler eingeschlichen haben.
>
> Das ist eine sehr gute Idee, allerdings koennte es einfacher sein,
> Gosmore dafuer zu verwenden, da musst Du nichts mehr raussplitten, denn
> Gosmore *ist* der Routing Core.
>
> Ich bastle gerade auch etwas in der Richtung, allerdings nicht fuer den
> automatisierten Betrieb, sondern fuer den manuellen - ein Webinterface,
> bei dem Du verschiedene OSM-Routingergebnisse und Google miteinander
> vergleichen kannst und dann einen Bug erfassen, wenn Dir was nicht
> koscher erscheint.
>
> > Eine idee waere die punkte direkt mit in die OSM Daten einzufuegen a la
> > routeqa=clustername auf irgendwelchen nodes.
>
> Lieber separat halten.
>
> > Das mit dem Cluster waere interessant damit nicht ein "any to any"
> > berechnet werden muss sondern nur punkte any to any innerhalb eines
> > clusters.
>
> Man braucht ja nicht gleich den Anspruch zu haben, flaechendeckend zu
> sein, ausgewaehlte Testrelationen waeren ja schonmal ein guter Anfang.
> Zu weit runter ins Detail will man nicht - dass irgendeine Strecke
> innerhalb Hamburgs statt 2km ploetzlich 3km lang ist, kann auch das
> Resultat einer tatsaechlichen Verkehrsberuhigungsmassnahme sein,
> waehrend eine Aenderung von 20m->30km in der Region sicher eher ein
> Fehler sein duerfte.
>
> Ich koennte mir auch vorstellen, dass man fuer bestimmte Regionen
> zunaechst aufgrund existierender Daten eine
> Verkehrsinfrastrukturkenziffer berechnet, die in etwa angibt, um wieviel
> laenger als die Luftlinie eine Verbindung zwischen zwei Punkten im
> Schnitt ist. Eine solche Kennziffer ist vermutlich nur fuer aehnlich
> lange Strecken gueltig, also koennte man eine "vik(50)" berechnen fuer
> 50km lange Strecken, eine vik(10) und eine vik(250) oder sowas. Dann
> pickt man sich zufaellige Punktpaare mit der entsprechenden Distanz aus
> dem Bereich, routet dazwischen und schaut, ob man Paare bekommt, bei
> denen das Ergebnis deutlich schlechter ist als zu vermuten gewesen
> waere, und das sind dann die Gegenden, in denen Strassen fehlen
> (entweder tatsaechlich fehlen oder in OSM fehlen). - Das ist aber
> natuerlich eine andre Art von QA, eher so eine Vollstaendigkeitsanalyse.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"
>
> _______________________________________________
> Talk-de mailing list
> Talk-de at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-de
>