Verständnisfrage: Wintec WBT-202 .tes Format einlesen, Wegpunkte

[routeconverter]

Probiere mal mit Deinen Testdateien auf welche Headergröße man runtergehen kann, ohne dass das Format zu gierig wird.

48 Bytes funktionierte ganz prima, so daß nur Dateien mit weniger als 3 Positionen nicht erkannt werden. Akzeptabel, oder?

[routeconverter]

Braucht ihr irgendwelche spezifischen Originaldateien im .tes Format zum Testen?

Das Problem hat Malte schon beschrieben: das Format darf nicht zu gierig werden. Insofern brauche ich eher Dateien, die nicht .tes sind aber als solches erkannt werden.

Übrigens erkennt die gerade hochgeladene Version .tes Dateien sofern sie mindestens 3 Positonen enthalten.

[cholertinu]

Das Problem hat Malte schon beschrieben: das Format darf nicht zu gierig werden.

Hmmm.... was versteht ihr unter "zu gierig werden"? Diese Ausdrucksweise ist mir nicht geläufig... Ist das ein R.C.-interner Entwickler-Slang?

Zur Info: Mit der aktuellen Snapshot-Version 1.34-SNAPSHOT-1.229 vom 29. Mai 2010 konnte ich den 36-Punkte-Track als .tes File öffnen.

Frage zum Öffnen: Warum werden trotzdem alle Formate "durchprobiert" (durchblättern oben rechts bei "Format: xxxx" ) auch wenn das Format aufgrund der Dateiendung bereits Rückschluss auf das Wintec WBT-202 .tes Format liefern würde? Weshalb werden da erst noch TomTom etc. probiert, welche ja eine ganz andere Dateiendung haben?

[routeconverter]

Das Problem hat Malte schon beschrieben: das Format darf nicht zu gierig werden.

Hmmm.... was versteht ihr unter "zu gierig werden"? Diese Ausdrucksweise ist mir nicht geläufig... Ist das ein R.C.-interner Entwickler-Slang?

Jein, der Hintergrund ist, daß RouteConverter ohne Zutun des Benutzers das Dateiformat erkennen und die Datei einlesen soll. D.h. alle Formate kommen an die Reihe und dürfen mal versuchen, die Daten zu lesen. Zu "Gierige" Formate interpretieren auch Daten, die sie gar nicht verstehen können, und liefern dann Müll zurück.

Frage zum Öffnen: Warum werden trotzdem alle Formate "durchprobiert" (durchblättern oben rechts bei "Format: xxxx" ) auch wenn das Format aufgrund der Dateiendung bereits Rückschluss auf das Wintec WBT-202 .tes Format liefern würde?

"Sei beim Lesen von Daten möglichst lax und beim Schreiben möglichst strikt" lautet ein Informatikprinzip für robuste Programme.

D.h. der Code dürfte sich auf die Dateiendung beim Lesen der Daten sowieso nicht verlassen und stur versuchen die internen Strukturen mit den gelesenen Daten zu füllen, sondern müßte immer damit rechnen, kaputte oder falsche Daten vorgesetzt zu bekommen. Diese Robustheit sieht der Nutzer nicht, kostet aber viel Extra-Code. Also habe ich da aus der Not eine Tugend gemacht. Fehler wie in Deinem Fall bekomme ich schnell von Nutzern berichtet und kann sie dann beheben.

Weshalb werden da erst noch TomTom etc. probiert, welche ja eine ganz andere Dateiendung haben?

Lieber etwas mehr Gehirnschmalz in den Komfort des Programmes stecken, dann haben es die Nutzer einfacher und ich weniger Arbeit durch Supportanfragen. Gerade die Supportanfragen darf ich nach etwa 250000 Downloads und zehntausenden regelmäßigen Nutzern nicht vergessen.

[cholertinu]

"Sei beim Lesen von Daten möglichst lax und beim Schreiben möglichst strikt" lautet ein Informatikprinzip für robuste Programme.

Sicher richtig. Das ist auch beim Hardwaredesign ein bewährtes Prinzip.

