NaviPOWM 0.2.4 freigegeben

    Zitat von Habe Handy

    Mir ist aufgefallen das OSM2POWM nur einen Tread benutzt und daher auf Multicoresystemen nur einen Kern auslastet. (50% CPU Last)


    Das ist richtig. Noch werden nicht mehrere threads unterstuetz.


    Zitat

    Daher will ich ein bisschen mit der Batchdatei rumfummeln um OSM2PoWM zweimal zu starten. Damit sollte sich die Rechenzeit beim Dualcore halbieren lassen.


    Aber mit Vorsicht: jeder einzelne Prozess sollte in einem separaten Verzeichnis laufen, da zusaetzliche MAP-Files erstellt werden, welche mit denen, die von den anderen Prozessen erstellt werden, kollidieren koennten!


    Ob sich die Geschwindigkeit dadurch verdoppelt, haengt natuerlich auch von der Groesse des Hauptspeichers ab... ;)


    Julian

    Hallo Julian,

    Zitat von J.Bugariu

    da zusaetzliche MAP-Files erstellt werden, welche mit denen, die von den anderen Prozessen erstellt werden, kollidieren koennten!

    ich hatte zu dem Problem (aus einem anderen Grund) hier schon mal was geschrieben. Wäre das realisierbar?


    Gruß,
    Stefan

    Zitat von J.Bugariu

    Zitat von »StefanDausR«




    Da solltest du Dir auch lieber erst von OSM2POWM eine BAT-Datei erzeugen lassen...


    Zitat von J.Bugariu

    Und zwar wie folgt:
    1. osmosis besorgen und sicherstellen, dass es funktioniert
    2. Unterverzeichnis result erstellen. (farbliche Markierung nur wegen ini-Datei)
    3. OSM2POWM.ini wie folgt anpassen (Pfade natuerlich anpassen):

    Hallo,
    ich habe 0smosis installiert.
    Wo genau muss das Verzeichnis hin und was bedeutet farbliche Markierung wegen ini-Datei?
    Ich habe das Verzeichnis result mal probeweise unterhalb des Verzeichnisses von osm2powm und osmosis angelegt.






    Meine osm2powm.ini :



    #######################################################################



    Parts = 3
    MaxArea = 16
    MaxPoints = 1500000
    Offset = 0.1
    OSM2POWMCallString = OSM2POWM
    OsmosisCallString = call c:\\navipowm\\osmosis-0.29\\bin\\osmosis.bat
    TargetPath = result
    DeleteString = del
    MoveString = move

    Zitat von J.Bugariu

    4. mit OSM2POWM -s MyFile.osm > MyFile.bat eine batch-Datei erzeugen lassen.
    5. mit MyFile.bat die Karten erzeugen.
    6. Die Ergebnisse befinden sich im Unterverzeichis result

    dann folgende .bat gestartet:
    OSM2POWM -s germany.osm > MyFile.bat



    Es wird Myfile.bat erzeugt (siehe anhängende Datei).
    Wenn ich nun Myfile.bat starte wird kurz ein 'Dos-Fenster' geöffnet und Text läuft sehr schnell durch. Danach schließt das Fenster. Es werden keine map-Dateien erzeugt.


    Irgendwas mache ich da sicher noch nicht richtig.


    Gruß
    Dieter Jasper






    [Blockierte Grafik: http://www.qtl.co.il/img/copy.png][Blockierte Grafik: http://www.google.com/favicon.ico][Blockierte Grafik: http://www.babylon.com/favicon.ico]</iframe>

    Das verzeichnis von Osmosis heißt nicht mehr \osmosis-0.29 sondern (bei mir ) osmosis-0.34


    Füge am besten mal nach den osmosis-befehl eine pause ein.


    Oder führe die datei mit den aufruf "myfile.bat >>log.txt" um zu sehen welcher Fehler gemeldet wird.

    Zitat von Habe Handy

    Das verzeichnis von Osmosis heißt nicht mehr \osmosis-0.29 sondern (bei mir ) osmosis-0.34


    Bei mir auch. Jetzt rödelt der Rechner (Festplattenleuchte blinkt) und zeigt eine leere 'Dos-Box'.
    Warten wir´s mal ab, was dabei herauskommt.



    Gruß
    Dieter

    Zitat von meppen7

    Irgendwas mache ich da sicher noch nicht richtig.


    Bitte diese [color] und [/color] herausnehmen. War nur fuer die farbliche Hervorhebung gedacht.
    Ein


    TargetPath = result


    in der ini-Datei reicht. Bitte auch die Batch-Datei anpassen. Die ist dadurch falsch erzeugt worden. Ich korrigiere mal mein Beispiel.



    Julian

    Hallo Julian,
    für meinen PNA P4410 wünsche ich mir eine kräftigere Farbdarstellung der Kreisstraßen, da sie in der Bildschirmdarstellung nur sehr schwer von z. B. residental bzw. unclassified zu unterscheiden sind.


    Lässt sich da was machen?


    Gruß
    Dieter Jasper

    Einmal editiert, zuletzt von meppen7 ()

    Zitat von StefanDausR

    Hallo Julian,

    ich hatte zu dem Problem (aus einem anderen Grund) hier schon mal was geschrieben. Wäre das realisierbar?


    Habe ich eben implementiert und eingecheckt (revision 417). Die -bx,y,z,m Werte werden jetzt automatisch beim Erzeugen der Batch-Datei eingefuegt. Ob es richtig funktioniert, muss allerdings noch getestet werden.



    Julian

    Wäre praktisch wenn man OSM2POWM anweisen könnte die Karten in grössere Teile zu zerschneiden um schneller zu rechnen (da weniger kacheln doppelt berechnet werden)


    Beispiel belgium.osm (481.350.363 Bytes) vom 21.03.2010:
    osm2powm belgium.osm benötigt 3,5 Min für die Umrechnung.


    Wenn ich die mit osm2powm -s Belgium.osm erstellte Batch benutze dauert die Umrechnung 9 Min.



    Beim umwandeln von China ist mir aufgefallen das viele Kacheln teilweise unter erheblichen Zeitaufwand doppelt berechnet werden.

    Zitat von Habe Handy

    Wäre praktisch wenn man OSM2POWM anweisen könnte die Karten in grössere Teile zu zerschneiden

    Das kannst du doch in der ini-Datei einstellen!


    Zitat von Habe Handy

    Beim umwandeln von China ist mir aufgefallen das viele Kacheln teilweise unter erheblichen Zeitaufwand doppelt berechnet werden

    Das war der Grund für den neuen Parameter -bx,y,z,m


    Gruß,
    Stefan

    Zitat von StefanDausR

    Das kannst du doch in der ini-Datei einstellen!


    Genau, und zwar hier:

    Code
    MaxArea = 9
MaxPoints = 1000000


    MaxArea sagt, wie gross eine Ausschnitt sein darf, der an einem Stueck mit SM2POWM konvertiert werden darf (hier 9 Kacheln)
    MaxPoints sagt, wieviele nodes der Ausschnitt haben darf.


    Die beiden Werte so aendern, dass Dein Speicher gut ausgelastet wird. Damit entfaellt ein Teil der Aufteilungen mit osmosis und das Ergebnis wird schneller berechnet.


    Zitat

    Das war der Grund für den neuen Parameter -bx,y,z,m


    Richtig. Anzumerken ist, dass dieses z.Z. noch in der Entwicklerversion zu finden ist und erst in der neuen Version enthalten sein wird.


    Gruesse,
    Julian

    Hallo Julian,

    Zitat von J.Bugariu

    Anzumerken ist, dass dieses z.Z. noch in der Entwicklerversion zu finden ist und erst in der neuen Version enthalten sein wird.

    ich habe gerade africa mit der Rev. 417 umgesetzt. Die neuen Parameter scheinen einwandfrei zu funktionieren.


    Ich arbeite nun nicht mehr mit osmosis sondern mit bboxSplit. Damit zerteile ich mir die osm-Daten vorab in die 1°x1°-Kacheln (eigentlich ja 1.2°x1.2°) und setze diese dann mit OSM2POWM um. bboxSplit scheint schneller zu arbeiten als osmosis.


    Gruß,
    Stefan


    Edit:
    ich habe gerade einen Schnelltest mit bremen.osm und der OSM2POWM V. 0.2.5-dev4 (R419) am Devserver gemacht:
    1 Thread: last run... 11 sec
    4 Thread: last run... 8 sec

    Einmal editiert, zuletzt von StefanDausR ()

    Zitat von StefanDausR

    Ich arbeite nun nicht mehr mit osmosis sondern mit bboxSplit. Damit zerteile ich mir die osm-Daten vorab in die 1°x1°-Kacheln (eigentlich ja 1.2°x1.2°) und setze diese dann mit OSM2POWM um. bboxSplit scheint schneller zu arbeiten als osmosis.


    Hi,


    muss ich was an den Parametern aendern, oder kann man das 1 zu 1 austauschen?


    Zitat

    Edit:
    ich habe gerade einen Schnelltest mit bremen.osm und der OSM2POWM V. 0.2.5-dev4 (R419) am Devserver gemacht:
    1 Thread: last run... 11 sec
    4 Thread: last run... 8 sec


    Naja, da mehrere Threads nur bei der Erstellung der map-Dateien sinnvoll sind (Einlesen und preprocessing sind im singlethreaded Modus), sind bei so kleinen Dateien keine grossen Spruenge zu erwarten. Probier mal Griechenland komplett (passt bei mir noch in1GB Speicher rein). Da merkt man den Unterschied doch schon... Es sei denn, man hat nur einen Prozessor(kern), dann wird es sogar noch langsamer... ;)


    Julian

    Wäre schön wenn es regelmäßig einen Build der Entwicklerversion geben würde, denn ich bin beim Versuch die Version 420 zu compilieren gescheitert.


    Nach stundenlangen planlosen hinzufügen von Verzeichnissen in den Einstellungen von MiniGW Studio habe ich es zwar geschafft zu compilieren ohne Fehlermeldung, aber das compilierte Programm bleibt mit der Fehlermeldung "Der Prozedureinsprungpunkt "??1QVariant@@QAE@XZ" wurde in der DLL "QTCore4.dll" nicht gefunden." stehen.


    Liegt wohl daran das ich keinerlei Ahnung von Programmieren habe. Für MiniGW und QT habe ich die neueste Version genommen. Daher hat es (vermutlich) keinen Sinn zu versuchen zu erklähren was ich falsch gemacht habe.

    Hallo Julian,

    Zitat von J.Bugariu

    Naja, da mehrere Threads nur bei der Erstellung der map-Dateien sinnvoll sind (Einlesen und preprocessing sind im singlethreaded Modus)

    ok, also haiti:
    haiti.osm hat 330 MB und erzeugt 28 map-files
    in einem Durchgang:

    Code
    4 Thread: last run... 181 sec
1 Thread: last run... 217 sec


    vorher in 1x1 zerteilt:

    Code
    zerteilen in 28 osm-files:  81 sec
28 mal OSM2POWM: 197 sec
zusammen also 278: sec


    wobei ich beim Zerteilen nicht optimal gearbeitet habe.



    Gruß,
    Stefan

    Einmal editiert, zuletzt von StefanDausR ()