Beiträge von Rhadamanthys

    Zitat von "Kai Nolte"

    Nun ist da noch ein Forummitglied welches mir eventuell mit der ersten Frage weiterhelfen kann?
    Gruß Kai


    Meine Multi-Jpg-Downloads mache ich mit einem selbst geschriebenen Excel-Makro. Das hat 3 Vorteile:
    1. Keine Beschränkung auf 500 Kacheln.
    2. Die Kacheln überlappen ein wenig, sodaß das Google-Logo sich auf der fertigen Karte nicht ständig wiederholt.
    3. Die Gesamtkarte muß nicht rechteckig sein. Ein Umrißpolygon, mit TTQV als Track erstellt, begrenzt den Download auf sinnvolle Bereiche.


    Die alte Variante erstellt dazu die qtl, die neue ein Script für Global Mapper zum Export im ecw-Format. Mit qtl gehen ca. 1500 Kacheln, dann werden die Ladezeiten ungemütlich und auf ganze Karte zoomen ist tödlich (für TTQV). Mit ecw gehen auch 25000 (i.W. fünfundzwanzigtausend): halb Deutschland ca. 12GB. Zoomt wie der Blitz. Für den Download muß man sich natürlich Zeit nehmen (abends starten, morgens Karte bewundern).


    Ich verwende GE4, das läßt sich mit VBA direkt anreden. Wie groß die Kacheln sind, ist mir gleichgültig, die fertige Karte wird so groß wie mein Umrißpolygon. GE4 tut, was ich brauche, also ignoriere ich die regelmäßigen Hinweise auf neue Versionen. Update=Ärger.

    Zitat von "sardinien"

    Achtung, dadurch könnte ein künftiger Zugriff auf Google Maps nicht mehr möglich sein.


    Das ist mir schon klar. In den Nutzungsbedingungen (http://www.google.com/intl/de_de/help/terms_maps.html), die auf der Website leicht zu finden sind und denen jeder Nutzer, insbesondere auch der API, explizit zustimmt, lese ich u.A.:


    "Außerdem ist es nicht zulässig, Google Maps in einer Weise zu erwenden, die Ihnen oder anderen Personen Zugriff auf Massen-Downloads oder Masseneingaben von numerischen Breiten- und Längengradkoordinaten verleiht."


    Gerade deshalb hätte ich von Joern gerne gehört, wie er sich das "Anzapfen" legalerweise vorstellt.

    Zitat von "TheRastaman"

    Bin jetzt getreu den Vorgaben in der Beschreibung vorgegangen, habe die Wert auch dreimal kontrolliert. Trotzdem ist ein Versatz von mehreren 100 Metern festzustellen, wenn ich zB zwischen NAVTEQ 2005/Q4 und der Norwegen-Karte wechsle.
    Hab den Fehler nur ich, oder sind die Karten einfach ungenauer.


    Auf meine Karten paßt die Navteq 2006Q4 perfekt, getestet mit Straßen in Oslo. Bei Versatz kann ich mir nur vorstellen, daß falsches Datum oder falsche "Scale_K" vorliegt (Anzahl der "9" zählen!). Du kannst auch versuchen, eine Karte in der Nähe von 15°E, z.B. Trondheim direkt mit UTM/WGS84 zu kalibrieren. Das geht nur deshalb nicht überall, weil TTQV eine Begrenzung von ca. 120km links und rechts vom Zentralmeridian eingebaut hat und dann gerne die nächste Zone sehen will.

    Zitat von "consultancy"

    Was genau machst Du an dieser Stelle?


    Das Makro produziert den Workspace "meinekarte.gmw". Die Endung gmw ist in Windows mit GM assoziiert, ein Doppelklick auf "meinekarte.gmw" startet also GM und übergibt die gmw. GM arbeitet die Datei ab, d.h. setzt die 4400 Kacheln zu 190 Streifen mit insgesamt 6GB und dann diese zur Gesamtkarte zusammen, ohne erst zu versuchen, sie im Fenster darzustellen. GM bleibt in der Taskleiste minimiert. Wenn ich GM normal öffne und die Kacheln oder Streifen lade, dauert das ewig.

    Zitat von "sardinien"

    Hallo Rhadamanthys,
    wieviel GB íst deine Karte groß? Hast du den Import in GM mit einer .prj
    vorgenommen? Wäre mal interessant zu wissen.
    Norwegen ist ja sehr schön, waren beim Windsurfen ziemlich alleine und die Nordsee hatte mal über Nacht von 20 Grad auf 14 Grad abgekühlt.
    Eignet sich glaub besser zum Fischen und Trekking.


    Was bei Kystverket als Raster/Schummerung angeboten wird, hängt vom gewünschten Maßstab ab. Ergo habe ich 4 Karten:
    5m/Pixel, 237633 x 299399, 6,3GB bei 5%, 3GB bei 20%
    25m/Px, 47559 x 60203, 325MB
    120m/Px, 10013 x 13908, 19MB
    250m/Px, 4921 x 6200, 4,7MB


    Ich kann die 4400 Kacheln nicht einfach in den GM laden, bei 2GB RAM ist nach einigen 100 Schluß. Soviel Auslagern kann niemand abwarten.


    Mein VBA-Makro produziert einen GM-Workspace, der erst die Kacheln waagrecht (W>O) zu ecw-Streifen zusammenfügt, dann die Streifen vertikal (S>N) zur Gesamtkarte, natürlich überlappend, sodaß die Maßstabsbalken und Copyrightvermerke nicht die ganze Karte versauen. Im Workspace steht auch die Projektion, UTM Zone 33. Anders als TTQV ist GM nicht pingelig wegen der Ausdehnung der Zone. Günstig ist der direkte Aufruf des Workspace, sodaß GM erstmal die Bedienoberfläche NICHT öffnet, sondern sich gleich an die Arbeit macht. Das spart Arbeitsspeicher und beschleunigt die Sache ungemein. 1 Tag Rechenzeit ist trotzdem drin. Dafür läßt sich die Karte in TTQV öffnen und zoomen, als wär's ein kleines Bildchen. Die auf 20% eingedünstete Karte sieht nur bei sehr scharfem Hinsehen etwas unruhiger als als die 5%ige. Bin echt dankbar für den GM!

    Zitat

    Auf die Idee bin ich überhaupt nicht gekommen. Ich habe immer nur beim Kalibrieren und in den Menüleisten gesucht.
    Eindeutig zu kompliziert gedacht.!


    Sehr hilfreich auch die Anleitung von Rolf Fe, reich bebildert, Link weiter oben.

    Ich habe mir jetzt einen gebastelt und damit ganz Norwegen 1:20000 gezogen. Läuft leider nicht ganz stabil, braucht gelegentlich Eingriffe. Der Server ist nicht sehr schnell, für jeden Download werden jpg, jgw und zip extra angefertigt, also mehr als 3 Kacheln/Minute ist nicht drin. Die ca. 4400 Kacheln habe ich mit Global Mapper zu einer Karte zusammengefügt.

    Zitat von "sardinien"


    Wenn man vor dem Start den Höhenmesser kalibriert, sind die Ergebnisse
    am Besten. Beim ersten Bild wird die Barometerhöhe aufgezeichnet.
    (Die barometrische Höhe wird bei einer gewissen Abweichung zur GPS-Höhe Schrittweise der GPS-Höhe angepasst)


    Hallo Gerd,
    bin gerade über deinen Beitrag gestolpert. Ich hatte mal einen Etrex Summit mit Kompaß und Barometer. Wie Garmin die barometrische Höhenmessung einbindet, ist echt eine Katastrophe: In den Tracks erscheint die GPS-Lage (Breite, Länge) und die barometrische Höhe, die die bekannten sytematischen Fehler besitzt, also ständig kalibriert werden muß. Umgekehrt wird im 2D-Modus (nur 3 Satelliten) die Barometerhöhe NICHT verwendet, sondern die letzte bekannte GPS-Höhe. Hat man oben auf dem Berg ausgeschaltet und im Tal wieder ein, stimmt erst mal gar nichts. Position weit daneben, weil mit falscher Höhe berechnet, Höhe weit daneben, weil der Luftdruck sich geändert hat.
    Garmin hat sich einfach keine Mühe gegeben. Die Barometermessung hat viel größere systematische Fehler als GPS, aber wesentlich geringere stochastische Fehler (Rauschen). Die Einbindung des Barometers in das Kalmanfilter der Navigationslösung wäre die korrekte Lösung, ist Garmin aber wohl zu anstrengend.
    Bei der Anschaffung meines GPSmap habe ich deshalb absichtlich auf die Barometervariante verzichtet. War richtig, wie der Vorschlag zeigt, das Barometer abzuschalten.

    Zitat von "wynetwix"

    Vielleicht mal das Komplettsetup drüber laufen lassen ?


    Habe ich soeben gemacht (114PU), wie erwartet, kein Unterschied (spricht für die Updates).
    Damit wir uns richtig verstehen: Hat man den X-Plorer intern, zeigt sich im Fenstermenü die Liste der Fensterbefehle, dann ein Querstrich, darunter eine numerierte Liste der geöffneten Unterfenster, also z.B.
    1 Touratech X-Plorer <WGS84>
    2 (1) Top 25 Deutschland...
    3 (2) TTQV Navteq...


    Der Querstrich und die Liste ist weg, stellt man den X-Plorer auf extern, genau wie von Volker vor 2,5 Jahren beschrieben. Dieses Verhalten hängt auch nicht von den Benutzerrechten ab. Würde mich echt überraschen, wenn es bei dir anders wäre!

    Zitat von "jockel"

    Das könnte daran liegen, daß es sonst schwierig wir, sich bei mehreren
    Tracks mit unterschiedlichen Zeitzonen auf eine zu einigen, ergo hat Tom
    vielleicht deshalb die GPS-Zeit genommen. Ist aber nur geraten, könnte
    nur Tom beantworten, kannst Du ja aber leicht selbst ausprobieren.


    Hab's ausprobiert, ist so. Man könnte natürlich die Sinnfrage stellen, weil Tracks aus unterschiedlichen Zeitzonen auch räumlich weit auseinander liegen. Möchte ich meine Bergtour in den Alpen mit einer im Himalaya vergleichen, brauche ich eine relative Zeitskala (ab Abmarsch) und muß dazu TTQV verlassen.


    Umgekehrt, ich betrachte meine kalifornischen Tracks zuhause in D (UTC+1h), dann muß ich die GPS-Einstellung ändern, um im Diagramm nicht scheinbar nachts unterwegs gewesen zu sein.


    Ich glaube, das ist einfach ein Relikt aus der Zeit, als Zonenzeit für Tracks noch TTQV-global war, QV2.5, wenn ich mich recht erinnere.



    Origineller finde ich, daß "Höhe DEM" offenbar immer in UTC gezeichnet wird, d.h: keine Umrechnung statt findet. In aller Regel passen die Diagrammlinien dann nicht zusammen. Man muß für die X-Achse "n" oder "s" wählen, dann passt es.

    Zitat von "blst"

    Das Problem sind aber die Zeitangaben der Trackpoints, wenn ich schöne Höhenprofile und Diagramme rausbekommen will. Sinnvoll für solche Auswertungen wäre IMHO ja nur, eine konstante Geschwindigkeit zwischen den letzten beiden guten GPS-Messungen vor und nach dem Wald anzunehmen. Die Zeitinformationen für die neu hinzugefügten Trackpoints, die sich aus dem Wegeverlauf ergeben, müssten hingegen aus den Abständen der neuen Trackpoints zum Startpunkt neu berechnet werden.


    Derlei löse ich außerhalb TTQV. Tracks über die Zwischenablage in Excel importieren, da stehen mir Verarbeitungsmöglichkeiten ohne Ende offen und schönere Diagramme gibts auch.

    Zitat von "Rhadamanthys"

    Danke!
    Habe eben die Topo25-Deutschland installiert. Auf der CD scheint mir schon ein DEM der o.a. Art. Mal sehen, ob das mit QV4.0.108 schon tut...


    Mit dieser kleinen Subroutine:
    Sub asc2bin(dateiname)
    Dim alt As Long
    Dim hi As Byte
    Dim lo As Byte
    bindatei = Replace(dateiname, ".ASC", "")
    hdrdatei = Replace(dateiname, ".ASC", ".hdr")
    Open dateiname For Input As 1

    Input #1, t
    ncols = Val(Mid(t, 14))
    Input #1, t
    nrows = Val(Mid(t, 14))
    Input #1, t
    xllcorner = Val(Mid(t, 14))
    Input #1, t
    yllcorner = Val(Mid(t, 14))
    Input #1, t
    cellsize = Val(Mid(t, 14))
    Input #1, t
    ndvalue = Val(Mid(t, 14))

    Open hdrdatei For Output As 2
    Print #2, "BYTEORDER M"
    Print #2, "LAYOUT BIL"
    Print #2, "NROWS " & nrows
    Print #2, "NCOLS " & ncols
    Print #2, "NBANDS 1"
    Print #2, "NBITS 16"
    Print #2, "BANDROWBYTES " & 2 * nrows
    Print #2, "TOTALROWBYTES " & 2 * nrows
    Print #2, "BANDGAPBYTES 0"
    Print #2, "NODATA " & ndvalue
    Print #2, "ULXMAP " & Str(xllcorner)
    Print #2, "ULYMAP " & Str(yllcorner + cellsize * nrows)
    Print #2, "XDIM " & Str(cellsize)
    Print #2, "YDIM " & Str(cellsize)
    Close 2

    If Dir(bindatei) > "" Then
    a = MsgBox("Überschreiben?", vbYesNo, bindatei & " existiert!")

    If a = vbNo Then
    Close
    Exit Sub
    End If

    End If

    Open bindatei For Binary As 2

    For zl = 0 To nrows - 1

    For sp = 0 To ncols - 1
    Input #1, alt

    If alt < 0 Then alt = alt + 65536

    hi = alt \ 256
    lo = alt Mod 256
    Put #2, , hi
    Put #2, , lo
    Next

    Next

    Close
    End Sub


    läßt sich aus der *.ASC-Datei von http://srtm.csi.cgiar.org eine passende Binärdatei (halb so groß) und die zugehörige *.hdr-Datei erstellen. Wird von QV4 (mindestens ab 102) problemlos akzeptiert. Man muß also nicht unbedingt auf QV5 warten, um die Löcher los zu werden.


    Das ASCII-Format ist natürlich ein Speicherplatzfresser, wie man schon am ZIP-Kompressionsfaktor ablesen kann...

    Zitat von "jockel"

    mojn, mojn,


    QV5 wird das Globalmapper DEM Format unterstützen, wir haben die
    korrigierten Daten von CGIAR/CIAT lizensiert und werden die dann im
    GM-DEM-Format anbieten.


    Danke!
    Habe eben die Topo25-Deutschland installiert. Auf der CD scheint mir schon ein DEM der o.a. Art. Mal sehen, ob das mit QV4.0.108 schon tut...

    Die Funktion ist schon OK. Das ganze System, also ein PC mit Windows, diverser Peripherie, dazu Anwendungssoftware mit Plugins usw. das läuft nicht so stabil, wie man sich das während einer mehrstündigen Autofahrt wünschen würde. Man kann ja nicht dauernd daran fummeln, außer der Beifahrer ist auch noch Experte. Und für den Einsatz im Fahrzeug ist es auch nicht wirklich gedacht, außer vielleicht so ein Tablet PC aus dem TTQV-Shop für über 3000 Euros.


    Daß sich TTQV gerne mal mit einem "Laufzeitfehler 0" oder dergl. verabschiedet, kann man hier im Forum leicht nachlesen (wer sucht, findet 119 Ergebnisse). Auch beim Onlinemodus haben einige ihre Probleme berichtet.


    Angeblich hat Microsoft in die Vistaentwicklung 40000 Mannjahre gesteckt. Könnt ihr mal nachrechnen, was raus kommt, wenn nur 1 Fehler pro Jahr rein programmiert wird. In Deinem Navigon steckt sicher nur ein Hundertstel der Software, schon von daher kann es 100mal stabiler laufen.


    Das Auto bleibt stehen. Alle Versuche scheitern, es zum Laufen zu bringen. Lösungsangebot der MS Knowledge Base: Schließen Sie alle Fenster und starten Sie das System neu...