Import von nmea-files schlägt fehl

Hallo blackwilli,

Zitat von blackwilli

Dieses schreibt so wunderbare csv:

6.9292|51.4799|8.0|149|6|1|1222713360|0

Die Timestamps sind übrigens im Unixformat und repräsentieren die vergangenen Sekunden seit dem 01.01.1970 00.00 Uhr.

Ich habe dazu gerade recherchiert, weil mir das Format auch bei GPSBabel aufgefallen ist. Dieses Format nennt sich character separted format . Verbrochen hat dieses Format Microsoft in zusammenhang mit der "Streets and Trips" Software. Gibt es irgenwo eine Software, wo MS die Finger mal draussen lassen kann?

http://www.gpsbabel.org/htmldo…lopment/style_intro2.html

Gruss Joern Weber

Zitat von Joern_Weber

Dieses Format nennt sich character separted format . Verbrochen hat dieses Format Microsoft .....

Ah, interessant. Mal sehen wie viele Formate noch wieder ausgegraben werden. Mit den "|" hat z.B. GTA durch die definierbaren Filter keine Probleme, kann meinetwegen auch ein "Ü" sein. Nur mit der TimeSpan-Angabe kann es z.Z. nichts anfangen, da ich dafür nichts in der Filterdefinition vorgesehen hatte. Ist aber kein Problem, das im nächsten Update einzubauen.

Was mir aber langsam fürchterlich auf den Wecker geht, sind diese ignoranten Firm- und Softwareentwickler. Langsam müsste es sich bis in die letzte Ecke herumgesprochen haben, dass es ein Format GPX zum Datenaustausch gibt.

Zitat von blackwilli

Was mir aber langsam fürchterlich auf den Wecker geht, sind diese ignoranten Firm- und Softwareentwickler. Langsam müsste es sich bis in die letzte Ecke herumgesprochen haben, dass es ein Format GPX zum Datenaustausch gibt.

Manche wollen es vielleicht gar nicht wissen, weil sie immer noch denken, dass gerade Sie als zweiter Bill Gates die Super-Applikation erfunden haben.

Das nächste Problem ist, das bei der Festlegung von GPX 1.1 auch Fehler gemacht wurden. Der Speed-Tag wurde schlicht vergessen, obwohl dessen Inhalt von jedem NMEA-Konformen Empfänger geliefert werden kann. Ich denke mal der Autor des GPX-Standards kann einfach nicht die Besonderheit des der Speed-Angabe aus dem VTG-Datensatz, das dieses auf den Doppler-Daten zu beruht und somit nicht ohne Qualitätsverlust durch einen Division von Entfernung und Zeit ersetzt werden kann.

Ich bin selber ja schon froh, das wir es geschafft haben GPX durchzusetzen. Ich kenne noch die Zeit vor diesem Standard und auch die Diskussion um seine Entstehung. Der Break war erreicht, als Garmin PCX5 zu den Akten legte und auch zu GPX wechselte. Seit dem gibt nur noch drei wichtige Format GPX, NMEA183 und CSV. NMEA deswegen, weil an Board aller Schiffe dieser Welt sowiso vorhanden. Und CSV ist ein allgemeingültiger Internet-Standard entsprechend den RFC's für unklassifizierte Daten und kann ausserdem von jeder Tallenkalkulation gelesen werden. Momentan fehlt ab tatsächlich ein einheitliches Binär-Format für die Inhalte der GPS-Logger. Ein komprimiertes Binär-Format ist dort auch Gründen der Speicherökonomie wichtig.

Gruss Joern Weber

Zitat von Joern_Weber

Das nächste Problem ist, das bei der Festlegung von GPX 1.1 auch Fehler gemacht wurden. Der Speed-Tag wurde schlicht vergessen, .....

Wie ich hier schon angemerkt hatte, ....

http://www.naviboard.de/vb/sho…php?p=251877&postcount=20

... sehe ich das nicht ganz so ursächlich. Setze ich den XML-Reader etwas flexibel ein - und dazu muss ich eben auch etwas flexibel denken - kann es mir vollkommen wurscht sein, was da noch so alles drin steht.

Zitat von Joern_Weber

Momentan fehlt ab tatsächlich ein einheitliches Binär-Format für die Inhalte der GPS-Logger. Ein komprimiertes Binär-Format ist dort auch Gründen der Speicherökonomie wichtig.

Und da graust es mir vor. Wie wir aus jahrzehntelanger Erfahrung wissen, werden sich nie wirklich alle zu 100% an ein Format halten. Bei Binärdateien werden Nichtigkeiten, wie ein vergessenes Abschlussbyte oder nur das versehentliche Vertauschen der Reihenfolge zweier Datenfelder, dazu führen, dass die Dateien von niemand anderen mehr gelesen werden können.
Wenn man heute mit ansieht, wie schwierig es zu sein scheint, so ein popeliges (sorry) Format wie GPX, zu schreiben, wird uns ein Binärformat noch viel Spaß bereiten.

