map composer 0.85 für Anfänger

Die Fehlermeldung besagt, daß unter “Ebenen” keine zu finden ist, die Wandersymbole aufnimmt.

Schau mal unter “Ebenen”. Dort solltest Du eine Finden, die “hiking marks” heißt.

Was steht da in der ersten Spalte bzw. im Dialog unter “Typ”?

bye
Nop

Hi Nop

Vielen Dank daß Du mir helfen willst.

Der Layer existiert jedenfalls:

Daran liegts also schonmal nicht :frowning:

Nun habe ich einen Versuch mit meinem alten PC (WinXP Home 32Bit) gemacht; und was soll ich sagen:

**Da funktionierts ! **
:slight_smile: :slight_smile: :slight_smile:

Also werde ich nun auf dem Win7-Rechner nochmal alles runterschmeissen und neu laden.

Wenn ich dann irgendwann herausfinde was an dem Win7-Rechner blockt melde ich das Ergebniss hier.
Vieleicht hats was mit der Java-Version zu tun o.ä.
Mal sehen

Hallo
wisst Ihr was ?
Fehlermeldung nach start
mkgmap call faild?
Beste Grüße

mkgmap konnte nicht aufgerufen werden

Dem ist wahrscheinlich nicht so. Denn in früheren Verarbeitungsschritten kann bei mir mkgmap ausgeführt werden. Nur das abschließende Erstellen der Karte scheitert. Das liegt wahrscheinlich an einer falsch vorbereiteten osm Datei, da diese sich mit mkgmap nicht umwandeln lässt. Rohe unbearbeitete OSM Dateien stellten aber kein Problem dar.

Hallo
Die Frage ist ja warum nicht
Mapcomposer soll die Datei ja laden erst macht er aber nicht ?
beste grüße

Mapcomposer startet ich kann aber keine Karte erstellen?

das file europe.osm.pbf liegt in mapcomposer/Input
Beste Grüße

@ win32netsky
Benutzt Du tatsächlich composer 0.85 oder doch den aktuellen 0.86?
Fehlermeldung?
Zu finden in der “Konsole” (schwarzes Fenster mit weißer Schrift)

Möglicherweise ein out of memory Effekt.

mkgmap call failed direkt nach Start ist merkwürdig.
Da würde ich erst mal die Verknüpfungen prüfen.

Gilt für Composer 0.86:
Wenn die Fehlermeldung ganz am Ende auftaucht, hängt das irgendwie mit der Erstellung von “Sekundärprodukten” wie Zipfile oder gmapsupp.img zusammen.
Wenn ich die Erzeugung dieser Dateien deaktiviere, bleibt bei mir die Fehlermeldung aus.
Trotz dieser Fehlermeldung (falls Zipdatei und gmapsupp.ing doch angehakt) landen die Kartentiles im Outputverzeichnis und können mit Hilfe von mapsettoolkit in MapSource eingebunden werden. Von dort lassen sie sich in das GPS-Gerät übertragen.

In früheren Composer-Versionen hat die Erstellung von Zipfiles und gmapsupp.img funktioniert.
Warum das jetzt nicht mehr klappt, weiß ich nicht.

Das Einbinden in MapSource habe ich schon immer mit MapSetToolkit gemacht.

Gruß
tt

Das klappt bei mir auch mit 0.86, zumindest mit dem Beispielgebiet des MC.

Liegt vermutlich daran, wie groß das Kartengebiet bzw das Datenvolumen ist.

Gruß,
ajoessen

Als ich das damals probiert hatte, konnte ich das Beispielgebiet auch durchrechnen. Allerdings hat ein kleines Gebiet in Tschechien nicht funktioniert. Das lag aber nicht am Gebiet sondern an der von Mapcomposer erstellten OSM Datei. Jedenfalls war die Fehlermeldung, das dort Wege waren die nicht standardkonform waren und mit der mkgmap nicht zurecht kam.
Wenn ich das gleiche Gebiet mit osmconvert ausgeschnitten habe, dann lief das gleiche mkgmap einwandfrei. Die Daten waren aber auch wesentlich kleiner und ohne Wanderwege und Höhenlinien.
Fehlermeldung im Log waren nur mkgmap failed

Da gibt es bestimmt noch bessere Diagnosemöglichkeiten. Das muß aber nop selber beantworten.
Es wird wohl irgendeine tagkombination sein, die er so nicht erwartet hat. Oder ein-Knoten-Wege oder ähnliches.

Gruß,
ajoessen

Was auch immer es ist. Irgendwie ist auch anderer Stelle sichtbar, daß irgendetwas hakt.
Ob das nun zusammenhängt oder nicht, kann ich nicht beurteilen.

