Beiträge von Martin K

Zitat von skyhopper

... Excel hab ich nicht. Geht eine ein ältere Version, z.B 97 auch? z.B office 97 ? Dann kauf ich mir eine alte Version bei ebay.

Hallo skyhopper, OpenOffice Calc liest und schreibt auch Dateien im Microsoft Excel Format *.xls. Gruß, Martin

Zitat von Hoagie

ich suche nach einer Lösung, eine Overlaykarte für meinen 276 zu erstellen. ... Wenn mich da bitte mal jemand auf den richtigen Weg schubsen könnte würde ich mich sehr freuen.

- Kochbuch - Rezepte für GPS-Karten im Garmin-Format von JürgenD (Das Kochbuch liegt im Ordner Docs von www.MapTk.dnsalias.com )

- Wie kommen lange Strecken und viele POIs in den GPS-Empfänger? - Tutorium zum Erstellen eigener Karten in 9 Folgen von Frank_B (Verknüpfung in ein anderes Forum)

- ezIMG von antyong (Download ; Tutorial dazu (Créer une carte transparente avec vos points et tracés GPS)

Viel Erfolg, Martin

Hallo Bernd,

wenn Du ein Legend mit MicroSD hast, dann verwende ein Kartenlesegerät, um die Karte zu übertragen. Das geht sehr viel schneller. Markiere in MapSource zuerst die gewünschten Kacheln der einen Karte (z.B. Topo D), wechsle dann zu der anderen Karte (z.B. Südtirol) und markiere dort die gewünschten Kacheln. In dem Reiter "Karten" sind nun alle markierten Kartenkacheln der verschiedenen Karten aufgeführt. Nun wählst Du "an Gerät senden". Die Datei "gmapsupp.img" im Dateiordner "garmin" wird dadurch ersetzt (=überschrieben). Wenn man regelmäßig bestimmte Kartensätze verwenden möchte, dann empfiehlt es sich, die entsprechenden "gmapsupp.img" in gesonderten Dateiordnern zu speichern. Dann braucht man sie nicht jedes Mal neu berechnen zu lassen und kann sie leicht und schnell kopieren und ersetzen.

Beschreibung von Bunav: Kartenmaterial vom PC auf GPS Geräte (GARMIN) übertragen
Video von AndreasL: Mehrere Karten auf das Gerät übertragen

Gruß, Martin

Hallo soarboy,

eine weitere interessante Seite ist die vom Explorer Magazin: Fehlende Map Datums und Grids.
Wähle an Deinem GPS Empfänger als Kartenbezugssystem User und trage die Parameter der Kowomaseite aus paul-josefs Beitrag ein. (In MapSource wählt man Benutzerdefiniertes Kartenbezugssystem; den Parameter für delta F muss man mit Dezimalpunkt eingegeben, nicht Dezimalkomma).
Bei dem Programm Geotrans V.2.4.2 fehlt bei mir NTF. Aber wenn ich es über Create Datum mit den Parametern für dX, dY, dZ von der Kowomaseite und Clarke 1880 als Ellipsoid ergänze, dann erhalte ich dasselbe Ergebnis wie mit dem GPS Empfänger oder MapSource.

Was ich nicht verstehe sind die Koordinaten. Ist damit N52.77469° E8.21008° (Dezimalgrad) gemeint? Dann war dort zur Zeit der Luftaufnahme in Google Earth eine kleine bewirtschaftete Wiese oder ein Baum in Deindrup bei Vechta (Niedersachsen), je nach dem, in welche Richtung die Koordinaten umgerechnet werden sollen.
N52.77469° E8.21008° (NTF) --> N52.77465° E8.20956° (WGS84) --> Wiese
N52.77469° E8.21008° (WGS84) --> N52.77473 E8.21060 (NTF) --> Baum
Aber warum dann NTF? Oder ist das so ein spezielles Geocacherätsel?

Gruß, Martin

Den vorangegangenen Hinweisen folgend habe ich einmal ein Ecklineal an den höchsten Punkt des "Reeth Low Moor" gehalten. Damit kann man wunderbar die Koordinaten ablesen: NZ(sollte auf der Karte ablesbar sein) 01(Gitter der Karte)28(Ecklineal) 00(Gitter der Karte)33(Ecklineal).

Ordnance Survey: Online Viewer (klick), Beschreibung des Britischen National Gitters (klick) von Menschen mit ziemlich großen Füßen.
Auf einem Garmin Outdoor Gerät (z.B. eTrex Vista HCx) und auch in Garmin MapSource kann man dieses Britische National Gitter als Positionsformat (nicht Kartenbezugssystem!) auswählen. Ob das beim TomTom 930 auch geht, weiß ich nicht (bei meinem alten Garmin StreetPilot kann man da gar nichts einstellen). Sonst hat Herbert in Beitrag#15 ja bereits auf ein Umrechnungswerkzeug verknüpft. Gruß, Martin

Hallo auelb, vielleicht magst Du der Einfachheit halber die Karte von extremecarver nehmen: http://openmtbmap.org | Download | Openmtbmap - Austria. Gruß, Martin

Hallo nordlicht,

danke für Deinen Hinweis. Bei den ASCII Datein von CGIAR/CIAT (klick) stehen die 6.000 mal 6.000 Höhenwerte in 6.000 Zeilen mit je 6.000 Zahlenwerten, wobei die einzelnen Zahlenwerte durch ein Leerzeichen getrennt sind, und die einzelnen Zeilen am Ende einen Zeilenumbruch haben. Diese Dateien kann ich problemlos in Microsoft Excel in eine Tabelle importieren. Ich kopiere mir dann anschließend beispielsweise die Zeile oder Spalte von einer Datei, füge sie bei einer anderen hinzu und erhalte so Dateien mit 6.001 mal 6.001 Höhenwerten. Wenn ich aber in dem Programm MicroDEM eine eigene Datei als ASCII arc grid speichere, dann stehen alle Höhenwerte in einer einzigen Zeile ohne Zeilenumbruch, und Microsoft Excel hat leider "nur" 16.384 Spalten. Leider kenne ich mich nicht mit VisualBasic aus, und vielleicht würde ich dann auch an die Grenze der Speicherverwaltung von 2 GB bei Excel 2007 stoßen. Bisher habe ich nur das folgende Script, wo mir aber die entscheidenden Bausteine noch fehlen:
Sub AscDateiimport()
Dim ASC As Byte
Dim Zeile As Integer
Dim Spalte As Integer
Dim Zeichenfolge As String
Dim AscDatei As String
Dim WS As Worksheet

ASC = FreeFile
Zeile = 1
Spalte = 1
AscDatei = Application.GetOpenFilename("Textdateien (*.asc),*.asc")
Set WS = ActiveSheet

' Datei einlesen
Open AscDatei For Input As ASC
Do While Not EOF(ASC) = True
Line Input #1, Zeichenfolge
????????????
WS.Cells(Zeile, Spalte) = Zeichenfolge
????????????
Zeile = Zeile + 1
Loop
Close ASC
End Sub
Mein Ziel war es, 216 Dateien mit jeweils 12.001 mal 24.001 Höhenwerten zu erzeugen. Als *.bil gespeichert und komprimiert sind die dann gar nicht mehr so groß. Letztlich bleibt das einigermaßen sinnfrei, das weiß ich schon selbst. Leider klappt es bei mir nicht, in MicroDEM durch Eingabe der Koordinaten einen ausgewählten Bereich einer großen zusammengefügten Karte zu speichern. Zufällig gibt es gerade einen Diskusionsbeitrag dazu (klick). Vielleicht sollte ich Prof. Guth einfach fragen, ob er den Zeilenumbruch nicht einfügen kann. Ich denke, das werde ich machen. Denn bei den ASCII Raster Format Dateien der NOAA stehen die Höhenwerte auch durch Zeilenumbruch getrennt in der Datei und können damit problemlos in Excel importiert werden. Gruß, Martin

Hallo Michael, vielen Dank für Deinen Tipp mit Vim und die Verknüpfungen. Ich habe mir die Version für Windows64 geladen und als GUI geöffnet (gvim.exe) und auch ein wenig in der Dokumentation gelesen. Die *.asc Dateien mit 6.000 mal 6.000 Höhendaten werden schnell geöffnet, aber mit dem Zeilenumbruch bin ich noch nicht weitergekommen. :set textwidth= nützt mir nichts, weil die einzelnen Höhendaten 1 bis 5 stellig sind (einschließlich Vorzeichen). Ich bräuchte also so etwas wie :set textwidth=6000 words. Mal schauen, ob ich da morgen mehr herausfinde, aufgeben mag ich noch nicht. Gruß, Martin

Hallo weoli,

nach längerer Zeit möchte ich noch einmal eine Ergänzung machen. Die angehängte Grafik zeigt den südwestlichen Bereich von srtm_39_02.asc von CGIAR/CIAT, dargestellt in MicroDEM. Markiert ist der Datenpunkt N50.0033E10.0033 (302 Hm), welcher von N50E10 (=289 Hm) jeweils vier Rasterabstände weiter nordöstlich liegt (4 * 0.00083333 = 0.0033(gerundet)). Zum Vergleich habe ich in MicroDEM die Übersicht "Terrain blowup" hinzugefügt sowie den entsprechenden Ausschnitt der Höhenwerte aus einem Texteditor.

MicroDEM zeigt den Höhenwert genau an der Stelle, wo er nach der der Information aus dem Data Header (yllcorner = 50 / xllcorner = 10 / cellsize = 0.000833333) auch sein sollte ==> keine Verschiebung. Das gleiche Bild erhalte ich, wenn ich srtm_39_02.asc als srtm_39_02.bil speichere, oder die daraus abgeleitete N50E010.hgt anschaue. MicroDEM stellt die Datenpunkte mit den Höheninformationen jeweils an der Position dar, wie sie sich aus dem Data Header errechnet, und zwar ohne irgendeine Verschiebung.

Dass der Bereich zwischen der ersten und zweiten Datenreihe bzw. -spalte nicht dargestellt wird, liegt daran, das ich den Rechenalgorithmus "8 neighbors (weight distance)" aus der Standardeinstellung gewählt habe, und in diesem Bereich noch keine 8 Nachbarn zur Berechnung zur Verfügung stehen.

Dass die Darstellung von Datenpunkten als flächige Pixel eigentlich nicht zulässig ist, darauf hat Jörn Weber ja schon in Beitrag#44 eindrücklich hingewiesen. Ich habe die Pixeldarstellung ja auch als Hilfsmittel zur Visualisierung verwendet (mit MapEdit++). Aber wenn GlobalMapper das *.asc Format anders darstellt als das *.bil Format, trotz gleicher Höhendaten und Angaben im Data Header, dann ist da etwas nicht korrekt.

Nun noch eine Frage: Kennst Du, oder ein anderen Mitleser, einen Texteditor, der automatisch nach einer bestimmten Anzahl von Wörtern einen Zeilenumbruch einfügt? Wenn ich die *.asc Dateien von CGIAR/CIAT in einem Editor oder Microsoft Excel einlese, dann ist dort nach jeder Datenreihe ein Zeilenumbruch. Aber wenn ich in MicroDEM eine Datei als ASCII grid speichere, dann stehen alle Höhenwerte in einer einzigen Zeile. Für einen Tipp wäre ich sehr dankbar. Oder kennt jemand einen anderen Weg, die Höhendaten in eine editierbare Tabelle zu bringen?

Ich habe mal Meerestiefen von der NOAA geladen und damit die Dateien von CGIAR/CIAT ergänzt (einfach mit MicroDEM | Edit | DEM Holes | replace values with rerference DEM).

Gruß, Martin

Hallo weoli,

bei den ArcASCII Daten gibt es keinen Versatz, wie er bei den GeoTiff Daten in MicroDEM angezeigt wird. Wenn man in MicroDEM eine ArcASCII Datei von CGIAR öffnet (auch *.zip Dateien kann MicroDEM direkt öfftnen) und dann den Data Header anschaut, dann sieht man, dass die südwestliche Ecke genau auf dem Längen- bzw. Breitengrad liegt. Wenn man aus einer solchen Datei Höhenlinien erzeugt (als *.bil speichern, BILxSRTM, DEM2Topo (oder MapEdit++)), dann sind die genau deckungsgleich zu denen aus den *.hgt Dateien der NASA. Deshalb auch meine Empfehlung, wo es möglich ist, die ArcASCII Dateien anstelle der GeoTiff Dateien zu nehmen. Ich hatte Dr. Jarvis damals auch eine Verknüpfung zu diesem Thema hier im Naviboard gesendet. Ich weiß zwar nichts über seine Sprachkenntnisse, aber zumindest die Bilder kann man auch so verstehen.

Gruß, Martin

Hallo weoli,

sei mir bitte nicht böse, wenn ich auch noch etwas ergänze (und insgeheim hoffe, dass es noch weitere Beiträge zu diesem Thema gibt):
Ich hatte die 26.799 *.hgt Dateien von N59W180 bis S53E179 bzw. von S45W180 bis N59E179 "kurzerhand" aus den ArcASCII Dateien von CGIAR erzeugt, weil es dort keine Verschiebung gibt. Lediglich für srtm_17_09, -18_01, -60_19 und -61_01 hatte ich die GeoTIFF Dateien verwendet (indem ich den Data Header angepasst hatte), weil sich diese vier komprimierten *.asc Dateien nicht öffnen ließen. Zusätzlich hatte ich bei srtm_19_03, -42_04, -43_03, -43_04, -44_04, -46_04, -47_04 und -47_05 die Datenlücken mit den Höhenwerten der angrenzenden Wasserflächen aufgefüllt.

Nachteil der *.asc Dateien ist, dass MicroDEM mehr Zeit braucht, sie zu öffnen, als etwa *.tif oder *.bil Dateien. Deshalb hatte ich mir zunächst die Mühe gemacht, die *.asc Dateien (und die erwähnten korrigierten Dateien) als *.bil zu speichern.

Ich hatte mir dann einen Plan gemacht, wie ich die einzelnen Dateien so vereinigen kann (Funktion merge), damit die fehlenden Datenreihen und -spalten der *.hgt Dateien am östlichen bzw. südlichen Rand der *.bil Dateien berechnet werden können (siehe Angehängte Grafiken). Schließlich hatte ich vier Dateiordner mit jeweils überlappungsfreien Daten. Mein Rechner benötigte etwa 90 Minuten pro Dateiordner, um mit BILxSRTM die entsprechenden *.hgt Dateien zu erzeugen. Anschließend habe ich über die Windows Suchfunktion (mit * als Platzhalter) die jeweils "äußeren" *.hgt Dateien gelöscht und schließlich alle übrigen *.hgt Dateien in einen neuen Ordner eingefügt: 26.799 an der Zahl.

In MicroDEM kann man leider nicht eine srtm_72_*.asc Datei mit einer srtm_01_*.asc Datei vereinigen. Dadurch bleibt bei den entsprechenden *E179.hgt Dateien jeweils die östliche Datenreihe ohne Werte.

Ich habe in MicroDEM mit File|Save DEM|Reinterpolate, Lat/Lon 1Sek Daten erzeugt. Der bilineare Interpolationsalgorithmus liefert teilweise etwas schönere Höhenlinien, teilweise werden aber auch Geraden zu sinusförmigen Kurven, und das gefällt mir nicht so.
Der Rechenaufwand für die Erzeugung der *.hgt Dateien mit BILxSRTM steigt enorm, ebenso wie der Rechenaufwand von DEM2Topo, wobei die erzeugten *.mp Dateien kaum doppelt so groß sind, wie aus 3Sek Daten. Dein Vergleich der Programme DEM2Topo und Global Mapper zur Erzeugung der Höhenlinien ist beeindruckend. Die Höhenlinien von Global Mapper sehen viel schöner aus. (Mit MapEdit++ kann man ja auch per Mausklick in Sekundenschnelle Höhenlinien aus *.hgt Dateien erstellen, aber die sind zum Rand hin zunehmend verschoben.)

Dass die SRTM3 v4.1 Daten für die Meeresflächen keine Daten enthalten ist einerseits ärgerlich, weil man dann selbst (wie Du es oben schon beschrieben hattest) mit Edit|DEM Holes|Missing Data to sea level diese Werte einfügen muss, wenn man mit dem Boot auf dem Meer unterwegs ist. Wenn man allerdings Dateien mit Meerestiefen zur Verfügung hätte, könnte man auch diese verwenden, um die fehlenden Werte für die Meeresflächen zu ergänzen.

(Ich weiß nicht, ob Du über die OSM Reit- und Wanderkarte gelesen hast. Ohne Deinen Hinweis auf MicroDEM und BILxSRTM sowie Deinen und Jörns Hinweis auf die v4.1 Daten von CGIAR wären die *.hgt Dateien nicht entstanden, die zurzeit zur Berechnung der Höhenlinien verwendet werden.)

Nun noch mein vorläufiges Fazit zur Eingangsfrage:
- Die ArcASCII Dateien sind (wo es möglich ist) den GeoTiff Dateien vorzuziehen. (Wegen der Lage des südwestlichen Pixels der GeoTiff Dateien hatte ich leider keine Antwort von CGIAR erhalten. (Möglicherweise ging die Antwort auch verloren, weil ich meine eMails nicht immer regelmäßig abgeholt hatte.))
- Reinterpolation von SRTM3 zu SRTM1 Daten kann zu schöneren Höhenlinien führen. Ob diese realitätsnäher sind als Höhenlinen aus SRTM3 Daten, kann ich nicht beurteilen. In jedem Fall steigt der Rechenaufwand und der Speicherbedarf.
- Es wäre wünschenswert, wenn CGIAR auch die *.hgt Dateien auf ihren Servern zur Verfügung stellen könnte. Eine kleine Fläche (z.B. Europa) kann sich jede/r selbst schnell errechnen, wenn er/sie mit den Programmen vertraut ist. Für alle aus den verfügbaren SRTM3 Daten errechneten *.hgt Dateien ist es meines Erachtens einfacher, auf privater Ebene DVDs auszutauschen, oder einen alternativen Server zu suchen, der die Dateien aufnimmt. Dabei gilt natürlich immer, dass auf CGIAR als Produzent der SRTM3 v4.1 Daten hinzuweisen ist und die Daten nicht kommerziell genutzt werden dürfen. (Kommerzielle Verwendung nur mit ausdrücklicher Erlaubnis von CGIAR.)

Gruß, Martin

Hallo Anton,

danke für das Testen und die Bildschirmfotos. Genial, dann ist das also ein möglicher Weg, wenn man das Programm TTQV besitzt. Das ist ja leider nicht immer so, dass Programme und Formate zueinander passen.

Gruß, Martin

Ergänzung am 14.Apr.2009: ich will das Thema nicht wieder nach oben bringen, deshalb füge ich nur diese Ergänzung ein:
Aus MicroDEM heraus kann man Karten direkt in Google Earth öffnen (ähnlich wie man aus MapSource heraus Wegpunkte, Tracks und Routen direkt in Google Earth öffnen kann):
--> MicroDEM | File | Save map as image | For Google earth
--> Google Earth wird mit der Karte geöffnet. (Über die Eigenschaften der Karte kann die Transparenz eingestellt werden.)
Das Beispiel zeigt den Blick auf den Zischgeles mit Westfalenhaus in der Bildmitte:

Ergänzung am 03.Mai2009: ich ergänze den Beitrag noch einmal mit einer *.kmz Datei für Google Earth: Schalfkogel_Hangneigungskarte_kmz.zip. Sie enthält zwei Hangneigungskarten des Schalfkogel, wobei die Steigung einmal nach dem "steilsten von 8 Nachbarn" und einmal nach dem "ungewichteten Mittelwert aus 8 Nachbarn" mit dem Programm MicroDEM berechnet wurde. Die Höhendaten im SRTM1 Format stammen von Jonathan de Ferranti.

Zitat von rennradler

... Ich meine sowas: http://gis2.tirol.gv.at/script…ualisieren&info=1&Suche=0
... Ist das Höhenmodell von Jonathan de Ferranti verläßlich?

Hallo Bernhard,

danke für die Verknüpfung zu der Seite von Tirol. Also die Neigungskarte, die dort hinterlegt ist, die kann man sich auch in wenigen Schritten und Sekunden in MicroDEM darstellen lassen und als GeoTiff (nur Farbpixel, keine Höhendaten, keine Höhenlinien) speichern:
- File/Open/Open DEM/ --> Datei auswählen (z.B. *.hgt Datei von Jonathan de Ferranti)
- Kartenausschnitt auswählen mit Subset & Zoom (Einstellung für Pan buttons nur über Options/Map )
- Modify/Display Parameter/Slope/Standard Categories --> Slope colors --> Anzahl der Kategorien, Farben und Wertebereiche festlegen --> Klick auf OK zeichnet die Hangneigungskarte (Auswahl der Legende über Modify/Display Parameter/Legend/Marginalia)
- File/Save map as image/As GEOTIFF, screen scale (color)
- Die verschiedenen zur Auswahl stehenden Algorithmen zur Berechnung der Hangneigung sind in der Hilfe von MicroDEM kurz beschrieben. Eine Beschäftigung mit dieser Thematik scheint mir unabdingbar. Die Auswahl erfolgt über Options/Analysis/Slope Algorithm.
- Hinweis zum öffnen einer eigenen Neigungskarte: File/Open/Open Image/ --> Datei auswählen:
Wenn die Farben nicht korrekt dargestellt werden, kann das an der Einstellung für Kontrast liegen. Tipp: Options/Imagery/Contrast/Enhancement=None (auch über Klick mit rechter Maustaste erreichbar)

Vielleicht kann jemand überprüfen, ob die angehängte GEOTIFF Datei in TTQV weiterverarbeitet werden kann.

Zur Qualität der Höhendaten von Jonathan de Ferranti kann ich nichts weiter beitragen. Da gibt es aber einige Aussagen von kompetenteren Naviboard Mitgliedern hier im Forum. Die angefügte Grafik zeigt die Schöntalspitze, die auch in der Verknüpfung angegeben war (klick). Man erkennt, dass die Auflösung gröber ist und der verwendete Algorithmus etwas andere Werte berechnet.

Bezüglich Lawinengefahr würde ich mich immer bei den lokalen Behörden vor Ort informieren. Ein Wert für die Hangneigung allein sagt ja gar nichts über die Exposition, die Schneemenge oder die Schneebeschaffenheit aus. Und leider bleibt eine Lawine nicht einfach stehen, sobald die Hangneigung geringer wird. Aber die Gefahr, eine Lawine selbst loszutreten, nimmt natürlich mit Abnahme der Hangneigung auch ab.

Gruß, Martin

Hallo Bernhard, vielleicht können Dir die Höhdendaten von Jonathan de Ferranti und das Programm MicroDEM von Peter Guth weiterhelfen.
Kleines Beispiel:
N47E009.hgt (Auflösung = 1 Bogensekunde)
Abstand der Höhendaten: West-Ost: 21 Meter/Pixel bzw. 0,0476 Pixel/Meter
Abstand der Höhendaten: Nord-Süd 30,83 Meter/Pixel bzw. 0,324 Pixel/Meter
Kartenauschnitt: N47.147 bis N47.159 (=1.315 Meter), E09.664 bis E09.681 (=1.315 Meter)
Höhendifferenz: 1.075 Meter bis 1.920 Meter
Linke Grafik: Steigung
Rechte Grafik: Höhenschichtung

- allgemeiner Tipp für Bildschirmfotos: die maximale Auflösung des Monitors auswählen
- Tipp für MapSource: Tastenkombination <Strg> + <T> und dann die Koordinaten jeweils um einen festen Betrag verändern. Mit einem Tabellenkalkulationsprogramm kann man sich auch eine kleine Tabelle dazu machen.
- Tipp für Garmin Topo Deutschland: verschiedene Kartendarstellungen vergleichen (MapSource 6.13.7 / MapSource 6.15.3 / verschiedene *.typ Dateien (Huzzel, MapTK))
- Tipp für Microsoft Powerpoint (geht bei anderen Programmen vielleicht ähnlich): Alle eingefügten Bildschirmfotos markieren, rechte Maustaste --> Größe und Position. Damit kann man gleichzeitig für alle markierten Fotos den Fensterrahmen wegschneiden.

Danke an tutterchen für das Stichwort Stitching. Bei Wikipedia fand ich daraufhin diesen Artikel (klick) und bei Microsoft dieses kostenfreie Programm (klick).
Ich habe dann mal 15 Bildschirmfotos von der OSM Reit- und Wanderkarte gemacht. Ich habe sie in Microsoft Powerpoint eingefügt, die Fensterrahmen entfernt und jedes Foto als einzelne *.jpg Grafikdatei gespeichert. Mit dem (kostenfreien) Microsoft Image Composite Editor v1.2 64-bit habe ich die 15 Grafikdateien dann in einem Rutsch zusammengefügt. Tipp: die Bildschirmfotos sollten mindestens 10 bis 20% überlappen, sonst funktioniert das "zusammennähen" nicht.

Vielleicht ist es doch ein Kartenfehler? AndiTheB hatte ja schon in Beitrag#67 auf MapSetToolKit hingewiesen:
--> im Fensterbereich "Mapset installed" werden alle installierten Kartenprodukte aufgelistet.
--> Klick auf die Schaltfläche "Check Registry"
--> die fehlerhaften Karten werden dann angezeigt.
Oft braucht nur die *.tdb Datei korrigiert zu werden. Das erledigt MapSetToolKit, indem man die entsprechende Karte neu installiert.

Gruß, Martin

Hallo schorsch,

in diesem Thema im OpenStreetMap Forum steht:
- Bei den Karten von Computerteddy aus Daten vom 31.12.2008 konnte man in einige Bereiche nicht ganz hineinzoomen. Bei den Karten aus Daten vom 07.01.2009 geht das wieder (siehe angehängte Grafiken vom eTrex Vista HCX).
- Die einzelnen Kartenkacheln überlappen teilweise sehr stark. Wenn nur ein bestimmter Kartenbereich auf den GPS Empfänger übertragen werden soll, dann müssen alle Kartenkacheln ausgewählt werden, die in den gewünschten Bereich hineinragen.

vielleicht hilft Dir das schon weiter. Sonst teile bitte noch mit,
- von welchem Datum die Karten sind,
- in welcher Region das auftritt und
- ob die Karte auch in MapSource verschwindet.

Gruß, Martin

Zitat von paul-josef

Es geht aber auch sehr gut graphisch, dazu oben in MS die Werkzeuge für die Trackbearbeitung einblenden.

... und dann die Trackteilungsfunktion verwenden.

nicht von Garmin, versetzt den Hörer aber auch in die Natur:

Vogelstimmen als *.mp3 und in Stereo bei The Virtual Bird:
Amsel (Turdus merula), Kranich (Grus grus), Sprosser (Luscinia luscinia), Waldkauz (Strix aluco).

Verknüpfung auf diese Dateien bei Vogelstimmen.de

Ergänzung: Tonaufnahmen von Stefan Wehr (www.vogelstimmen-wehr.de)