Beiträge von JürgenD

Hallo Oliver,
von Behinderung kann nicht die Rede sein. Ich will nur mit Garmin kompatible Karten erzeugen können. Andere 'Verbraucher' dieser Karten werde ich nicht berücksichtigen um die Kompatibilität mit Garmin-Produkten nicht zu gefährden. Ich implementiere auch nur was ich glaube verstanden zu haben. Das ist die Richtung.
Auf eine qualifizierte Frage werde ich immer eine qualifizierte Antwort geben - wenn ich denn eine habe. Konstantin ( MapEdit ) habe ich z.B. bei der Implementation der User-Typen unterstützt. Fragen, die geeignet sind z.B. den Kopierschutz zu umgehen werde ich ignorieren. Das gilt auch für das Geplapper von ein paar selbst ernannten Experten. Die Sourcen oder eine interne Doku werde ich sicher nicht veröffentlichen. Sie könnten zu illegalen Aktivitäten anleiten. Keine Lust auf Support und ellenlange Diskussionen ist ein weiterer Grund.

Zitat

Erweiterte Typen als Type|Subtype codiert kommen nicht vor.

Doch. Der Typ steht ganz normal in der Reihenfolge, der Subtyp ist im 32-Bit-Feld kodiert. Das ist z.B. einer der Gründe für die Begrenzung des Subtyps auf 0...0x1f.
Um die freien Karten mache ich mir keine Sorgen. Die Aufregung um einen neuen Kopierschutz kann ich nicht teilen. Schreibt doch ein Administrator des Garmin-Forums, dass Garmin freie Karten begrüßt https://forum.garmin.de/showthread.php?t=1209. Dass die interne Struktur der Dateien nicht publiziert wird oder MPC nicht an jeden gegeben wird, kann ich gut verstehen. Der unqualifizierte Umgang damit würde Garmin im Support auffressen. Was ich hier im Forum zu MapSource lese belegt das. Wenn jemand MapTk nicht mag oder nicht damit umgehen kann/will, soll er es einfach lassen. Diese Einstellung kann sich Garmin einfach nicht leisten, obwohl manchmal der Eindruck erweckt wird.

Schönen Tag noch
JürgenD

@extremcarver: Ich meine den Inhalt der OSM-Karten, nicht mkgmap. Auch wenn es eine Regel für die Einträge gibt darf doch jeder I... dagegen verstoßen. Dabei ist es völlig unwichtig was darin steht. Es muss nur für einen Kartensatz einheitlich sein. Das lässt sich per Programm auch nicht korrigieren. Geräte werden sich daran bestimmt nicht aufhängen, eher der Besitzer. Von der Verwendung von Sub-Typen > 0x1f kann ich nur dringend abraten. Der Compiler sollte das ablehnen. Die Bits 5 bis 7 werden an manchen Stellen anderweitig benutzt. Seit den User-Typen gibt es auch keinen Grund dafür, selbst wenn nachteilige Folgen nicht gleich zu beobachten sind. Auch hier gilt: Wenn keine Garmin-Karte Sub-Typen >= 0x20 benutzt, sollten man es ebenfalls lassen.

Wenn Stan mit seinem cgpsmapper die Lust verliert, kann ich ihn nicht sonderlich bedauern. In der freien Version jede Kachel mit einer deutlich sichtbaren Duftmarke zu versehen hat mich zu MapTk genötigt, der Preis der Pro-Versionen wohl zu mkgmap. Wenn er davon leben will, hat wohl sein Marketing nicht so recht funktioniert. Ein Compiler für die Kommandozeile passt nicht mehr in die Zeit. IDE ist angesagt. Das gilt auch für mkgmap. Dass wir alle hinter Garmin her dackeln, wird sich kaum umgehen lassen und sollte nicht zu Frust führen. Illegales MPC zu verwenden ist auch nicht die Lösung. Ich jedenfalls arbeite an MapTk zum Vergnügen, im Bewusstsein jederzeit einen Schlussstrich ziehen zu können.

