Sample-Sourcen ?

[lundefugl]

Dein letztes Post habe ich erst jetzt gesene. Ich schaue gleich mal.
Eigentlich wollte ich noch die Erklärung für die andere Änderung machen. Die kommt dann etwas später.

[lundefugl]

Hallo Christian

Deine Änderung bezüglich Flightradar24 sieht sehr gut aus. Die Dateien konnten bei mir problemlos geladen werden.
Wenn man da Änderungen dran macht, dann kommt es als ein CSV raus, was aber mit dem Flightradar24-Format nicht mehr viel zu tun hat. Das ist aber für mich OK, da ich das Flightradar-Format nur einlesen will. Danach geht es bei mir ohnehin im GPX-Format weiter.

Das zuvor von mir beschriebene Problem beim allgemeinen CSV-Format besteht aber immer noch.

Und nun noch die Erklärung zu meiner Anpassung bezüglich des Loggings.
Beim CSV-Format werden nacheinander verschiedene Zeitformatierungen beim Laden ausprobiert.
Sobald ein Format nicht passt, gibt es eine Logausgabe als "SCHWERWIEGEND". Zum einen wird da das Log bei grossen Files in meinen Augen mit geflutet und zum anderen irritiert es, da es ja nur ein Versuch war. Eigentlich liegt ja kein Fehler vor.

Hier mal ein Beispiel (ist im Zip anbei):

Code:

Description,Latitude,Longitude,Altitude,Speed,Time
Nordkap,71.1709797,25.7831594,263.0,10,"2026-01-01T00:01:00"
Westkap,62.1866052,5.1259121,481.0,20,"2026-01-02T00:02:00"
Südkap,57.982407,7.0477149,21.0,30,"2026-01-03T00:03:00"

Obwohl es nur 3 Zeilen im CSV sind, erscheinen bei mir schon zig Meldungen der Art:

Code:

SCHWERWIEGEND: Could not parse '2026-01-02T00:02:00' with format 'dd.MM.yy HH:mm:ss'
Jan. 10, 2026 2:01:25 PM slash.common.type.CompactCalendar parseDate
SCHWERWIEGEND: Could not parse '2026-01-02T00:02:00' with format 'dd.MM.yy HH:mm'
Jan. 10, 2026 2:01:25 PM slash.common.type.CompactCalendar parseDate
SCHWERWIEGEND: Could not parse '2026-01-02T00:02:00' with format 'dd.MM.yy HH:mm:ss'
Jan. 10, 2026 2:01:25 PM slash.common.type.CompactCalendar parseDate
SCHWERWIEGEND: Could not parse '2026-01-02T00:02:00' with format 'dd.MM.yy HH:mm'
Jan. 10, 2026 2:01:25 PM slash.common.type.CompactCalendar parseDate
SCHWERWIEGEND: Could not parse '2026-01-03T00:03:00' with format 'dd.MM.yy HH:mm:ss'
Jan. 10, 2026 2:01:25 PM slash.common.type.CompactCalendar parseDate
SCHWERWIEGEND: Could not parse '2026-01-03T00:03:00' with format 'dd.MM.yy HH:mm'
Jan. 10, 2026 2:01:25 PM slash.common.type.CompactCalendar parseDate
SCHWERWIEGEND: Could not parse '2026-01-03T00:03:00' with format 'dd.MM.yy HH:mm:ss'
Jan. 10, 2026 2:01:25 PM slash.common.type.CompactCalendar parseDate
SCHWERWIEGEND: Could not parse '2026-01-03T00:03:00' with format 'dd.MM.yy HH:mm'
Jan. 10, 2026 2:01:25 PM slash.common.type.CompactCalendar parseDate
SCHWERWIEGEND: Could not parse '2026-01-03T00:03:00' with format 'dd.MM.yy HH:mm:ss'
Jan. 10, 2026 2:01:25 PM slash.common.type.CompactCalendar parseDate
SCHWERWIEGEND: Could not parse '2026-01-03T00:03:00' with format 'dd.MM.yy HH:mm'

Daher wollte ich beim CSV-Format, wo mehrere Formatierungen nacheinander probiert werden, den Loglevel reduzieren.