Hallo,

Zitat von blackwilli

Und da graust es mir vor. Wie wir aus jahrzehntelanger Erfahrung wissen, werden sich nie wirklich alle zu 100% an ein Format halten. Bei Binärdateien werden Nichtigkeiten, wie ein vergessenes Abschlussbyte oder nur das versehentliche Vertauschen der Reihenfolge zweier Datenfelder, dazu führen, dass die Dateien von niemand anderen mehr gelesen werden können.

Ein Standard bei Binär-Formaten ist eine Frage der Ökonomie. Den Preis eines Logger dessen Daten gemäß ASN.1 strukturiert ist, möchtest Du nicht wissen.

Gruss Joern Weber

Hallo zusammen,

hoppala, wollte keine Grundsatzdiskussion auslösen. Ich habe blackwilli mit dem Format konfrontiert.
Mit dem Timestamp hatte ich keine Probleme. Auch sonst lässt sich alles problemlos nach GTA einlesen. Die Wegpunkte, die über die Typenkennung (0=Streckenpunkt, 1=Wegpunkt) gekennzeichnet werden mache ich dann weiter von Hand. Ich dachte nur, dass ich etwas übersehen hätte, was mir die Handarbeit erspart.
Für andere Leser noch technische Details:
Nokia 6233 mit GPS Maus, Freeware trackspace (trackspace.de), Weiterverarbeitung der Daten am PC;
Openstreetmap liefert die Möglichkeit zumindest eine Strassenkarte zu hinterlegen

Soweit für für diesmal

dagehtslang

Hallo,

Zitat von dagehtslang

Hallo zusammen,
hoppala, wollte keine Grundsatzdiskussion auslösen.

keine Sorge, wir diskutieren hier konstruktiv. Was heute Dein Problem ist, ist morgen vielleicht das Problem von anderen.

Ich habe blackwilli mit dem Format konfrontiert.

Zitat

Mit dem Timestamp hatte ich keine Probleme. Auch sonst lässt sich alles problemlos nach GTA einlesen. Die Wegpunkte, die über die Typenkennung (0=Streckenpunkt, 1=Wegpunkt) gekennzeichnet werden mache ich dann weiter von Hand. Ich dachte nur, dass ich etwas übersehen hätte, was mir die Handarbeit erspart.

Wenn ich es richtig verstehen möchtest Du die Wegpunkte von Trackpunkten maschinell Trennen. Das kann man in 10 Minuten mit Excel realisieren. Lese die Date dort im csv-Format ein, setze ein AutoFilter, lösche die nicht gewünschten Daten und speicher die Datei wieder. Das Trennzeichen solltest Du natürlich beim Einlesen korrekt angeben.

Gruss Joern Weber

Zitat von dagehtslang

hoppala, wollte keine Grundsatzdiskussion auslösen. Ich habe blackwilli mit dem Format konfrontiert.
....
Die Wegpunkte, die über die Typenkennung (0=Streckenpunkt, 1=Wegpunkt) gekennzeichnet werden mache ich dann weiter von Hand. Ich dachte nur, dass ich etwas übersehen hätte, was mir die Handarbeit erspart.

Zitat von Joern_Weber

keine Sorge, wir diskutieren hier konstruktiv. Was heute Dein Problem ist, ist morgen vielleicht das Problem von anderen.

So ist das. GTA ist ja auch im ständigen Ausbau und die definierbaren Import-Filter sind erstmalig implementiert. Ich kann und will auf der einen Seite natürlich nicht ständig die Aufräumarbeit für andere Entwickler machen ;), aber einige neue Features werden die Filterdefinitionen bestimmt noch bekommen.
Du kannst mir ja noch mal eine aussagekräftige Datei mit einfachen Tracks und Wegpunkten schicken. Dann baue ich das im Winter mit ein.

Hallo Blackwilli,

Zitat von blackwilli

Du kannst mir ja noch mal eine aussagekräftige Datei mit einfachen Tracks und Wegpunkten schicken. Dann baue ich das im Winter mit ein.

