NaviPOWM 0.2.2

Hallo,

die neue Version von NaviPOWM (0.2.2) ist freigegeben. Sie befindet sich an der ueblichen Stelle:

http://sourceforge.net/projects/navipowm

Hier ganz kurz ein paar der Unterschiede zur 0.2.1:

behobene Bugs:
- Grosse Gebiete mit wenigen Daten werden im Batch-Modus besser aufgeteilt
- kleinere Fehler beim Zeichnen der Karte behoben
- kleines Speicherleck entfernt

implementierte Feature Requests:
- Rote Farbe fuer Anzahl der Satelliten heller gemacht
- Strassen werden breiter dargestellt wenn man sehr nahe ranzoomt
- Namen von Ortschaften werden jetzt angezeigt
- residential und living_street werden unterschiedlich dargestellt

anderes:
- mitgelieferte Qt dlls jetzt in Version 4.5.1

Die alten Karten (ab 0.2.0) koennen weiterhin verwendet werden, enthalten aber nicht die kompletten Informationen.

Dokumentation im Wiki muss noch angepasst werden.

Ich wuensche Euch viel Vergnuegen mit der neuen Version.

Gruesse,
Julian

Tach!

Sodele, ist schon 'runtergeladen. Gestestet wird aber erst heute Abend...

Bis dann
johannes

Hallo Julian,

sieht recht gut aus!

Ein paar Anmerkungen / Wünsche zu NaviPOWM hätte ich noch:

Könntest du den Texthintergrund nicht transparent machen, dann würde es etwas übersichtlicher werden.

Kannst Du gleichartige, sich überlagernde POIs zusammenfassen? Bei den Parkplätzen ist das z.B. schon recht dicht.

Die Linien der Gebäudeumrandungen könnten m.E. immer 1px breit bleiben, sonst sind sie zu auffällig.

s. Bilder

Zu OSM2POWM:

Die Batch-Aufteilung scheint nun besser zu sein, obwohl sie bei großen Dateien sehr lange läuft. Da wäre es wahrscheinlich effizienter, zuerst die erste Grobaufteilung zu machen und daraus gleich die OSM-Teil-Dateien (0100.osm bis 0108.osm) zu generieren und dann den BATCH auf jeweils diesen Teildateien zu wiederholen. So mache ich das momentan manuell.

Bei der ASIA.OSM sind die Koordinaten der BoundigBox teilweise ungültig.
Werte größer als 180.0 und kleiner als -180.0 mag osmosis nicht. Wenn man mit einem Editor "180.10" durch "180.00" ersetzt, dann passt es. Das ist auch kein Problem, da es wohl -per Definition- keine Linien geben darf, die der 180. Längengrad überspannt.

Gruß,
Stefan

Zitat

Original von StefanDausR
Könntest du den Texthintergrund nicht transparent machen, dann würde es etwas übersichtlicher werden.

Hi,

Habe ich mal versucht, allerdings konnte man noch weniger sehen. Werde noch damit rumexperimentieren.

Zitat

Kannst Du gleichartige, sich überlagernde POIs zusammenfassen? Bei den Parkplätzen ist das z.B. schon recht dicht.

Das geht leider nicht auf die Schnelle. Wuesste ad hoc gar nicht, wie ich es implementieren sollte, ohne die CPU zum Gluehen zu bringen.

Zitat

Die Linien der Gebäudeumrandungen könnten m.E. immer 1px breit bleiben, sonst sind sie zu auffällig.

Hmmm... fand ich eigentlich ganz schoen so... Ich schaue mal.

Zitat

Zu OSM2POWM:

Die Batch-Aufteilung scheint nun besser zu sein, obwohl sie bei großen Dateien sehr lange läuft. Da wäre es wahrscheinlich effizienter, zuerst die erste Grobaufteilung zu machen und daraus gleich die OSM-Teil-Dateien (0100.osm bis 0108.osm) zu generieren und dann den BATCH auf jeweils diesen Teildateien zu wiederholen. So mache ich das momentan manuell.

Dass OSM2POWM im Batchmodus erst mal seeehr lange laeuft, ist OK so: die OSM-Datei muss komplett geparst werden, um entscheiden zu koennen, wie diese am besten gesplittet werden kann. Es sollte aber nicht so schlimm sein, denn die Batch-Datei kann ruhig ziemlich selten generiert werden. So viel aendert sich ja auch nicht. Oder man verwendet den von Dir beschriebenen Workaround.

Zitat

Bei der ASIA.OSM sind die Koordinaten der BoundigBox teilweise ungültig.
Werte größer als 180.0 und kleiner als -180.0 mag osmosis nicht. Wenn man mit einem Editor "180.10" durch "180.00" ersetzt, dann passt es. Das ist auch kein Problem, da es wohl -per Definition- keine Linien geben darf, die der 180. Längengrad überspannt.

