Beiträge von JürgenD

Ist aus der Ferne schwer zu sagen warum das Programm sich gleich wieder verabschiedet. Der Unterschied zur vorherigen Version ist eigentlich nur das Verzeichnis in dem es ausgeführt wird. Beim Start neu ist allerdings noch das Einlesen von MapTk.dat. Die Datei kann einfach gelöscht werden. Sie wird beim Start neu aufgebaut ( ohne die Icons ). Die lassen sich aber jederzeit wieder importieren, eben aus dieser Datei - ohne die Konfigurationsdaten - oder aus der Datei auf dem Server. In neuen Versionen wird sie auch nicht mehr im Archiv sein.

Import von BMP, GIF, ICO, JPG, PNG und TIF sind in der nächsten Version drin. Spec: max. 32 * 32 Pixel aus der NW-Ecke der Datei. Bei GIF werden transparente Pixel auch transparent sein. XPM wird nicht gehen. Die Python-Funktion mag dieses Format nicht, vermutlich ein Fehler ( Datentyp ). Ich muss das Ganze nur noch DAU-fest machen. Komme aber erst übernächste Woche dazu.

Papaluna: Mit den alten Zugangsdaten liegt eine Version zum Ausprobieren auf dem Server. Bildchen können importiert werden wie eine Bibliothek, nur anderer Datentyp. Die hochgeladenen Icons sind noch nicht fertig, nehme ich an. Alle haben einen grauen oder weißen Hintergrund. Ist leicht zu ändern ( Klick mit Shift-'transparent' auf den Hintergrund ), meine Zeit ist aber im Moment etwas knapp.

Gruß

Jürgen

Zitat

Deinen Hinweis bzgl. der 32*32 Pixel...

Ich meine, die automatische Reduktion auf z.B. 16 * 16 Pixel keine brauchbaren Ergebnisse liefert ohne mühsame Nacharbeit. 32 * 32 Pixel für einen POI verdeckt zu viel, da sind wir uns einig. Machen nicht Screencopies und diverse Formatumwandlungen mehr Arbeit als ein Bildchen abzuzeichnen ? Arbeitsaufwand für den Import ist einige Stunden wenn das Icon einfach übernommen werden soll. D.h. keine Bearbeitung wie Ausschnitt, Reduktion der Auflösung, ... Das ginge dann für die wichtigsten Grafikformate. Na, mal sehen.

Nun zur Installation: Vor dem Kopieren des Archivs einfach alle Dateien im Programmverzeichnis löschen sollte reichen. Das Format des Programms hat sich geändert. Zuvor wurde die EXE beim Start des Programms in ein temp. Verzeichnis ausgepackt und erst dort ausgeführt. Das hat den Nachteil, dass dieses Verzeichnis nicht entsorgt wird wenn das Programm gewaltsam beendet wird ( z.B. Rechner ausschalten ). Jedesmal bleiben dann ca. 10 MByte in über 90 Dateien hängen. Diese Dateien stehen jetzt eben schon an der richtigen Stelle und müssen nicht entsorgt werden. Die Datei 'psyco._psyco.pyd' ist allerdings wirklich falsch. Sie kann gelöscht werden. Das ist ein Rest aus einem bisher gescheiterten Versuch einen JIT-Compiler zu verwenden um die Bearbeitungsgeschwindikeit etwa zu verdoppeln. ( Der compilierte Code wird im Augenblick von der Garbage-Collection nicht entsorgt. ).

Gruss

JürgenD

Im Prinzip ist es möglich eine Importfunktion aus verschiedenen Grafikformaten einzubauen. Bleibt nur die Frage woher die Bilder kommen sollen. Icons für Windows und Linux sind mit 32 * 32 Pixel zu groß. Automatische Reduktion ruiniert das Bild. Aus über 1000 gesammelten Icons passen mal 3 oder 4 thematisch. Richtige Fotos sind völlig unbrauchbar. Fazit: Der Aufwand lohnt nicht - oder ?
Wenn mir jemand in den Upload-Bereich eine Icon-Bibliothek schiebt werde ich sie in die zum Download bereitstehende integrieren. Das macht mir zwar auch etwas Arbeit, ist aber wohl die bessere Lösung. Nicht vergessen: TYP-Datei in PRJ-Datei konvertieren und die Icons in die Bibliothek aufnehmen geht einfach und schnell.