Welche Daten benötigst Du genau? Unser User "dagehtslang" bezieht sich auf die Dateien im CSV-Format. Diese enthalten häufig Attribute zu den jeweiligen Positionsangaben. Oft sind das der RCR (Reason Code for Receive). Im RCR wird von den GPS-Loggern vermerkt, warum die Position aufgezeichnet wurde. Die Gründe sind zum Beispiel, das eine konfigurierte Distanz oder Zeiddauer zurück gelegt wurde oder ein Taste gedrückt wurde ode eine Software den Wegpunkt veranlasst hat. Letzteres ist bei Foto-Software häufig anzutreffen. Weiter hin ist in den CSV-Daten auch ein Flag zu finden, das angibt ob die Position mit einem 2D, 3D oder ohne gültigen Fix aufgezeichnet wurde. Damit du nicht den Pfusch von Soft- und Hardware Herstellern nacharebiten musst, würde ich dir einen smarteren Import-Filter für CSV-Dateien empfehlen. Das heißt, das der Import-Filter nur Datensätze passieren lässt, welche eine frei vom User konfiguriebare Bedingung bezüglich Feldinhalt erfüllen. Biete dem User einfach beim Import folgende Dinge an:

1. Frei wählbares Trennzeichen (aus dem konstanten Trennzeichen "Komma" einfach eine Variable machen)
2. Freie Definierbarkeit, welches Feld(er) des CSV-Datensatzes für Position, Höhe usw. verwendet werden sollen.
3. Freie Definierbarkeit eines User-definierten Wertes und eines dazugehörigen Datenfeld, welche bei einem Vergleich entscheiden ob der komplette Datensatz importiert wird oder nicht.

If <Feld3> = 1 then gosub Import

Damit kannst Du die Masse der Sonderfälle erschlagen und musst nich herstellerspezifische Dinge einbauen.

Den NMEA-Importfilter solltest Du meiner Ansicht nach grundsätzlich nur Standard-Konform erweitern. Wenn ein Hersteller dabei Murks baut, so ist das sein Problem. Allerdings, ist hier zu überlegen, ob man die theoretisch gegeben Möglichkeit, die vom Empfänger verwendete Höhenkorrektur-Matrix, auszutauschen, implementiert.

Den GPX-Import-Filter würde ich dir empfehlen zu einem XML-Importfilter zu erweitern. Die Hersteller können nichts dafür, das der GPX-Standard 1.1 den Speed-Tag vergessen hat oder nicht die Milisekunden beücksichtigt. Ähnlich dem dem CSV-Filter könnte man hier auch eine Zuordnung definieren, welcher XML-Tag für welchen Wert (Position, Höhe usw.) verwendet werden soll.

Gruss Joern Weber

Guten Morgen zusammen,

die Spalte "Type" schein so eine Art RCR (Reason Code for Receive) zu sein.
Eine Aufzeichnung als Wegpunkt muss ich manuell durchführen (zB an einer Kreuzung, wenn ich ein Photo mache oder so ...).
Ich hänge mal eine originale Datei an als *.zip, das Original nennt sich *.tsf.

Besten Dank für Eure Meinungen zu dem Thema und Grüße

Martin

Hallo,

Zitat von dagehtslang

die Spalte "Type" schein so eine Art RCR (Reason Code for Receive) zu sein.

Es scheint nicht nur so, es ist der Reason-Code des MTK-Logger-Chip EB230.

Zitat

Ich hänge mal eine originale Datei an als *.zip, das Original nennt sich *.tsf.

Das ist eine Datei in Caracter Separted Format. Das Zeichen "|" ist der Delimiter. Ich verwende zur Auswertung dieser Daten Excel oder scalc (OpenOffice) da bisher kaum ein Programm die Möglichkeiten der der MTK-Logs nutzen kann.

Ich kann dir noch http://www.apemap.de fürs Handy empfehlen. Das kann neben OpenStreetMaps auch Rasterkarten des Kompass-Verlages und mit TTQV lesbare Karten darstellen.

Gruss Joern Weber

Hallo Joern,

Zitat von Joern_Weber

Unser User "dagehtslang" bezieht sich auf die Dateien im CSV-Format.

Genau diese CSV. Verwende ich dann zum Testen, wenn ich die Filterdefinitionen ausbaue.

Zitat von Joern_Weber

Damit du nicht den Pfusch von Soft- und Hardware Herstellern nacharebiten musst, würde ich dir einen smarteren Import-Filter für CSV-Dateien empfehlen. Das heißt, das der Import-Filter nur Datensätze passieren lässt, welche eine frei vom User konfiguriebare Bedingung bezüglich Feldinhalt erfüllen. Biete dem User einfach beim Import folgende Dinge an:

............

Ist doch alles schon vorhanden, Joern. Schau mal da drauf:

http://www.gps-freeware.de/Images/D2Importfilter.jpg

Auch die Möglichkeit des Verwerfens einzelner Datensätze und Daten ist während des Imports gegeben. Flexibler geht es eigentlich nicht mehr. Allerdings ist so etwas immer ausbaubedürftig. Siehe die Typkennzeichnungen bei dagehtslang.

Zitat von Joern_Weber

