Erstellen von MPVs aus eigenen Daten

clayExtractor.pl ist jetzt fertig.

Es gibt eine eigene Konfiguration -> clayExtractor.cfg
hier habe ich sprechende Namen für
Linientypen, Areapattern, Routingklassen und für einige Farben und soweit ich es herausgefunden habe die Namen der POI Icons.

Ich habe das Script auf alle Clays, die ich in die Finger bekommen habe, losgelassen.

clayExtractor.pl DACH08Q4.clay

erzeugt DACH08Q4.clay.cfg

Mit

clayExtractor.pl -h

bekomt man eine kurze Hilfe.

Ich habe ein Windows-batchfile beigelegt.
Hier einfach die Pfade anpassen.
Und dann einfach das Clay-File auf clayExtractor.bat ziehen!

Neben der DACH08Q4.clay.cfg sollte man sich besonders Spain_Topo_Demo.clay.cfg anschauen.

Und bitte clayExtractor.cfg anschauen, und bitte wenn ihr Werte ergänzt dies auch an mich weitergeben, damit alles was davon haben.
Das gilt für sinnvolle Farben, POI Icon Namen (da sind bestimmt paar falsch), ...

Ich werde als nächstes ein Script schreiben, was mit Hilfe von z.B. DACH08Q4.clay.cfg jedes Beliebige Clay auf die gleichen Werte setzt.

Ray

freeday, ich verstehe es etwas anders.
Eher in der Richtung, das der Import von Garmin IMGs noch eine Baustelle ist, und daran gearbeitet wird.

Das Vektormodul ist noch nicht ganz sauber, z.B. geht momentan noch einiges an Infos bei der Konvertierung von VMP nach VMPF verloren.
Zum Teil kann man dies über das CLAY wieder gerade biegen.

Ich hatte in letzter Zeit wenig Zeit, oder war anderweitig abgelenkt, daher habe ich am ClayModifierer Script nicht gearbeitet, dieser ist etwa zu 30% fertig.

Wenn es heute Abend statt Schneien Regnen sollte habe ich wieder etwas Zeit, denn dann gehe ich nicht Biken.

Ray

Ich habe die letzten beiden Abende am clayModifierer.pl-Script arbeiten können.
Ich bin im Prinzip fertig, bis auf 2 Probleme.

Ich muss noch klären, wie es mit den Namen eines Layers ist wenn kein Name für eine Sprache verfügbar ist.
Darf man diesen freilassen oder muss dieser gesetzt sein?

Was mir Kopfzerbrechen macht, ist das in einigen Fällen die span. Namen der Layer nicht eindeutig ist.
Die Layer-Id kann ich nicht verwenden, da sie nicht eineindeutig sind.
Nur die span. Namen sind in der Regel für einen Objekttypen immer gleich.

Da es aber für einige Objekttypen im Spanischen keine unterschiedliche Namen gibt, kommt es hier vereinzelt zu Problemen.
Direkt lösen kann ich dies per Software nicht, ich werde aber auf Konflikte hinweisen, damit man weis wo man eingreifen muss.

Industrial area taucht z.B. einmal als Polygon und einmal als POI auf.
Bei Polizei Revier (state Police und ...) das gleiche.
EInfach mal in dieDACH.clay schauen.

Wenn jemand eine Idee hat....

Ray

Bin gestern Abend fertig geworden, jetzt muss ich nur noch aufräumen und damit spielen.

Feintuning an der Konfiguration...

Wer mittesten will, meldet sich einfach direkt bei mir per Mail.
Email-Adresse steht in jeden Script drin.

Heute fahre ich aber erst einmal MTB. Leider nur Strasse, da die tauende Schneepampe unfahrbar ist, geloipter Tiefschnee war da spassiger.

Ray

Ich habe fertig
Und das Naviboard läuft auch wieder ...

ClayModify.zip
Da sind 2 Scripte drin um CLAYs zu pimpen.

Als erstes lässt man clayExtractor.pl laufen

clayExtractor.pl DACH08Q4.clay