Da mein Wunschgebiet innereuropäische Grenzen überschreitet und die Verarbeitung der kompletten Europadatei mit Composer auf meinem Rechner nicht läuft (out of memory), schneide ich die Europa-Datei (zunächst noch) mit pbftoosm zurecht. Die Extrakte werden dann ohne Mucken verarbeitet.

Wegen der immer größer werdenden Datenflut ermittelt die automatische Kachelaufteilung des Composers immer kleinere Gebiete. Auch ohne Höhenlinien paßt da an Ruhr und Rhein schon lange kein 1°x1° Ausschnitt in eine einzige Garmin-Kachel (max nodes 2000). Die Kachelgrößen sinken stellenweise bereits auf 0,3 Werte.
An den Schnittkanten stelle ich regelmäßig Probleme mit der Verarbeitung geschnittener (auch einfacher) Polygone fest. Entweder werden sie “verzogen” oder sie verschwinden ganz.
Da mich das stört, bin ich dazu übergegangen, die einzelnen Kartenausschnitte von Hand so auszubalancieren, daß die mich störenden kaputten Flächen weit genug im Innern der Karte liegen und dadurch wieder korrekt angezeigt werden. Liegen dann am Rand nur kleine Flächen, fällt es nicht weiter auf, wenn diese kaputt sind. Und in der Nachbarkarte werden sie ja korrekt dargestellt, weil sie dort wegen der Überlappung im Innern der Karte liegen. So kann ich die Karte(n) dann doch wieder gut nutzen. Naja, könnte!

Wenn ich mehrere Karten benötige, entstehen Probleme.

Leider sind die Kartenausschnitte nur mit einer Nachkommastelle justierbar. Zumindest beobachte ich, daß eine zweite Nachkommastelle beim Speichern der Region regelmäßig gerundet wird. Das ergibt sehr große Überlappungen der Einzelkarten und erhöht dadurch das Datenvolumen einer aus solchen Einzelkarten zusammengesetzten Karte ziemlich drastisch. Im Raum Essen/Ruhr bedeutet das, daß die Nachbarkarten die Karte jeweils um 1/3 ihrer Fläche überlappen. Mit anderen Worten 1/9 der Fläche wird einmal, 4/9 werden zweimal und 4/9 werden dreimal berechnet und übereinander geschichtet. Das etrex kommt mit so einem Datenvolumen an die Grenze seiner Leistungsfähigkeit. Beim Verschieben der Karte fällt es regelmäßig auf das Garminlayout zurück. Wenn ich geduldig bin/Glück habe bekrabbelt es sich nach einem Moment. Ansonsten stürzt es ab. Dem kann ich nur entgehen, wenn ich alle gerade nicht benötigten Karten deaktiviere und natürlich nicht zu viele Karten auf einmal lade. 2 gleichzeitig aktivierte Karten im Überlappungsbereich funktionieren.

Damit ich die Karten im etrex erkennen kann, benötige ich für jede Karte eine aussagekräftige Bezeichnung. Eine fortlaufende Nummerierung ist das wohl eher nicht.
Also erzeuge ich jedes Gebiet als Einzelkarte, installiere diese in MapSource und schicke sie von dort aus auf das Gerät.
Das ist ziemlich umständliche Handarbeit und MapSource (zumindest eine der alten Versionen/ Test mit der aktuellen erfolgt nächste Tage) bekommt bei dieser Konstellation mit der Suchfunktion Probleme.

Das ist alles andere, als eine zufriedenstellende Lösung. Aber auf eine bessere Idee bin ich bislang noch nicht gekommen.

Gruß
tippeltappel

Der einzige Weg wäre Reduzierung der Datendichte.
Ich habe keine Ahnung wie Garmin auf Transparente Karten reagiert, aber wenn du die Höhenlinien in eine eigene Karte auslagerst, hast du schon viel mehr Platz auf den Kacheln oder?

@ viw
Höhenlinien rendere ich schon lange nicht mehr mit, da ich den Composer offline benutze.
Was ich beschrieb sind alles Erfahrungswerte mit einer Kartenberechnung ohne Höhenlinien.
Reduzierung der Datendichte funktioniert demnach nur noch durch Filtern der Daten und somit Reduzierung der angezeigten Objekte.
Das ist aber leichter gesagt, als getan. Nehmen wir die Einzelgebäude.
Da könnte man inzwischen eine Menge Datenvolumen sparen, wenn man die rausschmeißt.
Jedoch möchte ich wenigstens die öffentlichen Gebäude behalten.
Da es verbreitet ist, vorzugsweise building=yes zu mappen, anstatt building=residential|museum|chapel|church|town-hall|library|school|university|etc., ist es ziemlich schwierig, einen Filter zu bauen, der die Gebäude zuverlässig ihrer Bedeutung entsprechend sortiert bzw. aussortiert.
Das Tag building:type und building:use ist nicht verbreitet genug, um damit einen zuverlässigen Filter anzulegen.