Gruß
Thomas


  Test-3.zip (Size: 350 bytes / Downloads: 6)

[routeconverter]

In meinen Augen sollte beim Speichern immer in der Spalte gespeichert werden, die zuvor im File bereits drin war. Und damit hat man beim erneuten Laden auch wieder seine zuletzt bearbeiteten Werte.

Ja, das macht total Sinn.

Wenn man da Änderungen dran macht, dann kommt es als ein CSV raus, was aber mit dem Flightradar24-Format nicht mehr viel zu tun hat. Das ist aber für mich OK, da ich das Flightradar-Format nur einlesen will. Danach geht es bei mir ohnehin im GPX-Format weiter.

Wenn mal einliest und speichert, kommt exakt dieselbe Datei heraus. Auch wenn man ändert:

% diff ~/Downloads/flightradar24-samples/a.csv ~/Downloads/flightradar24-samples/flightradar24-sample-DE1246_3c5aa37c.csv
6c6
< 1758628994,2025-09-23T12:03:14Z,CFG7CM,"47.45669,8.553509",0,11,25
---
> 1758715394,2025-09-24T12:03:14Z,CFG7CM,"47.456669,8.553509",0,11,25

Beim CSV-Format werden nacheinander verschiedene Zeitformatierungen beim Laden ausprobiert.
Sobald ein Format nicht passt, gibt es eine Logausgabe als "SCHWERWIEGEND". Zum einen wird da das Log bei grossen Files in meinen Augen mit geflutet und zum anderen irritiert es, da es ja nur ein Versuch war. Eigentlich liegt ja kein Fehler vor.

Habe ich gerade angepaßt.

[lundefugl]

Hallo Christian

Wenn mal einliest und speichert, kommt exakt dieselbe Datei heraus. Auch wenn man ändert:

Du hast absolut recht. Wenn man direkt auf "Speichern" klickt, wird es korrekt geschrieben.
Ich wollte das Originalfile nicht überschreiben und hatte "Speichern als" geklickt. Und dort war dann "CSV Comma" ausgewählt, auf was ich nicht geachtet habe.
Also alles OK. Sorry für die Verunsicherung.

Habe ich gerade angepaßt.

Super. Das ist jetzt auch perfekt mit dem Logging.

Danke & Gruß
Thomas

[lundefugl]

Hallo Christian

ich habe mal die Änderung bezüglich der CSV-Spalten in einen neuen Branch gepackt. Das wäre https://github.com/lundefugl/RouteConver...sv-columns.
Evtl. kannst du mir daran erklären, wo da das bisherige Verhalten kaputt gemacht wird, da ich ja nicht alle Usecase im Detail kenne.

Danke & Gruß
Thomas

[routeconverter]

Hallo Thomas,

das sieht gut und verständlich aus. Stellst Du einen PR?

PS: In https://github.com/cpesch/RouteConverter/pull/94 war das zwischen vielen anderen Änderungen enthalten, daher habe ich die Intention vermutlich nicht verstanden. Vielleicht stellst Du lieber viele kleine PRs?

[lundefugl]

Hallo Christian

der PR ist erstellt. Den anderen PR habe ich geschlossen. Der ist ja inzwischen überholt.

Bezüglich der kleinen PR hast du absolut recht. Und das hätte ich eigentlich auch machen sollen.
Ursprünglich war das Flightradar-Format ja das Ziel. Und dabei sind mir die beiden anderen Dinge (Logging und das hier mit den Spalten) aufgefallen und haben mich behindert. Aber wahrscheinlich muss ich dann lieber einen Sammelbranch bei mir machen und die Teile in einzelnen Branchen und PR.

Mal sehen, ob ich beim nächsten Mal dran denke.
Und wahrscheinlich macht es auch Sinn, wenn ich hier die Intention hinter dem PR erkläre. Im PR selbst geht das ja nicht so leicht. Ich denke, dass da ein Beispiel mit Daten immer verständlicher ist, als der schriftliche Erklärungsversuch.

Gruß
Thomas

[routeconverter]

Ich denke, dass da ein Beispiel mit Daten immer verständlicher ist, als der schriftliche Erklärungsversuch.

Das hat mir sehr geholfen.