dies ergibt DACH08Q4.clay.cfg
Beim Lauf wird man auf Namenskonflikte hingewiesen.
Die spanischen Identifierer müssen eindeutig sein.
Einfach einen der span. Namen in DACH08Q4.clay anpassen (vorher Original sichern!) und danach einfach clayExtractor.pl nochmals aufrufen.
Beim beiliegenden DACH08Q4.clay habe ich die Namen bereits angepasst.

Das DACH08Q4.clay.cfg kann man dann an seine Wünsche anpassen.

Dann lässt man clayModifierer.pl laufen:

clayModifierer.pl DACH08Q4.clay

Das ergibt clayModifierer.pl.modified
Wenn es einen gefällt einfach in DACH08Q4.clay umbenennen. Original sichern!

Man kann aber, was noch besser ist, andere CLAYs damit pimpen:

clayModifierer.pl -c DACH08Q4.clay.cfg Greece08Q4.clay

Dann werden z.B. auch die dt. Identifierer im Greece08Q4.clay nachgetragen!
Beim Lauf wird man auf Namenskonflikte in Greece08Q4.clay hingewiesen.
Auch hier müssen die spanischen Identifierer eindeutig sein!
Layer die nur in Greece08Q4.clay auftauchen und nicht in DACH08Q4.clay.cfg werden nicht verändert!

Meine Idee war/ist damit eine Vorlage für alle OSM-Maps zu schaffen.
Dann halt man die Arbeit nur einmal.

Ray

tv-arnd hat mich auf ein Problem mit PTextReorg.pl hingewiesen.
Die OSM-Daten von BG liessen sich nicht verarbeiten.
Ich habe die .mp-Files in UTF-8 gelesen, das geht aber aufgrund des Encodings von BG schief.
Habe daher UTF-8 abgeschaltet.

Man kann mit osm2mp.pl erzwingen das UTF-8 der OSM Daten erhalten bleibt.
Land scheint aber nicht mit UTF-8 zu arbeiten.
Ich hoffe dies ändert sich mit Land 7.

Wer osm2mp.pl und PTextReorg.pl nutzen will, sollte sich zumindest die Posts 73 und 83 durchlesen.

Bitte die aktuelle Version von osm2mp.pl vewenden.

Ray

cjrams@Compe-Forum hat mir geantwortet.

Land benutzt das im Windows eingestellte Encoding, also für uns in Westeuropa 1252.

Wichtiger fand ich aber die Bestätigung meiner Vermutung, Land 7.x wird auf UTF-8 umgestellt.
Was ein deutlicher Fortschritt ist.

Weis jemand ob wann Windows XP auf UTF-8 einstellen kann?

Das wäre für die OSM-Daten ein riesen Vorteil, da OSM Unicode (UTF-8) verwendet.
Auch TwoNav ist seit 2.0.9v auf UTF-8 umgestellt.

Was ganz anderes:
Besteht Interesse an einer Ski-Map der Alpen?
siehe http://openpistemap.org/
Wer will sich daran versuchen?
Wir können dies als Übungsbeispiel gemeinsam erstellen!
Auflage meinerseits ist, das dabei eine Doku für die Wiki entsteht.

Ray

Habe gestern Abend einen klein Bugfix an ClayModify.zip gemacht.
Alle sprachversionen eines Identifieres müssen gesetzt werden.
Wenn der franz. Namen fehlt wird der nachfolgende dt. Bezeichner ignoriert.
Wenn Bezeichner fehlen, scauhe ich nach ob es einen engl. Namen gibt und verwende diese. Notfalls nehme ich den span. Namen, falls auch der engl. Namen fehlt.

Habe leider festgestellt das das Maping der OSM-Typen auf MP-Typen (oder VMP-Typen) wohl nicht stimmt.
Ich habe aufeinmal Fernstrassen auf La Palma, das sollten aber Bundesstrassen seien.
Das Konfigurieren des Mapings ist zeitwaufwendig und nervig.

Ray

Ich dachte könnte mal geschwind eine Ski-Map der Alpen erstellen.
Ich beschränke mich dabe bewusst auf Lifte, Godeln und Wege die mit piste:type=~/[nordic|downhill|skitour]/ getagt (incl. deren Schwierigkeitsgrad) sind.
Da ich alles andere ignoriere sollte nicht zu viele Daten anfallen.