Composer erstellt eine Statistik der im Planetfile enthaltenen Tags. Was man nicht braucht, kann man in die Liste der ignorierten Tag schreiben.
Das ist aber wohl nur beim Erstellen der Planetfile-Extrakte von Bedeutung.
Was in die Karte aufgenommen wird oder auch nicht, bestimmen ja die Renderregeln.
Ich kann mir nicht vorstellen, daß nicht abgefragte aber in den Rohdaten enthaltene Tags das Datenvolumen der Kacheln beeinflussen.

Wie dann das Datenvolumen reduzieren?
Irgendwann mal bewußt ausgesuchte Karteninhalte dezimieren?
Das möchte ich eigentlich nicht.

Mein Wunsch an Nop:
Bitte wieder 2 oder gar 3 Nachkommastellen bei der Definition der Bounding-Box möglich machen.
Dann lassen sich die Kacheln wieder feiner justieren und kleinere Überlappungen definieren.
Kleinere Überlappungen=Reduktion der Kartendaten im GPS-Gerät

Viele Grüße
tippeltappel

Ich habs für mich so gelöst:

Wenn eine bestimmte Wanderroute fest steht, eine passende bounding-box-Abfrage auf das Landesextrakt loslassen, und nur diesen Ausschnitt rendern. Bei einer Reichweite von max 35km bekommt man da garantiert keine Datenprobleme :wink:

Für die Grobplanung und für Radtouren nutze ich die velomap-nrw. Die ist auch noch handlich, und unterstützt auch offroad-Routing.

Für Wanderwege werde ich im Winter mal was vergleichbares basteln. Die Symboldarstellung der hierzulande üblichen X- und A-Wege im Map Composer gefällt mir nämlich überhaupt nicht: Ein schwarzes Rechteck und das Routenkürzel irgendwo daneben. Auf dieser Karte ist das sauberer gelöst:
http://wiki.openstreetmap.org/wiki/DE:OSM_Map_On_Garmin/Cycle_map

Höhenlinien brauche ich draussen nicht. Da sehe ich auch so, obs rauf oder runter geht. Mir ist die Verwechslungsgefahr mit Wegen zu groß. Bei der velomap kann man sie in Mapsource und am Gerät dazu laden, und am PC habe ich die bei den Tiles sowieso jederzeit zuschaltbar.

Gruß,
ajoessen

Nachdem es zunehmend Probleme mit dem Schneiden von immer komplexeren Multipolygonen gibt habe ich Composer so umgebaut, daß er das Schneiden komplett mkgmap überläßt. Theoretisch sollte dann alles klappen. Die Version ist aber noch nicht veröffentlicht weil in der Praxis immer noch komische Effekte auftreten und ich nach dem kürzlichen Ausfall meines Servers noch dort beschäftigt bin.

Aber mit der Version wird auf jeden Fall alles anders. :slight_smile:

bye
Nop

Das stört mich auch schon immer. Leider liegt es daran, daß die Garmin-Geräte nur vordefinierte Texte haben und keine farbigen Texte und keine genaue Textpositionierung unterstützen. Bzw. daß ich keine Technik kenne das sauber zu erreichen. Dieselben Daten mit mapnik oder Kosmos gerendert produzieren astreine Markierungen.

Wenn mir jemand verraten kann, wie das doch funktioniert, wäre ich absolut begeistert das schnellstmöglich einzubauen. :slight_smile:

bye
Nop

Die von mir als Beispiel gezeigte CycleMap setzt doch Shield symolizer ein. Das ist für Textdarstellung wesentlich besser als das, was Map Composer zur Zeit macht. Auf Farbigen text kann ich zur not verzichten; aber die Bezeichnung darf nicht am flaschen Weg stehen.

Gruß,
ajoessen

Also baust Du Dir im Prinzip wie auch ich lauter Einzelkarten. Je nach dem, wo ich hin will, brauch ich davon halt mehrere in meinem Gerät. Da muß ich dann die verschiedenen Karten zu und wegschalten, damit das Gerät nicht abschmiert.