Den NMEA-Importfilter solltest Du meiner Ansicht nach grundsätzlich nur Standard-Konform erweitern. Wenn ein Hersteller dabei Murks baut, so ist das sein Problem. Allerdings, ist hier zu überlegen, ob man die theoretisch gegeben Möglichkeit, die vom Empfänger verwendete Höhenkorrektur-Matrix, auszutauschen, implementiert.

Auch der läuft über die vorgenannten Filterdefinitionen und kann vom User eingestellt werden, wie er es braucht. Der zweite Punkt ist bereits angedacht.

Zitat von Joern_Weber

Den GPX-Import-Filter würde ich dir empfehlen zu einem XML-Importfilter zu erweitern.

Ist bereits ein XML-Reader. So habe ich die Möglichkeit, alle relevanten Felder frei zu definieren. Ich habe mich beim Einlesen nie fest an die Namespace-Uri gebunden.
Allerdings musst Du auch dabei ganz bestimmte Verknüpfungen beachten, z.B. ist es wichtig zu prüfen, ob die Schachtelungen der Nodes, die durch die Tags repräsentiert werden, korrekt sind und die Parent-Nodes richtig beschrieben sind. Ok, ich hör schon auf ....
Kurzum, aus diesen Gründen will ich für die GPX keine freien Definitionsmöglichkeiten wie in den Import-Filtern stellen. Mindestens 99% der User wären damit überfordert, oder anders gesagt, sie müssten sich intensiv mit diesem Format beschäftigen und deren Möglichkeiten und Varianten vollkommen beherrschen. Das wäre nicht der Sinn der Sache.
Ausserdem hat GTA prinzipiell keine Probleme mit GPX, es sei denn jemand hat unzulässige Werte in einen Tag geschrieben. das ist dann aber nicht mein Problem.

Zitat von Joern_Weber

Das ist eine Datei in Caracter Separted Format. Das Zeichen "|" ist der Delimiter. ..... da bisher kaum ein Programm die Möglichkeiten der der MTK-Logs nutzen kann.

Mit dem Delimeter hat GTA keine Probs (siehe Beitrag zuvor). Was ich jetzt noch einbauen muss, ist die Interpretation der Unix-TimeSpan-Angabe anstelle eines TimeStamps und die Typedefinition.

Zitat von blackwilli

Ist doch alles schon vorhanden, Joern. Schau mal da drauf:

http://www.gps-freeware.de/Images/D2Importfilter.jpg

Auch die Möglichkeit des Verwerfens einzelner Datensätze und Daten ist während des Imports gegeben. Flexibler geht es eigentlich nicht mehr. Allerdings ist so etwas immer ausbaubedürftig. Siehe die Typkennzeichnungen bei dagehtslang.

Die Version hat aber vermutlich dein Labor noch nicht verlassen, dann ich finde den Menüpunkt in GTA nicht. Aber schön, das du hier einen Screenshoth zeigst. Ich sehe gerade das noch eine Checkbox fehlt, mit der man die unixide Zeilenschaltung auswählen kann.

Zitat

Ist bereits ein XML-Reader. So habe ich die Möglichkeit, alle relevanten Felder frei zu definieren. Ich habe mich beim Einlesen nie fest an die Namespace-Uri gebunden.

Du scheinst dein Handwerk zu verstehen.

Zitat

Allerdings musst Du auch dabei ganz bestimmte Verknüpfungen beachten, z.B. ist es wichtig zu prüfen, ob die Schachtelungen der Nodes, die durch die Tags repräsentiert werden, korrekt sind und die Parent-Nodes richtig beschrieben sind. Ok, ich hör schon auf ....

Nö musst Du nicht, ich kann die folgen. Rechne damit, das die Tags mitunter nicht nur unterhalb der extensions-Node liegen, sondern sich direkt unterhalb der Trackpunkt-, Wegpunkt- oder Routenpunkt-Node befinden. Du benötigts als eine checkbox, mit der man dem XML-Import-Filter sagen, kann ob er das Feld unterhalb der Trackpunkt-, Wegpunkt- oder Routenpunkt-Nodes suchchen soll oder er es aus dem extensions-Abschnitt holen soll. Die Open und Close Statements sollten selbstverständlich korrekt geschachtel und gepaart sein. Wer das als Software- oder Hardware-Hersteller nicht hinbringt hat Pech gehabt. XML ist nunmal die Mutter aller Beschreibungssprachen.

Zitat

Kurzum, aus diesen Gründen will ich für die GPX keine freien Definitionsmöglichkeiten wie in den Import-Filtern stellen. Mindestens 99% der User wären damit überfordert, oder anders gesagt, sie müssten sich intensiv mit diesem Format beschäftigen und deren Möglichkeiten und Varianten vollkommen beherrschen.