Die Alps.osm hat 6.5 GB
osm2mp.pl kommt da gewaltig in Schwitzen und läuft seit gestern Abend durch.
Problem ist das osm2mp.pl erst einmal alle Daten in den Seicher lädt, trotz 64-bitigen Mac OS X reichen meine 4 GB RAM nicht mehr aus.
Die Aufrüstng meines MacBook Pro auf 8 GB RAM ist mir aber definitv zu teuer, auch wenn der Rechner dann in kurzer Zeit fertig wäre.
Ich bin gespannt ob osm2mp.pl fertig ist, wenn ich von der Arbeit nach Hause komme.
Wenn sich kein anderes Tool findet, werde ich nächsten Winter evt. einen eigenen Konverter für OSM nach MP schreiben.
Das OSM-File von Deutschland ist etwa nochmals doppelt so groß.

Aber ich denke die Grenze beim Import von MPs in Compe Land ist schon deutlich früher erreicht.

Ray

@extremcaver, die CPU-Last war nicht das Problem sondern die Speicherauslastung. CPU-Last war im Mittel bei 5%.
Mein MacBook pro macht eine Aufrüstung auf 8 GB mit, nur sehe ich die Kosten nicht ein, da ich normalerweise sehr gut mit 4 GB auskomme.

Das Java schneller und ressourcenschonder ist, würde ich nicht unterschreiben. Zum Glück wird es mit jeder Version besser.
Da traue ich mich nicht eine Festlegung zu machen was schneller ist, das ist auch sehr Problem-Abhängig was besser ist.
Ich habe Fortran Programme nach Perl portiert, und war erstaunt das Perl genauso schnell oder in einigen Fällen sogar schneller ist.
Keine andere Sprache hat eine so gute Integration von Regular Expression.
Dadurch ist Perl ideal für alles was mit Parsen zu tuen hat.
Nicht ohne Grund haben sich Regular Expressions und auch Hashes über Perl hinaus verbreitet.
Ich würde nie auf die Idee kommen GUI oder OO mit Perl zu machen, da fühle ich mich mit Java deutlich wohler.
Perl und Java sind meine Lieblingssprachen. C, C++, ... rühre ich nicht mehr an.

Von den 6.5 GB der Alps.osm bleiben keine 10 MB übrig, wenn man sich auf Ski-Pisten beschränkt. Damit hat Land definitiv keine Probleme.

Ray

POIs interessieren mich weniger, da habe ich nicht weiter geforscht.
Ich wüsste auch nicht wie, da VMP unf VMPF binär sind und die Formate nicht offengelegt sind.
Ich hoffe Compe hat bei Land 7 auch das Vektormodul weiterentwickelt.
Die POI-Datenbank müsste Land eigenständig füllen, was es aber nicht tut.
Das die Icons beim Konvertieren von VMP nach VMPF verloren gehen, sehe ich als Bug an.
Das man diese über das Clay setzen kann, ist nur ein Workaround.

Ray

Danke für die Info, da warte ich lieber auf Compe Land 7.

Ray

yep.

Hast du einen Aventura?
Dann bekommst du Compe Land für 56,-

Du willst die OSM Map von CDN-BC konvertieren?

Ray

Morgen Abend stelle ich eine Ski Karte der Alpen online.
Ich muss das Clay noch etwas optimieren.

Ich habe osm2mp.pl ein zweitesmal laufen lassen müssen.
Der Lauf war 24h unterwegs bei einer Speicherauslastung von bis zu 8.3 GB RAM

Diese Map enthält Gondeln, Skilifte, Schlepplifte, ...,Skipisten, Skilanglauf- und Skitouren-Wege.
Mit den jeweiligen 6-stufigen Einstufungen.
Aber sonst keine Infos. Wege, Strassen und POIs habe ich bewusst weggelassen.

Das Alps.osm von Geofabrik umfasst nicht die kompletten Alpen.
Ein Großteil der Westalpen fehlen.
Okay, zum Skifahren kein ernsthaftes Problem.

Ray