Neue Maps braucht das Land

Im Celtune Repository gibt es aktuelle Maps für die Länder Deutschland und Österreich. Zu finden ist das ganze unter http://rabenfrost.net/celtune/navit-osm-maps/.

Die Karten:
http://rabenfrost.net/celtune/navit-osm-maps/germany-06082008.bin
http://rabenfrost.net/celtune/navit-osm-maps/austria-06082008.bin

Und noch eine andere Sache: Bei der Version 0.1.0 von Navit muss man in der Datei /usr/share/navit/navit.xml unter Plugins lib*.so zu lib*.so.0 und libgraphics_null.so zu libgraphics_null.so.0 ändern. Dies gilt aber nur für besagte Version.

Möchte man nun noch Support für Garmin Karten haben so installiert man einfach das Paket libgarmin indem man folgendes auf dem Terminal eingibt:

opkg install libgarmin und libgarmin-bin

Wichtig ist dabei das man das celtune Repository drin hat. Und schon kann es wieder losgehen :)

Und so sieht Navit mit einer Garmin Map aus.

Festplatte mit FAT32 formatieren

Ich wollte gestern eine externe Festplatte mit einer FAT32 formatieren. Aus Gründen welche wohl nur Microsoft kennt geht dies aber nur bei Festplatten bis 32 GB. Wahrscheinlich wollte Microsoft die Verbreitung seines NTFS Dateisystemes ein bisschen ankurbeln. Dank der c’t gibt es eine einfache Lösung auch größere Festplatten mit einer FAT32 zu formatieren.

Dazu benötigen wir das Tool h2format welches unter ftp://ftp.heise.de/pub/ct/ctsi/h2format.zip heruntergeladen werden kann. H2format formatiert aus Sicherheitsgründen nur unformatierte Partitionen (solche in denen die letzten Bytes des Bootsektors nicht 55 AA lauten). Solch eine Partion ann man in der Datenträgerverwaltung einfach anlegen in dem man während des Prozess des Anlegens „Partion nicht formatieren“ wählt. Danach kann man mittels

H2format
z.B. H2format X:

die Festplatte mit FAT32 formatieren.

Wie geht es weiter?

Gestern saß ich am Rechner und vor mir lag mein Neo. Ich habe es dann mal angeschaut und war mal wieder total begeistert welche ungeahnten Möglichkeiten in diesem Gerät stecken. Das führte dazu das ich erst einmal für Minuten nichts anderes getan habe, als begeistert zu sein :) Ich wollte eigentlich schon vor längerer Zeit meine erste Openmoko-Anwendung schreiben. Leider ist das nicht so einfach wie zuerst gedacht.

Da ich diese Anwendung auf Enlightment Basis realisieren wollte und plötzlich merkte das es neben Evas und Edje auch ein UI Toolkit benötigt. Da gibt es ja wie ich beim letzten Mal schon schrieb die Toolkits EWL und Etk. Ich habe mich dann für EWL entschieden und musste dann mal wieder feststellen das es dafür kein Pythonbinding gibt.

Als Entwickler ist man nun doch etwas enttäuscht. Was wir brauchen ist ein leichter Einstieg in für Entwickler, denn nicht jeder Entwickler hat Lust erst Tage und Wochen damit zu verbringen überhaupt mal eine Anwendung hervorzuzaubern. Ich hätte gerne einen „Standard“ welche Widgets benutzt werden sollen etc.

Im Endeffekt musste ein integriertes System entstehen. Was das bedeutet kann man sich an Systemen wie Windows, GNOME, und KDE sehen. Jede Anwendung benutzt die gleichen Widgets und für Benutzer sieht das ganze immer irgendwie bekannt aus. Nachdem FSO die Middleware liefert sollten wir uns um die Benutzeroberfläche kümmern.

Da viele Leute (zu mindestens die mit denen ich zu tun hatte) eine Umgebung auf Enlightment (und Illumne) Basis bevorzugen (ich auch), sollten wir anfangen genau dort anzufangen. Konkret bedeutet das folgendes: Zur Zeit ist Zhone (das Testimage für FSO), eine nicht grade modular aufgebaute Anwendung. Was uns fehlt ist ein Äquivalent zu den GNOME Libs (und anderen ähnlichen Dingen).