kiozen: Das erste Byte der TYP-Datei ist das Längenbyte eines Subfile-Header. 'Normal' ist 0x5b. Was zusätzlich bei Längen von 0x6e und 0x9c in der Datei versteckt ist habe ich bisher nicht analysiert. Sobald die erweiterten Typen auftauchen muss mit einem 32-Bit-Feld die Reihenfolge definiert werden. Mir ist es dabei egal ob das wirklich nötig ist. MapTk benutzt immer das Bitfeld. Auch für die 'alten' Typen, da ist das Bitfeld 0x00000000 (andere Werte blenden das Polygon aus ). Daran scheint Garmin zu erkennen, dass es sich um den traditionellen Stil handelt. Eine Kennzeichnung im Kopf braucht es dazu nicht.

JürgenD

Moin,

das Maß der Dinge ist für mich Garmin. Was der Online-Editor oder QLandkarte machen ist mir dagegen relativ egal. 'koizen' schreibt da was von einem 1. Byte 0x6e ( in Polygon ? ). Da ist Bit 6 gesetzt, was ich bisher in keiner Garmin TYP-Datei gesehen habe. Folglich werde ich es auch nicht setzen ( wobei es Garmin scheinbar nicht weiter auswertet, zumindest nicht in MapSource ). Die PRJ-Datei enthält keine Vorgaben wie eine Objektbeschreibung ( Quellcode ) in die Binärdatei umgesetzt wird. Das ist Sache des Compilers. Es gibt also keine Möglichkeit neue oder alte Formate zu steuern. Warum auch ? Je weinger Parameter, desto weniger Probleme beim Anwender und im Support.

Die unterschiedlichen Formate zur Bestimmung der 'Drawpriority' beziehen sich auf die PRJ-Datei - früher als eigene Tabelle wie bei cgpsmapper, heute zusammen direkt in der Beschreibung des Polygons. Das macht Kopieren und Vergleichen einfacher und das Programm für den grafischen Editor übersichtlicher. Die TYP-Datei ändert sich dadurch nicht.

Der Polygon-Typ 0x2d und andere sind zwar bei cgpsmapper und MapEdit nicht definiert, wurden aber in der Zeit vor den User-Typen ( 3-Byte-Typen ) gelegentlich in topografischen Karten benutzt. Eine TYP-Datei macht das möglich. QLandkarte kann des gern ignorieren, macht für mich aber wenig Sinn. Oder hat man den Sinn einer TYP-Datei nicht verstanden ? Solange Garmin das mitmacht werde ich nicht einmal eine Warnung anzeigen. Bedenklicher finde ich da schon die Sub-Typen >= 0x20 bei POIs, wie ich sie mehrfach in OSM basierten Karten gesehen habe.

An das Ende der TYP-Datei hängt MapTk seit einiger Zeit eine Signatur. Die Dient dazu festzustellen ob und mit welcher Version MapTk die Datei erzeugt hat. Das habe ich eingeführt nachdem man mir fehlerhafte Dateien vom Online-Editor unterschieben wollte. Wenn man hinter dem Ende der definierten TYP-Beschreibung weitermacht, Pech gehabt.

Zufällig habe ich etwas gefunden: Wenn in der Übersichtskarte für größere Orte im Bereich 1 bis 0x0b die Region und das Land definiert werden, kann man in MapSource nach diesen Orten mit dem Namen suchen. Das funktioniert ohne MDR- und MDX-Dateien ! Ist im Moment wohl nicht mehr so interessant, könnte aber für ältere Karten nützlich sein ( durch Austausch der Übersichtskarte ).

Noch eine Bemerkung zum Index: Die Definition von Ort, Region und Land sollte unbedingt einheitlich vorgenommen werden. Nur dann kann man vernünftig die Suche nach Ort, Region und Land eingrenzen. OSM-Karten sind eine Musterbeispiel wie man es nicht machen sollte. Das ist aber wohl prinzipbedingt ...

Schönen Tag noch
JürgenD

Lesen bildet: Doku Kapitel 1.2

Shakespeare um 1601: "Was ihr wollt"

MapTk nimmt alle Punkte ( Cities sind auch nur Punkte ) der folgenden Gruppen in den Index auf: 0x0100 – 0x1100, 0x2800, 0x2a00 – 0x3000 und 0x6400 – 0x6600. So steht's im Manual Seite 45 der deutschen Version. Kleine Orte auszublenden macht doch keinen Sinn.

