Hallo!
Der Map Composer ist in der Version 0.83 verfügbar. Diese Version bringt ein paar Neuerungen:
Die komplette Historie und den Download Link findet Ihr auf der Homepage von Composer.
http://composer.waldpfa.de/
viel Spaß damit
Nop
Super, Danke für deine Arbeit und Mühen!
Könntest du noch kurz erklären, wie das mit dem Batch-Modus funktioniert?
Braucht man spezielle Renderregeln für die Meeresflächen oder reicht es aus auf 32 das Meerespolygon als Kartenobjekt zu haben?
Hab’s inzwischen in der Anleitung nachgetragen.
Super…der Batch-modus ist Klasse! Großes LOB mit Bienchen 
Sinvolle Ergänzungen wären eventuell, dass auch die Verarbeitungsfenster nicht erscheinen und eine Anzeige der Bearbeitungsdauer.
Weiterhin wird eine generateTime.html-Datei im public-Verzeichnis angelegt, in der sich das aktuelle Datum befindet. Wofür ist die gut?
Das mit den Fenstern ist kniffliger - und ich bin eigentlich ganz froh, wenn ich bei mehrstündigen Prozessen sehen kann wo sie stehen.
Bearbeitungsdauer ist eingebaut (0.84).
Das ist das Datum der OSM-Daten, falls man es sich beim Composerlauf gemerkt hat. Dann mußt Du Dir nicht merken, von welchem Stand Deine Karten sind.
bye
Nop
Hallo
ich habe mal versucht ne Karte zu generieren. Jedoch bleibt der Composer beim “Garmin Karte wird zusammengestellt” mit NullPointer Exception hängen. Was mache ich da falsch?
D:\www\GPS\OSM\OSMComposer\map_composer_083>java -Xmx1100M -cp map_composer.jar
ndsc15.jar;nop.jar;stax-1.2.0.jar;colorpicker.jar;bzip2.jar nop.osmc.MapCompose
written 92517
Time for analysis 1 min
rate 5763 (5763) queue: 501 hits: n=14723 c=53874 a=18124 l=93
Time for compilation 1 min
15.05.10 18:34 java.lang.NullPointerException
15.05.10 18:34 Exception Main loop
java.lang.NullPointerException
at nop.osmc.generator.garmin.GarminMapper.composeMap(GarminMapper.java:
32)
at nop.osmc.generator.garmin.GarminMapper.generate(GarminMapper.java:75
at nop.osmc.generator.Mapper.generate(Mapper.java:227)
at nop.osmc.MapComposer$12.act(MapComposer.java:378)
at nop.gui.MenuThreadAction.run(MenuThreadAction.java:27)
at java.lang.Thread.run(Unknown Source)
MfG
Achim
Stimmt auch wieder. Diese Info auch in die Kommandozeile zu packen ist wahrscheinlich deutlich zu aufwändig. Schön wäre es halt nur, dass dann keine Fenster mehr aufpoppen und sich den Fensterfokus klauen…Das stört immer so beim Film gucken 
Könnte man noch anzeigen a) die Gesamtnodes, -ways und -routen und b) das ganze pro Kachel. Jewils immer am Ende der jeweiligen Verarbeitung.
Achso…das sagt mir immer das Dateidatum Aber damit kann man wohl auch leben.
Ansonsten bleibt im tmp-Ordner immer eine contour_sample.osm zurück.
Die statistics.txt im data Ordner scheint mir auch ein Relikt vergangener Versionen. Ihre Erstellung ist im übrigen unabhängig von der Statistik-Einstellung im Job.
Das wäre ein Hinweis auf einen ungültigen Pfad für das Ausgabeverzeichnis unter Einstellungen/Garmin/Kartenverzeichnis.
bye
Nop
Was ich noch vergaß…
Der Composer legt bei mir auch immer eine Ordnerstruktur D:\Maps\Mapnik an.
Der Composer liegt bei mir unter D:\Openstreetmap\map_composer.…
Hallo Nop,
vielen Dank, das wars.Ich dachte, er legt das Verzeichnis an.
Ich habe noch einen seltsamen Effekt. Ich habe einen Kartenausschnitt. Im oberen Drittel endet am linken Rand ein Fluß (Blau). Dieser wird dann am linken Rand senkrecht nach untengezeichnet und geht dann in einem anderen Fluß wieder in die Karte. Dargestellt in Mapsource.
MfG
Achim
Hallo Achim,
kann es sein, dass es der selbe Fluss ist und das beide Stellen zu einem Weg-Segment gehören? Dann liegt es am Beschneiden mittels osmosis Seitens Geofabrik. Dagegen hilft meines Wissens nur das Benutzen eines größeren osm-Files, aus dem man dann ein Rechteck ausschneidet.
Hallo Henning,
danke für die Antwort. Es ist nicht der gleiche Fluß. Aber er mündet außerhalb des Darstellungsbereich in den ersten. Da ich in der Übungsphase bin stört das aber nicht.
Noch ne Frage an den erfahrenen Anwender: Was muß ich tun, dass zB. wenn ich im Wizard eine Flächendarstellung (Ortschaft) oder Line (Track2) in der Darstellung ändere, dass das durchlägt und in Mapsource verändert dargestellt wird. Klar Mapsource beenden und nach der Generierung neu starten. Das wird aber nur verändert, wenn ich im Garmin-Teil den Dateinamen ändere. Oder muß ich da was explizit löschen, dass das verändert generiert wird?
Viele Grüße
Achim
Hallo,
MapSource legt einen Cache der von ihm dargestellten Kacheln an und holt sich bevorzugt dorther die Daten. Es bekommt also erstmal garnicht mit, dass sich die Daten geändert haben. Nun gibt es 2 Möglichkeiten das zu ändern.
Den Detailierungsgrad in MapSource hin und her stellen
Mapsource über eine Batch-Datei starten, in der man vor dem Aufruf von MapSource den Cache löscht. Dieser liegt irgendwo in dne User-Daten des Windows-Benutzers.
Ich habe beides mal gemacht. In meiner Probieren-Phase ging mir irgendwann 1) auf die Nerven udn ich bin auf 2) umgestiegen. Mittlerweile ändere ich nicht mehr allzu viel und ich nutze lieber wieder den Cache um den Rechenaufwand zu verringern.
Hallo
noch eine Frage : Wie kann ich “routingfähige” Karten erzeugen? Reicht da das Häkchen bei den Einstellungen im Garmin-Ordner nicht? Was muß ich da tun?
Bin für Tipps dankbar.
Viele Grüße
Achim
Wenn du das Routing-Häkchen gesetzt hast, werden bei den Renderregeln für Wege bei manchen (den unterstützten ID’s) zusätzliche Optionen freigeschaltet, in denen man RoadSpeed und RoadClass angeben muss. Diese Parameter ebinflussen dann dass Routing. Damit muss man dann ein wenig rum experimentieren, bis es den eigenen Wünschen genügt.
Hallo,
so nach ein paar Stunden herumprobieren mit dem Batch-Modus wollte ich euch mal meine Erfahrungen mitteilen.
Anzeige der Verarbeitungsdauer erreicht man auch über die batch an sich.
Beginn der Zeitzählung:
@ECHO OFF & setlocal
for /f "tokens=1-3 delims=:," %%i in ("%time%") do set /a start=%%i*3600+60*(1%%j %% 100)+1%%k-100
@ECHO ON
Ende und Ausgabe der Dauer:
@ECHO OFF
for /f "tokens=1-3 delims=:," %%i in ("%time%") do set /a stop=%%i*3600+60*(1%%j %% 100)+1%%k-100
Set /a DauerInMin=(stop-start) / 60
Set /a UndRestInSecs= (stop-start) - DauerInMin*60
Set /a FmtSecs=UndRestInSecs+100
Set /a FmtMins=DauerInMin+100
@Echo Laufzeit: %FmtMins:~-2%:%FmtSecs:~-2%
Weiterhin bin ich zu dem Schluss gekommen, dass es sinnvoller ist, die Batchaufrufe am Ende eines Jobs gleich in die Composer-Start-Batch zu integrieren.
Bspw:
Das ist nötig, weil die Composer-Start-Batch logischerweise nur solange wartet, bis der Composer fertig ist, nicht aber die Batch-Bearbeitung im Anschluss abwartet. Es läuft dann daraus hinaus, dass der PC je nach Batch mehrere Dinge gleichzeitig machen muss, die ihn aber jeweils alleine schon voll auslasten. Bei mir ist das ein Kompressionsvorgang und dann das nächste Planetfile-Schneiden im Composer.
Wie es sich verhält, wenn man dem Composer mehrere Jobs gleichzeitig übergibt hab ich nicht ausprobiert, weil ich es für nötig halte, dass der Composer nach einem durchlauf neugestartet wird, um wieder genügend RAM zu haben. Das kann aber bei kleinen Gebieten anders sein.
Hallo nop,
hab mit der 083 Testläufe gemacht. Das Problem mit unvollständigen Waldflächen bei Multipolygonen besteht nach wie vor. Haken bei Meeresflächen generieren hab ich gesetzt, spielt dafür aber scheinbar keine Rolle. Hast Du noch ne Idee…?
Viele Grüße
Frank
(osmFrank)
Mysteriös. Kannst Du mir nochmal eine aktuelle Koordinate und Beschreibung oder OSM ID von solchen Wäldern geben? Dann seh ich’s mir nochmal genauer an.
bye
Nop
Ich hätt’ da auch nochmal was…
Meine Node-Grenze liegt bei 2.000.000. Die wird auch eingehalten beim Teilen der Kachel. Nun hab ich aber 3 _garmin.osm-Dateien, die 450-700mb groß sind. Der Rest bleibt bei max ~200mb. Dies ist auch die einzige Karte, wo das auftritt. Dänemark und Deutschland lief problemlos.
Die Dateien haben die Kennungen: 00287_0601_31_35, 00286_0672_32_41 und 00285_0636_33_36.
Das ist grob gesagt der südliche Teil der Finnisch-Russischen Grenze oder anders gesagt, wenn ich mir das auf Mapnik anschaue ist da nicht sonderlich viel los.
mit der 0.82 hab ich die Region bereits funktionsfähig gerendert.
EDIT: In einem weiteren Versuch taucht nurnoch eine übermäßig große Kachel auf: 00286_0601_32_32_garmin.osm mit 740mb
EDIT2: Mein Polygon-File endet im übrigen kurz hinter der finnischen Grenze. St. Petersburg gehört auf jeden Fall nicht mehr dazu.
und hier nochmal die mkgmap-Meldung:
uk.me.parabola.imgfmt.MapFailedException: There is not enough room in a single garmin map for all the input data
The .osm file should be split into smaller pieces first.
at uk.me.parabola.imgfmt.app.BufferedImgFileWriter.ensureSize(BufferedImgFileWriter.java:192)
at uk.me.parabola.imgfmt.app.BufferedImgFileWriter.put(BufferedImgFileWriter.java:160)
at uk.me.parabola.imgfmt.app.trergn.Polyline.write(Polyline.java:150)
at uk.me.parabola.imgfmt.app.trergn.RGNFile.addMapObject(RGNFile.java:140)
at uk.me.parabola.imgfmt.app.map.Map.addMapObject(Map.java:242)
at uk.me.parabola.mkgmap.build.MapBuilder$ShapeAddFilter.doFilter(MapBuilder.java:1077)
at uk.me.parabola.mkgmap.build.LayerFilterChain.doFilter(LayerFilterChain.java:57)
at uk.me.parabola.mkgmap.filters.RemoveEmpty.doFilter(RemoveEmpty.java:61)
at uk.me.parabola.mkgmap.build.LayerFilterChain.doFilter(LayerFilterChain.java:57)
at uk.me.parabola.mkgmap.filters.PolygonSplitterFilter.doFilter(PolygonSplitterFilter.java:57)
at uk.me.parabola.mkgmap.build.LayerFilterChain.doFilter(LayerFilterChain.java:57)
at uk.me.parabola.mkgmap.filters.DouglasPeuckerFilter.doFilter(DouglasPeuckerFilter.java:101)
at uk.me.parabola.mkgmap.build.LayerFilterChain.doFilter(LayerFilterChain.java:57)
at uk.me.parabola.mkgmap.filters.SizeFilter.doFilter(SizeFilter.java:50)
at uk.me.parabola.mkgmap.build.LayerFilterChain.doFilter(LayerFilterChain.java:57)
at uk.me.parabola.mkgmap.filters.RoundCoordsFilter.doFilter(RoundCoordsFilter.java:81)
at uk.me.parabola.mkgmap.build.LayerFilterChain.doFilter(LayerFilterChain.java:57)
at uk.me.parabola.mkgmap.filters.PreserveHorizontalAndVerticalLinesFilter.doFilter(PreserveHorizontalAndVerticalLinesFilter.java:61)
at uk.me.parabola.mkgmap.build.LayerFilterChain.doFilter(LayerFilterChain.java:57)
at uk.me.parabola.mkgmap.build.LayerFilterChain.startFilter(LayerFilterChain.java:75)
at uk.me.parabola.mkgmap.build.MapBuilder.processShapes(MapBuilder.java:946)
at uk.me.parabola.mkgmap.build.MapBuilder.makeSubdivision(MapBuilder.java:653)
at uk.me.parabola.mkgmap.build.MapBuilder.makeMapAreas(MapBuilder.java:587)
at uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:195)
at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:96)
at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:61)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:189)
at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:186)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Exiting - if you want to carry on regardless, use the --keep-going option
Hm, ich würde mal vermuten, daß die Daten in der Gegend anders strukturiert sind oder die räumliche Anordnung eine ungewöhnliche Form hat und deshalb die Abschätzung durcheinanderkommt. Ich habe sie anhand der Verhältnisse in Deutschland kalibriert.
Verbessert sich das Verhalten, wenn Du einfach mal auf 1500k oder noch weiter runtergehst für diese Gegenden?
bye
Nop