seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11179
Wohnort: München
|
glaskugel schrieb: Alle gpx-Dateien zeigen den gesamten Track von Spanien und Portugal. Ich vermute Algier ist ein Ausreißer.
Ok, das muss ich mir nochmal ansehen. glaskugel schrieb: Kannst du im Namen noch die Abweichung zu UTC anführen? IMHO UTC als erstes, dann hat man gleich eine Sortierung.
Also sowas wie zeitzone_pt-es_ayamonte_+01:00_Europe_Lisbon.gpx? Kannst du ein Log anführen, das ein bisschen gesprächig ist was gemacht wurde? Ich brauche nämlich neben dem GPX-Split auch Informationen wie ich die Fotos in verschiedene Ordner verteile. Die Fotos haben im Namen das Datum und die Zeit.
Das ist mir nicht ganz klar - anhand der Lokalzeit-Timestamps der Bilder kann man den Ort ja nicht zuverlässig zuordnen - das ist der Grund für den ganzen Aufwand. Sonst könnte man die Bilder-Timestamps einfach in UTC setzen und sich das Splitten, separate Ordner usw. sparen. ZB wäre sowas hilfreich. UTC Datum Uhrzeit - Land / Zeitzone verlassen - Koordinaten (zum Kopieren in Maps)
UTC Datum Uhrzeit - in Land / Zeitzone gewechselt - Koordinaten Ich frage mich, ob das nach stderr ausgegeben werden soll, denke aber nicht. Ich kann mir das zwar auch in eine Variable zusätzlich holen, aber dann ist die gesamte stderr-Ausgabe in der Variablen.
Sowas kann ich prinzipiell einbauen. Zu berücksichtigen ist, dass in eine bestimmte Zeitzone mehrfach gewechselt werden kann. Beispiel dieser Ausflug von Portugal nach Spanien und wieder zurück nach Portugal, wobei es da noch einen weiteren Ausflug nach Spanien / Sevilla gibt, der aber bei der Beispiel gpx-Datei nicht mehr enthalten ist. Das lade ich gerne als gpx-Datei zum Testen hoch, wenn du das möchtest.
Ja, das könnte helfen, das am Datensatz nachzuvollziehen. Die Frage ist auch, ob man alle gpx-Daten aus 1 Zeitzone in 1 Datei schreiben soll? Ich würde eher sagen ja, dh zuerst teilen, wegen dem Log um die Fotos in die Ordner verteilen zu können und dann am Ende zusammenfassen?
Was genau soll da zusammengefasst werden? Sollte man die offensichtlich falschen GPX-Daten nicht gleich rauswerfen? Es gibt da zwar was in meiner Beispieldatei, aber bei diesen Koordinaten dürfte es gültige Timezone-Data geben.
Ich kenne keinen allgemeingültigen Algorithmus dafür, der offensichtlich falsche GPS-Daten identifiziert - aber natürlich kannst du Punkte, die du nicht verwerten willst, aus den gpx-Dateien entfernen.
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Ok, das muss ich mir nochmal ansehen.
Hattest du nach Zeitzonen oder Länder gesplittet? Ich hatte eine komplexere GPS-Datei da kamen Files mit unterschiedlichem Namen aber gleicher Zeitzone. Aber zuerst soll es mit der erwähnten Portugal-Spanien-Datei passen.
Also sowas wie zeitzone_pt-es_ayamonte_+01:00_Europe_Lisbon.gpx?
Ja genau in dieser Reihenfolge, dann hat das eine gewisse Logik mit ls. Wird die Cache-Datei der Splits automatisch erstellt? Das ist zwar dann ein organisatorisches Problem, aber ich habe pro Fotoalbum genau 1 gpx-Datei, die sich genau so nennt wie der Ordner-Name + ".gpx". Mein Bash-Script benennt automatisch um und die Cache-Datei wird dann sowieso neu erstellt. Ich lösche die Cache-Datei vom Split also.
Das ist mir nicht ganz klar - anhand der Lokalzeit-Timestamps der Bilder kann man den Ort ja nicht zuverlässig zuordnen - das ist der Grund für den ganzen Aufwand
Sicher, aber ... Ich verwende zum Testen vorwiegend fremde Fotos und fremde gpx-Dateien (von Leuten, die sich über Zusammenhänge keine Gedanken machen und daher ist da auch mit einigen Problemen zu rechnen. Bei diesen Portugal / Spanien - Fotos ist die Zeit immer MEZ, dh für Portugal muss die Zeit korrigiert werden und da ich nicht selber fotografiert habe, muss ich herausfinden was nun in Spanien und was in Portugal war bzw. wo die Grenze ist. Da muss man dann ein wenig detektivisch sein. Wenn ich nun weiß, der Zeitzonenwechsel war um zb 17,00, dann kann ich schauen wie die Fotos dazu passen. In diesem Fall fand ich raus, dass Spanien passt und Portugal nicht, also wurde die Lokalzeit in Portugal nicht eingestellt. Passt es also, dann wurde die Zeit bereits vor Jahren korrigiert, passt es nicht, dann müssen die Fotos herausgefunden werden, die in Spanien bzw. Portugal gemacht wurden und deswegen hätte ich gerne die Übersicht. Bei mehrmaligem Wechsel kann das kompliziert werden. Eine Liste hat den Vorteil, dass man nicht im GPX-File nachsehen muss. Wenn es für dich kein Problem ist, dann wäre zusätzlich ein kml-File interessant. Damit lasse ich mir mit Marbel die Trackpoints anzeigen. Mit gpsbabel ist das einfach, ist nur eine Frage der korrekten Namen, wenn man in der Konsole testet.
Ja, das könnte helfen, das am Datensatz nachzuvollziehen.
GPX-Datei kommt ASAP.
Was genau soll da zusammengefasst werden?
Beispiel:
Du machst Urlaub in Portugal nahe der spanischen Grenze. Nach Spanien brauchst du mit der Fähre nur 10 Minuten. Also fährst du öfters nach Spanien zum Essen, etc. und fotografierst immer. So kommt es, dass die Fotos wiederholt in verschiedenen Zeitzonen sind. zB
1.8. vorm. Portugal
2.8. nachm. Spanien
2.8. abends Portugal
3.8. vorm. Portugal
3.8. vorm. Spanien
etc. Es gibt aber nur 1 GPX-Dateo aus 1 Logger. Also muss zwischen Spanien und Portugal getrennt werden. Es gibt dann also 2 gpx-Files für Portugal, ist ja 1x Spanien dazwischen: 1.8. vorm. Portugal
2.8. abends Portugal - 3.8. vorm. Portugal Du arbeitest ja den Track ab, wenn ich es richtig verstanden habe. Um den Ort der Fotos leichter zu finden / erraten, brauche ich die Zeiten wenn die Zeitzonengrenzen überschritten wurden. Also zuerst die Trennung in jeden Zeitzonenwechsel. Wenn ich also in Portugal das Hotel habe und ein paar Mal in den spanischen Grenzort fahre, dann werde ich die protugiesischen Fotos in 1 Ordner geben und die spanischen wieder in 1 anderen Ordner. Ich brauche also 1 gpx-Datei für Portugal und 1 für Spanien. Will ich das nicht, dann muss ich eben die 1 zusammen gefasste gpx-Datei in die einzelnen Ordner geben. Das hat nur den Nachteil eines geringfügig höheren Speicherbedarfs, das ich aber vernachlässige. Ich hoffe, ich war klar genug 😉
Ich kenne keinen allgemeingültigen Algorithmus dafür, der offensichtlich falsche GPS-Daten identifiziert
Ich meinte, dass du die Einträge rauswirst, die keine Zeitzoneninformation haben, wie du es bis jetzt schon gemacht hast. Ein Ansatz wäre die Geschwindigkeit (aus dem Island-kml-File wo es einen Ausreißer nach Schottland AFAIR gab) <table>
<tr><td>Longitude: -20.458185 </td></tr>
<tr><td>Latitude: 64.189535 </td></tr>
<tr><td>Altitude: 3526.000 meters </td></tr>
<tr><td>Speed: 14.6 km/hour </td></tr>
<tr><td>Heading: 334.8 </td></tr>
<tr><td>Time: 2015-07-29T16:26:41Z </td></tr>
</table>
]]></description>
<LookAt>
<longitude>-20.458185</longitude>
<latitude>64.189535</latitude>
<tilt>66</tilt>
</LookAt>
<TimeStamp><when>2015-07-29T16:26:41Z</when></TimeStamp>
<styleUrl>#track</styleUrl>
<Point>
<coordinates>-20.458185,64.189535,3526.00</coordinates>
</Point>
</Placemark>
<Placemark>
<name>TP3714</name>
<snippet/>
<description><![CDATA[
<table>
<tr><td>Longitude: -20.453570 </td></tr>
<tr><td>Latitude: 64.177287 </td></tr>
<tr><td>Altitude: 90.000 meters </td></tr> <tr><td>Speed: 994.8 km/hour </td></tr> <tr><td>Heading: 170.7 </td></tr>
<tr><td>Time: 2015-07-29T16:26:46Z </td></tr>
</table>
]]></description>
<LookAt>
<longitude>-20.453570</longitude>
<latitude>64.177287</latitude>
<tilt>66</tilt>
</LookAt>
<TimeStamp><when>2015-07-29T16:26:46Z</when></TimeStamp>
<styleUrl>#track</styleUrl>
<Point>
<coordinates>-20.453570,64.177287,90.00</coordinates>
</Point>
</Placemark>
<Placemark>
<name>TP3715</name>
<snippet/>
<description><![CDATA[
<table>
<tr><td>Longitude: -20.453565 </td></tr>
<tr><td>Latitude: 64.177258 </td></tr>
<tr><td>Altitude: 88.000 meters </td></tr>
<tr><td>Speed: 2.3 km/hour </td></tr>
<tr><td>Heading: 175.7 </td></tr>
<tr><td>Time: 2015-07-29T16:26:51Z </td></tr>
</table> Man könnte da also eine Option machen, die Geschwindigkeiten über x km/h ausschließt bzw. noch die Werte davor und danach vergleichen und den Zeitunterschied berücksichtigen. Wenn man sicher ist, dass das kein Flug ist, dann kann man Geschwindigkeiten um 1000km/h problemlos elimieren. Das nur als Ansatz für einen Algorhitmus, keine Ahnung wie schwer das umzusetzen ist.
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Die Realität ist dann nochmals komplizierter 😉 Im Anhang findest du eine GPX-Datei, die die bereits erwähnte Flussüberquerung mit Änderung der Zeitzone bei Ayamonte enthält und dann gibt es da noch eine Fahrt nach Sevilla von Portugal aus, wobei das GPS den 1. Fix erst in Spanien bekommen hat. Auf der Rückfahrt gibt es dann aber den Wechsel von Spanien nach Portugal direkt an der Grenze. Für die Liste würde das bedeuten, dass der Zeitzonenwechsel 1x aus dem letzten Punkt in Portugal besteht, der nicht an der Grenze ist und ebenso ist der 1. Punkt in Spanien dann auch nicht an der Grenze.
- zeitzonenwechsel43-4x.gpx.tar.gz (84.3 KiB)
- Download zeitzonenwechsel43-4x.gpx.tar.gz
- zeitzonenwechsel43-4x.kml.tar.gz (277.4 KiB)
- Download zeitzonenwechsel43-4x.kml.tar.gz
- Bilder
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11179
Wohnort: München
|
Das mit dem UTC-Offset im Dateinamen macht es komplexer - eine Zeitzonen-ID wie "Europe/Berlin" bleibt auch über die Zeitumstellung hinweg gültig, aber der Offset kann in dem Fall zwischen +0100 und +0200 springen. Mit deiner Beispieldatei sieht die Auflistung der Zeitzonenwechsel z.B. so aus:
$ ./geoinfo.py -s gpx/zeitzonenwechsel43-4x.gpx
trying to open gpx/zeitzonenwechsel43-4x.cache
loaded cache file
2011-07-25 09:47:30: changed to timezone Europe/Lisbon at point TP4740 (37.1969016, -7.4146133)
2011-07-25 10:03:01: changed to timezone Africa/Algiers at point TP4821 (37.1983499, -7.4124866)
2011-07-25 11:09:55: changed to timezone Europe/Madrid at point TP5199 (37.21259, -7.4074833)
2011-07-25 11:29:26: changed to timezone Africa/Algiers at point TP5359 (37.2127533, -7.407545)
2011-07-25 12:40:42: changed to timezone Europe/Lisbon at point TP5629 (37.1976033, -7.4122916)
2011-07-27 07:57:10: changed to timezone Europe/Madrid at point TP6073 (37.2460866, -7.3029866)
2011-07-27 16:45:25: changed to timezone Africa/Algiers at point TP10236 (37.2377933, -7.4191483)
2011-07-28 19:11:03: changed to timezone Europe/Lisbon at point TP10487 (37.1768149, -7.44871)
processing trackpoints for tzname 'Europe/Lisbon'
creating zeitzonenwechsel43-4x_Europe_Lisbon.gpx for timezone Europe/Lisbon
processing trackpoints for tzname 'Africa/Algiers'
creating zeitzonenwechsel43-4x_Africa_Algiers.gpx for timezone Africa/Algiers
processing trackpoints for tzname 'Europe/Madrid'
creating zeitzonenwechsel43-4x_Europe_Madrid.gpx for timezone Europe/Madrid
Das mit Africa/Algiers fand ich auffällig - das sind ist jeweils Punkte auf oder in der Nähe des Río Guadiana, die von tzwhere "geraten" werden, weil sie anscheinend nicht sauber aus den shapefiles http://efele.net/maps/tz/world/ errechnet werden können. Das Problem wurde auch im Bugtracker von (py)tzwhere diskutiert:
Die Google-Maps Timezone API liefert da bessere Ergebnisse:
GET https://maps.googleapis.com/maps/api/timezone/json?location=37.1983499,-7.4124866×tamp=1311590442&key=$APIKEY
{
dstOffset: 3600,
rawOffset: 0,
status: "OK",
timeZoneId: "Europe/Lisbon",
timeZoneName: "Western European Summer Time"
} Mit geonames ginge es auch, aber leider nur für die aktuelle Ortszeit, weswegen man die Offset-Angaben für historische Punkte nicht verwerten kann:
GET http://api.geonames.org/timezoneJSON?lat=37.1983499&lng=-7.4124866&username=$USERNAME
{
sunrise: "2016-09-24 07:19",
lng: -7.4124866,
countryCode: "PT",
gmtOffset: 0,
rawOffset: 0,
sunset: "2016-09-24 19:22",
timezoneId: "Europe/Lisbon",
dstOffset: 1,
countryName: "Portugal",
time: "2016-09-24 09:37",
lat: 37.1983499
} Online-Abfragen sind verhältnismäßig kostspielig, da man bei jedem Dienst nur begrenzte tägliche Anfragen nutzen kann - bei der Beispieldatei müsse man z.B. die Zeitzone für 654 Punkte Abfragen, bei denen tzwhere rät - soll ich das einbauen, dass er in dem Fall Google bzw. Geonames (wenn es einen passenden API-Key bzw. Username gibt) befragt?
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11179
Wohnort: München
|
Alternativ könnte man natürlich auch angeben, dass man die Timestamps aus den GPX-Daten in die Lokalzeit einer bestimmten Zeitzone für den Vergleich umwandeln möchte bzw. dass er statt zu raten oder es online anzufragen auf eine bestimmte Zeitzone zurückfallen soll. Da die ehemalige Vorbedingung, dass die Bilder immer in Lokalzeit vorliegen ja anscheinend nicht allgemein zutreffend ist und es jede Menge Spezialfälle gibt, hat man an der Stelle mehr Freiheiten.
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11179
Wohnort: München
|
Hier noch der aktuelle Stand. Wenn du die Zahl der Einträge wissen willst, bei denen tzwhere beim Split raten muss, musst du vorher die .cache-Datei löschen.
- geoinfo.tar.xz (5.9 KiB)
- Download geoinfo.tar.xz
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11179
Wohnort: München
|
glaskugel schrieb: Hattest du nach Zeitzonen oder Länder gesplittet?
Er splittet aktuell nach Zeitzonen-ID. Das ist die relevante Information, um die Ortszeit zu errechnen. Wird die Cache-Datei der Splits automatisch erstellt?
Ja, weil die Daten dafür ja sowieso schon errechnet wurden - ich habe es mal rausgenommen. Das ist mir nicht ganz klar - anhand der Lokalzeit-Timestamps der Bilder kann man den Ort ja nicht zuverlässig zuordnen - das ist der Grund für den ganzen Aufwand
Fotos ist die Zeit immer MEZ, dh für Portugal muss die Zeit korrigiert werden und da ich nicht selber fotografiert habe, muss ich herausfinden was nun in Spanien und was in Portugal war bzw. wo die Grenze ist. Da muss man dann ein wenig detektivisch sein.
Das ist dann nicht die Aufgabe eines vergleichsweise einfachen Skriptes, wenn das praktisch nur in Handarbeit möglich ist. Wenn ich nun weiß, der Zeitzonenwechsel war um zb 17,00, dann kann ich schauen wie die Fotos dazu passen. In diesem Fall fand ich raus, dass Spanien passt und Portugal nicht, also wurde die Lokalzeit in Portugal nicht eingestellt. Passt es also, dann wurde die Zeit bereits vor Jahren korrigiert, passt es nicht, dann müssen die Fotos herausgefunden werden, die in Spanien bzw. Portugal gemacht wurden und deswegen hätte ich gerne die Übersicht. Bei mehrmaligem Wechsel kann das kompliziert werden. Eine Liste hat den Vorteil, dass man nicht im GPX-File nachsehen muss.
Mal sehen, wie gut das klappt - mit der Ungenauigkeit des Empfängers und eventuell den Abweichungen der tzshape-Dateien könnte das in Grenznähe ziemliches Glückspiel sein, das zuverlässig zuzuordnen. Ich kenne keinen allgemeingültigen Algorithmus dafür, der offensichtlich falsche GPS-Daten identifiziert
Ich meinte, dass die Einträge rauswirst, die keine Zeitzoneninformation haben, wie du es bis jetzt schon gemacht hast.
Ich ignoriere aktuell die Einträge, für die tzwhere keine Zeitzone errechnen bzw. erraten kann - aber das heißt nur, dass sie nicht an einem Ort liegen, an dem eine offizielle Zeitzone gilt. Da könnte man sich behelfsmäßig aus dem Längengrad eine nautische Zeit ableiten, oder akzeptieren, dass UTC-Timestamps immer die beste Lösung sind, wenn es um den Abgleich von Zeitdaten geht 😉 Man könnte da also eine Option machen, die Geschwindigkeiten über x km/h ausschließt bzw. noch die Werte davor und danach vergleichen und den Zeitunterschied berücksichtigen. Wenn man sicher ist, dass das kein Flug ist, dann kann man Geschwindigkeiten um 1000km/h problemlos elimieren.
gpxpy kann aus der Luftlinie zwischen zwei Punkten die Geschwindigkeit errechnen - aber welchen der beiden Punkte soll man dann verwerfen, wenn es eine zu hohe Geschwindigkeit gibt?
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Das mit dem UTC-Offset im Dateinamen macht es komplexer - eine Zeitzonen-ID wie "Europe/Berlin" bleibt auch über die Zeitumstellung hinweg gültig
Ich bin mir bei den Problemfällen nicht so recht klar. Kann man bei einer gpx-Datei die Zeit um zB 1h verändern? Da geht es um sehr alte Dateien, wo offensichtlich nicht durchdacht die Apps programmiert wurden. Am einfachsten ist es da manuell ein Offset einzustellen, das bedeutet aber nicht, dass es keine andere Lösung gibt, vermutlich einfach eine passende Zeitzone verwenden, wenn es auch nicht die tatsächliche ist.
Ja, weil die Daten dafür ja sowieso schon errechnet wurden - ich habe es mal rausgenommen.
Ich denke es wird einfacher bzw. fehlerfreier. Da man die Splits ja sowieso verteilen muss und ich die Splits ja wieder umbenenne.
Das ist dann nicht die Aufgabe eines vergleichsweise einfachen Skriptes, wenn das praktisch nur in Handarbeit möglich ist.
Ich verschiebe manuell die Fotos und ändere bei Bedarf die Zeit. Auch wenn ich jetzt die Zeitzonenwechsel gelistet habe, bedeutet das nicht, dass der GPS-Logger bei jedem Foto an war oder es einen Fix gab. Ich verwende für diesen Fall dann "Rückfall-Koordinaten", die verwendet werden, wenn kein Abgleich möglich war. Könntest du bitte "no entry found" nicht nach stderr ausgeben und unterhalb "minimum timedelta" listen?
Mal sehen, wie gut das klappt - mit der Ungenauigkeit des Empfängers und eventuell den Abweichungen der tzshape-Dateien könnte das in Grenznähe ziemliches Glückspiel sein, das zuverlässig zuzuordnen.
Es muss die Praxis zeigen, wobei ich meine, dass es bei Fotos am Zeitzonen-Grenzfluss egal ist, ob nun der portugiesische oder der spanische Ort gelistet ist. Entscheidend ist, dass die jeweilige GPX-Datei nur Koordinaten aus 1. Land hat.
Ich ignoriere aktuell die Einträge, für die tzwhere keine Zeitzone errechnen bzw. erraten kann
Ja, das half ja bis jetzt immer, deckt aber nicht alle GPS-Ausreißer ab, aber besser als nichts. Wenn ich da einen Ausreißer von ein paar km habe, dann wird die Ortsbestimmung noch immer passen. Perfekt wird man nie schaffen.
Da könnte man sich behelfsmäßig aus dem Längengrad eine nautische Zeit ableiten,
Da kenne ich mich nicht aus. Meinst du wenn man irgendwo mitten über dem Atlantik im Flugzeug ist, sodass man dann noch was brauchbares bekommt? Ich denke, diese Fotos sind vernachlässigbar. Ich kann mir da nicht viel vorstellen, zB eine schöne Wolkenformation.
gpxpy kann aus der Luftlinie zwischen zwei Punkten die Geschwindigkeit errechnen - aber welchen der beiden Punkte soll man dann verwerfen, wenn es eine zu hohe Geschwindigkeit gibt?
Beide eliminieren? Gehen wir davon aus, dass es kein Flug ist, dann ist die Veränderung zu Fuß innerhalb ein paar Sekunden nicht sehr groß und hat keinen Einfluss auf den Ortsnamen. Dann ist eben timedelta nicht 15 Sekunden sondern 30 Sekunden oder vielleicht 1 Minute. Von Ungenauigkeiten muss man sowieso immer ausgehen. Ungenauer wird es, wenn man aus einem fahrenden Auto oder einem Flugzeug fotografiert. Im FLugzeug ist aber zwischen Ort an dem fotografiert wird und dem Ort, der fotografiert wird sowieso ein großer Unterschied. Das können leicht 50km sein. Problemfall sind also primär Fotos aus dem Auto bzw. einem Reisebus. Alternativ müsste man die Punkte davor bzw. danach vergleichen, tendenziell meine ich, dass der 1. Punkt eher passen wird. Wenn es mehrere hohe Geschwindigkeiten hintereinander gibt, dann kann man ab dem 2. beide elimieren.
Alternativ könnte man natürlich auch angeben, dass man die Timestamps aus den GPX-Daten in die Lokalzeit einer bestimmten Zeitzone für den Vergleich umwandeln möchte bzw. dass er statt zu raten oder es online anzufragen auf eine bestimmte Zeitzone zurückfallen soll.
Wäre eine Idee
Online-Abfragen sind verhältnismäßig kostspielig, da man bei jedem Dienst nur begrenzte tägliche Anfragen nutzen kann - bei der Beispieldatei müsse man z.B. die Zeitzone für 654 Punkte Abfragen, bei denen tzwhere rät - soll ich das einbauen, dass er in dem Fall Google bzw. Geonames (wenn es einen passenden API-Key bzw. Username gibt) befragt?
Ich fürchte mit Google ist das kostenlos in der Praxis nicht machbar. Da ist man schnell am Limit. Bei geonames sehe ich vom Limit keine Probleme.
Mit geonames ginge es auch, aber leider nur für die aktuelle Ortszeit, weswegen man die Offset-Angaben für historische Punkte nicht verwerten kann
Hast du bereits andere Server probiert, wie brauchbar die Angaben liefern, wenn die mehr Abfragen als Google kostenlos zulassen. Ich denke man muss geonames in der Praxis probieren. Es ist auch zu überlegen, was passiert, wenn man die geratenen einfach eliminiert. Ich denke bei meinem Beispiel ist das vom Ergebnis kein Problem. Sieht man dann sowieso, dass das Foto am Fluss gemacht wurde und ob das auf der spanischen oder portugiesischen Seite gemacht wurde, hat für mich keine Bedeutung. Aber es kann natürlich Situationen geben, wo das wichtig ist.
Das mit dem UTC-Offset im Dateinamen macht es komplexer
Ich bin deswegen auf die Idee gekommen. Abfrage noch mit der alten Version: ls -1 *.gpx
test_Africa_Algiers.gpx
test_Europe_Athens.gpx
test_Europe_Berlin.gpx
test_Europe_Lisbon.gpx
test_Europe_Ljubljana.gpx
test_Europe_Madrid.gpx
test_Europe_Paris.gpx
test_Europe_Podgorica.gpx
test_Europe_Sarajevo.gpx
test_Europe_Skopje.gpx
test_Europe_Tirane.gpx
test_Europe_Vienna.gpx
test_Europe_Zagreb.gpx
test_Europe_Zurich.gpx
test.gpx Also gibt es da offensichtlich mehrere Dateien für die gleiche Zeitzone. Deine neue Version muss ich mir erst ansehen, Feedback ASAP, bin zeitweise unterwegs, weiß aber noch nicht wann genau.
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Gleich zur neuen Version eine kleine Anregung. Wenn man die gpx-Datei mit Pfad angibt, dann sollten die Splits auch den Pfad verwenden. Das ist der Auszug mit der neuen Version und der im Thread davor verwendeten Testdatei: $ python3 /usr/local/bin/geoinfo.py --tzsplit test.gpx
trying to open test.cache
creating cache file...
successfully created cache file test.cache
2011-07-15 10:44:56: changed to timezone Europe/Berlin at point TP0001 (48.3562, 11.7824983)
2011-07-15 11:16:12: changed to timezone Europe/Vienna at point TP0214 (47.69341, 12.4112216)
2011-07-15 11:16:57: changed to timezone Europe/Berlin at point TP0223 (47.6292366, 12.4970683)
2011-07-15 11:17:02: changed to timezone Europe/Vienna at point TP0224 (47.6220599, 12.5066883)
2011-07-15 11:29:37: changed to timezone Europe/Ljubljana at point TP0375 (46.4886733, 14.0341299)
2011-07-15 11:40:53: changed to timezone Europe/Zagreb at point TP0508 (45.5100666, 15.4250833)
2011-07-15 11:44:20: changed to timezone Europe/Sarajevo at point TP0550 (45.212835, 15.903235)
2011-07-15 12:06:35: changed to timezone Europe/Podgorica at point TP0817 (43.2613483, 18.713)
2011-07-15 12:14:15: changed to timezone Europe/Tirane at point TP0909 (42.5341433, 19.6039482)
2011-07-15 12:22:50: changed to timezone Europe/Skopje at point TP1012 (41.6750566, 20.5334833)
2011-07-15 12:32:00: changed to timezone Europe/Athens at point TP1122 (41.0770683, 21.90922)
2011-07-21 13:42:25: changed to timezone Europe/Berlin at point TP2423 (48.1273616, 11.6058899)
2011-07-21 15:51:52: changed to timezone Europe/Vienna at point TP2714 (47.8108133, 13.0446166)
2011-07-21 19:20:35: changed to timezone Europe/Berlin at point TP3029 (47.8293416, 12.9936516)
2011-07-23 08:50:41: changed to timezone Europe/Lisbon at point TP3298 (37.1830516, -7.4442533)
2011-07-25 10:03:01: changed to timezone Africa/Algiers at point TP4821 (37.1983499, -7.4124866)
2011-07-25 11:09:55: changed to timezone Europe/Madrid at point TP5199 (37.21259, -7.4074833)
2011-07-25 11:29:26: changed to timezone Africa/Algiers at point TP5359 (37.2127533, -7.407545)
2011-07-25 12:40:42: changed to timezone Europe/Lisbon at point TP5629 (37.1976033, -7.4122916)
2011-07-27 07:57:10: changed to timezone Europe/Madrid at point TP6073 (37.2460866, -7.3029866)
2011-07-27 16:45:25: changed to timezone Africa/Algiers at point TP10236 (37.2377933, -7.4191483)
2011-07-24 16:32:20: changed to timezone Europe/Lisbon at point TP10311 (37.1787909, -7.4489332)
2011-07-24 17:00:14: changed to timezone Africa/Algiers at point TP10459 (37.1722284, -7.4486776)
2008-12-31 00:00:02: changed to timezone None at point TP10486 (27.1067377, -146.8005855)
2011-07-28 19:11:03: changed to timezone Europe/Lisbon at point TP10487 (37.1768149, -7.44871)
2011-07-29 08:09:43: changed to timezone Africa/Algiers at point TP11071 (36.9902933, -7.7235216)
2011-07-29 08:15:25: changed to timezone Europe/Madrid at point TP11140 (37.1940716, -6.9935599)
2011-07-29 08:15:35: changed to timezone Africa/Algiers at point TP11142 (37.1993766, -6.9702799)
2011-07-29 08:15:40: changed to timezone Europe/Madrid at point TP11143 (37.2020383, -6.9586033)
2011-07-29 08:15:50: changed to timezone Africa/Algiers at point TP11145 (37.20735, -6.9351916)
2011-07-29 08:15:55: changed to timezone Europe/Madrid at point TP11146 (37.2099299, -6.92344)
2011-07-29 09:12:22: changed to timezone Europe/Paris at point TP11814 (42.9090366, -0.5794216)
2011-07-29 10:00:20: changed to timezone Europe/Zurich at point TP12347 (46.3837283, 6.8016233)
2011-07-29 10:17:50: changed to timezone Europe/Berlin at point TP12557 (47.5463216, 9.5494549)
guessed 1434 points
processing trackpoints for tzname 'Africa/Algiers'
creating test_Africa_Algiers.gpx for timezone Africa/Algiers
processing trackpoints for tzname 'Europe/Lisbon'
creating test_Europe_Lisbon.gpx for timezone Europe/Lisbon
processing trackpoints for tzname 'Europe/Podgorica'
creating test_Europe_Podgorica.gpx for timezone Europe/Podgorica
processing trackpoints for tzname 'Europe/Berlin'
creating test_Europe_Berlin.gpx for timezone Europe/Berlin
processing trackpoints for tzname 'Europe/Skopje'
creating test_Europe_Skopje.gpx for timezone Europe/Skopje
processing trackpoints for tzname 'Europe/Vienna'
creating test_Europe_Vienna.gpx for timezone Europe/Vienna
processing trackpoints for tzname 'Europe/Ljubljana'
creating test_Europe_Ljubljana.gpx for timezone Europe/Ljubljana
processing trackpoints for tzname 'Europe/Tirane'
creating test_Europe_Tirane.gpx for timezone Europe/Tirane
processing trackpoints for tzname 'Europe/Athens'
creating test_Europe_Athens.gpx for timezone Europe/Athens
processing trackpoints for tzname 'None'
processing trackpoints for tzname 'Europe/Paris'
creating test_Europe_Paris.gpx for timezone Europe/Paris
processing trackpoints for tzname 'Europe/Sarajevo'
creating test_Europe_Sarajevo.gpx for timezone Europe/Sarajevo
processing trackpoints for tzname 'Europe/Zagreb'
creating test_Europe_Zagreb.gpx for timezone Europe/Zagreb
processing trackpoints for tzname 'Europe/Madrid'
creating test_Europe_Madrid.gpx for timezone Europe/Madrid
processing trackpoints for tzname 'Europe/Zurich'
creating test_Europe_Zurich.gpx for timezone Europe/Zurich Ich denke es könnte Sinn machen, wenn man die Zeitzonenwechsel in eine Text-Datei schreibt, dort wo die Cache-Datei geschrieben wird.
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11179
Wohnort: München
|
glaskugel schrieb: Gleich zur neuen Version eine kleine Anregung. Wenn man die gpx-Datei mit Pfad angibt, dann sollten die Splits auch den Pfad verwenden.
Ok, darf ich den Pfad weglassen, wenn ein Cachedir gesetzt ist oder soll ich in dem Fall im Cachedir die Unterordnerstruktur anlegen?
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Ok, darf ich den Pfad weglassen, wenn ein Cachedir gesetzt ist oder soll ich in dem Fall im Cachedir die Unterordnerstruktur anlegen?
Ich bin mir nicht sicher, ob ich dich richtig verstehe. Wenn der cache in /bla/blub/test.cache steht, dann sollen auch die splits in /bla/blub/ sein, wenn als gpx-Datei /bla/blub/test.gpx angegeben wurde. Nur kurze Info, So wie es aussieht wird nach Ländern gesplittet und nicht nach Zeitzonen. Das finde ich aber sowieso gut / interessanter. Man muss sich danach nur überlegen wie man die gpx-Files passend zusammenführt. Ich muss das noch näher prüfen, aber ich denke es fehlt was, nämlich die Rückfahrt von Sevilla, die hört an der span. Grenze auf. Im port. Teil ist da nichts mehr vorhanden. Mein File umfasst einen größeren Bereich als den Grenzfluss, ist aber dort ident. Ich bereite dir Screenshots von einem File vor, das Länder von Portugal bis Griechenland enthält. Größtenteils sieht es gut aus, aber bei ein paar Dingen muss ich noch näher schauen.
Könntest du bitte "no entry found" nicht nach stderr ausgeben und unterhalb "minimum timedelta" listen?
Das würde mir zum Testen sehr helfen, wenn du das kurzfristig umsetzt.
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11179
Wohnort: München
|
glaskugel schrieb: Nur kurze Info, So wie es aussieht wird nach Ländern gesplittet und nicht nach Zeitzonen.
Es wird nach Zeitzonen-IDs gesplittet - Europe/Paris und Europe/Berlin sind z.B. eigenständige Zeitzonen-IDs, die heutzutage beide in MEZ/MESZ laufen. Das finde ich aber sowieso gut / interessanter. Man muss sich danach nur überlegen wie man die gpx-Files passend zusammenführt. Ich muss das noch näher prüfen, aber ich denke es fehlt was, nämlich die Rückfahrt von Sevilla, die hört an der span. Grenze auf. Im port. Teil ist da nichts mehr vorhanden. Mein File umfasst einen größeren Bereich als den Grenzfluss, ist aber dort ident.
Falls das in Küstennähe oder in der Umgebung des Río Guadiana war, würde ich mal in die Datei für Africa/Algiers schauen - in bestimmten Gebieten rät tzwhere leider relativ schlecht.
Könntest du bitte "no entry found" nicht nach stderr ausgeben und unterhalb "minimum timedelta" listen?
Das würde mir zum Testen sehr helfen, wenn du das kurzfristig umsetzt.
Ok, das baue ich später noch ein - wenn es schnell gehen soll, kannst du auch stderr auf stdout umleiten:
output=$(./geoinfo -s test.gpx 2>&1)
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Es wird nach Zeitzonen-IDs gesplittet
Ok, ich habe damit brauchbar eine Ländertrennung.
Falls das in Küstennähe oder in der Umgebung des Río Guadiana war, würde ich mal in die Datei für Africa/Algiers schauen
Habe ich schon, da war es auch nicht. Screenshots später. Jetzt lade ich eine Übersicht der Trennungen hoch. Es ist manchmal ziemlich ungenau, aber denke brauchbar. Screenshots auch später.
Ok, das baue ich später noch ein - wenn es schnell gehen soll, kannst du auch stderr auf stdout umleiten:
Klar, so habe ich mir bei einigen Dingen geholfen, müsste bei meinem Script da aber an mehreren Stellen umbauen bzw. wiederholt abfragen. Ich wollte es nur erwähnen, damit es nicht wegen wichtigerer Dinge vergessen wird. Mal schauen, wieviel ich hochladen kann. Es ist stark komprimiert, sollte aber reichen.
- Bilder
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11179
Wohnort: München
|
Die Punkte in https://media-cdn.ubuntu-de.org/forum/attachments/22/38/8519848-2_timezonetest_pt-gr_algier.jpg liegen ja fast alle im Meer - war das eine GPS-Ungenauigkeit oder eine Bootstour? In Anhang ist schon mal das mit dem Pfad für die gesplitteten Dateien und der Ausgabe von "no entry found" auf stdout mit drin.
- geoinfo.tar.xz (5.9 KiB)
- Download geoinfo.tar.xz
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
war das eine GPS-Ungenauigkeit oder eine Bootstour?
Gute Frage, sind nicht meine Fotos, vermute aber eine Ungenauigkeit.
Anhang ist schon mal das mit dem Pfad für die gesplitteten Dateien und der Ausgabe von "no entry found" auf stdout mit drin.
Danke. Du hattest übrigens recht, der Track versteckt sich bei der Sevilla Rückfahrt bei Algier, man muss entsprechend tief zoomen. Problematisch finde ich, dass die Tracks im Ort Ayamonte bei Algier sind. Vgl. https://media-cdn.ubuntu-de.org/forum/attachments/26/38/8519888-4_ungenauigkeit_alg-es.jpg Bei der Sevilla-Rückfahrt wird perfekt in Spanien beendet. Siehe Screenshots. Ich denke, die Grenzungenauigkeiten von ca. 1km bei einer Route kann man vernachlässigen, aber dass Ayamonte total daneben ist, dafür muss man sich einen Workaround überlegen. "alg" im Dateinamen steht für Algier, sollte aber eigetlich klar sein.
- Bilder
|