glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
passt da eventuell etwas mit den Rechten in /usr/local/bin nicht?
Das könnte es sein, auswendig weiß ich das jetzt nicht genau, aber ich glaube /usr/local/bin ist ein Link auf ein NFS-Verzeichnis des Trusty-PCs mit dem ich normalerweise arbeite. Brauchst du noch irgendwelche Informationen? Durch das NFS-Verzeichnis ist gewährleistet, dass alle Scripts immer aktuell sind.
PS: Wie es aussieht, kann man das WLAN in einem ICE der deutschen Bahn u.a. als GPS-Tracker nutzen
Ich weiß jetzt nicht mehr, ob ich hier über meine Probleme im Zug geschrieben habe. Jedenfalls war die Genauigkeit falsch eingestellt. Ich denke im Zug sollten 100m auch reichen bevor etwas verworfen wird. Ansonsten habe ich zum FIltern kaputter Tracks noch eine andere Überlegung. Es kommt natürlich sehr auf die Situation an. Wenn ich in einer Stadt fotografiere, dann bin ich in der Regel zu Fuß unterwegs, dh mehr als 8km/h kommen da ziemlich sicher nicht vor und dadurch fliegt da sehr viel raus, das ich aber gar nicht brauche. Interessanterweise ist aber bei 8km/h eine Busstrecke noch sehr gut nachvollziehbar. Der haltet ja immer wieder, steht im Stau etc. Hin und wieder sehe ich Geschwindigkeiten, die nicht gefiltert wurden, in der Praxis ist das aber vernachlässigbar. Da ich ja auf der Suche nach einem besseren GPS bin, habe ich zufällig das gefunden:
http://goughlui.com/2014/05/24/quick-review-teardown-garmin-etrex-10-handheld-gps/ "While the GLONASS constellation adds to the number of data sources available for tracking, and may add to reliability, the number of visible GLONASS satellites is normally only about six at most, and viewing four is required to get a good fix on GLONASS alone. The behaviour of the chipset with GPS + GLONASS is not well documented – it is not believed that less than four GLONASS satellites can provide a position with less than four GPS satellites. In essence, I believe the two constellations are used and tracked separately, with the position data being filtered/combined for the result although this is purely a guess."
Ich schau mir jetzt mal den Canmore GT-740FL - http://www.canadagps.com/CanmoreGT-740FL.html an, der ist zwar technisch nicht auf dem neuesten Stand, hat aber kein Bluetooth, das unnötig dauernd Akku saugt bzw. werde testen, wie lange der Akku beim GT-750FL - http://www.canadagps.com/CanmoreGT-750FL.html trotz unnötig aktivem BT hält.
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11180
Wohnort: München
|
glaskugel schrieb: passt da eventuell etwas mit den Rechten in /usr/local/bin nicht?
Das könnte es sein, auswendig weiß ich das jetzt nicht genau, aber ich glaube /usr/local/bin ist ein Link auf ein NFS-Verzeichnis des Trusty-PCs mit dem ich normalerweise arbeite. Brauchst du noch irgendwelche Informationen? Durch das NFS-Verzeichnis ist gewährleistet, dass alle Scripts immer aktuell sind.
Ist da für die Freigabe eventuell squash_root gesetzt?
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
192.168.2.96/27(rw,root_squash,sync,no_subtree_check) Ich frage mich aber sowieso, ob das in diesem Fall klug ist. Der NFS-Server ist (noch) Trusty und wird es wohl noch einige Zeit bleiben (müssen) und der Client ist Xenial, ein PC zum Testen, ob das was unter Trusty funktioniert, auch bei Xenial funktioniert. Wenn da Python was nach /usr/local/bin schreibt, einmal für Trusty und 1x für Xenial mit eventuell unterschiedelichen Pyhtonversionen, dann könnte das problematisch werden. Ich denke da an vielleicht einen weiteren Programmpfad hinzuzufügen (in /etc/environment), wo die NFS-Scripts sind. Was meinst du?
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11180
Wohnort: München
|
glaskugel schrieb: 192.168.2.96/27(rw,root_squash,sync,no_subtree_check)
Dann ist es ziemlich unsinnig als root darauf über NFS zuzugreifen, weil er zu nobody degradiert wird. Ich frage mich aber sowieso, ob das in diesem Fall klug ist. Was meinst du?
Ich würde getrennte Verzeichnisse nehmen. Wenn du z.B. auf zwei Rechnern gleichzeitig eine neue Version herunterladen und nach /usr/local/bin kopieren willst, kannst du z.B. in tmux mit C-b :setw synchronize-panes mehrere SSH-Sitzungen gleichzeitig steuern: https://sanctum.geek.nz/arabesque/sync-tmux-panes/
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Ein deutliches Beispiel im Anhang, wo der kmh-Filter nicht tut was er soll. Kannst du dir das bitte ansehen. Die Geschwindigkeit war auf 140 beschränkt, Eval von 100-1500
- kmhproblem.tar.gz (34.1 KiB)
- Download kmhproblem.tar.gz
- Bilder
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11180
Wohnort: München
|
Laut den Rohdaten sind da drei Punkte drin, die auf den ersten Blick komplette Ausreißer sind (TP0239, TP0240 und TP0241). Da die ersten beiden sehr nahe bei einander liegen, wird nur TP0239 eliminiert, denn die errechnete Geschwindigkeit von TP0240 ist so ca. 86,3 km/h. Außerdem werden TPO241 und TP0242 rausgeworfen, weil die aus dem vorangehenden Wegpunkt errechnete Geschwindigkeit über dem Limit liegt:
Speed at waypoint TP0238 is 79.45 km/h (22.07 m/s), max speed 140.00 km/h (38.89 m/s)
Speed at waypoint TP0239 is 14256.03 km/h (3960.01 m/s), max speed 140.00 km/h (38.89 m/s)
ignoring TP0239, speed above limit: 3960.01 m/s = 14256.03 km/h
Speed at waypoint TP0240 is 86.21 km/h (23.95 m/s), max speed 140.00 km/h (38.89 m/s)
Speed at waypoint TP0241 is 159.77 km/h (44.38 m/s), max speed 140.00 km/h (38.89 m/s)
ignoring TP0241, speed above limit: 44.38 m/s = 159.77 km/h
Speed at waypoint TP0242 is 1912.96 km/h (531.38 m/s), max speed 140.00 km/h (38.89 m/s)
ignoring TP0242, speed above limit: 531.38 m/s = 1912.96 km/h
Speed at waypoint TP0243 is 56.15 km/h (15.60 m/s), max speed 140.00 km/h (38.89 m/s) Entweder dir fällt da ein besserer Algorithmus ein als die Geschwindigkeiten der aufeinander folgenden Punkte mit den vorgegebenen Werten zu vergleichen oder du musst die Rohdaten von Hand aufräumen - was z.B. in Kombination Google Earth (plus OSM-Overlay von http://www.mgmaps.com/kml/) für die Identifikation + Texteditor zum Löschen der Wegpunkte in der GPX-Datei nicht besonders viel Zeit kostet und das Problem tatsächlich löst statt nur zu raten.
- Bilder
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Danke, jetzt verstehe ich das Problem besser. Wie man den Algorithmus optimieren kann, bin ich mir auch nicht sicher. Ich stelle mal zur Überlegung, Script 2x/mehrmals laufen lassen bzw. nach Entfernen der Punkte prüfen, wie hoch die Geschwindigkeit zwischen den gebliebenen Punkten ist, wenn größer als Schwelle dann den 2. Punkt verwerfen. Ich bin mir da nur nicht klar, was da passieren könnte, wennn es sehr viele Punkte gibt, die nicht passen, also vielleicht maximal x mal verwerfen? Der Tunnel ist ein schönes Beispiel wo so was passiert, ist aber in der Praxis nicht sehr relevant, außer man will gleich nach dem Tunnel aus dem fahrenden Auto fotografieren. Ich hatte aber auch schon Beispiele, wo das zu Problemen führte, habe ich dann manuell eleminiert (man muss das nur entdecken, wenn etwas automatisiert gemacht wird). Mein Blumax kommt mit diesem Tunnel übrigens perfekt klar. Siehe Anhang.
- Bilder
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Das Ergebnis von tzsplit bei Ayamonte hat sich geändert. Ob da jemand bei OSM den Thread verfolgt? Siehe Anhang.
- Bilder
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11180
Wohnort: München
|
OSM hat damit nichts zu tun - die einzigen Helfer beim Ermitteln der Zeitzonen-ID wenn tzwhere raten müsste sind Geonames und die Google Maps API.
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Trotzdem interessant, dass sich da was geändert hat und jetzt in der Mitte was fehlt (das mir aber egal ist). Die Filter auf der portugiesischen Seite war 120 km/h, auf der spanischen 8 km/h. Auf der spanischen kann ich mir ja noch vorstellen, dass das Boot schneller als 8km/h war, aber sicher nicht schneller als 120 km/h auf der portugiesischen.
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Habe ein Verständnisproblem mit dem angehängten Track. Warum ist das Gröndland-Zeitzone und nicht Island nach tzsplit?
- Island_America_Godthab.gpx.tar.gz (8.4 KiB)
- Download Island_America_Godthab.gpx.tar.gz
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11180
Wohnort: München
|
Vermutlich weil die Shape-Daten, die tzwhere nutzt, in der Küstenregion nicht mehr so ganz passen und es schlecht rät, wenn es nicht auf geonames oder die Google Maps Zeitzonen-API zugreifen darf. In so einem Fall kannst du (wie schon früher geschrieben) zum Matchen der Bilder mit "-i TZ-ID" die Zeitzone festlegen anstatt sie erraten zu lassen.
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
nicht mehr so ganz passen
Dann hat sich das in den letzten Wochen geändert und das hat mich eben gewundert, ansonsten völlig egal, ob das Foto am Greenzfluss nun Ayamonte oder Vila Real zugeordnert wird. Es ist jetzt ein wenig anders mit der Verteilung auf Portugal und Spanien, aber viel verwirrender ist es, wenn man von Vila Real Ayamonte mit leichtem Tele fotografiert und dann Vila Real vermerkt ist. Das ist eben das grundsätzliche Problem von Fernaufnahmen, das immer der Standort vermerkt ist.
In so einem Fall kannst du (wie schon früher geschrieben) zum Matchen der Bilder mit "-i TZ-ID" die Zeitzone festlegen
Ja, klar, aber die Zeitzone ist ein guter Filter was kaputt ist, Stichwort Algier. Ich hätte aber eine andere Bitte, mein Script merkt nicht bzw. nur schwer, wenn die Credits aus sind. invalid response from geonames elevation api
invalid literal for int() with base 10: 'ERR:19:the hourly limit of 2000 credits for ... has been exceeded. Please throttle your requests or use the commercial service.' Ich sehe das bei den sehr vielen anderen Ausgaben meines Scripts nur zufällig, weil die ganzen Ausgaben ganz schnell vorbei laufen. Könntest du bitte die o.a. 2 Zeilen in stdout als Hinweis ausgeben? Dann kann ich das bei der Abfrage von Ort, etc. prüfen und abbrechen. Wenn es kürzer sein soll, dann reicht auch "the hourly limit of 2000 credits has been exceeded" Ich frage mich gerade, ob das mit meinem Grönland Zeitzonen-Problem zusammenhängt, bei einem anderen Geschwindigkeistsfilter war das nicht so, da waren die Tracks bei Island. Da passiert das bei tuzsplit, in diesem Fall bitte das Script mit deutlicher Fehlermeldung abbrechen. Ich habe das bei tzsplit aber noch nie gesehen.
|
seahawk1986
Anmeldungsdatum: 27. Oktober 2006
Beiträge: 11180
Wohnort: München
|
glaskugel schrieb: Könntest du bitte die o.a. 2 Zeilen in stdout als Hinweis ausgeben? Dann kann ich das bei der Abfrage von Ort, etc. prüfen und abbrechen. Wenn es kürzer sein soll, dann reicht auch "the hourly limit of 2000 credits has been exceeded"
Ok, wenn er in den Fehler läuft, beendet sich das Skript mit der Fehlermeldung auf stdout und stderr. Ich frage mich gerade, ob das mit meinem Grönland Zeitzonen-Problem zusammenhängt, bei einem anderen Geschwindigkeistsfilter war das nicht so, da waren die Tracks bei Island.
Ja, wenn das Skript geonames und die Google Maps Zeitzonen-API nicht fragen kann, versucht tzwhere zu raten.
- geoinfo.tar.xz (8.4 KiB)
- Download geoinfo.tar.xz
|
glaskugel
(Themenstarter)
Anmeldungsdatum: 8. Juli 2010
Beiträge: 3453
|
Ok, wenn er in den Fehler läuft, beendet sich das Skript mit der Fehlermeldung auf stdout und stderr.
Damit es da kein Missverständnis gibt. Bei tzsplit habe ich eine gute Chance, dass ich eine Fehler-Ausgabe in der Konsole sehe. Ich splitte per Script nach Tagen und ganz am Ende gibt es die meisten Abfragen, dh wenn Credits fehlen, sollte ich das am Ende merken. Dazwischen laufen ja die ganzen Ausgaben bzgl. Gescwindigkeit und Höhe. Beim Fotoabgleich sieht es aber anders aus, da wird ein Foto nach dem anderen abgearbeitet und wenn sich da dein Script beendet weil die Credits erreicht sind, macht mein Script ein "Fallback" und gibt "Standard-Koordinaten" des Albums ein, dh ich merk das nicht. gpsinfo=`python3 /usr/local/bin.geoinfpo.py -a "$GOOGLEAPI" -u "$GEONAMESUSER" -g "$GEOCODER" --timedelta "$TIMEDELTA" --override-elevation $ELE_TOL -lde "$gpxfile" "$photo"` Ich bräuchte also in dieser Variable den Hinweis auf "credits for ... has been exceeded", denn dann habe ich ein Kriterium, dass mein Script abbricht, wenn nur dein Script abbricht, dann kann ich nicht genau sagen, was dann passiert, gibt zu viele Varianten, aber ziemlich sicher findet mein Script einen Workaround und bricht nicht ab.
|