HOWTO: Osm->mp->mpv(f)

Hallo,
im Prinzip ja, aber kommt auf die Daten an, die alle in den shp's enthalten sind. Eventuell ist eine Vorarbeit nötig.

JA.
Dazu brauchst du die Voll-Version.

Zitat von ray

Kennt jemand eine Möglichkeit die .osm-Files zu spliten?

Ich habe das mit diesem Tool für BW mal gemacht...

IIRC sind die Einstellungsmöglichkeiten sehr beschränkt - aber es hat
funktioniert.

Viele Grüße,
Seppel

Die Größe der einzelnen Teile wird über --max-nodes festgelegt - ja
.
Welcher Wert da sinnvoll ist, hängt von Deinem Rechner ab Ich weiss noch, dass ich für meine Kiste (Win 32bit, 2GB RAM) rumprobieren musste und BW schlussendlich in 7 Teile gesplittet habe, damit osm2mp damit klar kam.
Welchen Wert ich am Ende benutzt habe, weiss ich leider nicht mehr

Zitat von ray

Im Compe-Forum wurde schrieben (ich finde den Thread gerade nicht wieder) das man Suchbare Karten-POIs bekommt, wenn man den Layer0 auf POI umbennt.

Ist das korrekt und was muss man genau machen?

Ich benutze von Anfang an der Übersicht wegen folgende Struktur

<Layers>
  <Style>
     Languages=ES
  </Style>
  Layer0=24,POIs,4294967295,4294967295,1,0.0000,-1.0000,-1,1,20.0000,0.0000,7316,0,0,0.0000,-1,1,0,1,FFFFFFFFFFFFFFFF,0,0.0000,4294967295,4294967295
    <Layers>
      Layer0=3156739,Unterstand,4294967295,4294967295,1,0.0000,0.0000,-1,120,120.0000,0.0000,024_Unterstand,0,0,0.0000,2181,0,381,1,FFFFFFFFFFFFFFFF,0,0.0000,4294967295,4294967295
      ....etc
      Layer24=18,Orte,4294967295,4294967295,1,0.0000,-0.0039,-1,1,0.0000,0.0000,,0,0,0.0000,-1,1,0,1,FFFFFFFFFFFFFFFF,0,0.0000,4294967295,4294967295
        <Layers>
          Layer0=3149056,Pueblos (simbolo),4294967295,4294967295,1,0.0000,0.0000,-1,1,40.0000,0.0000,city_1,0,0,0.0000,774,1,3837,1,FFFFFFFFFFFFFFFF,0,0.0000,4294967295,4294967295
          ...etc
        </Layers>
    </Layers>
  Layer1=0,Wege,4294967295,4294967295,1,0.0000,0.0000,-1,1,0.0000,0.0000,,0,0,0.0000,-1,1,0,1,FFFFFFFFFFFFFFFF,0,0.0000,4294967295,4294967295
    <Layers>
      Layer0=1,Bedingt fahrbar,65535,65535,1,0.0000,0.0000,-1,5,12.0000,0.0000,,2,5,1.0000,859,1,115,1,FFFFFFFFFFFFFFFF,0,0.0000,65535,65535
      ....etc
    </Layers>
  Layer2=17,Polygons,4294967295,4294967295,1,0.0000,0.0000,4,1,1.0000,0.0000,,0,0,0.0000,-1,1,0,1,FFFFFFFFFFFFFFFF,0,0.0000,4294967295,4294967295
    <Layers>
      Layer0=1048596,Wildpark,4294967295,4294967295,1,0.0000,0.0000,-1,1,1.0000,0.0000,,0,0,0.0000,-1,1,13,1,FFFFFFFFFFFFFFFF,0,0.0000,4294967295,4294967295
      ....etc
    </Layers>
 </Layers>

Wenn ich den Layer nur "POI" oder anders genannt habe funktionierte die Suche nicht. Nur "POIs" nicht jedoch "POIS" scheint dies zu ermöglichen.

Ray,
beides,
wo und wie du dein CLAY erstellst ist doch Jacke wie Hose, sofern es den Anforderungen von Compe genügt(welche wir ja nur erahnen können bzw. zufällig oder durch viel trial+error herausbekommen)

Der Vorteil der Strukturierung ist die bessere Übersichtlichkeit und bei den POI der Umstand das du ohne Gruppierung bisher noch jeden einzelnen Typ von Hand ausschalten musst von der Anzeige. Und da sich Twonav bisher noch diese Einstellungen nicht merkt, muss dies jedesmal neu gemacht werden.
Das habe ich schon sehr oft angesprochen bei CompeGPS.
Insbesonders bei der Zunahme an POI-Daten in den kommenden VMAPS ist das dringend nötig.

Ich hatte (mehr zu Testzwecken) eine kleine MTB-Karte rund um meinen Heimatort erstellt. Ist allerdings bereits 1/2 Jahr her - und wurde auch nie recht von mir eingesetzt.

Sobald mein Sportiva wieder von Compe zurück ist, mache ich mich nochmal dran, eine OpenMTB-Karte von Süd-BW zu basteln. Ich berichte dann nochmal im Detail...