JürgenD

Version 2.0 steht zum Download bereit:

• Konfigurationsparameter für Codepage, Sprache der Hilfe und Pfad zum PDF-Viewer.
• 'Edit': Unterstützung beim Erzeugen einer neuen PRJ-Datei.
• 'Edit': Grafischer Editor für TYP-Dateien.
• Bibliothek für POI-Icons.
• Icons für POIs bis 32 * 32 Pixel.
• 'TYP analysis': mehrere Fehler behoben .
• Erzeugen einer Übersichstkarte aus einer oder mehreren Detailkarten.
• Auslesen und setzen der 'DrawPriority' von IMG-Dateien.
• 'TYP analysis': Problem mit 'String=' und nur einer Farbe bei POIs behoben.
• Zusätzliche und verbesserte Fehlermeldungen.

Weitere Info in der Dokumentation.

JürgenD

Hi

Für die Längenangabe der Strings aller Sprachen steht 1 Byte zur Verfügung. Diese Länge rechnet sich zu

Längenbyte = (Summe aller Texte + 2 * Anzahl Sprachen) * 2 + 1

Damit bleiben bei einer Sprache maximal 125 Zeichen pro POI, Polyline oder Polygon.
Mit der nächsten Version von MapTk gibt es eine ordentliche Fehlermeldung.

JürgenD

Hallo Stefano,

die Dateien enthalten 2 Fehler:

• Die ID von 'Testtrack 1' ist 9 Zeichen ( darf max.
• In der Übersichtskarte fehlt der Verweis auf die Detailkarte, hier '~[0x1d]50000001' im Label vom Type 0x4a

Mit diesen Änderungen geht es. Siehe Anhang.

Jürgen

Moin !
Der Übersichtskarte fehlt ein Polygon vom Typ 0x4a. Das ist die Position und die Identifikation der Detailkarte, die in Mapsource den gelben Rahmen bekommt. Ich kopiere mit einen Texteditor ( z.B. Notepad++ mit mehreren Fenstern ) aus den Detailkarten das Hintergrund-Polygon in die Übersichtskarte. Ein Texteditor ist die bessere Wahl. MapEdit richtet bei solchen Kopieraktionen Chaos im Block [IMG ID] an ! Dann Typ von 0x4b nach 0x4a ändern, 'Background=Y' entfernen und 'Label' auf die Identifikation der Detailkarte setzen. Hier

Label=TestMap~[0X1D]00000001

also Name + Nummer der IMG-Datei getrennt durch ein Sonderzeichen.
Fertig.
JürgenD

Ich bin auch kein Freund von Windows. Sehe aber in Linux immer noch keine wirkliche Alternative. Trotzdem habe ich ( mit Starthilfe eines Linux-Fans ) auf Linux portiert. Entwicklung unter Ubuntu 7.10, Test mit openSuse 10.3. Werkzeuge: Python 2.51, Eclipse 3.3, Subversion. Alles für beide System verfügbar. Download und mehr Info: http://www.maptk.dnsalias.com.

JürgenD

Information zu den Typen von Linien:
CESTA: 0x19
ZELENA: 0x2b
ZLUTA: 0x15
Die Beschriftung ist in der IMG-Datei für diese Linien eingetragen, also nicht mit einer TYP-Datei änderbar. Hintergrund: Die in der IMG-Datei eingetragenen Label haben Priorität weil sie z.B. einer Straße den Namen geben. Label aus der TYP-Datei überschreiben nur die in der Firmware festgelegten Label, die immer dann angezeigt werden wenn dem Objekt kein individueller Name zugeordnet worden ist. Sinnvollerweise funktioniert die Umstellung der Sprache nur für die Objekte ohne individuellen Namen.
Die von popej genannte TYP-Datei mit 797 Bytes enthält die Definitionen von Linien und Polygonen. Dieser Kartensatz ist geschützt, also nicht modifizierbar.

Jürgen

Die TYP-Datei I000031B.TYP ist nicht leer. Sie enthält für 20 Polygone die Reihenfolge der Darstellung ( Draworder=... ). MapTk hat diese Werte bisher nicht angezeigt da sonst keine Definition der Polygone in der Datei stehen. Das wird mit der nächsten Version zusammen mit einigen anderen Fehlern korrigiert.
Ich vermute mal, dass der Kartensatz 'gelockt' ist. Die Kacheln sind dann nicht in eine MP-Datei zu verwandeln in der die betreffenden Codes leicht ermittelt werden könnten. Die meisten Codes sind hoffentlich entsprechend der einschlägigen Listen verwendet worden. Garmin ist da allerdings ziemlich Kreativ. Für den Rest ist bei nicht 'normaler' Verwendung probieren angesagt. Der Bereich, der nach meinen Erfahrungen dargestellt werden kann, ist für Linien 0 ... 0x2b und für Polygone 0 ... 0x54. Ich habe bisher keinen Code in diesem Bereich gefunden, der durch eine TYP-Datei nicht darstellbar wäre. 0x00 habe ich weder für Linien, noch für Polygone in einer Originalkarte gefunden. Ich nutze für meine Karten inzwischen fast den gesamten Bereich. Dazu kann die Datei MyCodes heruntergeladen werden.
Eine Beschriftung, die in der IMG-Datei explizit festgelegt ist ( z.B. Name einer Straße ) kann mit einer TYP-Datei weder entfernt noch überschrieben werden. Beschriftungen, die als Vorgabe für den Typ in MapSource oder im GPS-Gerät gespeichert sind sollten ab der nächsten Version durch ein Leerzeichen überschrieben werden können ( String=2," " ).

Jürgen

Eigentlich lässt sich jeder Kartensatz mit einer individuellen TYP-Datei verschönern. Eine allgemeine Lösung gibt es nur mit Einschränkung. Die Verwendung der Codes für POIs, Linien und Flächen ist nicht durchgehend einheitlich. Es gilt also herauszubekommen welche Codes anders oder zusätzlich verwendet werden und die TYP-Datei daraufhin anzupassen. Beispiele als Ausgangspunkt für eigene TYP-Dateien können bei http://www.maptk.dnsalias.com heruntergeladen werden.
Besser ist natürlich das Original zu decompilieren und dann zu bearbeiten. Die nicht decompilierbare TYP-Datei bitte hochladen. Mal sehen was stört und ob sich da was machen lässt.

JürgenD

Ich hab mal eine Liste von Typen wie ich sie benutze zum Download bereitgestellt. Ist ein deutsch / englischer Kauderwelsch und nicht immer Standard wie im Manual von cgpsmapper oder Mapdekode gezeigt ! Als PDF für Leute ohne OpenOffice, als ODT für OpenOffice zum Weiterverarbeiten.

Gruß
Jürgen

Eine Aufforderung mir Karten zu schicken war nur bedingt gemeint. Wenn es Meldungen von MapTk gibt, die es nicht geben sollte, ist das der erste Grund. Wenn eine IMG-Datei die von mir genannten Grenzen überschreitet und trotzdem funktioniert ist das ein zweiter Grund. Ansonsten gehöre ich nicht zu den Sammlern und Jägern.

Ein Nachtrag: Die 4-MByte-Grenze gilt streng genommen nicht für die ganze Datei sondern für Subfile RGN, das ist etwa 90% der Datei im Mittel. Außerdem sind doch 18 MByte etwa 20 MByte, genau wie 25. Oder ? Ist nur ein Anhaltspunkt, der Inhalt entscheidet.

Die mögliche Anzahl der Objekte in einem Level ist so nicht abzuschätzen. Wichtig ist die 64-kByte-Grenze ( 16 Bit Pointer ). Bei einer 'normalen' Verteilung der Objekte auf die Level, d.h. etwa wie bei den Topo-Karten von Garmin, sollte es keine Probleme geben. Diese Karten sind nach meiner Erfahrung optimal übersichtlich. Auf etwa diese statistische Verteilung ist Aufteilung in Subdivisions abgestellt. Eine übersichtlich gestaltete Karte sollte keinesfalls zu Problemen führen. Sonst: siehe oben.

Von großen Symbolen für die POIs halte ich nicht viel. Die kleistern doch nur die Karte zu. Ich bevorzuge möglichst kleine und einfache Symbole mit wenigen Farben, dafür aber mit hohem Erkennungswert. Die verspielten, sehr amerikanischen Symbole ( siehe MapSource 'große Symbole' ), gar mit Farbverlauf finde ich unübersichtlich und sie decken mit zuviel darunter ab. Trotzdem werde ich mal sehen was sich da machen lässt - wenn ich mich wieder über die TYP-Datei hermache. Mir fehlt da ein hübscher Editor für POIs und Muster für Linien und Polygone.

Nachdem das englische Manual verfügbar ist, ist das nächste Thema Linux, dann die generischen Typen und dann erst der TYP-Editor. Wie lange das alles dauert ist kaum abzuschätzen.

Gruß
Jürgen

Limitierungen:

Größe der IMG-Datei: 4 MByte
Größe eine Subdivision: 64 kByte
Anzahl möglicher Level: 2 bis 8

20 MByte große MP-Dateien ergeben ca 4 MByte bei Verteilung der Objekte entsprechend der Topo Deutschland. Begrenzungen bezüglich der Länge von String, Anzahl POIs, Linen, Polygone, ... sind nicht bekannt.
Wo die Grenzen liegen ist nicht immer ganz klar. Durch Mapsource und die Geräte gegeben - oder habe ich die Struktur der Dateien nicht gut genug verstanden ? Deshalb ist es immer interessant Karten zu analysieren die nicht funktionieren oder IMG-Dateien die trotzdem funktionieren. Durch eine andere interne Struktur spielen z.B. die Kacheln der Topo Deutschland V2 mit ihren generischen Typen in einer anderen Liga. Diese Struktur mit MapTk zu erzeugen ist mir noch nicht gelungen. Hab' die Hoffnung aber noch nicht aufgegeben.

Auch solche unorthodoxen Karten soll das Programm bearbeiten. Ursache ist, dass ich die Fehlermeldung schon bei 32k einer Subdivision herausgebe ( die größte war ganz knapp darüber ). Das ist jetzt korrigiert. Um etwas Luft zu bekommen - Faktor 2 ist mir zu unsicher - habe ich die Dichte der Subdivisions der groben Level erhöht ( jetzt ca. 6k maximal für diese Karte, insgesamt ca. 1200 Subdivisions ). Eine Version zum Testen liegt auf dem Server ( mit papaluana anmelden, Passwort ist der Name der Karte Name=.... ). Ich sammle die Korrekturen für das nächste Release da ich eine Versionsinflation vermeiden möchte.

Gruß
Jürgen

Hallo papaluna.

es mal mit der Version 1.3.1 versuchen. Wenn das nicht hilft bitte die IMG-Datei auf den Server schieben.

Hintergrund: Eine IMG-Datei ist in bis zu mehreren tausend Subfiles unterteilt. Ein Subfile darf bis zu 64k groß sein. Ich vermute, dass in [IMG ID] Levels=2 oder 3 definiert ist. Bei Levels=2 gab es fälschlicherweise nur maximal 1 Subfile, bei Levels=3 auch zu wenig. Das ist in der Version 1.3.1 behoben.

Gruß
Jürgen

MapTk kann beides - hin und zurück. Bei Übertragung zwischen Kartensätzen müssen unbedingt die Daten im Kopf [Project]
angepasst werden. Ich empfehle mit einer vorgefertigten PRJ-Datei zu beginnen.
cgpsmapper kann nach meiner Kenntnis keine TYP-Dateien für die Top Deutschland V2 erzeugen.

Gruß Jürgen

Hallo morgen1,

mein Interesse an TDB-Dateien ist arg begrenzt - solange ich funktionierende TDBs der Version 300 erzeugen kann. Aus Neugier habe ich die TDB-Analysefunktion von MapTk auf die Versionen 408 ( z.B. CN7 ) und 410 ( CN9, Topo D V2 ) erweitert soweit ich den Inhalt verstehe.

Im Header ( 0x50 ) hängen zusätlich 49 ( Version 408 ? ) bzw. 60 Bytes ( Version 410 ? ) hinter dem Familiennamen. Bei einem Offset von 30 Byte scheint die Codepage 1252 zu stehen. Der Rest ist unbekannt, bei verschiedenen Produkten aber sehr ähnlich.

Eine wesentlich Erweiterung hat im Block 0x4c stattgefunden: Die Anzahl und Reihenfolge der Größenangabe der Subfiles wird nach weiteren 7 Bytes ( unbekannte Bedeutung ) durch entsprechend viele 13 Byte lange Namen bestimmt.

Weiter gibt es von John Mechalas nicht dokumentierte Blöcke:
0x52: Name des Produktes ( ? )
0x53: Liste und Nummer der Regionen
0x54: 20 Bytes mit unbekanntem Inhalt

Gruß
Jürgen

Hallo Gert,

ich kenne nur eine Stelle an der eine Karte transparent geschaltet werden kann. MapEdit scheint nur 'Transparent=Y' in der MP-Datei auszuwerten, nicht aber das Flag in der IMG-Datei.

In der hochgeladenen MP-Datei gibt es Fehler. Vier mal hängt am Ende eine Zeile mit 'Data0=' ein [POLYLINE]. Wie z.B. hier:

[RGN40]
Type=0x03
Label=Va~[0x1c];;RR;Nebstr;Asph;0,91km;RR Sieg;550;
Levels=2
Data0=(50.773178,7.350845),.....,(50.768006,7.359461)[POLYLINE]
[END-RGN40]

Das irritiert den Parser. Mal sehen ob ich so etwas frühzeitig erkennen und mit einer besseren Meldung abfangen kann oder wie MapEdit ignorieren kann.

Mit den verschobenen Symboltexten habe ich noch nichts unternommen. Es sieht für mich so aus, als ob Garmin die Symbole zu einer Matrix von 32 * 32 Pixel nach N und O auffüllt und dabei den nützlichen Teil in die SW-Ecke schiebt. Ich werde versuchsweise die Symbol auch aufffüllen, aber nach W und S. Macht die Typdatei bestimmt nicht schöner. Aber wenn's hilft ... Das hat fast keine Priorität und kommt dran nachdem einige andere Baustellen abgearbeitet sind.

Jürgen

Hi,

ein Teil der Fragen wird hoffentlich durch die gerade fertige Version 1.3 beantwortet:

• 'IMG analysis': Nur Daten des Level 0 werden in die MP-Datei übernommen. Die Tiefe der Anzeige ( Levels=... ) jedes Objektes wird aus der Übersichts-Sektion der IMG-Datei abgeleitet. Damit ist 'Uniform' vor dem Compilieren nicht mehr notwendig.
• 'IMG analysis': Die Codepage wird aus der IMG-Datei entnommen ( CodePage=... ).
• 'IMG': Erzeugung der Karten ( RGN / TRE ) wurde vollständig neu strukturiert.
  
  • 'Background' 0x4b ist jetzt nicht mehr notwendig, darf geteilt sein und muss nicht rechteckig sein.
  • Karten mit 2 bis 8 Level können erzeugt werden.
  • Kacheln bis 4 MByte RGN möglich ( IMG-Datei ~4 MByte, MP-Datei ~16 MByte ). Bei zu großen Kacheln:
    'Abort: map is too complex (RGN)!'
  • Einige neue und weniger kryptische Fehlermeldungen und Warnungen.
  • Linien und Flächen werden in allen Ebenen vereinfacht für kleinere Dateien.

[INDENT]Die zuvor sehr einfache Struktur war sehr schnell beim Compilieren, brauchte aber den 'Background' und war nicht geeignet für geteilte und nicht-rechteckige 0x4b sowie Karten über ca. 1 MBytes. Leider hat die neue Struktur den Nachteil deutlich längerer Compilationszeiten ( ~ 60 kBytes/s Source ).
[/INDENT]

• 'IMG': 'Elevation=M' in [IMG ID] wird jetzt ausgewertet. Alle Höhenangaben werden in Metern angegeben, sonst 'feet' wenn die Dimension 'M' fehlt.
• 'IMG': Die Hausnummer in Adressen kann jeden druckbaren Text enthalten.
• 'IMG': Codepage wird in die IMG-Datei übernommen.
• 'TYP': Fehlermeldung wenn 'Style=' in [Project] leer ist.
• 'TDB analysis': TDB Versionen 300, 408 und 410 werden unterstützt.
• 'TDB': Probleme bei Blockgrößen > 512 Byte behoben.
• Export von MapEdit funktioniert wieder.
• Das Programm wird jetzt mit der Codepage ISO.8859-1 produziert. Diese Codepage wird ebenfalls zu Anzeige im Status-Fenster benutzt. Ein neuer Aufrufparameter 'cp=' erlaubt die Anzeige anderer Zeichensätze. Z.B. 'MapTk.exe cp=cp1251' für kyrillische Zeichen. Das betrifft nur die Anzeige, nicht den Editor oder die erzeugten Karten.
• 'Uniform': Umbenannt zu 'Script'. Kann weiterhin benutzt werden um globale Änderungen an einer Karte durchzuführen.

Nun zu den übriggebliebenen Fragen:

Draworder bestimmt die Reihenfolge beim Zeichnen von Polygonen. Der Hintergrund scheint ohne Eintrag nicht dargestellt zu werden. Das gilt auch für die 'neuen' Typen der Topo V2. Da ich keine echten Overlays verwende, bzw. ich die Karten darunter vollständig abdecke, trage ich den Hintergrund ein und gebe ihm zusätzlich die Farbe 0xffffff ( weiß ). Die Karte selbst ist aber als transparent markiert. Auf diese Weise ist Routing ( mit drunterliegender CN9 ) möglich. Die Anzeige ist aber die topologische Karte. Die Transparenz funktioniert möglicherweise aus diesem Grunde nicht wenn die ursprüngliche PRJ-Datei heruntergeladen wurde.

Overview-Karten erkennt MapTk am ID in der MP-Datei. Eine Nummer kennzeichnet eine Detailkarte ( z.B. '00001234' ). Ist die ID keine Nummer ( z.B. 'topov2' ) ist es eine Übersichtkarte. Steht so auch im Manual. Die Variable gibt das nur wieder.

'Streetdesc' is ein Text. Es gibt keine Begrenzung in MapTk. An eine Begrenzug bei Garmin bin ich bisher nicht gestoßen.

'list index out of range' ist eine Meldung aus dem Laufzeitsystem. Das ist in der Regel eine Verletzung von Array-Grenzen. Hat mit Sicherheit nichts mit 5 oder 6 Nachkommastellen zu tun sondern ist eher Hinweis auf Fehler in der MP-Datei die nicht abgefangen werden. 5 Stellen sind mehr als ausreichend. Die kleinste Einheit bei Garmin ist ca. 1.11 m entprechend 0.0000215 Grad ( am Äquator oder in N-S-Richtung ). TTQV kenne ich nicht, würde die Dateien aber gern einmal ansehen.

Jürgen