Hi!
Hast Du geprüft, ob die Priotät der Flächen in den Kartenobjekten paßt? Prio von Platz muß größer sein als die von Stadt, sonst wird es drunter gerendert.
bye
Nop
Ich denke immer noch, daß es möglich sein müßte, exakt so zu schneiden wie das mkgmap tut, wenn man wüßte worauf mkgmap achtet.
bye
Nop
Ist aktualisiert. Verständlich so?
bye
Nop
Ich habe mit --generate-sea=extend-sea-sectors auch recht gute Erfahrungen gemacht. Meine neuste Garminkarte ist damit gerechnet und bis auf eine abgesoffene Kachel mitten in den Alpen hat das auch funktioniert. Composer wird in der 0.83 deshalb eine eingebaute Unterstützung dafür bekommen, die dann auch die Küstenlinien hartcodiert beibehält.
Eine Verfeinerung der Tagfilter steht schon längere Zeit auf dem Plan, momentan will ich aber keine tieferen Eingriffe in Basismechanismen machen, dafür ist das Wetter zu schön. 
Der See ist bei mir auch ausgetrocknet. In meiner lokalen Version macht Composer exakt gar keine Anpassungen an Multipolys mehr, ändert aber nix dran. Von daher wär das doch vielleicht mal was für die mkgmap-Liste.
bye
Nop
Ähm…an das wiki hatte ich garnicht gedacht 
sondern primär an den Hilfetext im Composer selbst, der kommt, wenn man mit der Maus über das Textfeld geht. Aber die Beschreibung ist mMn gut verständlich.
Der Nachteil bei generate-sea im Vergleich zu eigenen See-Polygonen ist nur der, dass er das Meer nur da zeichnet, wo auch Küstenlinien sind. Wenn man bspw. Deutschland aus der germany.osm erstellt, hat man an der Küste links udn rechts nicht bis zum Kartenrand Wasser, sondern eben nur bis zur jeweiligen Grenze, wo die Daten aufhören. Daher nehme ich nun immer europe.osm und schneide mir das komplette umschließende Rechteck von Deutschland aus.
Bzgl. des See’s ist mir noch was eingefallen. Ich hab mir den mal in josm genauer angeschaut. Der hat ja auf den “Wegen” nur ein fixme-Tag, welches der Composer per default ignoriert. Könnte es sein, dass dadurch der Weg gelöscht wird und somit die Multipolygon-Relation hinfällig wird? Wenn dem so ist, müsste man die Relationen zuerst durchkauen und diese Wege dann vom ignoriert werden schützen.
Nein. Composer entfernt keine Geometrie, nur die nicht verwendeten Tags.
bye
Nop
Hallo Walter,
ich hab das gleiche Problem mit einer großen Waldfläche (Sächsisch-Böhmische Schweiz) ID23872 und keine Lösung. Hab schon mehrfach verschiedene Teilstücke verbunden und andere getrennt um die max. Punktzahl nicht zu überschreiten. Immer nur andere Fehlerdarstellungen der Fläche…
Die Teilpolygone werden einfach an den Endstücken “geschlossen” und bei Inseln wirds ganz verrückt.
osmFrank
Vielen Dank Nop für die Aufnahme in die ToDo Liste.
Beim Composer sind ja wirklich in kurzen Intervallen immer wieder tolle Neuerungen zu erwarten.
Die Kachelgrenzen werden auch noch irgendwie lösbar sein, wir haben nur noch nicht die richtige Idee dazu gefunden.
Bezüglich der Meerespolygone werde ich auf die Version 0.83 warten.
Ich habe zwar nicht verstanden, was da genau gemacht werden soll, aber freuen kann ich mich ja trotzdem schon mal drauf.
Die Anzeige von Plätzen funktioniert jetzt, es lag wohl an der Reihenfolge.
Der ausgetrocknete See ist dem Anschein nach kein reines mkgmap Problem.
In meiner Anfrage im Forum wurde rückgemeldet, dass der See mit mkgmap angezeigt wird.
Ich habe es mal mit der All-In-One probiert, dort ist der See inkl. Schilfgürtel richtig dargestellt.
Irgendwo muss beim Composer doch noch etwas verloren gehen, was von mkgmap benötigt wird.
Hallo Frank,
ich habe generell den Sinn der MP noch nicht so ganz verstanden.
Da habe ich eine Linie, die ist ein See, aber ich trage kein TAG für den See dort ein.
Das mache ich irgendwo anders - in einer Relation, wo es dann erst wieder dorthin übertragen werden muss, wo es eigentlich hingehört.
Kein Wunder, dass die meisten Mapper damit mehr oder weniger große Probleme haben.
Walter
Genau wie bei mir, All-In-One zeigt das Waldgebiet incl. Inseln richtig an…
Ich denk die Multipolygone haben schon ihren Sinn: Wie sollte mann sonst Waldlichtungen ohne viel Aufwand einpflegen können?! Oder in Deinem Fall Inseln, ja sicher könnte man da mit Layernummern arbeiten, aber das erscheint mit doch zu umständlich… und die Gesamtlänge ist nicht mehr begrenzt, man unterteilt das einfach. Die Mehrheit wird das sicher nicht auf Anhieb verstehen, da gebe ich Dir vollkommen recht!
osmFrank
Ok, hab die Ursache gefunden. Da war doch noch ein hammerharter Bug im Composer. Gefixt.
bye
Nop
Hallo Nop,
Das freut mich ehrlich, muss ich nicht mehr experimentieren!
Wann kann man denn mit der 083 rechnen (würde meine Wandergegend gern “aufforsten”), oder ist das in der aktuellen jetzt 082 schon drin?
osmFrank
Nein, das kommt in der 0.83. Ich bin noch an zwei Sachen am Basteln, ich würde mal so vermuten in einer Woche.
bye
Nop
Hallo Nop,
prima und vielen Dank, der Composer ist echt ne Wucht (und sein Programmierer auch).
So viele Updates in derart kurzer Zeit, jedesmal mit einer Menge an Neuerungen …
da könnte sich so manches kommerzielle SW-Produkt eine Scheibe davon abscheiden.
Ich bin derzeit gerade dran, Europa in einige große Blöcke zu teilen. (ganz Europa stürzt beim Generieren leider ab)
Mein Österreich-Plan hat derzeit in der Länge 8° und in der Höhe 3° (kann man das als 24°² bezeichnen?).
Mein größter Plan liegt derzeit bei 10° x 6° (60°²), das ist vermutlich aber auch noch nicht das Maximum.
Wir groß sind denn derzeit die maximalen Gebiete, die mit dem Composer problemlos bewältigt werden können?
Gibt es irgendwelche Parameter bei den Einstellungen (Nodecache, Objekte/Kachel, Kontournodes) die man dafür optimieren sollte.
Ein Problem habe ich derzeit mit Skipisten.
Gibt es jemanden, der das TAG piste:difficulty=easy… bereits auswertet?
Es ist das erste mal, dass ich ein TAG mit : verwende, und es will einfach nicht dargestellt werden.
Walter
Hallo Walter,
über den Nodecache steuerst du die Geschwindigkeit. Höhere Werte=Schneller=mehr RAM-Verbrauch.
Mein größtes Gebiet ist/war DK/D/A/CH/CZ und etwas PL. Sowi vor laanger Zeit, mit v0.7x mal ganz Skandinavien.
Letzteres geht von 55°-72° und von 4°-32°…aber da ist auch mehr Kontur als Daten 
Hallo Henning,
für D/A/CH benötige ich derzeit 4 getrennte Kacheln.
Keine Ahnung, was ich falsch mache, dass größere Gebiete bei mir abstürzen.
Ich komme mit den Kacheln aber auch gut zurecht, solange das Routing nicht besser funktioniert.
Nodecache habe ich derzeit auf 1000 gesetzt.
Wer stellt derzeit TAGs mit : bereits erfolgreich dar und kann bestätigen, dass der Doppelpunkt keine Probleme macht.
Ich komme bei meinen Skipisten mit piste:difficulty nicht so recht weiter.
Beim Routing habe ich recht seltsame Beobachtungen gemacht.
Ich werde teilweise beim Routing für Auto/Motorrad gegen die Einbahn oder auf Fußwege geroutet.
Es passiert nur ab und zu, kommt aber immer wieder vor.
Die entsprechenden Wege zeigen keine Auffälligkeiten.
Hat jemand bereits ähnliches beobachtet?
Walter
Ich erzeuge DACHIT am Stück. Nodecache steht auf 2000.
Auf welche Art und Weise stürzt es denn bei Dir ab?
Der Doppelpunkt sollte überhaupt keinen Unterschied machen - das ist ein ganz normaler Buchstabe.
bye
Nop
Hallo NOP,
die letzten Meldungen im Composer Log Window lauten:
osmosis done
Starting region xxx
Newer input file detected
In der Statuszeile steht: Analysiere Daten für xxx
Der Button “Generieren” bleibt disabled, der Composer generiert aber nicht weiter, läßt sich jedoch bedienen.
Die letzten Dateien in \data sind alle 0 Byte groß:
zum Startzeitpunkt: pois.osm, commands.log,
ca. 1h später: xxx_routes.osm, xxx_relations.osm
Die Datei \input\xxx_input.osm wird korrekt geschrieben.
Der Speicherverbrauch (3GB RAM) steigt von 30% auf 70% und bleibt dort.
Auf der Festplatte ist genügent Platz frei.
Ich hoffe, du findest mit den Angaben die Ursache.
Walter
Hallo Walter!
Hast du mal in den Error-Log oder in das Komandozeilenfenster geschaut, evtl. steckt da ja der Fehler. Ansonsten setz doch mal diese Grenzwerte auf die Defaults zurück. Könnte ja sein, dass dem Composer der RAM ausgeht. Unter Win32 sind das ca. 1,2-1,5Gb pro Anwendung. Oder hast du ein 64bit-System?
Hallo Nop!
mir ist aufgefallen, dass es ab und an mal vorkommt, dass der Composer mkgmap die osm-Dateien doppelt übergibt, sodass die doppelte Anzahl an Kacheln berechnet werden. Ich habe aber noch keine Regelmäßgkeit feststellen können. Das Problem trat aber schon bei mehreren Versionen des Composers auf.
Hallo Nop,
mir ist eben noch eine Idee gekommen, wie man den Composer verbessern könnte.
Wenn man den Composer komplett weitergeben möchte oder ihn umziehen lässt muss man alle Pfadangaben ändern. Hier wären relative Pfade super, da sich an der Pfadstruktur innerhalb des Composerordners nichts ändert.
Da es recht schwer ist zu erkennen, ob der User nun einen falschen Pfad eingegeben hat, oder ob es ein relativer Pfad sein soll, würde ich dies über einen Ausdruck regeln, den der Composer dann mit dem Pfad zur osm_composer.jar ersetzt.
Bsp.:
{ComposerPath}Tools\mkgmap.jar wird dann intern ersetzt mit Z:\Composer\Tools\mkgmap.jar
diesen Dummy-Parameter sollte man dann überall nutzen können, wo man einen Pfad angeben kann.
EDIT: Weiterhin wäre es schön (da einheitlich) wenn die Pfadangaben zum mkgmap-Option-File und zum Polygonfile ebenfalls komplett angegeben werden müssten.
Hm, sowas könnte man einbauen. Allerdings nicht relativ zum JAR-File, sondern relativ zum Arbeitsverzeichnis beim Start.
Allerdings muß ich sagen, vielleicht gibt es bald überhaupt keinen Composer mehr bei OSM.
http://gis.638310.n2.nabble.com/OSM-composer-not-open-source-td4989116.html#a4989116