Für überforderte User gibt es Standard-Einstellungen oder Templates. Ein starrer XML Filter wird in der Zukunft hinderlich werden. Gegenüber dem CSV-Filter bräuchtest du lediglich eine Checkbox zusätzlich, die entscheidet, ob der Tag aus der Parent-Section des jeweiligen Objects oder aus seiner extension section zu ziehen ist. Wenn du die Checkbox unbedingt nicht haben möchtest, dann durchsuchst Du sowohl Parent- und
extension Section nach dem gewünschten Tag.

Zitat

Ausserdem hat GTA prinzipiell keine Probleme mit GPX,

GPX beinhalte schon Probleme in sich. Siehe Speed-Tag. Man kann es in die extension section packen, dann darf es belibiegen Inhalt haben und nur vom Ersteller verwendet werden. Man kann den Speed-Tag auch in die Parent secetion eines Weg- oder Trackpunktes schreiben. Dann muss der Tag aber ordenlich formatiert sein.

Zitat

es sei denn jemand hat unzulässige Werte in einen Tag geschrieben. das ist dann aber nicht mein Problem.

Definiere unzulässig. Eine höhere Präzision als im Standard vorgesehen ist IMHO nicht unzulässig. Wenn Du irgendwo neue Variablem oder Kostanten anlegst, dann mache das gleich so, das sie Zentimeter und Millisekunden aufnehmen können. Das wird dir zukünftig Arbeit ersparren.

btw. Die unixide Zeilenschaltung kann auch in XML-Dateien vorkommen.

Gruss Joern Weber

Zitat von Joern_Weber

Die Version hat aber vermutlich dein Labor noch nicht verlassen, dann ich finde den Menüpunkt in GTA nicht.

Oh doch. Ist seit August online.
Einen Menüpunkt gibt es nicht.
Klick mal auf das GPS V in der Symbolleiste.
Oder lese die Hilfe.

Zitat von Joern_Weber

Nö musst Du nicht, .... Du benötigts als eine checkbox, mit der man dem XML-Import-Filter sagen, kann ob er das Feld unterhalb der Trackpunkt-, Wegpunkt- oder Routenpunkt-Nodes suchchen soll oder er es aus dem extensions-Abschnitt holen soll.

Das ist meiner Procedur grundsätzlich egal, ob ein Tag innerhalb der Extensions steht oder nicht. Zwischen trkpt, rtept und wpt wird mittels Optionen bzw. unterschiedlicher Importroutinen unterschieden.

Zitat von Joern_Weber

Für überforderte User gibt es Standard-Einstellungen oder Templates. Ein starrer XML Filter wird in der Zukunft hinderlich werden.

Ja, das sehe ich grundsätzlich auch so. Aber auch, dass es mit zunehmenden Möglichkeiten immer schwieriger für die User wird, dies zu differnzieren. Nicht jeder will sich da vertiefen, sondern einfach seine Track auswerten lassen. Das lasse ich auf mich zukommen.

Zitat von Joern_Weber

GPX beinhalte schon Probleme in sich. Siehe Speed-Tag.

Das lese ich gar nicht erst ein und werde ich auch nicht einlesen. Um vernünftig auswerten zu können, brauche ich verifizierbare Werte und die habe ich nur, wenn ich sie selbst berechne.

Zitat von Joern_Weber

Definiere unzulässig. Eine höhere Präzision als im Standard vorgesehen ist IMHO nicht unzulässig.

Kein Problem. Damit meine ich die Darstellungsform von Werten innerhalb von Tags, wie z.B. eine Koordinate in Exponentialangabe 1234546-e5. Jaaa, schon gesehen.

Zitat von Joern_Weber

Wenn Du irgendwo neue Variablem oder Kostanten anlegst, dann mache das gleich so, das sie Zentimeter und Millisekunden aufnehmen können. Das wird dir zukünftig Arbeit ersparren.

Ist ja in Planung.

Zitat von blackwilli

Oh doch. Ist seit August online.
Einen Menüpunkt gibt es nicht.
Klick mal auf das GPS V in der Symbolleiste.
Oder lese die Hilfe.

Das brachte mir überhaupt nichts. Ich Depp hatte noch die alte Version auf dem Desktop verlinkt...

Ich habe jetzt mit der aktuelle Version versucht, einige meiner CSV-Dateien einzulesen:

Der erste Versuch scheiterte, da GTA die Header-Zeile nicht überlesen kann. Deshalb folgende Idee:

1. GTA sollte erst aber einer vordefinierbaren Zeile beginnen die datensätze zu lesen, denn viele CSV-Dateien haben einen header.
2. GTA sollte alle zeilen mit einer vordefinierbare Zeichenfolge am Zeilenbeginn ignorieren können. Dami kann man dann Kommentarzeilen übergehen. Nicht selten beginnen diese mit Semikolon oder Raute.

