Geht das hinzufügen denn nicht über den bisherigen Weg, oder willst du den für andere Daten frei halten?
Wenn das Extrahieren und das Hinzufügen über des herkömmlichen Weg geht würde ich mich über eine Beta (oder was auch immer) freuen.
Es ist etwas mehr nötig - sonst hätten wir die gespeicherten Coastlines und die in den neuen OSM-Daten doppelt - das dürfte ein suboptimales Ergebnis liefern.
Schick mir doch mal eine Mailadresse über den OSM account. Hab Dir neulich eine Mail über’s Forum geschickt, aber die kam wohl nicht an. 
bye
Nop
Hab eine Nachricht über Hallo Nop,
könnte man die Jobeinstellungen nicht noch etwas mehr aufblähen, sodass man die wichtigen Arbeitsschritte manuell wählen könnte. Bspw. soll er die Datei aufteilen, soll er mkgmap aufrufen, soll er ein TYP-File erstellen. Um eine Fehlbedienung auszuschließen kann man ja alle darauf aufbauenden Schritte mit deaktivieren. Bspw. wenn ich das Aufteilen deaktivieren wird auch mkgmap mit deaktiviert. TYP-File wird aber erstellt. Dann würde ich bei dieser Einstellung eine verarbeitete osm-Datei haben und das TYP-File.
Man könnte aber auch nur mkgmap deaktivieren, weil man den Aufruf selber machen möchte oder man deaktiviert das TYP-File, weil man es nciht jedesmal neu erstellen will, wenn sich nichts am Style geändert hat.
Das würde den Composer deutlich vielseitiger machen
… und komplizierter. 
Komplizierter wird es dadurch nicht. Default sind die Schalter an, sodass du deine Karte erstellt bekommst.
Man könnte auch drüber nachdenken, diese Einstellungen über Kommandozeile zu übergeben. Wäre zwar für den Nutzer umständlicher, aber für einen Experten kein Problem. Das würde aber den Composer auch unübersichtlich machen.
Und soviel Komplizierter wird es auch nicht, wenn man jetzt anstatt des “großen” Garmin-Knopfes mehrere Knöpfe hätte.
Dann ist mir eben noch ein Fehler/Lücke beim Versionsupdate aufgefallen. Löscht man die config.props und startet dann den Composer führt er ein Update von Version 0.0 auf die aktuelle aus. Danach ist der Composer aber im A**** und hat keine Icon mehr. Hier wäre es schön, wenn eine Sicherung eingebaut wird. Am besten wäre es natürlich, wenn der Composer die vorhandenen Einstellungen bei einem Update zipt oder anderweitig sichert. So als DAU-Schutz für Leute, die kein regelmäßiges Backup des Composers machen.
EDIT:
Noch etwas zum Hintergrund des ersten Vorschlags: Ich finde, dass der Composer ein super Werkzeug zum erstellen von Styles ist, allerdings beim ersellen der Karte in manchen Fällen schlechter bzw. ressourcenhungriger ist als andere Programme.
Bspw. könnte man dann den Composer auch einfach nur dazu verwenden, ein TYP-File zu erstellen oder aber die verarbeitete Datei _data.osm in anderen Programmen weiter zu verarbeiten.
Beim Composer ist es nur Möglich alles oder nichts zu bekommen, was ich schade finde.
Hallo an alle,
ich hab ein Problem seit ca. 2 Wochen (bemerkt). Ich habe einige neue Wander-Routen angelegt welche alle eine osm-ID mit nunmehr 7 Stellen (zB. Relation Nr. 1022092) besitzen, bisher waren die Werte mit max 6 Stellen aktuell, diese Grenze ist nun überschritten. Ausschließlich diese werden beim Download nicht in die route.tbl übernommen. Gibt es eine ID-Stellenbegrenzung beim Programm?
Log-Ausschnitt:
Downloading (3 attempts) http://api.openstreetmap.org//api/0.6/map?bbox=12.299999999999999,46.1,12.399999999999999,46.2
java.lang.IllegalArgumentException: index capacity exeeded 1022092
Updating record 82 in index Settings/nach Name
Updating record 82 in View Settings
Updating record 82 in index Settings/nach Name
Updating record 82 in View Settings
Die Meldung kommt auch im weiteren für andere, nicht von mir erstellte 7-stellige Relationen. Es tritt in 082 + 083 auf.
Hat jemand von Euch ebenfalls dieses Problem?
Grüße
Frank
In der config.props wird die aktuelle Version verwaltet. Wenn Du die zerstörst, kommt Composer natürlich ins Schleudern. Ein Backup wird in der Anleitung ausdrücklich empfohlen - das muß der Anwender dann schon selber machen. 
bye
Nop
Stimmt. Es ist zwar keine absichtliche Begrenzung, aber der Teil, der beim Zusammenbasteln der Download-Segmente prüft ob eine Relation schon da ist, kommt tatsächlich mit IDs über 1000000 nicht zurecht.
Ist in 0.84 gefixt. Planetfiles sind von dem Problem nicht betroffen.
bye
Nop
I am receiving following error message:
java.lang.IllegalArgumentException: index capacity exeeded 1029651
over 40 times while running 0.83 (the number differs but remains over 1 million)
Added to the message is (just one example)
at nop.osm.PresenceIndex.getPage(PresenceIndex.java:40)
at nop.osm.PresenceIndex.contains(PresenceIndex.java:51)
at nop.osmc.generator.RegionMapper.downloadRegion(RegionMapper.java:109)
at nop.osmc.generator.Mapper.generate(Mapper.java:172)
at nop.osmc.MapComposer$12.act(MapComposer.java:378)
at nop.gui.MenuThreadAction.run(MenuThreadAction.java:27)
at java.lang.Thread.run(Unknown Source)
The “java.lang.IllegalArgumentException” is explained in the troubleshooting documentation as
mögliche Ursache:
durch Arbeiten an der Kartenobjektliste wurde eine Verknüpfung zu den Renderregeln zerstört
Lösung:
Liste der Renderregeln mit der Vorgabe “alle Objekte” aufrufen.
rot hervorgehobene Einträge heraussuchen und Verknüpfungen reparieren
Sind keine roten Hervorhebungen sichtbar, Composer speichern/beenden und erneut starten. Daraufhin sollten die fehlerhaften Einträge rot markiert sein.
I tried this: Es gab keine rot markierte Objekte.
Two questions:
- Is this something that I can be happy with; i.e. it is a minor failure in some osm-data-tags
or - Am I making a mistake?
Will be thankful for any suggestions/Hilfe.
Antwort kann in Deutsch sein
Grüß an alle
David Perrins
Das ist das gleiche Problem wie in den vorhergehenden Posts beschrieben. In V0.84 gefixt, mit der aktuellen Version muß man vorübergehend auf ein Planetfile ausweichen.
bye
Nop