Neue Version MapTK

DEM steht für mich im Moment nicht auf der Tagesordnung, kommt aber irgendwann. Trotzdem ein Hinweis: MapTk erstellt eine detaillierte Analyse mit den Abmessungen ( Tools -> TDB analysis ).

An dem Begriff 3-Byte-Codes bin ich möglicherweise indirekt schuld. Mit der Erzeugung von TYP-Dateien sind mir diese Codes bekannt geworden. Um sie in der PRJ-Datei, und auch später in der MP-Datei, einfach unterscheiden zu können habe ich zu den Codes 0x10000 addiert, also 3 Byte daraus gemacht im Quelltext. Das war im Oktober 2007 mit der Version 1.2 von MapTk. Diese Schreibweise haben andere übernommen oder parallel neu erfunden. In den Bereichen RGN2, 3 und 4 sind die Objekte getrennt speichert ( im Gegensatz zu RGN1, wo alle einen gemeinsamen Bereich teilen ). Soweit ich das überblicke sind einige Grenzen gefallen. Z.B. die 4 MByte-Grenze des Subfile RGN im herkömmlichen Format und natürlich viele Möglichkeiten Objekt sehr detailliert zu beschreiben. Welches Potential wirklich dahinter steckt wird man noch sehen. Aber auch diese Aktivität ruht bei mir in der nächsten Zeit, nicht zuletzt weil MapEdit damit noch nicht umgehen kann.

Zitat

looks like 0x11... is a DEM type but i don;t know if anyone have done some progress on the .DEM file.

Das verstehe ich nicht. Die V2Types haben mit DEM nichts zu tun, sie werden nur in einem anderen Format organisiert und gespeichert.

Gruß
JürgenD

An der Wankbahn ist nichts, was ungewöhnlich wäre. Der Typ der Linie ist 0x10e14 ( = 3 Bytes ! ) und in der TYP-Datei als Seilbahn benannt. Nach 0x11 übersetzt ist das OK um mit MapTk weiterzuarbeiten.

... und ich hab schon per Mail geantwortet.

Am Anfang habe ich 'UseOrientation' ausgiebig probiert. MatpTk setzt dieses Flag. Ohne wird die die Anzeige eher schlechter, d.h. kontrastärmer. Also kein Grund den Anwender mit einem weiteren Parameter zu quälen.

In der nächsten Version ( dauert noch einige Tage ) werden beide Parameter durchgereicht. Aber bitte wozu ?

Hallo Papaluna,

kommt alles mit der nächsten Version ( schon eingebaut ). Die nächste Version braucht aber vermutlich doch noch etwas länger.

Mit der Version 2.5 gibt es, neben kleinen Verbesserungen und Fehlerkorrekturen, neue Funktionen. Die sollen helfen aus aufgezeichneten Tracks und Wegpunkten eine Karte zu erstellen oder zu vervollständigen. Das funktioniert natürlich mit qualitativ guten Daten besser. Schrott sollte man vorher aussortieren. Die Knäule, die bei Pausen entstehen werden nicht immer ganz entfernt, also in MapSource vorher rauslöschen. Die neuen Kernfunktionen:

• Kombination von Tracks in einer oder mehreren GPX-Dateien durch Mittelwert. Parallel verlaufende Tracks werden durch Mittelwertbildung zusammengefasst. Qualitativ gute Tracks werden dadurch verbessert.
• Maskieren von Tracks in einer oder mehreren GPX-Dateien durch Linien ( z.B. Straßen und Wege ) in einer oder mehreren MP-Dateien. Dabei werden Tracks unterdrückt/abgeschnitten die als Line bereits in einer MP-Datei vorhanden sind.

Das sind im Prinzip Vorbereitungen die Daten des Wegeprojekts ( hoffentlich ) in die Südtirol-Karte automatisch zu übernehmen oder alternativ eingesammelte Tracks und POIs. Die Bearbeitung braucht viel Rechenzeit ( z.B. 4 MByte Tracks brauchen leicht mal eine Stunde, kleinere Dateien deutlich weniger). Als abschließenden Test habe ich eine neue Südtirol-Overlay-Karte aus allen eingesammelten Daten damit generiert. Die Wege darin sind an keiner Stelle mit MapEdit bearbeitet worden. Das Ergebnis steht zum Dowload bereit.

Weiter ist in der Version eine Backup und Löschfunktion für die Registry neu. Weiter gibt es kleine Verbesserungen und Fehlerkorrekturen.

Gruß
JürgenD

Hallo Gert,

hab' mir das mal angesehen. Dass die Nodes nicht angezeigt werden liegt an der Reihenfolge der Parameter. Hab' beim Ändern nur die MP-Datei mit dem Texteditor auf Vollständigkeit überprüft. Der Editor erwartet offensichtlich die Nodes hinter den Koordinaten. Das ist nicht ganz verständlich. Wozu denn die Schlüsselworte wenn die Reihenfolge wichtig ist ? Garmin macht bei GPX-Dateien ähnlichen Mist. In der nächsten Version kommen alle Routingparameter am Ende.

Das mit 0x16 kann ich nicht nachvollziehen. Habe obigen Test gerade mit 0x16 gemacht - funktioniert. Schick mir mal das Script. Könnte da verborgen sein.

Gruß
JürgenD

Du hast recht. Ich kann nicht lesen. Ich habe das Schüsselwort RoutParam allgemein genommen für die Summe der Parameter. Für 0x16 gab es im Programm etwas versteckt eine Sonderbehandlung.
Eine neue Version möchte ich im Moment nicht auf den Markt schmeißen. Das reparierte Programm kannst Du unter den bekannten Zugangsdaten runterladen.

Gruß
Jürgen

Hallo Huzzel,

das ist so nicht ganz richtig. Wenn Du über das Menü 'Functions -> Compile typ' gehst, kannst Du fast beliebig viele TYP-Dateien in einem Rutsch erzeugen ( bei ca 400 gibt Windows / Python mit Fehlermeldung auf ). Der Batchbetrieb, fast für alle Funktionen möglich, ist hier der Unterschied vom Menü zum Button.

Gruß
JürgenD

Moin,

alle PRJ-Dateien müssen natürlich in einem Verzeichnis stehen. Wie überall in Windows die Dateien mit Ctrl-linker-Maustaste auswählen. Öffnen. Fertig.

Was ist denn überhaupt die Anwendung für viele TYP-Dateien im Batch ? Ich habe bisher nie den Wunsch gehabt mehrere im Batch zu kompilieren. Jeder TYP-Datei muss doch auf die Karte mit ihren besonderen Eigenschaften abgestimmt werden. Ich habe schon mal daran gedacht eine Datei mit allgemeinen Definitionen zu importieren, aber aus genau diesem Grund wieder verworfen.

Kommandozeilen-Parameter ist sicher möglich, braucht dann aber eine Batch-Datei. Meine Erfahrung sagt, dass das kaum jemand nutzt. Die meisten User wissen nicht mal was das ist.

Gruß
JürgenD