Beiträge von reinim19

    Meiner bescheidenen Meinung nach, anhand meiner Suche nach Höhendaten - und ich bin nicht gerade ein QV-Newbie ;-)


    - Zuerst schaue ich im Menü und den Icons von QV7 ob es dort so etwas wie "Import Höhendaten" gibt => es gibt "Neue Karte importieren" > "DEM". Dazu muss man aber eine zuvor runtergeladene Höhendatei (.hgt, .gmg) öffnen

    - dann öffne ich die QV-Hilfe und suche nach "Höhendaten" > es öffnet sich die Seite https://quovadis-gps.com/anlei….php?id=de:35_maps:k_dems

    - ich google nach "Quovadis Höhendaten" und stoße auf https://quovadis-gps.com/shop/Hoehendaten . Dort gibts aber nur kostenpflichtige Daten, deren Herkunft - sagen wir mal - nicht immer ganz ausführlich beschrieben ist. Ständig stößt man auf "SRTM" und "Auflösung von 25 m". Auch SRTM 1" haben diese Auflösung, sind aber nicht zu vergleichen mit LiDAR-Quelldaten der selben Auflösung, dass sagt also nicht viel aus.


    Dort steht nirgends eine Wort von Sonny's Höhendaten oder Horst_H Spezialkarten - die auch DEMs beinhalten. Selbst wenn ich diesen Eintrag in QV links unter "Downloadpakete" gesehen hätte, hätte ich nicht reingeschaut da ein DEM für mich keine "Karte" ist ;-) Genauso wenig wie andere interesssante Daten darin wie POIs. Vielleicht sollte man dieses Paket umbenennen in "Horst_H - Karten, DEMs, POIs"

    Normalerweise sollte ich eine E-Mail erhalten wenn jemand in einem von mir abonnierten Thread antwortet. Das habe ich in den Benachrichtiguns-Einstellungen so eingestellt ("Sofortige E-Mail Benachrichtigung"). Das dürfte aber derzeit nicht funktionieren, ich erhalte keine E-Mails, auch nicht im Spam-Ordner. Haben Andere auch dieses Problem?

    Danke Horst,

    Wo genau finde ich die *.gmg-Dateien für QV7? Ich habe hier gesucht: https://quovadis-gps.com/shop/Hoehendaten-fuer-QV7 und auch https://quovadis-gps.com/shop/Hoehendaten aber dort nichts gesehen.

    Außerdem ist die Herkunft der dortigen Daten nicht ganz klar: Auf den Übersichtsseiten ist sowohl von "SRTM3", "SRTM1", "Hochauflösende Höhendaten" die Rede, die Detailseiten eines Prdodukts werden da auch nicht konkreter. Von "Sonny Lidar Höhendaten" ist da nirgends was zu lesen.

    Auf folgender Website: https://sonny.4lima.de gibt es von Sonny zahlreichen europäischen Ländern digitale Höhenmodelle (DEM) zum (kostenlosen) Download. Diese basieren auf präzisen Opendata LiDAR-Höhendaten der Vermessungsinsitute dieser Länder.

    Die Verbesserungen in Sachen Genauigkeit, Qualität und Detailliertheit dieser Dateien verglichen mit satelliten-basierten Modellen wie SRTM, ASTER, ALOS, COPERNICUS sind enorm. Speziell in Waldgebieten, felsigem Terrain oder engen Tälern.


    Man kann diese in QV als genaue DEM-Quelle verwenden. Also zur Anzeige der Höhe einer Koordinate, zum Berechnen des Höhendifferenz eines Tracks, Schummerungen, oder zur 3D-Darstellung. Natürlich auch zum Erzeugen von besseren Höhenlinien oder Schummerungen für QV-Karten.

    Nach einem weiteren Blick auf deine Screenshots: Geh mal in den Kalibrierdialog und sieh nach, welche UTM-Zone dort eingestellt ist. Bei deinem QVX-Screenshot steht das Gitter auf UTM-Zone 31, die Karte liegt aber in Zone 33.

    Um auch noch das aufzuklären: Die rosa Zahlen sind da noch in Zone 31, weil man noch nicht in die Karte geklickt hat um den Kartencursor zu positionieren. Tut man das, dann steht dort auch in rosa Zone 33

    Hast du es denn schon ausprobiert?

    Bei mir hat nämlich genau das die Lage- und Artefakte Probleme behoben ;-)


    Man braucht überhaupt kein Koordinatengitter oder Kalibrierung einstellen. Einfach die Original Geotiff vom BEV importieren, "Load Bmp, jpg, png, tiff patially" aktivieren und fertig. QV7 kommt mit EPSG 25833 aka ETRS89 + UTM 33 einwandfrei und ohne Lagerverschiebung zurecht.

    Ich hab mir die Datei angeschaut und bin dem Problem auf die Schliche gekommen. Also, die vom BEV angebotenen GeoTIFFs sind sogenannten "tiled Geotiffs", also sie liegen dateiintern 256x256 Pixel Kacheln vor. Damit hat aber QV7 leider mit den Standardeinstellungen sowohl Georeferenzierungsprobleme was zu den angesprochenen Lageungenauigkeiten führt. Als auch vereinzelte optische, keilförmige Artefakte. Dazu gibt's bereits Threads:


    Probleme mit größeren GeoTIFF Karten
    Keilförmige Kartenfehler bei gekachelten GeoTIFF-Karten

    Probleme in der Darstellung von ATKIS DTK25 Kacheln

    TopoKarte Svalbard (Spitzbergen)

    Probleme bei Kartenimport von älteren Topo Karten


    Glücklicherweise gibts aber ein Lösung, die man aber unpraktischerweise erst von Hand aktivieren muss:

    Rechtsklick auf Karte im Explorer > Stil der ausgewählten Elemente ändern > Allgemein > "Load Bmp, jpg, png, tiff patially" aktiviern
    (es funktioniert auch mit "Open with TatukGIS", mit diesem baut die Karte aber extrem langsam auf)

    Abschließend möchte ich noch folgenden Link zum Thema GeoTIFF posten:
    http://blog.cleverelephant.ca/…pression-for-dummies.html

    Das ist ein Bericht von einem Experten, der tatsächlich in seiner Arbeit auch mit größeren Karten zu tun hat. Sein Fazit: mit den richtigen Erstellungsparametern (Tiled TIFF, JPEG Kompression, Pyramide) stehen auch große GeoTIFF Karten anderen Karten im ECW und MrSID Format sowohl performancemäßig als auch in Punkto optischer Qualität bei gleicher Dateigröße um nichts nach. Sowohl bei 24-bit Farbkarten als auch bei 8-bit Palettenfarbkarten.

    Dem kann ich aufgrund meiner langjährigen praktischen Erfahrung damit vollkommen zustimmen.


    Das Problem ist nicht das Dateiformat. Es ist deren Implementierung im Leseclient.

    Ich verwende (sehr große) GeoTIFFs die mit JPEG kompromiert wurden schon viele Jahre lang. Dies liefen unter TTQV4 stets völlig probemlos. Ganz zu schweigen von deren fehlerfreien Verwendung in Programmen wie Global Mapper oder QGIS. Da zu behaupten diese Kombination sei "suboptimal" ist daher fragwürdig. Gerade auch wenn man gekachelte GeoTIFFs verwendet. Subotimal ist höchstens die derzeitige QV-Engine diesbezüglich. Ich weise nur auf Probleme hin, die es grob vor 10 Jahren mir TTQV bei den gleichen Dateien nicht gab.


    Gekachelte GeoTiffs sind/waren mit JPEG Komprimierung bisher (in TTQV4) genauso performant, optisch und dateigrößenmäßig ebenbürtig zu ECW. ECW hatte dagegen in TTQV4 ein paar kleine aber in meiner Verwendung wichtige Nachteile gegenüber ECW. GeoTIFF ist bei weitem nicht nur ein Format für Liniengrafiken etc. Deshalb wird es selbst im professionellen Bereich manchmal als Austauschformat für Landkarten aber auch Luftbilder benützt - und da spreche ich jetzt nicht von BigTIFF, sonder von Standard-TIFFs bis zu 4 GB.


    Je nach verwendeter Kompressionsrate ist damit so gut wie kein Unterschied zur Orignalkarte inkl. Reliefschattierungen zu erkennen. Das ist exakt so wie wenn du ein Foto mit 95% oder mit 60% JPEG-Faktor erstellst. Beim einen wirst du sogut wie keine Artefakte zum (unkomprimierten) Orginal erkennen, bei anderern schon. Das ist eine völlig andere Methode und für differenzierte Quellen (Luftfotos oder reliefschattierte Karten) geeignete Kompressionsmethode als die verlustlose Packbits/LZW/ZIP Kompression speziell für 8-bit Farbbilder. Diese habe ich früher für unschattierte Karte verwendet. Damit erzähle ich dir aber wohl eh nichts neues ;-)

    Eine schattierte Austrian Map, Kompasskarte oder eine Openstreetmap mit eigens erzeugter Relief-Schattierung erhält auf 8 bit reduziert soviele Artefakte, Farbfehler, unstetigen Schattierungsverlauf, durch das Farbreduzieren erzeugte neue virtuelle Flächen - das kommt für mich nicht in Frage.

    Also nach Ausreden zu Suchen warum QV7 nicht so gut mit größeren GeoTIFF umgehen kann wie andere Programme und dies am angeblich mit nicht passenden Dateiformat zu begründen - das in TTQV4 völlig anstandslos funktioniert hat - ist aus von Softwareentwicklerseite her gesehen wohl der falsche Ansatz ;-)

    Abgesehen davon habe ich aber inzwischen festgestellt, dass es in QV7 beim ECW-Format die kleinen Troubles aus TTQV4 nicht mehr gibt - und somit wohl die Alternative sein wird, falls die GeoTIFF-Probleme sich nicht beheben lassen.

    Hi Denis, danke für deine Ansichten, ich werde das ECW-Format auch noch ausprobieren, ob das mit QV besser zusammenspielt.


    Es handelt sich um Karten mit Reliefschattierung, sie müssen also als mit 24 bit Farbe gespeichert werden, weil sonst bei Umwandlung in 256 Farben die groben Farbartefakte nicht hinnehmbar sind. Ich habe diese als GEKACHELTE (teilebasiert, im gegensatz zu den normalen streifenbasierten) GeoTIFFs (mit JPEG-Kompression) erzeugt, weil ich festgestellt habe, dass QV damit beim Verschieben & Zoomen die Karte am flüssigsten aufbaut. Der in QV eingebaute "Load Bmp, Jpg, Png, Tif partially"-Mechanismus is dagegen sowohl bei KachelTIFFs, als auch bei herkömmlich streifenbasierten TIFFs deutlich langsamer.


    Gerade das GeoTIFF-Format ist auch im professionellen Bereich sehr verbreitet, einige Landesvermessungsämter bieten Karten in diesem Format an. Mit dem BigTIFF-Format wurde ja eigens für riesige Karten sogar eine Erweiterung des Formats geschaffen um die 32 bit (4 GB)-Dateigröße zu sprengen. Es ist schade, dass QV7 mit so einem populärem Fomat nicht zuverlässig umgehen kann, wo GeoTIFF Karten mit gleicher Größe übrigens früher in TTQV4 KEINE Probleme bereiteten. Abgesehen von diesem - offenbar Speicherproblem - gibts ja auch noch https://wbb5.qvgps.com/forum/i…kachelten-geotiff-karten/ bei Karten mit Dateigröße um "nur" 500 MB.


    Ich werde mich auch noch mit ECWs herumspielen, die hatten in der Vergangenheit in QV (TTQV?) bei mir den kleinen Nachteil zu GeoTIFF, das ich deren Helligkeit in QV nicht verdunkeln konnte und ich während des Scrollvorgangs keine Nachbarzellen sah - ich also quasi ziellos die Karte verscheiben mußte beim Scrolllen. Kann aber sein, dass es diese kleinen Nachteile inzwischen alle nicht mehr gibt bei ECWs in QV.

    Auf meinem System (Windows 10 64bit, 8 GB RAM) hat QV7 Probleme größere GeoTIFF Karte ANZUZEIGEN. Der IMPORT dagegen klappte bei allen Karten.

    Ich habe dazu eine Serie verschiedener Kartegrößen erstellt und jeweils das Verhalten von QV7 mir angeschaut. Es handelt sich um Karte im Format GeoTIFF, 24 bit Farbe, LZW-Kompression.


    Dateigröße 500 MB: wird noch angezeigt

    850 MB: wird manchmal angezeigt, manchmal kommt aber Meldung "Nicht genügend Hauptspeicher zur Anzeige".

    1200 MB: entweder "Nicht genügend Haupspeicher" oder QV7 stürzt komplett ohne Fehlermeldung ab.

    2300 MB: es wird entweder kurz 2 Sekunden ein leeres Kartenfenster angezeigt, und QV springt dann sofort wieder aufs Explorerfenster zurück, oder QV7 stürzt komplett ab.


    ich habe danach bei allen Karten die Option "Load Bmp, Jpg, Png, Tif partially" aktiviert.
    Nun werden die 850 MB und 1200 MB-Karten angezeigt. Nicht aber die 2300 MB Karte: hier kehrt QV nach 2 Sekunden leerem Kartenfenster wieder in den Explorer zurück.


    Dieses Verhalten (unkontrollierte Abstürze, 2 Sekunden leeres Kartenfenster) iszt absolut unbefriedigend. Eine Karte mit 850 MB ist jetzt auch noch nicht wirklich gigantisch. Selbst wenn sie nicht auf einmal in den Hauptspeicher geladen werden kann, sollte QV sie automatisch "partially" laden können. Oder zumindest eine Fehlermeldung mit dem Hinweise an den User erzeugen, dass er die Option "Load Partially" dafür aktiveren soll. Das hilft aber auch nur wenn das Partially Loading auch mit größeren Karten funktioniert und nicht wie bei mir mit der 2300 MB Karte streikt.

    Falls das einmal zuverlässig funktionert, könnte man dann auch schauen wie QV mit wirklich großen Karten > 4 GB im BigTIFF-Format zurecht kommt.

    Hallo,

    in der 3D-Anzeige werden bei mir Waypoints "auf Geländehöhe gesetzt". Leider hat diese Einstellung keinen Einfluss auf die Anzeige der dazugehörigen Waypoint-Links. Die Symbole der Waypoint-Links sind oft sehr weit von ihren Waypoints entfernt, da sie scheinbar "auf Meereshöhe" gerendert werden.
    Wäre super, wenn Waypoints und ihre Links das selbe Höhenverhalten in 3D haben.

    Hallo, es geht um einen Fehler, der ähnlich wenn nicht sogar der selbe ist wie in jenem Thread erwähnt:

    TopoKarte Svalbard (Spitzbergen)


    Ich exportiere mittels Global Mapper (das bei diesem Export wiederum glaube ich auf dem im obigen Thread erwähnte GDAL basiert) eine Karte ins GeoTIFF-Format und benutze dabei die Option "gekachelte Datei". Der Import und auch die Anzeige dieses GeoTIFFs funktioniert mit QV.

    Allerdings treten dabei zum einen stellenweise keilförmige Kartenfehler auf, so als ob dort Kartenabschnitte nicht sauber zusammengefügt wurden.

    Zum anderen stimmt nun die Kalibrierung der Karte nicht mehr genau, sprich wenn ich auf einen Ort in der Karte klicke, so sind dessen in QV angezeigten Koordinaten ein paar Kilometer falsch.


    Ich bin nun drauf gekommen, das diese Probleme nur auftreten wenn bei der Karte unter "Style Maps" > "Load bmp, jpg, png, tif partially" NICHT aktivert ist! Was aber "blöderweise" die default-Einstellung ist und viele wohl gar nicht wissen, dass man diese Einstellung ändern kann. Wenn ich diese Einstellung aktivere, wird Karte fehlerfrei ohne diese keilförmigen Artefakte und auch lagerichtig angezeigt.


    Zum Vergleich: ich habe das gekachelte GeoTIFF auch mit diversen anderen Grafikprogrammen angezeigt, auch diese zeigen es ohne keilförmige Fehler an.

    Könnte man dem Grund des Fehlers auf die Schliche kommen? Oder andernfalls zumindest beim Import von solchen gekachelten GeoTIFFs von QV automatisch die Option "Load bmp, jpg, png, tif partially" setzen lassen?

    Mir ist eingefallen, dass noch ein weiterer wichtiger Punkt für eine dauerhafte Einstellung spräche: Schon in TTQV4 konnte man bei aktivierter Option "...ignorieren, Wegpunkt trotzdem erzeugen, nicht mehr danach fragen.." den GPX-Import viel, viel schneller durchführen als mit aktivierter "Konfliktprüfung". Damals war das sogar in den Haupteinstellungen fix speicherbar.


    Ähnliches könnte auch in QV 7 möglich sein. Ich habe anhand einer GPX-Datei verglichen: Beim Import in eine leere Tabelle wird nur etwa die Hälfte jener Zeit benötigt, die QV beim Import der selben GPX-Datei in eine bereits vorhandene Tabelle benötigt. Und da war bei beiden Test die Konfliktprüfung noch gar nicht von Anfang an ausgeschaltet, erst aber dem ersten Aufpoppen des Dialogs wo ich dann "nicht mehr fragen" anklicken konnte. Sprich je mehr Punkte untereinander auf Konflikte vergleichen werden müssen, desto länger dauert offenbar der Import ein und derselben Datei.
    Also bei von Anfang an deaktivierter Prüfung am schnellsten?

    Ich habe festgestellt dass die Anzeige einer Tabelle mit enorm vielen Wegpunkten natürlich seine Zeit braucht bis sich die Karte mit den Wegpunkten schließlich öffnet. Richtwert z.B. 60 Sekunden pro 10.000 Wegpunkten.
    Wenn man hingegen zuvor Einstellungen > Performance > "Überlappung von Beschriftungen zulassen" deaktiviert, so wird zumindest bei mir die Karte deutlich schneller geöffnet, z.b. 15 Sekunden pro 10.000 Wegpunkte.
    Wenn ich gleich danach wieder "Überlappung von Beschriftungen zulassen" aktiviere (was so gut wie keine Zeit mehr benötigt) habe ich meine gewünschte Wegpunkanzeige (alle Wegpunkte werden auf der Karte dargestellt inkl. Überlappungen) viel schneller erreicht.


    Können dieses Verhalten andere auch bestätigen?


    Vielleicht könnte sich Tom etwas ausdenken wie man diese manuelle kurzzeitige Umschaltung irgendwie automatisch bewerkstelligen könnte, sodass man nicht jedesmal beim laden großer Tabellen 2 mal ins Einstellungsmenü muss, oder man gar darauf beim nächsten Mal vergisst und QV "ewig" lädt.

    Deswegen wäre ja eine dauerhafte Einstellung auch jener Option sinnvoll, mit der man gewünscht mehrere Wegpunkte mit identischem Namen aber unterschiedlichen Koordinaten (oder sonstigen unterschiedlichen Tags) importieren kann ohne jedesmal wieder diesen Dialog bestätigen zu müssen.