Hi @emga und @surveyor54… Ja Grundsätzlich ist es “nur” das… Aber da steckt ein großes “Aber” dahinter.
Ein Aber, da ich schon viel Erfahrung mit Geotagging habe und ich auch die Arbeitsweise von Mapillary (ich guck mir das Skript dennoch nochmal genau an) kenne… Ebenso sind mir auch die verschiedensten Programme zum taggen (Lieblingstool, ist hier für mich auch JOSM und “Geotagger” bekannt.
Aber es ist so wie @Harald Hartmann es schon herausgelesen hat… Um Fotos an einem Track zu justieren benötigt man im Track eine relativ “kleine” und Genaue" Zeit/Raum-Äuflösung. Also das, was auch herauskommt wenn man einen GPS-Tracker oder eine Tracking-App mitlaufen lässt (mache ich ja auch bei anderen Projekten) In meinem Falle habe ich fahrten in den Urlaub (Süddeutschland->Norddeutschland) die Hauptsächlich über Land führten (weil schöner ;-))… Leider haben wir damals keinen “Tracker” mitlaufen lassen… Eine manuelle Georefferenzierung habe ich mal angefangen, aber bei mehreren Urlaubsfahrten mit insgesammt weit mehr als 10.000 Einzelbildern ist dass kein Zuckerschlecken…
Um mir die Arbeit einfacherer zu machen habe ich einfach mal einen GPX-Track gefaked (da die Route ja noch bekannt ist und auch anhand der Fotos schnell mit modernen “Routern” nachjustiert werden kann - war das auch sehr einfach zu machen. Diese Route kann ich dann als GPX exportieren.
Da die Router aber ja keine Ahnung haben an welchem Ort man wie schnell gefahren ist, habe ich diese Informationen einfach über die bekannten Zeiten von Fotos an bekannten Orten (z.B. Kreuzungen) nachgetaggt… Ich habe erwartet, das hier riesige Abweichungen zustande kommen, da man ja auch mal Pausen macht, oder langsam fährt… Zu meiner Überraschung sind diese Abweichungen selbst bei 1000+km und 8h+ Autofahrten relativ gering, wenn man etwa 5% der Fotos als Basis für die Zeiten nimmt und dann nach dem Prinzip der Binären Teilung (Also erst Anfang und Ende → Dann die Mitte → Wieder die Mitte → Wieder die Mitte usw.) die Werte linear vervollständigt…
Stichprobenartig habe ich dann (in den Mitten die dann errechnet waren) Spitzenabweichungen von ca. ±10 Sekunden gehabt… Was die Fotos schon fast hinreichend genau (zumindestens für meine Ursprünglichen Zwecke) georeferenziert…
Da das so gut funktioniert hat… Habe ich mir überlegt… ob man es nicht noch verbessern kann und ob man nicht herausfinden kann, wo die größten Abweichungen entstehen…
Naja das ist kein großes Hexenwerk, denn die Abweichungen entstehen genau an den Stellen wo die Abweichung zum arithmetrischen Mittel der Geschwindigkeit am größten ist. Also
a) an Ampeln
b) auf Parkplätzen
c) an Ortseinfahrten
d) an Ortsausfahrten
e) an Kreiseln
All diese Punkt sind aber in OSM (größtenteils) wunderbar erfasst… Weswegen ich (zunächst mal nur) die Idee hatte diese “linear” berechneten fehlenden Zeitinformationen der Zwischenstücke nicht Linear (also einfach Entfernung des Anfang<->Endpunkts geteilt durch die Anzahl der Zwischenpunkte) berechnen zu lassen sondern anhand der gültigen Höchstgeschwindigkeiten der jeweiligen Straße zu berechnen.
Also wenn zwei Zwischenpunkte in der 30’er Zone liegen und die anderen alle auf der 70’er Strecke, wird vermutlich die Fahrt von dem einen zum anderen 30’er GPS-Punkt mehr Zeit in Anspruch genommen haben, als die gleiche Strecke auf der 70’er Strecke 
Und zwischen dem 30’er und dem 70’er Punkt wird vermutlich annähernd linear Beschleunigt worden sein.
In meiner gedankelichen Thorie sollte damit die Abweichung von ±10 Sekunden deutlich reduziert werden können… Eventuell führt dies sogar dazu, das viel weniger als 5% Fixpunkte nötig sind…
In einem weiterem Schritt könnte man auch noch den Kuvenradius (http://blog.openstreetmap.de/blog/2016/02/wochennotiz-nr-290/), Ampeln, Ortsgrenzen mit einbeziehen…
Und da ich diesen Thread hier gefunden habe, wollte ich mal nachfragen, ob sich da in 5 Jahren schon Wissen “drüber” angesammelt hat oder ob ich bei Null anfangen muss
:tldr
Eigentlich noch mal das gleiche wie in meinem ersten Beitrag nur mit ausführlicherer Motivation.
**Edit1: **
P.S. Was sich auch noch verwursten ließe wäre die jeweilige Steigung der Strecke - die ich lustigerweise habe, da man die Routen mit den SRTM-Daten abgleichen kann und die Höhe einer Position ermitteln kann (genau so eine Abfrage wäre bei OSM mein Glücksfall). Also an Steigungen wird eine Beschleunigung von 30km/h auf 70km/h im Mittel länger dauern als bei einem Gefälle
Noch eine Frage am Rande… weiß jemand ob man bei OSM eine Richtungsbezogene Abfrage bei der API machen kann also:
Gib mir alle Straßensegmente in einem Window, die in die Richtung “78°” zeigen?
P.P.S. Ich denke fast, dass das hier jetzt doch zu komplex wird… 
Ich werde berichten wenn ich fortschritte machen, aber in dem Thread sollten wir im Bezug auf die Frage des damaligen OT bleiben, vieleicht will der ja auch noch eine Antwort haben
P.P.P.S. Ich habe mittlerweile auch bemerkt das die API von OSM dafür (auf Grund der Nutzungsbedigung) nicht geeignet ist und werde daher doch einen eigenen OSM-Server brauchen…
Edit2:
Noch ein Nachtrag…
Ich bin ein beachtliches Stück weiter gekommen und habe mir jetzt fix ein Phython-Skript zusammengebastelt, welches genau diese Abfrage erledigt. Nutzen tue ich dabei die OverpassAPI die laut Usage policy
bis zu 10.000 Queries pro Tag erlaubt, ohne das ich jemanden damit störe - imho. ist overpass hier auch der richtigere Ansatz, da es hier ja um das “lesen” geht, was ja die osm api gerade nicht will (siehe oben)…
Ich gebe also in das Skript eine gpx-datei mit den Tracks ein, und erhalte den “Way” der jeweiligen Straße in 5m Umkreis um dn GPS-Punkt, der Rest ist jetzt Scriptlogik…
Der bisherige Python-Code ist so simpel, dass ich ihn hier kurz niederschreiben will
import gpxpy
import gpxpy.gpx
import overpass;
api = overpass.API();
gpx_file = open('mygpx_file.gpx', 'r')
gpx = gpxpy.parse(gpx_file)
for track in gpx.tracks:
for segment in track.segments:
for point in segment.points:
searchstring = 'way(around:5.0, {0}, {1});'.format(point.latitude, point.longitude)
response = api.Get(searchstring)
print response;
Ich nutze hierbei den Parser https://github.com/tkrajina/gpxpy und den Wrapper
https://github.com/mvexel/overpass-api-python-wrapper
Damit steht an dieser Stelle eigentlich auch eine Lösung für den Threadersteller bereit.
Naja, fast… da man natürlich das Ergebnis noch parsen muss…