Der nächste Versuch meine Dateien einzuelesen scheitert am Datum-Zeitformat. Das schaut zum Beispiel so aus:

,2008/08/24 18:28:37.800,

Eine dafür passende Datums Definition müsste dann so aussehen:

yyyy/mm/dd

Leider importiert GTA damit das Datum nicht. Analog schaut es mit der Uhrzeit aus. Vermutlich funktioniert es deshalb nicht, weil GTA nicht belibige Zeichen an einer festen Position ignorieren kann. Mein Vorschlag dazu, führe ein Joker-Zeichen ein, welches belibiege Zeichen an fester Position ignoriert. Dann sehe die Definiton für obiges feld so aus:

Datum:
yyyy/mm/dd ??:?ß:??.???

Uhrzeit:

??/??/?? hh:mm:ss.???

Eine Testdatei zu diesem Datums- und Zeitformat anbei.

btw. Die Wegpunkte aus den CSV-Dateien lassen sich mit dem Kennungs-Mechnismus platt machen. Wenn RCR-Fled als Kennungsfeld setze und als Kennung "T" verwende bleiben die Wegpunkte aussen vor.

Warum du den Speed-Wert aus den Tracks nicht verwenden willst ist mir unklar. Dieser ist wesentlich genauer, als du Ihn berechnen könntest, da er auf den Dopplerdaten beruht. Die Phasenverschiebung wird im Gegensatz zu den Codedaten kontinurlich kumuliert und daraus der Mittelwert der geschwindigkeit zwischen zwei Wegpunkten errechnet. Das ist ein Information die der GPS-Empfänger auch intern für Static Navigation und ähnliches verwendet, so das die hersteller sich um Genauigkeit bei diesem Wert bemühen. Die Höhe des Quotienten aus dem vom Empfänger ermittelten Wert und dem aus der Entfernung zweier Trackpunkte berechneten Wert, ist übrigens ein Maß dafür ob der gewählte Trackpunkt abstand passt oder auch nicht passt. Um so kleiner dieser Wert, um so geringer der durch die Quantifizierung der Strecken entstanden Fehler in der Entfernungsberechnung.

Gruss Joern Weber

Zitat von Joern_Weber

Der erste Versuch scheiterte, da GTA die Header-Zeile nicht überlesen kann. Deshalb folgende Idee:
.......

Daran scheitert aber nicht das Einlesen der Datei. Entweder auf "Diesen Datensatz verwerfen" oder gleich auf "Alle folgenden, fehlerbehafteten Datensätze verwerfen" klicken.

Oft beginnen Header- oder Kommentarzeilen in einer Datei aber nicht mit gleichen Zeichen. Du hast auf der anderen Seite die Möglichkeit, eine Zeilenkennung für Datenzeilen anzugeben, wie bei nmea.

Zitat von Joern_Weber

Der nächste Versuch meine Dateien einzuelesen scheitert am Datum-Zeitformat. Das schaut zum Beispiel so aus:

,2008/08/24 18:28:37.800,
......

Ach ja, immer diese User, die keine Hilfen lesen möchten. :p
Datum und Zeit stehen hier in einem Datenfeld und dieses muss natürlich jeweils komplett definiert werden:

Datum: yyyy/mm/dd xx:xx:xx.xxx

Uhrzeit: xxxx/xx/xx hh:mm:ss.xxx (Millisekunden kommen bald)

Zitat von Joern_Weber

Warum du den Speed-Wert aus den Tracks nicht verwenden willst ist mir unklar. Dieser ist wesentlich genauer, als du Ihn berechnen könntest, da er auf den Dopplerdaten beruht. ......

Das weiß ich alles, Joern. Aber was manche User so alles gern haben möchten, ist so nicht wirklich im überschaubaren Rahmen möglich:

Erstmal sollen alle bereits vorhandenen Werte übernommen werden (z.B. Speed). Dann sollen alle Werte editierbar sein und natürlich autom. korrigierbar. Wobei natürlich Originalwerte, die von korrigierbaren abhängen, nicht verfälscht werden dürfen. Merkst Du was? Genau! Entweder ich will mit den Werten arbeiten, d.h. editieren, korrigieren, glätten, rauslöschen etc., oder ich kann sie einlesen und basta. Beides geht nicht, da eine Verifizierung der Daten untereinander unmöglich wäre.

Zitat von blackwilli

Daran scheitert aber nicht das Einlesen der Datei. Entweder auf "Diesen Datensatz verwerfen" oder gleich auf "Alle folgenden, fehlerbehafteten Datensätze verwerfen" klicken.

