Überarbeitung "Snap to Road"

[jens]

Es gibt zwar grade schon zwei andere Threads zu ähnlichem Thema, aber so ganz passt es dann doch nicht, deshalb hier ein neues.

Gewichte der Kosten auf Meter normieren
Damit man sich die Gewichte besser vorstellen kann, würde ich vorschlagen wir geben alles in Meter-Äquivalenten an, also zB in candidate_cost() nicht mehr mit cost_per_meter_distance_to_gps multiplizieren.

Statdessen zB in cost_by_direction_dot() 150 zurückgeben, falls ortoghonal zum Weg gefahren wird. Also „Quer fahren ist genauso wahrscheinlich, wie 150m falsche Position“
(Siehe auch anderen Thread, diese Funktion scheint bei Einbahnstraßen kaputt zu sein)

Natürlich müssten dann auch die anderen Kosten skaliert werden, aber ich glaube man kann sie sich dann besser vorstellen. (Wenn wir alle Kosten skalieren, hat das auf die Minimum-Suche, keinen Einfluss, oder sehe ich da was falsch?)

GPS Genauigkeit berücksichtigen (vielleicht später)
Wir speichern die gemessene Genauigkeit (HDOP), das könnte man bestimmt berücksichtigen, aber ich wüsste grade nicht wie.

Radwege berücksichtigen
Wurde schonmal hier diskutiert
Jetzt (mit Portal Version 0.9, Juli 2024) haben wir den neuen Algorithmus, bei dem sich individuelle Gewichte definieren lassen. Ich würde unterscheiden in:

• Radweg ohne Überholvorgang (wahrscheinlich)
• Radweg mit Überholvorgang (unwahrscheinlich)

[osc]

Moin, bitte berücksichtigen, daß es nicht benutzungspflichtige Radwege gibt und man nebenan auf der Fahrbahn fährt. Ich habe auch einige benutzungspflchtige Radwege, die ich meide und Fahrbahn fahre. Innerstädtisch… bei Rennradfahrern im Trainining ist das nach meiner Kenntnis auch Außerorts erlaubt oder zumindest üblich. Viele Grüße, Olaf

[gluap]

@osc keine Sorge, das Problem mit „Radinfrastruktur parallel zu Autoinfrastruktur“ ist allen bewusst. Tatsächlich ist diese Art Infrastruktur der Grund, warum derzeit nur Straßen, die laut OSM Autoerlaubt sind in der Liste sind. Denn sonst hat man in Städten sehr nah beieinanderliegend (also innerhalb der GPS-Ungenauigkeit) im Zweifelsfall 2 Radwege und zwei KFZ-Spuren. Und eine der Sachen, die aus der Analyse rausfallen soll ist ja: Wo ist man gefahren. Das ist ziemlich aussichtslos, wenn das Straßen- und das Radwegpolygon nur 2-3 Meter voneinander entfernt verlaufen.

@opatut hatte mal einen Prototypen, bei dem man für ein kleines Gebiet ein (manuelles) simples semantisches mapping statt OpenStreetmap machen konnte. Die idee war: Openstreetmapgenauigkeit brauchen wir eigentlich nicht. Wir definieren Kreuzungen und welche Reisewege dazwischen möglich sind und ignorieren die OpenStreetmap für Gebiete in denen das Remapping exisitert.

@jens danke für den Nudge zum Bug in der Einbahnstraße! Den Hinweis hatte ich übersehen.