Import der TMC-Locations in OpenStreetMap

Ich beschäftige mich gerade privat mit TMC (Also elektronische Verkehrsnachrichten)
um mein Navi Traveling Salesman mal TMc-fähig zu machen.

Macht soweit auch riesen Fortschritte (Hier die Wiki-Seite dazu).

Nunja, erstes Problem: Wo kriegt man die TMC-spec her.
Antwort: für $$$

Glücklicherweise scheinen aber etliche Leute schon mit TMC gespielt zu haben und haben ihre Erfolge dokumentiert. Ohne die Spec kommt man am Ende aber doch nicht wirklich aus.
Spätestens wenn es an Multigroup-Messages geht.

zweites Problem: man braucht die Liste der Event-Codes.
Antwort: okay, mit viiiel Suchen findet man die im Netz.

drittes Problem: man braucht die Location-Codes für das jeweilige Land(+den Anbieter)
Antwort: ...die kann man bei der BASt einfach mal so runterladen.

Aber wie jetzt die Location-Codes mit den Locations in der Karte verbinden?
Tja....eine kurze Anfrage bein der BASt hat erstaunliches ergeben.

...und wurde erlaubt existierende Objekte in der OpenStreetMap mit ihrem
TMC Location-Code zu versehen.

Was bedeutet das?
Erstmal viiel Arbeit. Das ist nicht irgendein Daten-Import sondern die Daten müssen
von Navis ja eindeutig identifizierbar sein. Incl. so Sachen wir dass eine Ortsangabe
in TMC auch heissen kann "Erstreckt sich von Code XYZ 7 Schritte rückwärts in der
doppelt verketteten Liste der Locations".
Ausserdem gibt es natürlich mehrere Länder mit TMC und mehrere Anbieter und
mehrere Versionen der Code-Liste. Ergo: Müssen die Werkzeuge nicht nur 1x benutzt werden
sondern der Import auch von Leuten mit weniger Ahnung von TMC in anderen Ländern =
Sprachen und Besonderheiten wiederholt werden können.

Was bedeutet das weiterhin?
Navis mit TMC schreiben ohne die Code-Listen zu haben. Denn die Codes sind schon
in der OpenStreetMap. Damit entfält für Nutzer der OSM der schwierigste Schritt
wenn man TMC in Navis einbauen will!!!

jGnucashLib wird erwachsen

Nach langer Zeit verbessere ich das (monatlich von mir genutzte) jGnucashLib mittlerweile wieder weiter.

Gestern konnte ich etliche Verbesserungen für die Behandlung mehrerer Währungen
in den Editor-Komponenten einbauen und sogar einige (lange unentdeckte) kleinere Fehler in der Währungsbehandlung finden und fixen.

Heute hat der Editor das Arbeiten mit mehreren Tabs gelernt.
Danke sauberer Architektur alles überhaupt kein Problem.
Mit einem sauber durchgezogenen MDA-Ansatz sind mehrere Views auf die gleichen Daten immer im aktuellen Zustand.
Damit wächst der Editor für die Gnucash-Fibu-Dateien von einem simplen Werkzeug welches
nur als Platform für das Einhängen von mächtigen Plugins zur Batch-Verarbeitung von
Fibu-Daten (Konten-Abgleich mit HBCI, Paypal und CSV, Rechnungs-Parsen und -Import,
Bestellungs-Import,...) zu einer vollwertig nutzbaren Fibu.

Sicherlich ist es weiterhin kein Ersatz sondern ein Hilfsmittel für Gnucash
aber kleinere Erfassungen und Änderungen kann man teilweise jetzt viel einfacher
damit als mit dem grossen Gnucash erledigen.

https://sourceforge.net/projects/jgnucashlib/

Navi bereit für das Auto

Mittagspause.. und sihe da: Die Optimierungen haben echt was gebracht.
Der kleine Eeepc konnte über nach ganz Baden Württemberg importieren.
Das war bisher nur dem grossen Dual-Core vorbehalten, da der Nettop
zu wenig Adressraum hatte und daher sehr früh von Memory-Mapped IO
auf konventionelles IO umschaltet.
Mittlerweile ist konventonelles IO kaum noch langsamer.

Da habe ich nun also ganz BaWü auf dem kleinen Kästchen.
Dass die Fahr-Anweisungen mittlerweile taugen haben einige
Testfahrten in Norwegen mit aufgezeichneten GPS-Tracks schon gezeigt.
Resultierte in Anweisungen für Kreisverkehre, einem GPX/NMEA-control-Panel
wenn man sein GPS-Signal aus einer Datei liest und in übersetzten
Fahr-Anweisungen. Zentral mal von mir angeleiert und jetzt für alle
OpenStreetMap-Navis im Wiki gesammelt. Kaum eine halbe Woche und schon
ein Dutzend Sprachen. Ach ja... und Sprachausgabe konnte ich letztes
Wochenende zusammen hacken. Zusammen mit einem weit besseren Plugin-System.


Also...
Karte CHECK
Routing CHECK
Karten-Rendering CHECK
Fahranweisungen CHECK
...bereit sich am Wochenende in's Auto zu schwingen und wirklich mal damit
herum zu fahren.

Openstreetmap erntet zwei Linux New Media Awards

Es ist immer toll wenn ein Projekt an dem man arbeitet Anerkennung erntet.

Heute wurden dem Projekt OpenStreetMap 2 der nur 6 Linux New Media Awards
von Suns Open-Source-Chef Simon Phipps auf der C-Bit überreicht.
Die Kategorien waren:
Bestes Community-Projekt
und
Innovativstes Open-Source-Projekt


Meldung des Linux Magazin

Profiling II

Nachdem die erste grosse Optimierungs-Runde an Traveling Salesman
so gut geklappt hat, ging es diesmal um die Möglichkeit
* unnötige Elemente der Karte frühzeitig zu filtern
* asynchron zu schreiben

https://apps.sourceforge.net/mediawiki/travelingsales/index.php?title=travelingsales:33

Fazit:
Ich bin für einen Karten-Import von Hamburg in mein selbetgeschriebenes Navi
runter auf 73,9% (etwa 11 statt 15min) der Zeit. Aus bisher ungeklährter Ursache
wird mit Schreib-Caching alls eher langsamer als schneller.
Man sollte meinen, dass es sich umgekehrt verhält.

Merke:
Programmierer sind tendenziell schlecht darin langsame Code-Stücke zu erraten.
Geeigneten Werkzeuge spaaren hier unglaublich Zeit und helfen einem im Verständniss
wo denn die ganze Zeit bleibt.

Rückkehr zu jGnucashLib

Man merkt, ich habe schon eine Weile nichts mehr an jGnucashLib
- meine Fibu-Automatisierungs-Platform gebaut.
Die letzten Gnucash-Versionen enthielten einen Fehler (Root-Konto
wurde ohne Währungs-Stückeling geschrieben) und erst jetzt taucht
das durch eine Nutzer-Meldung bei mir als Bug auf (jGnucashLib weigert
sich selbstverständlich solche kaputten Dateien zu laden und würde
sie nie selber schreiben).

Naja, gleich mal Zeit den Gnucash-Parser noch an einigen anderen
Stellen robuster zu machen... wo man schonmal dabei ist.

Version 2.0.17 ist raus.
https://sourceforge.net/projects/jgnucashlib/