Wenn City, Region und Country angegeben sind ist das ein Kriterium zur Eingrenzung der Suche in MapSource. Die Suche nach Punkten in der Nähe ging schon immer, auch ohne einen Index. Im Prinzip lässt sich ein Index aus beliebigen IMG-Dateien erzeugen - solange die erforderlichen Einträge gefunden werden können. Die Möglichkeiten hier Fehler zu machen sind vielfältig. Im einfachsten Fall kann eine Karte nicht an das Gerät übertragen werden oder schmiert bei Aufruf der Suche ab. Im Extremfall lässt sich MapSource nicht mehr starten. Die Fehlermeldungen sind aussagekräftig wie Kaffeesatz. Da ich für Support dieser Art wenig Begeisterung aufbringe und auch keine Glaskugel besitze, besteht MapTk auf durch MapTk ab Version 2.7 compilierten Dateien.

Wie die Suche abläuft, z.B. "Auto Complete" in MapSource max. Entfernung nächstgelegener Punkte in Geräten ist nicht eine Eigenschaft des Compilers, auch nicht von mkgmap. Und was während der Suche angezeigt und ob eingegrenzt werden kann ist eine Eigenschaft der Karte, die mal wieder reichlich Zeit kostet. Die Südtirol-Karte hat schon 3700 Einträge.

Moin,

was bitte ist 'City POI Code von mkgmap' ? Die Kodierung der Daten im MP-Format hat doch nichts mit dem Compiler zu tun ! Oder ist damit die seltsame Typisierung von OSM-Karten gemeint ? Ich kann nur empfehlen mit der Verwendung der Typen dicht am 'Standard' zu bleiben wie er in MapEdit vorgeschlagen wird. Andere Verwendung führt leicht zu Merkwürdigkeiten. Garmin hat oft eigene Vorstellung bezüglich der Darstellung. OSM oder mkgmap ist für mich sicher kein Vorbild.

Ich kann in der Performance der verschiedenen Implementation von einfarbigen Flächen ( 2. Farbe transparent oder dupliziert ) keinen Unterschied feststellen. Test mit MapSource 6.13.6 und 6.15.7 sowie Colorado und Oregon. Bei MapSource 6.15 ist es durch Caching sowieso egal. Also kein Grund etwas zu ändern.

Es gibt starre Beziehung zwischen Index und Kacheln ( Verweise auf diverse interne Tabellen der IMG-Dateien ). Änderungen oder zusätzliche Kacheln ohne den Index neu zu generieren führt damit zwangsweise zu Problemen mit absonderlichen Fehlermeldungen. MapTk erzeugt deshalb den Index nachdem alle Kachel aktualisiert und kompatibel sind im Rahmen von 'Make'.

Die automatische Benennung verschiedener Dateien erleichtert die Definition eines neuen Satzes von Karten - besonders für Einsteiger. Nachteile sind für mich nicht erkennbar da es immer nur eine Datei dieses Typs für einen Kartensatz geben darf und kann. Selbst wenn ich 5 kleine Projekt in einem Verzeichnis halte ist die Zuordnung jederzeit klar. MapTk verfolgt eben einen ganzheitlichen Ansatz und kein gefrickel mit diversen Tools und ellenlangen Parametern.

Schönen Sonntag noch !
Jürgen

Version 2.6.4

• 'TYP': Das GMAP Format für Karten kann jetzt benutzt werden um eine Liste aller verwendeten Typen zu erzeugen: 'TYP -> List of types in GMAP'. Wie 'List of types from IMG' nur in Windows verfügbar.
• 'Make': Die Maske für IMG-Dateien darf jetzt auch '*.img' sein ohne zu versuchen die Übersichtskarte als Detailkachel einzubinden.
• Einige Fehlermeldungen wurden verbessert.

Gruß
JürgenD

Hallo Andreas,

die kleinen Seen haben den Typ 0x3d. DrawOrder von 3 auf 4 setzen reicht aus. Ich habe das als einige Änderung ausprobiert. Es funktioniert. Der mischwald darüber 0x1101f hat DrawOrder 3. Sand 0x110d (am nördlichen Üfer) sollte auch auf 4 gesetzt werden.

Jetzt verstehe ich auch 'Platzhalter'. Sie sind zum Setzen der DrawOrder ohne die Fläche neu definieren zu müssen. Platzhalter (placeholder) ist eine wirklich unglückliche Wortwahl. Die Funktion ist eben nur die Änderung der DrawOrder ohne die Definition der Firmware zu verändern. Das ist seit 1.3.2 in MapTk implementiert ohne im Manual so beschrieben zu sein - sollte aber als transparente Fläche intuitiv richtig zu benutzen sein. 0x3d in der V2 gehört aber nicht in diese Kategorie.