Oft beginnen Header- oder Kommentarzeilen in einer Datei aber nicht mit gleichen Zeichen. Du hast auf der anderen Seite die Möglichkeit, eine Zeilenkennung für Datenzeilen anzugeben, wie bei nmea.

Ok, das habe ich im Fall der csv-Datei auch getan. Hilft aber nicht, wenn die ersten paar Zeilen eine irreguläre Beschreibung der Felder enthalten.

Zitat

Ach ja, immer diese User, die keine Hilfen lesen möchten. :p

Das Lesen der Hilfe nützt nichts, wenn das Programm einen Bug hat. :p

Zitat

Datum und Zeit stehen hier in einem Datenfeld und dieses muss natürlich jeweils komplett definiert werden:

Datum: yyyy/mm/dd xx:xx:xx.xxx

Uhrzeit: xxxx/xx/xx hh:mm:ss.xxx (Millisekunden kommen bald)

Genau das habe ich auch so versucht.
Der von dir beschriebene Datums-Ausdruck matcht nicht und wird beim Testen des Filters als fehlerhaft erkannt. Der von dir beschriebene Ausdruck für die Zeit führt beim zum sofortigen Ausstieg des Filters beim testen. Kannst Du dir bitte dazu mal den folgenden csv-Content anschauen.

Content:

INDEX,RCR,TIME,VALID,LATITUDE,N/S,LONGITUDE,E/W,HEIGHT,SPEED,HEADING,DSTA,DAGE,PDOP,HDOP,VDOP,NSAT (USED/VIEW),SAT INFO (SID-ELE-AZI-SNR),DISTANCE,SEPARATOR
5,B,2008/08/24 18:28:50.200,1,50.892160,N,11.611599,E,242.139 M,0.337 km/h,323.521240,0,0.000000,4.54,3.05,3.36,5(10),#29-29-87-18;#25-13-328-18;#21-75-134-23;18-21-141-00;#24-40-58-22;07-01-343-00;#16-67-280-18;03-21-278-00;30-03-143-00;10-10-29-00,1.31 M,L
6,T,2008/08/24 18:28:55.200,1,50.892156,N,11.611598,E,242.524 M,0.450 km/h,323.521240,0,0.000000,4.54,3.05,3.36,5(12),#29-29-87-19;#25-13-328-16;#21-75-133-26;30-03-143-00;#24-40-58-17;10-10-29-00;07-01-343-00;#16-67-280-14;03-21-278-00;31-17-215-00;06-36-277-00;18-21-141-00,0.59 M,
7,T,2008/08/24 18:28:55.400,1,50.892156,N,11.611598,E,242.539 M,0.502 km/h,323.521240,0,0.000000,4.54,3.05,3.36,5(12),#29-29-87-19;#25-13-328-16;#21-75-133-26;30-03-143-00;#24-40-58-17;10-10-29-00;07-01-343-00;#16-67-280-14;03-21-278-00;31-17-215-00;06-36-277-00;18-21-141-00,0.03 M,
8,T,2008/08/24 18:28:55.600,1,50.892156,N,11.611599,E,242.555 M,0.529 km/h,323.521240,0,0.000000,4.54,3.05,3.36,5(12),#29-29-87-19;#25-13-328-16;#21-75-133-26;30-03-143-00;#24-40-58-17;10-10-29-00;07-01-343-00;#16-67-280-14;03-21-278-00;31-17-215-00;06-36-277-00;18-21-141-00,0.03 M,
9,T,2008/08/24 18:28:55.800,1,50.892155,N,11.611599,E,242.570 M,0.524 km/h,323.521240,0,0.000000,4.54,3.05,3.36,5(12),#29-29-87-19;#25-13-328-16;#21-75-133-26;30-03-143-00;#24-40-58-17;10-10-29-00;07-01-343-00;#16-67-280-14;03-21-278-00;31-17-215-00;06-36-277-00;18-21-141-00,0.03 M,
10,T,2008/08/24 18:28:56.000,1,50.892155,N,11.611599,E,242.586 M,0.534 km/h,323.521240,0,0.000000,4.54,3.05,3.36,5(12),#29-29-87-18;#25-13-328-16;#21-75-133-26;30-03-143-00;#24-40-58-17;10-10-29-00;07-01-343-00;#16-67-280-14;03-21-278-00;31-17-215-00;06-36-277-00;18-21-141-00,0.03 M,
11,T,2008/08/24 18:28:56.200,1,50.892155,N,11.611599,E,242.601 M,0.520 km/h,323.521240,0,0.000000,2.03,1.79,0.96,5(12),#29-29-87-18;#25-13-328-16;#21-75-133-25;30-03-143-00;#24-40-58-17;10-10-29-00;07-01-343-00;#16-67-280-14;03-21-278-00;31-17-215-00;06-36-277-00;18-21-141-00,0.03 M,