OK, wieder was gelernt. Habe ich als Bug eingetragen.

Gruesse,
Julian

Zitat

Original von J.Bugariu

OK, wieder was gelernt. Habe ich als Bug eingetragen.

Und auch schon behoben.

Gruesse,
Julian

Hallo Julian,

Zitat

Original von J.Bugariu
Und auch schon behoben.

super!

Zitat

Original von J.Bugariu
Dass OSM2POWM im Batchmodus erst mal seeehr lange laeuft, ist OK so: die OSM-Datei muss komplett geparst werden, um entscheiden zu koennen, wie diese am besten gesplittet werden kann. Es sollte aber nicht so schlimm sein, denn die Batch-Datei kann ruhig ziemlich selten generiert werden. So viel aendert sich ja auch nicht.

Kann es sein, dass die lange Laufzeit auch am 180. Längengrad liegt oder ist es die flächenmäßig große Ausdehnung? Ich habe die ASIA-Batch-Datei nochmal komplett erzeugen lassen (in Hintergrund), hat aber über 2 Tage gedauert (2.5 MB) ...
Die Europa BAT-Datei wird aber in ein paar Stunden generiert.

Ich muss aber -gerade in Gegenden, die noch viele weiße Flecken haben- den Batchmodus öfter nutzen, da sonst ggf. hinzugekommene Gebiete übergangen werden, da die MAP-Files sonst nicht kopiert werden.

Zu den Texten:

Zitat

Original von J.Bugariu
Habe ich mal versucht, allerdings konnte man noch weniger sehen. Werde noch damit rumexperimentieren.

Hast Du schon mal versucht, den schwarzen Text z.B. in weiß um 1 Pixel versetzt zu hinterlegen, also so eine Art weißen Schatten zu erzeugen? Das geht relativ schnell und erzeugt etwas Kontrast zum Hintergrund.

Gruß,
Stefan

Zitat

Original von StefanDausR
Kann es sein, dass die lange Laufzeit auch am 180. Längengrad liegt oder ist es die flächenmäßig große Ausdehnung? Ich habe die ASIA-Batch-Datei nochmal komplett erzeugen lassen (in Hintergrund), hat aber über 2 Tage gedauert (2.5 MB) ...
Die Europa BAT-Datei wird aber in ein paar Stunden generiert.

Hallo Stefan,

es haengt nur von der Groesse der OSM-Datei und der geografischen Ausdehnung ab: je groesser ide OSM-Datei, desto laenger dauert es beim Einlesen. Die Ausdehnung duerfte auch eine nicht unerhebliche Rolle spielen, da versucht wird, die naechste Aufteilung so vorzunehmen, dass in allen erzeugten Teilen aehnlich viele Punkte vorhanden sind. Und das geht nach der brute force Methode: alles testen und das beste Ergebnis verwenden.

Zitat

Ich muss aber -gerade in Gegenden, die noch viele weiße Flecken haben- den Batchmodus öfter nutzen, da sonst ggf. hinzugekommene Gebiete übergangen werden, da die MAP-Files sonst nicht kopiert werden.

Duie MAP-Dateien werden (aus Sicht der Batch-Datei) immer erzeugt und auch somit auch kopiert. Falls nicht, dann ist es noch ein Fehler. Dass leere MAP-Dateien von OSM2POWM nicht erzeigt werden, ist OK. Falls beim naechsten Lauf diese Dateien nicht mehr leer sein sollten, werden sie natuerlich auch erzeugt und kopiert. Du kannst die "move"-Befehle im Batch pruefen und du wirst feststellen, dass keine MAP-Dateien ausgelassen werden. Behaupte ich jetzt mal einfach so.

Zitat

Zu den Texten:
Hast Du schon mal versucht, den schwarzen Text z.B. in weiß um 1 Pixel versetzt zu hinterlegen, also so eine Art weißen Schatten zu erzeugen? Das geht relativ schnell und erzeugt etwas Kontrast zum Hintergrund.

Ich hatte noch nach einer API-Funktion gesucht, die sowas elegant macht, werde aber um das Versetzen von Bitmaps wohl nicht rumkommen.

Gruesse,
Julian

Hallo Julian,

mir ist noch aufgefallen, dass die ways der Adressinterpolation in der Karte angezeigt werden (s. Bild 1). Kannst Du die herausnehmen?

Dort gibt es auch ziemlich viele POIs... (s. Bild 2)

Gruß,
Stefan

Zitat

Original von StefanDausR
mir ist noch aufgefallen, dass die ways der Adressinterpolation in der Karte angezeigt werden (s. Bild 1). Kannst Du die herausnehmen?

Grundsaetzlich schon, den naechsten Punkt finde ich viel wichtiger:

Zitat

Dort gibt es auch ziemlich viele POIs... (s. Bild 2)

Ist aber nichts im Vergleich zu London

Gruesse,
Julian