Gruß
Jürgen

Hallo Andreas,

mit der Erklärung kann ich nichts anfangen. Ich sehe einfach keinen Sinn für Platzhalter, wofür auch immer. Die TYP-Datei gibt doch nur an wie POI, Linie und Flächen anzuzeigen sind die in der Karte vorhanden sind. An der Karte selbst ändern sich nichts. 'Platzhalter' machen da einfach keinen Sinn. Ich habe für jeden Kartensatz eine eigene Projektdatei. Die generiere ich bei fremden Karten aus der ursprünglichen TYP-Datei. Diese modifiziere ich dann, ggf. auch mit einem 2-Fenster-Text-Editor. Eine eigene PRJ-Datei ist sinnvoll schon wegen der unterschiedlichen Family-IDs und den Speicherort der TYP-Dateien. Die PRJ-Datei liegt bei mir meist im Ordner der IMG-Dateien - sofern ich für den Kartensatz keine MP-Dateien besitze. Ist erst einmal der Header richtig ausgefüllt geht das Aktualisieren mit einem Klick auf 'TYP'. Optional werden für Benutzer von MS 6.15.6 die gespeicherten Daten gelöscht ( damit die Änderungen auch angezeigt werden, Option einschalten in 'File -> Preferences' ).

Gruß
Jürgen

@Andreas: Ich verstehe 'Platzhalter' nicht. Was ist damit gemeint ? Polygon, die in der TYP-Datei definiert wurden aber in der Karte nicht vorkommen ? Das ist kein Problem, bläht nur die Datei auf. Verlangsamte Darstellung habe ich nicht bemerkt, aber auch nicht explizit getestet.

Die Reihenfolge der Darstellung hat nur bedingt mit der Karte zu tun. Wenn entweder schlampig gearbeitet wurde ( also z.B. die Grünfläche über dem See liegt, was in der Natur kaum sein kann ), bei absichtlichen Überlagerungen ( z.B. teilweiser transparenter nasser Boden über einer Wiese ) oder Details beim Zoomen verschwinden sollen ( z.B. einzelne Häuser über Stadtgebiet ). Das oben liegende Polygon bekommt die höhere Priorität, wird als zuletzt gezeichnet. Die Reihenfolge bestimmt die Bedeutung des Polygons, ist damit eigentlich unabhängig von der Karte. Da die Polygone gleicher Bedeutung aber durchaus unterschiedliche Codes haben können ist die Reihenfolge leider doch abhängig von der Karte. Beispiel: in der V1 ist der Wald 0x50, in der V2 aber 0x10f18, 0x10f19, 0x10f1a, 0x110e oder 0x110f je nach Ausprägung. Bei schlampiger Arbeit gibt es dann leicht Konflikte. Schlamperei zu vermeiden ist sehr zeitaufwendig wenn man Polygone aus verschiedenen Quellen in der Karte zusammen kopiert. Überdeckungen sind da kaum zu vermeiden. Das ist sicher ein Qualitätsmerkmal einer Karte.

Gruß
Jürgen

Die Drawpriority vom See hoch setzen. Dann wird die Grünfläche vom Wasser bedeckt ;).
Übrigens: Die V1 hat nicht viel mit V2 oder V3 gemein. Die differenzierte Darstellung von V2 und V3 wurde erst durch die sogenannten 3-Byte-Typen möglich.

Gruß
Jürgen

MapTk kann entweder mit Projekten im MP-Format oder Kartensätzen im IMG-Format eine Liste der verwendeten Objekte erstellen. Im Falle der IMG-Dateien muss der Kartensatz in die Registry eingetragen sein. Das GMAP-Format unterstützt MapTk noch nicht, steht jetzt aber auf der To-Do-Liste.
Ich habe keine V3 ( Routing als Wanderer lehne ich ab ), an der kostenlosen Testversion kann man aber einige Unterschiede in der Belegung sehen. Beispiel: Polyline 0x0f: Wirtschaftsweg bzw. Radweg. Was in der Testversion drin ist habe ich als Datei angehängt.
TYP-Dateien kann man durch Start von 2 Instanzen von MapTk mit den beiden PRJ-Dateien vergleichen. Die Konvertierung in IMG-Dateien mit dem MapReverseConverter funktioniert, erfordert aber die Eintragung in die Registry von Windows, etwas Zeit und einigen Platz auf der Platte. Der Kartensatz kann dann als Belohnung mit der Version 6.13.6 verwendet werden. Die verzerrt die Karte wenigstens nicht und kann selbst erstellte POI-Typen fehlerfrei anzeigen.