Filter:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <creator>GPS-Track-Analyse.NET 4.6.2.1</creator>
  <!--Diese Konfigurationen werden automatisch von GPS-Track-Analyse.NET erstellt-->
  <!--Jede manuelle Änderung kann dazu führen, dass die Anwendung nicht mehr ausgeführt werden kann-->
  <UserFilter>
    <FilterSection id="0">
      <Filter name="Comma Separated Format" ext="*.csv;*.tk" nmea="False" />
      <Datei Auszug="47.5760579,13.0240560,1802.1&#xD;&#xA;47.5760365,13.0240345,1796.8" />
      <Trennzeichen Anzahl="9" Feld="," Dezimal="." />
      <Kennung chb="False" Feld="2" />
      <Datum chb="False" Kennung="T" Feld="3" Format="yyyy/mm/dd xx:xx:xx.xxx" />
      <Uhrzeit chb="True" Kennung="T" Feld="3" Format="xxxx/xx/xx hh:mm:ss.xxx" UTC="True" />
      <BreiteHemis chb="True" Kennung="T" Feld="6" Format="NS" />
      <Breite chb="True" Kennung="T" Feld="5" Format="dd.dddddd" />
      <LaengeHemis chb="True" Kennung="T" Feld="8" Format="EW" />
      <Laenge chb="True" Kennung="T" Feld="7" Format="dd.dddddd" />
      <Hoehe chb="True" Kennung="T" Feld="9" Format="0.000" Einheit="0" />
      <Kurs chb="True" Kennung="T" Feld="11" Format="#" />
      <Herzfrequenz chb="False" Kennung="" Feld="" Format="" />
      <Trittfrequenz chb="False" Kennung="" Feld="" Format="" />
      <Temperatur chb="False" Kennung="" Feld="" Format="" />
    </FilterSection>
  </UserFilter>
</configuration>

Zitat

Beides geht nicht, da eine Verifizierung der Daten untereinander unmöglich wäre.

Beides gleichzeitig geht in der Tat nicht, eine alternierende Nutzbarkeit wäre aber auch eine Lösung. Ob dir Höhe des Aufwandes dafür gerechtfertigt ist, musst Du zum Glück entscheiden.;)

Zitat von Joern_Weber

Das Lesen der Hilfe nützt nichts, wenn das Programm einen Bug hat. :p

Wir sollten jetzt lieber nicht darüber diskutieren, wo der Bug sitzt ......
Geht doch einwandfrei, passender Filter zu Deiner Testdatei unten zum Download.

Mal ganz im Ernst, bis auf die tollen Timestamps im Unix-Timespan-Format, hatte ich bisher nicht eine einzige Anfrage zu einem csv-Importproblem, welches nicht mit der Filterdefinition gelöst werden konnte.

Zitat von Joern_Weber

Beides gleichzeitig geht in der Tat nicht, eine alternierende Nutzbarkeit wäre aber auch eine Lösung. Ob dir Höhe des Aufwandes dafür gerechtfertigt ist, musst Du zum Glück entscheiden.;)

Das lohnt den Aufwand bei weitem nicht. User, die mit GTA arbeiten, wollen in der Regel ihre Tracks auch in irgend einer Form bearbeiten. Und bei den kleinsten Anpassungen, fängt beim Löschen eines TP an, müssen die umgebenden Werte neu berechnet werden. Und schon hast Du zumindest gemischte Werte, die die gesamten Trackdaten inkonsistent werden lassen.

Zitat von blackwilli

Wir sollten jetzt lieber nicht darüber diskutieren, wo der Bug sitzt ......
Geht doch einwandfrei, passender Filter zu Deiner Testdatei unten zum Download.

Mag sein das der Bug vor dem Bildschirm sitzt. Dann seih bitte so freundlich und nehme mir das Brett vor dem Kopf weg. Wenn ich deinen Config-Datei und das oben genannte Beispiel verwende erhalte ich diese beiden Fehlermeldungen:

http://www.naviboard.de/vb/att…d=5072&stc=1&d=1225708393
http://www.naviboard.de/vb/att…d=5073&stc=1&d=1225708684

Ich verwende die Version 4.6.2.1. Es ändert sich auch nichts, wenn ich das Einlesen auf den Kenner "T" im 2. Feld, also die Trackpunkte beschränke.

Zitat

Mal ganz im Ernst, bis auf die tollen Timestamps im Unix-Timespan-Format, hatte ich bisher nicht eine einzige Anfrage zu einem csv-Importproblem, welches nicht mit der Filterdefinition gelöst werden konnte.

Das möchte ich dir ja gerne glauben...

Gruss Joern Weber