D.h. der Code dürfte sich auf die Dateiendung beim Lesen der Daten sowieso nicht verlassen und stur versuchen die internen Strukturen mit den gelesenen Daten zu füllen, sondern müßte immer damit rechnen, kaputte oder falsche Daten vorgesetzt zu bekommen. Diese Robustheit sieht der Nutzer nicht, kostet aber viel Extra-Code. Also habe ich da aus der Not eine Tugend gemacht. Fehler wie in Deinem Fall bekomme ich schnell von Nutzern berichtet und kann sie dann beheben.

Sicher auch richtig.
Aber: Warum nicht bei bekannter Endung .tes erstmals einen Leseversuch als .tes starten? Wenn es nicht klappt, kann immer noch davon ausgegangen werden, dass die Endung nicht stimmt oder sonstwas nicht passt.
Wenn es aber klappt resultiert daraus ein deutlicher Komfortgewinn für den Bediener, welcher nicht erst auf das Durchprobieren aller Formate warten muss.

Lieber etwas mehr Gehirnschmalz in den Komfort des Programmes stecken, dann haben es die Nutzer einfacher und ich weniger Arbeit durch Supportanfragen.

Eben. Performancegewinn ist auch Komfort.

Gerade die Supportanfragen darf ich nach etwa 250000 Downloads und zehntausenden regelmäßigen Nutzern nicht vergessen.

Ich hoffe, ich gehe dir nicht zu sehr auf die Nerven...

Ein Ansatz, den Supportaufwand niedriger zu halten kann darin bestehen, die entsprechenden Anleitungen in guter Qualität aktuell verfügbar zu halten. Oder aber im Programm selbst Online-Unterstützung einzubauen.
In diesen beiden Punkten sehen ich durchaus noch Handlungsbedarf - intuitive Bedienung hin oder her.

Was mir z.B. aufgefallen ist:
Wenn ich z.B. die Anzahl Wegpunkte reduzieren will, gehe ich auf >Tools >Delete Positions (das erscheinende Fenster heisst dann jedoch "Lösche Positionen" ;-)
Was ist nun hier der genaue Unterschied zwischen "Markiere alle Pos. so dass mindestens xxx Meter zwischen den verbleibenden Positionen liegen" und "Markiere ale redundanten Positionen bei einem Grenzwert von xxx Metern". Ein Link zu einer Erklärungsseite oder eine Art "Whats this"-Rollover würde hier helfen.

[routeconverter]

Aber: Warum nicht bei bekannter Endung .tes erstmals einen Leseversuch als .tes starten?

Das mache ich auch seit der 1.33, wenn im Dateiöffnen-Dialog ein Format ausgewählt wurde. Für Drag-and-drop hilft das nichts.

Lieber etwas mehr Gehirnschmalz in den Komfort des Programmes stecken, dann haben es die Nutzer einfacher und ich weniger Arbeit durch Supportanfragen.

Eben. Performancegewinn ist auch Komfort.

Hast Du Performance-Probleme?

Ein Ansatz, den Supportaufwand niedriger zu halten kann darin bestehen, die entsprechenden Anleitungen in guter Qualität aktuell verfügbar zu halten. Oder aber im Programm selbst Online-Unterstützung einzubauen.
In diesen beiden Punkten sehen ich durchaus noch Handlungsbedarf - intuitive Bedienung hin oder her.

Das sehe ich auch - darum will ich versuchen, die Oberfläche besser zu strukturieren, eine Hilfe einzubauen und mir von anderen bei einer Anleitung helfen zu lassen. Alleine schaffe ich das nicht. Um mit der Tür ins Haus zu fallen: hättest Du Interesse?

Was mir z.B. aufgefallen ist:
Wenn ich z.B. die Anzahl Wegpunkte reduzieren will, gehe ich auf >Tools >Delete Positions (das erscheinende Fenster heisst dann jedoch "Lösche Positionen" ;-)

Das ist die Vorabversion, im Moment Baustelle ;-)

Was ist nun hier der genaue Unterschied zwischen "Markiere alle Pos. so dass mindestens xxx Meter zwischen den verbleibenden Positionen liegen" und "Markiere ale redundanten Positionen bei einem Grenzwert von xxx Metern". Ein Link zu einer Erklärungsseite oder eine Art "Whats this"-Rollover würde hier helfen.