Die Textbasierte Wegmarkierung gefällt mir so schon lange nicht. Deshalb habe ich für die Buchstaben und Zahlen Täfelchen gebastelt, die wie die Symbole über eine eigene ID eingebunden werden. In den Radelkarten fiel mir kürzlich eine gute Idee auf: Zweistellige Ziffern werden durch die Kombination halbdurchsichtiger Täfelchen erstellt. Da in Nops Routenfreischaltung Vorder- und Hintergrund zu einer Tafel kombiniert werden können, muß ich da mal bei passender Gelegenheit mit experimentieren. Da geht bestimmt was. Auf diese Weise lassen sich für alle gängigen Zahlen- und Buchstabensysteme (gelb auf schwarz, schwarz auf weiß, blau auf weiß, grün auf weiß, weiß auf grün … ) Täfelchen bauen. POI-IDs gibt es genug dafür. :slight_smile: Wichtig ist dann nur, daß man darauf achtet, IDs für die Kombischildchen zu wählen, die in der G-Software mit den gleichen hartcodierten Eigenschaften ausgestattet sind. Wenn man dann noch für die Textbezeichnung die Schriftfarbe ausschaltet (leeres Feld wählen), läuft dieser Text am Weg in eckigen Klammern als Name mit und hängt nicht irgendwo quer in der Karte.

Gruß
tippeltappel

Danke Nop, für Deinen Einsatz!

Wäre natürlich fein, wenn die Schnitte dann weniger Fehler aufweisen würden.
Die Kartenausschnitte wenigstens bis 2 Stellen hinter dem Komma einstellen zu können, wäre trotzdem ganz praktisch. In den ganz alten Composerversionen waren mindestens 3 möglich. Warum das umgestellt wurde, hab ich irgendwie nicht mitbekommen.

Wegmarkierungen aus Zahlen und Buchstaben
Wie im vorausgehenden Post beschrieben, ist die Verwendung von kombinierbaren Täfelchen für Buchstaben und Zahlen ein Ansatz, den man mal verfolgen kann. Für 2-stellige Ziffern- und Zahlenkombinationen müßte das gut gehen. Es werden aber auch 3-stellige Kombinationen benötigt. Da wird’s dann schwieriger. Die einzelne Grafik darf ja eine bestimmte Maximalbreite nicht überschreiten. Mein WDE-Schildchen (allerdings keine Kombitafel, sondern aus einem Stück) ist mit gutem Willen zu erkennen. Und auch Schildchen wie z.B. A12 oder A40 funktionieren. Für häufig auftretende Zahlen- und Buchstabenkombinationen hab ich trotz der großen Anzahl an benötigten IDs bislang Einzelschildchen in Verwendung. Einige Farbvarianten ignoriere ich und ersetze sie. Gelb auf weiß kann man beispielsweise eh nicht lesen. Da die Beschriftung dieser Schildchen in der Objektliste gleichzeitig als Name eingetragen wird, läßt sich dieser mit Hilfe des Mauszeigers bei Bedarf aufrufen, sofern die Routenbezeichung durch oben beschriebenen Trick an den Weg gelegt wird. Dreistellige Routennummern stelle ich bislang nicht als Täfelchen dar. Da nehme ich ein passendes Symbol und hänge dann die Zahl als Routenname an den Weg oder an das Symbol.
Die am Weg liegende Routenbezeichnung läßt sich immer an Schnittstellen oder Kreuzungen abrufen. Setzt man den Mauszeiger auf einen mit Wanderwegmarkierung hinterlegten Weg, ploppt bei mir nur die Objektbezeichnung dieser Wegmarkierung “Wanderweg” auf. Sobald die Spitze des Mauszeigers aber eine Wegeinmündung berührt, wird die Objektbezeichnung oder der Name des einmündenden Weges und der im Textfeld hinterlegte Name der Route angezeigt. Wenn man das weiß, findet man die Routenbezeichnung wesentlich schneller, als wenn man die Strecke nach einem Symbol absuchen muß (das möglicherweise gerade nicht im Kartendisplay sichtbar ist), um die daran hängende Routenbezeichnung abzulesen. Deshalb bevorzuge ich bei den Routenbeschriftungen die Deaktivierung der Textfarbe. Bei sehr allgemeinen Objektnamen wie “Keil” oder “Winkel” wäre es nett, wenn es möglich wäre, die Routenbeschriftung sowohl an das Symbol, als auch an den Weg hängen zu können. Einer Überfüllung des Displays wird durch “Verdrängung” der an den Täfelchen hängenden Routen-Beschriftungen vorgebeugt. Sie wird also ausgeblendet, wenn nicht ausreichend Platz zwischen anderen Kartenelementen ist und nur dann angezeigt, wenn man das Schildchen mit dem Mauszeiger berührt. In dem aufploppenden Kästchen ist der Routenname dann sehr gut zu lesen. Da die Wanderwegsymbole aber nicht immer sichtbar sind, sind mir die Routenbezeichnung am Weg wichtiger.

Viele Grüße
tippeltappel