Feature Request (Anregung)?

Ich habe mit SQLite schon gearbeitet und finde es sehr praktisch. Leider habe ich kein Möglichkeit gefunden, diese mit dem alten Compiler zu übersetzen, den ich noch für Glopus nutze, damit auch ganz alte Geräte unterstützt werden.
Das heißt also, Glopus muss sich von alten Geräten verabschieden und das habe ich mir nicht getraut.

Zitat von Peter Kirst

... damit auch ganz alte Geräte unterstützt werden.
Das heißt also, Glopus muss sich von alten Geräten verabschieden und das habe ich mir nicht getraut.

Da wäre es schon interessant, was unter "alten Geräten" zu verstehen ist.

Wenn mein FS Loox N520 mit WM5 betroffen sein würde, wäre ich (und natürlich alle anderen mit WM5) "not amused" ...
beziehungsweise heilfroh, dass du dich nicht getraut hast.

Gruß Helmut

Mit den Glopus-Datenformaten bin ich eigentlich recht zufrieden und sehe keine größeren Handlungsbedarf. Beim GMF könnten zwar noch ein paar Bytes hinzukommen für Datum und Projektion, aber ansonsten ist es schön schlank.

Bei mir sind die GMF-Karten typischerweise mehrere hundert MB groß (Topokarten der Bundesländer, Generalkarte). Die Lösungen zuvor mit Einzeldateien oder mit ZIP-Archiven waren mit diesen Datenmengen viel zu langsam. Auch SQLite könnte hier eine starke Performance-Bremse sein, weil eine Datenbank-Layer zwischengeschoben wird. Im GMF kann man dagegen recht flott direkt an die Fileposition springen und das PNG in den Speicher mappen. Gerade beim Kartenmaterial ist Performance sehr kritisch.

Für die sonstigen Geodaten wäre SQLite eher weniger ein Performance-Problem. Momentan bin ich aber recht froh über die standardisierten Rohdaten wie NMEA für die Tracks und ASCII-CSV für POI, Ziele und Routen. Diese Dateien sind sehr kompatibel, können im Explorer schnell zwischen NAvi, PNA verschoben werden. Mit Datenbank-Scripts wäre das nur umständlicher. POI-Datenbanken gibt es in ASCII-Form. Es wäre nicht schön, wenn jedes Programm ein eigenes Format hätte, was nicht austauschbar ist. GPX ist natürlich auch sehr schön, aber auch wegen der Formats-Flexibiltät (XML) schwieriger in Scripts zu verarbeiten. Man muss die Sachen ja auch nicht komplizierter machen als sie sind. "Daten-Tanken" mit Download-Dateien geht auch ohne Datenbank.

Zitat von womisa

..auch das GMF Format braucht eine Verwaltung! Genau diese Verwaltung könnte einem die "normierte" SQLite Schnittstelle durch bewährte und optimierte Suchalgorithmen abnehmen. Wie du schon erwähnt hast "könnte" eine "Performance-Bremse" sein, muß aber nicht Schau dir mal Navicomputer an. Der Vorteil für den Programmierer zur Verwaltung seiner Karten und suchen welche Karten fürs Zielgebiet passen, wird dadurch wesentlich einfacher. Ferner kann mit Standardtools zB: Firefox-Plugin SQLIte-Manager die Datenbasis leicht analysiert werden. Ich möchte aber keine DB-Diskussion vom Zaun brechen. War ja nur ne Anregung

Eine relationale Datenbank ist dafür aber völlig überdimensioniert. Warum SQL? Welche Relationen? Das wird zwangläufig langsamer sein als eine optimierte Behandlung in C. Es geht doch um eine einfache Liste von Kacheln. Dazu noch das Caching der Metadaten (Namen,Kalibrierpunkte), damit das Starten schneller geht. Optimaler geht es doch kaum noch. Das Handling der Karten über GMF-Dateien im Explorer finde ich sehr praktisch. Eine Datenbank wäre für den Benutzer eher umständlicher. Hast du den Navicomputer auch mit großen Karten getestet, z.B. Generalkarte mit >250MB oder die Topo 25 Bayern-Süd mit 1 GB? Es gibt nicht viele Programme, die mit so großen Rasterkarten zurechtkommen. Das ist eine besondere Stärke von Glopus.

Das einzige was ich mir für zukünftige Versionen wünsche, wäre die Möglichkeit, die POI-Datenbank-Datei von dem POI-Warner V3 zu nutzen.
Dann könnte man sich eine Version vom Warner sparen.

Ist nur die Frage, in wieweit Markus da mitmachen würde....

Gruß

Marc

Zitat von MarcS

Ist nur die Frage, in wieweit Markus da mitmachen würde....

Das OK dafür habe ich sogar schon seit einiger Zeit. Die Macher vom POI-Warner sind diesbezüglich sehr kooperativ und haben mir sogar schon mehrfach geholfen. Aus oben genannten Gründen habe ich diesbezüglich aber noch nichts angefangen.

Nur, muss das unbedingt in Glopus eingebaut sein? Man könnte auch nach dem Datenbankdownload die POI in eine Glopus-verträgliche ASCII-Form konvertieren. Mit den TomTom OV2-Daten geht das beispielsweise.