Hallo Stefan,
ZitatOriginal von StefanDausR
Zu 2) Nachhinken: Es kann eigentlich nicht am Receiver liegen. Ich habe die OSM-Karten in meiner Gemeinde alle selber aus GoPal-TRK-Dateien erstellt und wenn ich nun mit NaviPOWM diese Straßen wieder nachfahre, dann kommt das Nachhinken. Also scheint die Track-Aufzeichnung zeitnah zu erfolgen, nur die Berechnung der Anzeige dauert eben.
Es kann durchaus sein, dass der Receiver eine gewisse Zeit braucht, bis die Ergebnisse am seriellen Port ausgegeben werden. Die Berechnungen dauern auch eine gewisse Zeit. Wer, wie lange braucht, muss ich noch untersuchen.
ZitatZu 3) Optimierung: Man könnte ja ab einem best. Maßstab gewisse Straßenklassen ausblenden. Außerdem kann man sich Rechenzeit sparen, wenn man die Punktanzahl der Polygone vor der Anzeige reduziert (Punkte die auf die selben Pixel fallen eliminieren).
Das habe ich auch vor: ein Ausduennen der Informationen je nach Zoom-Level. Ob das on the fly gemach wird, oder von OSM2POWM, weiss ich noch nicht.
ZitatIch habe deinen Code nur mal überflogen. Was berechnest Du denn alles zur Laufzeit? Du hast ja einige Koordinatentransformationen d'rin. In welchen Koordinatensystem erfolgt die Bildschirmdarstellung (Mercator oder WGS84).
Es werden die Positionen aller Punkte so transformiert, dass man diese (in Abhaengigkeit der Fahrtrichtung und Zoom-Level) korrekt darstellen kann. Als Koordinatensystem fuer die Darstellnug verwende ich UTM.
ZitatZu 6) Das Problem ist beim PNA, dass bei der Aktivierung auch die ggf. eingeblendete Taskleiste überdeckt wird und man nicht mehr z.B. zu GoPal zurückkommt, ohne NaviPOWM zu beenden. Könnte man das Verhalten nicht über FullScreen = steuern, das zeigt beim PNA anscheinend sonst keinen Wirkung.
Das war so geplant, scheint aber nicht richtig durchdacht gewesen zu sein. Werde ich in 0.1.1 wieder einstellbar machen.
ZitatZu 7) OSM2POWM: Mir istz das Problem halt aufgefallen, da ich in die Deutschland-Map aktuelle Daten aus einen Teilgebiet einbauen wollte. Ich muss dann erst die "Überflüssigen" Kacheln löschen, ist aber auch kein größeres Problem. Falls Du aber einen Schalter einbauen könntest, ob die Bounding-Box aus der OSM-Datei (bei JOSM enthalten!) berücksichtigt werden soll, dann wäre das toll.
Das Datenformat selbst müsste auch noch deutlich optimierbar sein!
Ich muss mir mal das Bounding-Box mal naeher anschauen. Das Problem mit unvollstaendigen Kacheln koennte aber m.E. bestehen bleiben, es sei denn, man zwingt JOSM dazu, die Kachelgrenzen einzuhalten...
ZitatMit welcher Entwicklungsumgebung arbeitest Du eigentlich?
WM5: embedded Visual Studio 4 mit WM5 target
Windows: Visual Studio 6 und MinGWStudio
Linux: KDevelop
Es muss eben moeglich sein, nur mit frei verfuegbaren Mitteln NaviPOWM und OSM2POWM zu entwickeln. OK, VisualStudio 6 ist nicht frei, dafuer aber MinGWStudio.
Gruesse,
Julian