oder anders ausgedrückt . . . ganz Österreich geht nicht auch wenn ganz Portugal problemlos geschrieben wird
Chile geht vielleicht auch ganz gut auf einen Rutsch.
Also ihr seid mir schon welche.:)
Sagt doch gleich, ein Verhältnis 1 zu Wurzel aus 2!
Gruß
LUDGER
Hallo,
ich modifiziere meine Kartenorganisation in Richtung Reise/Tourenplanung mit CGPSL. Ist etwas mühsam, da bei manchen Sat-Mercator ecw's erst dieses imp File zum Erfolg führt:
CompeGPS MAP File
<Header>
Version=2
VerCompeGPS=7.1.2
Projection=30,Elliptical Mercator,
Coordinates=1
Datum=WGS 84
</Header>
<Map>
eine GB in ecw mit orig: PROJ_DESC=Transverse Mercator / OSGB36 / meters
PROJ_DATUM=ORDNANCE SURVEY 1936 (OSGB36) führt so zum Erfolg:
CompeGPS MAP File
<Header>
Version=2
VerCompeGPS=7.1.2
Projection=6,BGN (British National Grid),
Coordinates=1
Datum=WGS 84
</Header>
<Map>
Die Mühe lohnt sich. Wie beispielsweise CGPSL hochauflösende Maps flächendeckend in 3 D+ und als Hypermap darstellt, ist sensationell. Satmaps sind bekanntlich speicherhungrig. Teile von Westeuropa können locker um die 250 GB haben.
Weshalb die Umstellung?
TTQV zeigt bei großflächigen Karten, zusammengesetzt aus Tiles, erhebliche Performanceprobleme in 2D und 3D+ und kann bei TwoNav Spezialitäten wie Roadbook usw. nicht mithalten. Die WPT Verwaltung in CGPSL muss ich mir noch überlegen bzw. Compe sollte hier eine Datenbankform, ähnlich dem Track-Logbuch implementieren. Das Einbringen einer weltweiten Ortsdatenbank soll bereits in der Planung sein.
Also ihr seid mir schon welche.:)
Sagt doch gleich, ein Verhältnis 1 zu Wurzel aus 2!
Hallo Ludger,
sorry, dass ich nicht auf dein Posting reagierte, da ich es für einen Scherz hielt. Jetzt finde ich diesen Satz aber auch in Deinem Wissenslexikon. Das ist aber nicht korrekt so.
Chile ist ein extrem langes Land, das sich aber hauptsächlich in N-S-Richtung erstreckt. Deshalb kann der Export vermutlich auf einen Rutsch erfolgen, falls die resultierende rmap weniger als 4 GB hat.
Genauer gesagt: Es spielt absolut keine Rolle, wieviele Pixel vertikal anfallen. Das könnten auch 10 Mio sein!
Die Zahlenwerte in meinem Beispiel waren rein willkürlich.
Speichermäßig kommt es nur auf die Anzahl der horizontalen Pixel an.
Die Daten werden sequentiell verarbeitet. Das läuft so ab, dass immer eine konstante Anzahl von Zeilen auf einen Rutsch abgearbeitet werden.
Wenn ich das (anhand von Fehlermeldungen bei fehlerhaften Export) korrekt interpretiere, verarbeitet QV immer jeweils 1024 Zeilen auf einmal.
Wieviel Speicher QV dabei konkret verbrät, weiß ich nicht. Aber wenn es Speicherprobleme gibt, nutzt es nichts, die Anzahl von vertikalen Pixeln einzuschränken, sondern Du musst die Anzahl der horizontalen Pixel reduzieren.
Beispiel:
Export einer rmap mit (horizontal) 30000 Pixeln x (vertikal) 100000 aus QV:
Zunächst wird ein Speicherpuffer erzeugt für 30000 x 1024 Pixel.
In einer Schleife wird dann der Puffer sukzessive gefüllt und in ein Zwischenformat auf Platte exportiert.
Anzahl Schleifendurchgänge = Anzahl vertikaler Pixel / 1024
Falls bei der Division ein Rest bleibt, kommt noch ein letzter Schleifendurchgang hinzu mit der restlichen Anzahl von Zeilen (< 1024).
1. Schleifendurchgang:
Zeilen 0 bis 1023 werden in den Puffer übertragen und in das Zwischenformat exportiert.
2. Schleifendurchgang:
Zeilen 1024 bis 2047 werden in den Puffer übertragen und in das Zwischenformat exportiert.
...
Die Anzahl der Schleifendurchgänge ist - wie gesagt - völlig wurscht. Es kann höchstens passieren, dass die 4GB-Grenze überschritten wird. Dann muss man den Exportausschnitt kleiner wählen.
Ich hoffe, dass diese Erklärung ein bisschen besser verständlich ist.
Viele Grüße
Werner
Hallo,
bei der Tourenplanung in den Alpen kann 3 D+ sehr wertvoll sein. Hier ist TwoNav wahrlich genial. Beispiel einer Hypermap von der Pizol-Region. Die kniffligen Stellen bei der Skitour sind schnell erkannt. Das blitzartige Umschalten zwischen 2D/3D+ ist hervorragend. Verwendete Maps:
Swiss-Ortho, Swiss Topo 25, Kompass:
[Blockierte Grafik: http://up.picr.de/7413897syn.jpg]
[Blockierte Grafik: http://up.picr.de/7413895hrp.jpg]
[Blockierte Grafik: http://up.picr.de/7413982mou.jpg]
die kompass sieht ja zum fürchten aus, warum kauft man sowas wenn man die swisstopo hat 
ich hänge hier mal eine kurze frage an. wie handhabt ihr die trackverwaltung in cgpsl? mir fehler hier eine übersicht wie in ttqv, das manuelle laden kann ja nicht deren ernst sein? gibts hier in der vollversion ev eine entsprechende funktion?
die kompass sieht ja zum fürchten aus, warum kauft man sowas wenn man die swisstopo hat ;)....... trackverwaltung in cgpsl?......
ich habe meine Maporganisation umstrukturiert für die Planungen in CGPSL. Wenn möglich mit Hypermaps. Die Mapsuche ist denkbar einfach:
1 x Map Index > Dateiexplorer öffnen (bei mir liegen alle Maps in " _GPS Karten TwoNav" mit Länderordnern als Unterverzeichnisse")
1 x Suchen
Beispiel einer Hypermap CH.imp mit VMAP. Man beachte, dass die Satmap 2xeingebunden ist. Die im Hypermapfile (*.imp) verbandelten Maps können natürlich immer auch einzeln aktiviert werden in CGPSL/TwoNav. Erstellumg mit IMPGENERATOR. Zoomlevelabänderung erledige ich gewöhnlich per Editor.
CompeGPS MAP File
<Header>
Coordinates=1
</Header>
<HiperMapLayers>
<HLayer File="Swiss west.rmap" visible="1" MaxZoomLevel="3"/>
<HLayer File="Swiss Ost.rmap" visible="1" MaxZoomLevel="3" MinZoomLevel="0.5"/>
<HLayer File="Swiss Bild OstB1.ecw" visible="1" MaxZoomLevel="5" MinZoomLevel="3"/>
<HLayer File="Swiss Bild WestA1.ecw" visible="1" MaxZoomLevel="5" MinZoomLevel="3"/>
<HLayer File="Swiss Bild WestB1.ecw" visible="1" MaxZoomLevel="5" MinZoomLevel="3"/>
<HLayer File="Swiss Bild OstA1.ecw" visible="1" MaxZoomLevel="5" MinZoomLevel="3"/>
<HLayer File="KOMPASS SCHWEIZ.RMAP" visible="1" MaxZoomLevel="20" MinZoomLevel="5"/>
<HLayer File="Swiss 200K.rmap" visible="1" MaxZoomLevel="30" MinZoomLevel="20"/>
<HLayer File="Swiss500.rmap" visible="1" MaxZoomLevel="50" MinZoomLevel="30"/>
<HLayer File="Swiss Bild OstB1.ecw" visible="1" MaxZoomLevel="99999" MinZoomLevel="50"/>
<HLayer File="Swiss Bild WestA1.ecw" visible="1" MaxZoomLevel="99999" MinZoomLevel="50"/>
<HLayer File="Swiss Bild WestB1.ecw" visible="1" MaxZoomLevel="99999" MinZoomLevel="50"/>
<HLayer File="Swiss Bild OstA1.ecw" visible="1" MaxZoomLevel="99999" MinZoomLevel="50"/>
</HiperMapLayers>
[Blockierte Grafik: http://up.picr.de/7426624urz.jpg]
[Blockierte Grafik: http://up.picr.de/7426625dac.jpg]
[Blockierte Grafik: http://up.picr.de/7426626mer.jpg]
Trackorganisation:
über Logbuch (Accesdatenbank)
Für die Waypointorganisation fehlt bis jetzt eine Datenbankstruktur.
Bin mal gespannt, wie sie die Logbuch-Funktion in der Mac-Version realisieren werden!
Cheers,
Marc
Sent from my MB525 using Tapatalk
Hallo,
im Netz (auf GE sind ebenfalls viele Radlerrouten downloadbar) sind oft viele Tracks/Routen downloadbar, die in viele Segmente unterteilt sind. Wenn diese einzelnen Segmente in CGPSL nicht in der richtigen Reihenfolge aufgeführt sind, ist ein zusammenführen zu einem Gesamttrack mit Schwierigkeiten verbunden.
Um die Reihenfolge zu bereinigen und einen lupenreinen Gesamttrack zu erhalten, der den Richtungspfeil bei der Tracknavigation richtig plaziert, wird ein neuer Track angelegt und die Segment in der richtigen Reihenfolge in diesen neuen Track eingefügt. Anschließend noch einige Nahtstellen korrigieren > zusammenführen > fertig.
In CGPSL vermisse ich für neue Reisevorbereitungen die WPT Verwaltung von TTQV 4 in Zusammenarbeit mit dem Chris50 Tool. Das Trackmanagement von CGPSL und deren Archivierung ist dagegen erste Sahne
ich bin mit dem Trackmanagement noch nicht wirklich warm geworden. Kann man den Importworkflow irgendwie optimieren? Ich habe zwar einen Pfad wo meine GPX Daten landen angegeben, aber diese werden nicht wie zB Landkarten automatisch eingelesen. Aktuell scheint es mir als müsste man die Tracks manuell öffnen und einzeln zum Logbuch hinzufügen?
Hallo Gerhard,
wenn die Ordner verlinkt sind, werden diese laut Screen eingelesen und tauchen in der Suche auf:
[Blockierte Grafik: http://up.picr.de/7443265zmz.png]
Die Tracks können über "Dateixplörer>öffnen" komplett Ordnerweise geöffnet werden.
Die Überführung ins Logbuch erfolgt einzeln über ziehen in die Logbücher.
Die Dateinamen der Tracks müssten noch über ein Skript in das TRK File geschrieben werden. Qu4>mdb wäre einfacher.
Hallo,
generiere soeben aus umfangreichen kml Dateien WPT. In CGPSL sollte bei einigen Anwendungen, wo das markieren von vielen Files nicht geht, die STRG Taste dazu benützt werden.
Mit dieser Technik gehen auf einen Rutsch 30 KML Dateien nach 30 WPT.
Auch beim Einlesen sollte man etwas probieren. Im PC Explorer viele Dateien markieren und per Drag & Drop in CGPSL öffnen, kann zielführender sein, als direkt über CGPSL>Datei öffnen.
Es gibt keine fixe Regel. Einfach probieren.
Hallo,
hier ein Beispiel, wo TTQV 5 immer noch Probleme macht . Bei Compe als Hyper keinerlei Probleme, selbst in 3D. Gesamthaft 90 GB ecw:
[Blockierte Grafik: http://up.picr.de/7729550zso.jpg]
[Blockierte Grafik: http://up.picr.de/7729551aew.png]
Hallo,
ein eklatanter Schwachpunkt von CGPSL ist der Umgang mit manchen größeren Geotiff's zur RMAP Generierung. Habe dieserhalb ein Ticket erstellt mit gleichzeitiger Bitte der GM>RMAP Unterstützung, damit dieses Problem umgangen werden könnte;) . QV6 ist da deutlich besser und Tom arbeitet an einer weiteren Optimierung, dieses wichtigen, je nach Kompression verlustfreien Formates, speziell für 8 Bit Maps.
Bei einigen zufälligen Überprüfungen bei Tourenvorbereitungen ist mir aufgefallen, dass CGPSL und GM in der Regel gleich reprojizieren. QV 6 hat Abweichungen von ca. 3-5 m beispielsweise bei einer UTM/WGS84 Kombination, die sich auch in einer entsprechenden RMAP Abweichung wiederspiegeln. Bei kleinmaßstäblichen Karten fällt das auf, sonst kaum.
Wer gerne ECW in RMAP umwandelt (bessere Performance und bei vielen Maps deutlich geringere SDHC Speicherbelegung) wird in CGPSL keinen Qualitätsverlust im Gegensatz zu QV6 erkennen.
Kontinentale Planungen erfordern in QV 6 den Einsatz von Dummymaps, wenn dafür kleinmaßstäbliche bzw. Tile-Maps herangezogen werden.