Gruß
Jürgen

Sich in MapTk partiell einzuarbeiten ist sicher effektiver als einen Texteditor zu verwenden. Die Anleitung von Papaluna sollte den Einstieg wesentlich erleichtern.
Anmerkung zu Punkt 3: Ich empfehle die Erweiterung PRJ mit MapTk zu verknüpfen. Dann reicht ein Doppelklick.
Anmerkung zu Punkt 6: Wenn im Header der Pfad für die Typ-Datei auf das Kartenverzeichnis verweist entfällt Punkt 7.
Wenn es mit der neuen Version 2.6.3 nicht geht bitte die Datei zur Analyse hochladen ( könnte eine weitere Variante des TYP-Formats sein die ich noch nicht kenne ).

Gruß
JürgenD

PS: Danke Papaluna

Version 2.6.3

• 'Script': Teilen von Linien und Flächen mit > 255 Punkten wurde verbessert..

• 'IMG': Anführungszeichen am Anfang und Ende eines Labels werden nicht mehr entfernt.
• 'IMG': Neue Varianten des IMG-Formats werden richtig bearbeitet.
• 'TYP': MapSource-Tilecache wird bei neuer TYP-Datei gelöscht. ( optional nur für Windows ).
• 'TYP / TYP Analysis': Texte für alle Sprachen dürfen > 127 Zeichen lang sein.
• ' TYP Analysis': Neue Varianten des TYP-Formats werden richtig bearbeitet.
• 'TYP': Draworder für Polygon ist jetzt 0 ... 31.
• 'SCRIPT': Verbesserte Fehlermeldungen.
• 'SCRIPT': Doppelte Punkte in Linien und Flächen werden entfernt.
• 'TDB Analysis': Version 4.11 wird bearbeitet.
• Fehlendes Verzeichnis für IMG-, TDB-, REG- oder TYP-Datei wird automatisch erzeugt.
• Länge der Dateinamen ( TDB, TYP, Übersichtskarte ) wird überprüft ( <= 8 Zeichen ).
• Eine MDX-Datei wird zusammen mit der TDB-Datei erzeugt.

Gruß
JürgenD

Das hat so seine Richtigkeit. Die Karte ist eine exklusiv für Bike-GPS erstellte Version. Sie enthält Wege speziell für Radfahrer die dem Copyright von Bike-GPS unterliegen, abgestimmt auf deren Touren-Angebot. Diese Wege sind ausgesprochen hochwertig - zu 100% gegen Luftbilder verifiziert und korrigiert. Das kostet. Zudem wird die Karte auf einer Speicherkarte geliefert.

Die Wege der freien Version stammen zu mehr als 95% aus GPX-Dateien von Anwendern der Karte. Es ist unglaublich welcher Schrott mir da zugeschickt wurde. Die Qualität der daraus generierten Wege geht von gut bis nicht einschätzbar. Offensichtlich unbrauchbare Tracks konnte ich aussondern. Der Rest entspricht nicht meinen Vorstellungen von Qualität. Eine Version mit Daten des Wegeprojektes wird es nicht geben. Sollte sich die Möglichkeit ergeben hochwertige, kostenpflichtige Tracks zu Wegen zu verarbeiten, werde ich die freie Version nicht weiter bearbeiten.

Gruß
Jürgen

Version 2.6.1 liegt zum Download bereit:

• 'IMG': Orte sind im Index eingetragen.
• 'IMG analysis': 3 mal schneller.
• 'IMG': Hexadezimale IDs für Karten wie 'I1234567' werden jetzt akzeptiert.

• 'Iconlib': Qualität der Ausdrucke der ICON-Bibliothek wurde verbessert ( für 300 dpi ).
• 'Edit': Sprache der Auswahl von POIs, Polylinien und Polygone wurde verbessert.
• 'GPX/MP': Probleme mit mehrfachen Tracks wurden behoben.
• 'GPX/MP': Filter für kombinierte Tracks wurde entfernt.
• 'TYP': Linien ohne Farbdefinition werden nicht in die TYP-Datei übernommen.
• 'TYP': Warnung wenn 'DrawOrder' nicht im Bereich 0...7 ist.