Hinter "Markiere ale redundanten Positionen bei einem Grenzwert von xxx Metern" steckt der Douglas-Peucker-Algorithmus - vielleicht sollte ich das auch so nennen ;-)

[cholertinu]

Das mache ich auch seit der 1.33, wenn im Dateiöffnen-Dialog ein Format ausgewählt wurde. Für Drag-and-drop hilft das nichts.

Warum sollte das bei Formaten mit eindeutiger Endung nicht helfen? Bei .kmz / .kml mit mehreren hinterlegten Versionen ist mir das schon klar, bei .tes jedoch nicht. Da kann doch aufgrund der Endung auch auf ein klar definiertes Wunschformat geschlossen werden.

Hast Du Performance-Probleme?

Jein. Wenn ich länger als nötig auf das Öffnen der Datei warten muss, weil zuerst (unnötig) viele Formate durchprobiert werden, dann bezeichne ich dies als Performance-Problem.

Das sehe ich auch - darum will ich versuchen, die Oberfläche besser zu strukturieren, eine Hilfe einzubauen und mir von anderen bei einer Anleitung helfen zu lassen.

Das ist gut!

Alleine schaffe ich das nicht. Um mit der Tür ins Haus zu fallen: hättest Du Interesse?

Beitrag #5 dieses Themas dürfte diese Frage beantworten, leider.
Ich sehe meine Rolle momentan eher darin, einfach frisch drauflos zu testen und zu melden, was mir so auffällt - z.T. mit Vorschlag wie es evtl. gemacht werden könnte.

Das ist die Vorabversion, im Moment Baustelle ;-)

Klar doch, darum motze ich auch, solange noch Änderungen möglich sind.

Hinter "Markiere ale redundanten Positionen bei einem Grenzwert von xxx Metern" steckt der Douglas-Peucker-Algorithmus - vielleicht sollte ich das auch so nennen ;-)

Ob das jemand verstehen würde? Zumindest wäre dann das Stichwort für weitere Recherchen gegeben - durch aus nicht ein zu unterschätzender Vorteil. Viel eher würde hier eine piktogrammartige grafische Darstellung des Sachverhalts helfen.

[routeconverter]

Das mache ich auch seit der 1.33, wenn im Dateiöffnen-Dialog ein Format ausgewählt wurde. Für Drag-and-drop hilft das nichts.

Warum sollte das bei Formaten mit eindeutiger Endung nicht helfen?

Stimmt, das ist ein Implementierungsdetail: es gibt kein Mapping vom Dateiendungen auf Dateiformate, also habe ich bei Drag-and-drop nur die Datei bzw. URL in der Hand. Beim Dateiöffnen-Dialog dagegen kann ich den Dateifilter fragen, den der Nutzer gewählt hat.

Bei .kmz / .kml mit mehreren hinterlegten Versionen ist mir das schon klar, bei .tes jedoch nicht. Da kann doch aufgrund der Endung auch auf ein klar definiertes Wunschformat geschlossen werden.

Hinter "Markiere ale redundanten Positionen bei einem Grenzwert von xxx Metern" steckt der Douglas-Peucker-Algorithmus - vielleicht sollte ich das auch so nennen ;-)

Ob das jemand verstehen würde? Zumindest wäre dann das Stichwort für weitere Recherchen gegeben - durch aus nicht ein zu unterschätzender Vorteil.

Wohl eher nicht. Der Algorithmus versucht mit möglichst wenig Punkten einen Linienzug abzubilden - wie soll man das kurz erklären? Vielleicht sollte ich das umkehren und den Nutzer eintragen lassen, auf wieviele Wegpunkte er reduzieren möchte?

Viel eher würde hier eine piktogrammartige grafische Darstellung des Sachverhalts helfen.

Wie stellst Du Dir das vor? So wie hier rechts auf der Wikipedia-Seite?

[EddiVonDerAlm]

Vielleicht sollte ich das umkehren und den Nutzer eintragen lassen, auf wieviele Wegpunkte er reduzieren möchte?

Aber bitte nicht ersetzen, sondern höchstens als weitere Option. Ich bereinige meine Tracks immer mit einem Wert von 3 Metern. Egal ob das 2 Stunden oder 12 Stunden Aufzeichnungen sind. Da bringt es mir wenig ein Zielwert anzugeben.