Hallo Ray,
ich habe auch schon etwas länger nicht mehr mit den OSM-Daten + tools gearbeitet da mangels funktionierender MPFV-Erstellung das derzeit wenig Sinn macht.
Testhalber habe ich mir heute mal den ALps-Extrakt im PBF-Format von der Geofabrik runtergeladen.
Mit --max-nodes=3500000 wurden mit splitter.jar 28 outputfiles(im pbf-format) erzeugt.
Wesentlich mehr darf es nicht sein, da sonst die files für MKGMAP zu gross werden bzw. die max. Grösse der IMGS überschritten würde.(ist eher eine Garmin-Restriktion)
(I5-2500 4GB Win7/64)
Splitter brauchte ~2min
mkgmap brauchte ~8 min um die IMG zu erzeugen.
Das grösste resultierende IMG war ~ 17MB (~119Mb als MP-File)
Hieraus ergab sich ein MPV ~94MB
Alles mit den Standard-Styles von MKgamp.
Über die Styles kann man gut steuern welche Objekte man haben will und somit z.B. Aussehen/Inhalt + Größe der Dateien steuern.
Da wenig Doku hierzu da ist muss man sich leider erstmal einarbeiten. Dann bietet es aber ungeheure Möglichkeiten.
OSM2MP ist imo da eher eine Krücke. Afaik kann es ja nicht das komprimierte pbf-Format lesen.

Zitat von ray

D.h. du gehst den Umweg über das Garmin-Format?
Erkaufst du dir damit nicht zu viele Nachteile?

Welcher Art sollen die sein.?
Ok, evtl.:
1. max. zulässige Grösse für das IMG seitens Garmin und damit ein Beschränkung der max. möglichen Grösse eines Dateninput-files => kann man das evtl. auch übergehen(wäre zu testen) da eine Nutzung auf Garmin-Gps für uns in dem Zusammenhang nicht relevant ist.
2. siehe 1. evtl Notwendigkeit mehrere Files zu einem zusammenzuführen.
Das ist aber derzeit nur relevant, da mir es bisher nicht gelungen ist mehrere MPV bei Bedarf zu einem zu vereinigen.(Stichwort: afaik kein Routing über Kachelgrenzen bei MPVF. Müsste ich aber auch nochmal testen.

Zitat von ray

Das Garmin-Format hat durchaus auch Einschränkungen.

Welche für uns relevanten sollten das sein?
Das eine direkte Konvertierung von OSM nach MPV/MPVF(sofern sie die leichen Möglicgkeiten bietet) besser wäre steht ausser Frage.

Zitat von ray

Ich habe nie versucht ein Garmin-IMG nach Land zu importieren.

Hat mit der 7er schon immer funktioniert

Zitat von ray

Der Weg OSM->IMG->MPVF scheint mir etwas obskur.

Imo nicht obskurer als OSM->MP(->MPV->)MPVF

Zitat von ray

Oder geht dieser Weg besser als der Weg
OSM->MP->MPVF?

Beide Wege sind natürlich machbar. Imo bietet der Weg über Mkgmap einfach mehr Möglichkeit der Einflussnahme. Sicher kannst du vermutlich den Code von Osm2Mp so anpassen/erweitern, das sich das nicht viel nimmt.
Hat man die Steuerung des Datenoutputs via Styles kapiert ist dies ein äußert mächtiges Instrument.
Afaik gibt es wohl einen Multithreading-Support=> für Mehrkerner interessant

Zitat von ray

Zu MKgamp gibt es ja Frontends, u.a. OSMComposer, hast du mal damit gearbeiet?
Wenn ich es richtig sehe, kann man damit passende Styles für MKgamp erstellen.

Ja.
OSMcomposer ist schwerpunktmäßig auf die Reit+Wanderkarte ausgerichtet. Es soll dem DAU die Arbeit/Erstellung von Karten erleichtern. Solange man sich an die Vordefinition hält mag das auch stimmen.
Sobald man aber Veränderungen vornehmen will, ist das System auch nicht gerade leicht zu durchsteigen.
Ich habe es eigentlich nur verwendet um die Wanderwegsrelationen mit dynam. Wegmarkierungen(Points) zu bekommen, was mit Mkgmap in der Form nicht ging(evtl. ist das zwischenzeitlich anders).
Im Hintergrund wird der Style für Mkgamp erzeugt.
Das du den generellen Wissenshintergrund hast, ist ein direktes arbeiten mit mkgmap/style imo für dich sinnvoller.

Bisher hatte ich es in der Tat nie probiert mehrere Dateien in Land zu importieren.
Gerade mit jeweils 2 Dateien probiert. Sowohl mit MP als auch IMG ging dies.

Im Moment ist für mich neben dem Umstand das mal alle, mal nur einige Daten von MPV=>MPVF transferiert werden, vor allem das Layering(draw priority) rätselhaft.
Die selbe Eingangs-MP wird z.B. von 7.0.9.B anders behandelt wie z.B. 7.2
Ist mit 7.0.9.b. MPV + MPVf ok ist es bei 7.2 nur noch das MPV, während das MPVF dann die POI zwischen Polygon und Polylinien quetscht.
Bei dem Weg über OSM-IMG-MPVF stimmt das Layering mit der 7.2 auf einmal, wobei wiederum gleiche Objekttypen zum Teil nicht richtig erkannt werden.

Ich denke ich werde die Tage nochmal ein Briefchen an Compe schreiben und um eine dedizierte Beschreibungs des Workflows bitten, der von ihnen vorgesehen ist unter Berücksichtung der Eingangsformate und der Relevanz von Dateien wie der Types.dbf + layers_mp.dat.