Wir sollten nun Anfangen uns an das Reißbrett zu setzen und ein System zu designen welches modular ist und vor allem auch in der Zukunft ausbaufähig ist. Damit wir die Bibliotheken z.B. die für die Widgets nicht an den Bedürfnissen vorbei entwickeln sollten wir unserer Brot und Butter Anwendungen entwickeln und parallel dazu die passenden Bibliotheken. Ich denke am Anfang sollten es folgende Anwendungen sein:

– einen Dailer
– ein SMS Programm
– ein Adressbuch
– einen Kalender
– einen Mediaplayer
– ein Notiz Programm
– ein Memo Programm
– eine Uhr bzw. Weltzeit Uhr (mit Wecker)

Bei der Entwicklung dieser Programme sollte dann parallel dazu die passenden Bibliotheken entwickelt werden, damit der Entwickler auf einem Framework aufsetzen kann bei dem er nicht befürchten muss das nächste Woche schon wieder alles anders macht und der Benutzer eine einheitliche Oberfläche mit einheitlichen Anwendungen bekommt.

Jetzt stellt sich eigentlich nur noch Frage. Wer macht mit?

Das TMX Format

Auf der Website http://www.mapeditor.org gibt es einen freien Tilebasierten Mapeditor names Tiled. Der Editor wurde in Java geschrieben und wird unter anderem von Projekten wie The Mana World (http://www.themanaworld.org) benutzt.

Das Standardformat dieses Editores ist TMX. Dabei handelt es sich um eine XML Datei in der die Daten kodiert sind. Vor einiger Zeit war ich damit beschäftigt einen Reader für das Format zu schreiben. Leider ist die Dokumentation des Formates sehr lückenhaft, aber dank einiger tatkräftiger Hilfe auf der Mailingliste war der Reader nach einer Weile dann doch fertig. Doch nun zum TMX Format. Eine TMX Datei könnte z.B. so aussehen: ow-testmap.tmx

Als erstes kommt der map Tag in dem alle anderen tags untergeordnet sind. Der erste Tag von Interesse ist dann der tileset Tag. In diesem Tag stehen der Name des Tilesets, die FirstGID (dazu später mehr), die Breite und Höhe der Tiles sowie das Quellbild des Tilesets.

Nachdem die Tilesets definiert sind beginnen auch schon die Layer Definitionen. Eine Karte kann aus mehreren Layern bestehen z.B. einem Kollisionlayer. Im Layer Tag stehen der Name, die Breite und Höhe des Layers. Darunter folgt bei komprimierten Karten (die Standardeinstellung von Tiled) der Tag data mit dem Attribut encoding. In unserem Beispiel ist die Kodierung Base64 und die Kompression gzip. Um an die Daten des Layers zu kommen muss man den von den Data Tags eingeschlossen String nehmen und mittels Base64 decodieren. Anschließend erhält man ein Byte Array. Dieses Byte Array muss dann noch mittels des gzip Algorithmus dekomprimiert werden. Bei dieser Aktion kommt am Ende auch wieder ein Byte Array heraus.

In diesem Byte Array stehen dann die Tilenummern drin und zwar in Form von 4 Byte Integers (Little Endian). Hat man z.B. eine 2×2 Karte so würden die Tiles in folgender Reihenfolge kommen: 0,0 – 0,1 – 1,0 – 1,1.

Nun stellt sich nur noch die Frage wie man diese Tilenummern interpretiert. Und dabei kommt jetzt die FirstGID des Tileset zum tragen. Nehmen wir an das wir die Tilenummer 270 auslesen. Um nun zu ermitteln zu welchem Tileset die Nummer gehört prüfen wir in welches Tileset in diesem Bereich liegt und stellen fest das das Tileset desert2 genau in diesem Bereich liegt. Dann rechnet man noch Tilesetnummer – FirstGID und schon hat man die Tilesetnummer und das Tileset (in diesem Fall 11). Nun wissen wir das das Tile das elfte Tile im Tileset desert2 ist.