Gruß
JürgenD

Transparent ist die Abwesenheit einer Farbe. Mit anderen Worten: Es gibt keine Farbe die ein Pixel transparent macht. Die Linie bleibt in der TYP-Datei, die Definition wird aber von der folgenden Linie übernommen. Ob transparente Linien sich überhaupt in eine TYP-Datei definieren lassen, kann ich so schnell nicht übersehen. Obwohl ein 'Error' ausgegeben wird bleit die Linie fälschlicherweise in der TYP-Datei und verwirrt MapSource.
Es gibt aber eine Lösung die Linien fast verschwinden zu lassen: 'Pattern' mit einer Breite von 32 Pixeln definieren und nur 1 Pixel davon auf eine unauffällige Farbe setzen, der Rest ist transparent. Die Beschriftung sollte auf 'no text' gesetzt werden. Um diese Linen noch zu entdecken braucht man schon eine Lupe.

Die Punkte in den Tracks sind Stützstellen, die über eine gerade Linie verbunden werden. Das gibt zusammen einen Track ( oder als Karte konvertiert einen Weg ). Wenn die Punkte eng genug beieinander liegen wird daraus eine hübsche Kurve. Hütten, Gipfel und andere Punkte sind eine separate Angelegenheit. Sie liegen ja meist auch nicht auf dem Weg.

Straßen, Wirtschftswege und Landbedeckung sind schon in der Karte vorhanden. Es fehlen die Wege und Pfade sowie viele Hütten und Berggasthäuser. Die üblicherweise z.B. im CityNavigator enthaltenen Tankstellen, Geldautomaten usw. müssen nicht unbedingt in die Karte. Ich gehe davon aus, dass unter der Südtirol-Karte eine Straßenkarte liegt die das schon enthält und über die man zum Startpunkt der Wanderung per Autorouting navigiert.

Hilfe kann ich natürlich gebrauchen. Die größte Hilfe sind GPX-Dateien guter Qualität, die um Ausreißer und Pausen bereinigt sind. Bei guter Qualität der Daten erledige ich den Rest mit MapTk weitgehend automatisch.

Ich bin verärgert. Mit den Wegen aus dem Wegeprojekt wird es nichts. Es gibt keinen Kontakt Amt für Tourismus und Alpinwesen in Bozen. Mails bleiben unbeantwortet. Jeder Versuch mit dem Verantwortlichen zu kommunizieren scheint mit inzwischen unsinnig. Das verdirbt mir die Lust die Karte für die Allgemeinheit zu pflegen. Kurz habe ich daran gedacht die Karte vom Server zu nehmen, würde damit aber die Falschen bestrafen ( Version 1.03 über 8000 Downloads ! ).
Also gibt es ein Update, geplant für Anfang 2. Juni-Woche. Alle Tracks und POIs als GDB- oder GPX-Datei kann ich verwenden. Wer also noch Daten hat: Bitte gleich schicken. Redaktionschluss ist der 1. Juni. Ich werde allerdings gnadenlos Material schlechter Qualität aussondern: Klasse statt Masse. Referenz sind die Straßen und Wirtschaftswege der Karte und Google-Earth. Und bitte keine Ski-Touren !
Bei GPX-Dateien gehe ich davon aus, dass es selbst aufgenommene Tracks sind, die nicht mit einem Urheberrecht belastet sind. Die Dateien dürfen mehrere Tracks und POIs, auch gemischt enthalten. Tracks auf Straßen und Wirtschaftswegen werden entfernt. Tracks sollten sollten möglichst viele Punkte enthalten. Die Sortierung ist mir egal. Teilstücke werden automatisch zusammengesetzt. Doppelte Tracks und POIs werden gemittelt um die Qualität zu verbessern, auch wenn sie aus unterschiedlichen Dateien stammen. MapTk macht es möglich.
@sonyc: Die Fragen sind keineswegs unsinnig. Die GPX-Dateien enthalten wohl maximal ~300 Punkte pro Track, egal wie lang. Kurze Teilstücke sind demnach detailierter. Den Rest der Fragen habe ich wohl schon indirekt beantwortet.