Beiträge von Wolfgang16

Garmin fenix 7X und epix Gen 2 im Test

Der Schwerpunkt dieses Tests und Vergleichs der Garmin Fenix 7X Solar und Garmin Epix Gen 2 liegt auf den Sensoren wie Höhenmesser, Positionsbestimmung und Herzfrequenz. Was unterscheidet die beiden GPS-Outdoor-Smartwatches? Und wie gut ist die Taschenlampe der Fenix 7X für den Outdoorbereich? Hier geht es zum Test der Outdoor-Smartwatches ...

  • Qlandkarte GT unter Ubuntu 20.04 focal fossa kompilieren?

    Hallo,

    ich habe eine *.deb zum Installieren von QLandkarteGT erzeugt unter Linux Mint 20, sollte daher auch unter Ubuntu 20.04 funktionieren. QLandkarte ist dann Teil des Paketsystems und kann auch über den Paketmanager wieder deinstalliert werden. Beachtet bitte, dass ich kein Programmierer bin, nur wenig Ahnung von der Materie habe und daher keinerlei Verantwortung übernehmen kann. Probiert es am besten vorher in einem Livesystem oder einer virtuellen Maschine aus; so hab ich das auch gemacht. Viel Erfolg!


    https://drive.google.com/file/…rcOkIYxK/view?usp=sharing


    für das garmindev muss man dann noch dies installieren:


    https://launchpad.net/~dirk-co…8.04.1~c42.ppa1_amd64.deb


    Noch ein paar Anmerkungen zum Verständnis:

    Erzeugt habe ich das nach der Methode:

    http://www.renatscher.de/gis_qlandkartegt.html

    Dass die Quellen aus dem Debian Repository stammen, scheint keine negativen Konsequenzen für Ubuntu zu haben. So wie in dem Link beschrieben funktionierte das allerdings nur bis etwa Juni 2020. Danach gibts einen Fehler beim Bauen der *.deb, vermutlich im Paket libqt5serialport5, weil Debian dann von Qt 5.12 auf 5.14 gegangen ist. Offenbar hat aber bisher niemand einen weiteren Patch geschrieben. Da Linux Mint (und vielleicht auch Ubuntu??) nach wie vor Qt 5.12 verwenden, könnte das auch mit den aktuellen Versionen klappen.

  • Vergleich der Höhenlinien in Österreichkarten

    Zitat von Speichennippel

    N51° 15.024' E7° 03.257'


    Die Viewfinder haben natürlich auch eine unterschiedliche Qualität. Die russischen Karten gab es in den Alpen bis runter auf 1:50.000. Im Bergischen Land war das wohl nicht der Fall. An dem See zeigt meine NRW Karte noch einen Kalksteinbruch. Wie der Ersteller der Viewfinder mit solchen Veränderungen umgeht, weiß ich nicht.


    Im rechten Bild sind die Viewfinder, oder? Das rechte Bild sieht schon allein deswegen schlechter aus, weil die Höhenlinien nur aus wenigen Punkten bestehen.


    Meine Höhenlinien hab ich mit GlobalMapper erzeugt. Da kann man schön mit den Parametern spielen und das gleich visuell überprüfen. Das kann auch die Tiroler oder Vorarlberger Höhendaten direkt lesen und kann OSM schreiben. Das OSM muss man dann noch ein bischen editieren und kann das dann über Osmosis mit den anderen OSM Daten zusammenführen. Das geht, wie morgen1 schon schrieb, über Script.


    Spontan als Alternative fällt mir nur noch gdal_contour ein. GDAL kann zahlreiche Formate lesen und schreiben, nur kann es (im Gegensatz zu Globalmapper) leider kein OSM schreiben. QGIS in Verbindung mit GRASS GIS wäre noch eine Alternative; QGIS kann OSM schreiben.

  • Vergleich der Höhenlinien in Österreichkarten

    Mit "Auflösung" meine ich den horizontalen Gitterabstand der Daten. Sonny bietet ja an 1"x1" im .hgt Format ( also wie SRTM ) oder 20x20m als GeoTIFF. Welche hast du denn in das phyghtmap gesteckt? Ich hab leider noch nie mit phyghtmap gearbeitet, daher stehe ich da jetzt auch auf dem Schlauch.

  • Vergleich der Höhenlinien in Österreichkarten

    Die Viewfinder Daten stammen ursprünglich aus der Digitalisierung der Höhenlinien der russischen topografischen Militärkarten. Diese haben wohl ebenso wie die Daten von Sonny eine gute Qualität, so dass mich nicht wundert, wenn sie ähnliche Resultate liefern. Die Auflösung ist doch durch phyghtmap auf 1" begrenzt, oder? Also die 20m Daten von Sonny kann man damit nicht verwenden.

  • Vergleich der Höhenlinien in Österreichkarten

    Ich hab noch keine Karte gefunden, die das Potential der österreichischen 10x10m Lidardaten voll ausschöpft. Grund dafür scheint zu sein, dass einerseits das oft verwendete phyghtmap damit nicht umgehen kann und andererseits der Speicherbedarf enorm anwächst. Man könnte also keine komplette Alpenkarte rendern.


    Um den Unterschied zu demonstrieren hab ich einen Graben geeigneter Größe genommen. Damit sieht man das deutlicher als etwa bei Bergspitzen. Die Diskussion dazu ist im OAM Forum

  • QV 7.3 - jetzt mit osm routing

    Hallo Ludger,


    das QV Wiki hab ich natürlich gelesen. Darin steht, dass der Compiler nach dem Mapsforge Standard arbeitet. Deshalb habe ich mich mit Mapsforge beschäftigt und kann nun solche Karten erzeugen. Als ich das dann mit dem QV Compiler versucht habe ergaben sich Probleme:


    - Das Thema Elevate/Elements 4 (von Openandromaps) wird von QV überhaupt nicht erkannt. Um ein aktuelles Thema zu verwenden, musste ich daher auf Tiramisu zurückgreifen.
    - Pfade (also mit Tag highway=path) werden bei mir in QV überhaupt nicht angezeigt, auch nicht in den mitgelieferten Standardthemen
    - Die Karten sehen in QV im Stil vollkommen anders aus, als bei Cruiser, Routeconverter oder MOBAC, während es zwischen letzteren auf den ersten Blick praktisch keine Unterschiede gibt.


    Das Ganze hab ich auch schon in dem Forum gepostet, dessen Link Ulmer Spatz nach fast 2 Wochen oben eingefügt hat, hab aber da keine Antwort erhalten.

  • QMapShack: Georeferenzierung über GCPs und Drehung

    Ok, nimm dir eine .vrt ohne Drehung, die korrekt angezeigt wird. Da steht sowas drin wie:


    <GeoTransform> 4.5179628825603623e+005, 5.0470000000000006e+001, 0.0000000000000000e+000, 5.1228927789576873e+006, 0.0000000000000000e+000, -5.0470000000000091e+001</GeoTransform>


    Der dritte und der fünfte Parameter sind Null, d.h. es gibt keine Drehung. Jetzt ändere diese auf einen Wert >1e-6 aber klein genug, dass man es eigentlich noch nicht sehen sollte, also z.B.:


    <GeoTransform> 4.5179628825603623e+005, 5.0470000000000006e+001, 1.0000000000000000e-005, 5.1228927789576873e+006, 1.0000000000000000e-006, -5.0470000000000091e+001</GeoTransform>


    Jetzt erscheint die Karte in QMS sichtbar nach rechts gedreht.

  • QMapShack und GPS Geräte

    QLandkarte war das einzige Programm, mit dem man auf einem Linux Netbook navigieren konnte. So hab ich QLandkarte überhaupt kennengelernt. Das mit dem naiv hab ich auch schon gemerkt; deshalb hänge ich jetzt immer noch bei TTQV4, während es schon QV7 gibt...


    Toll an QLandkarte fand ich übrigens auch, dass Geotiff als Standard verwendet wurde. Das ist jetzt leider auch nicht mehr so. Wenn ich mir eine Karte mache, dann speichere ich sie entweder als Geotiff oder ECW ab und letzters geht leider auch nicht... :(

  • QMapShack: Georeferenzierung über GCPs und Drehung

    Hallo Oliver,


    irgendwo hattest du mal geschrieben, dass du bei QLandkarte Drehungen in der Geotransformation nicht implementiert hast. Deshalb vorab die Frage, wie das jetzt bei QMS ist? Ich hab das gerade mal mit einer .VRT ausprobiert, und wenn die Drehparameter in der Transformationsmatrix Null sind, stimmt die Position der Karte, wenn sie aber nur minimal von Null abweichen, dann ists falsch.

  • QMapShack

    Hallo,


    ich hab die neueste QMapShack_Install_Windows64bit__1.5.1p1627Qt5.5.exe installiert. Musste ich nochmal deinstallieren und neu installieren, weil die C++ redistributable gefehlt hat.


    QMapShack meckert beim Start, dass hdf5.dll, libecwj2.dll, cfitsio.dll, netcdf.dll, hdfdll.dll u.a. fehlen, startet aber doch. Wenn ich z.B. gdalbuildvrt aufrufe, passiert das wieder (popups) und im Hauptfenster erscheint:


    ERROR 1: Can't load requested DLL: C:\Program Files\GDAL\gdalplugins\gdal_BAG.dll
    126: Das angegebene Modul wurde nicht gefunden.


    ERROR 1: Can't load requested DLL: C:\Program Files\GDAL\gdalplugins\gdal_ECW_JP2ECW.dll
    126: Das angegebene Modul wurde nicht gefunden.


    usw.


    Diese Dateien sind da. Das ist aber meine GDAL Installation. Bringt QMapShack nicht seine eigene mit?


    Servus
    Wolfgang


    Achja: Windows7 64bit ist das Betriebssystem.

  • Karte mit map Datei laden

    Ich hab mich noch ein bischen mit GDAL beschäftigt:


    die Befehlszeile zur Umwandlung lautet:


    Code
    gdal_translate -co COPY_SRC_OVERVIEWS=YES -co TILED=YES -co COMPRESS=LZW name.map name.tif


    In der name.map muß die zugehörige Bilddatei angegeben sein. Das kann jetzt im Prinzip alles sein, was GDAL verarbeiten kann, insbesondere kann es auch eine tif Datei sein. Man kann jetzt also map+tif in GeoTiff umwandeln.


    Die Projektionen UTM und Lambert Conformal Conic funktionieren.


    Mit "-co COPY_SRC_OVERVIEWS=YES" übernimmt man die in der ozf Datei enthaltenen Overviews direkt in die GeoTiff. gdaladdo ist dann nicht mehr nötig.


    Im gdal-data Verzeichnis befinden sich eine ozi_datum.csv und eine ozi_ellips.csv, die man manuell editieren und so weitere Datums hinzufügen kann.


    Es gibt eine Umgebungsvariable OZI_APPROX_GEOTRANSFORM. Wenn man die auf YES setzt, dann zwingt man GDAL, die Geotransformation durchzuführen.


    Und noch was sehr interessantes, was aber nichts mit Ozi zu tun hat: man kann jetzt JPEG Bilder ohne Rekompression - also verlustfrei - in Tiff mit JPEG Kompression umwandeln!



    :jubel:


    http://osgeo-org.1560.x6.nabbl…o-geotiffs-td5039714.html

  • Karte mit map Datei laden

    Hallo Martin,


    dieses Skript scheint mir überflüssig. GDAL kann die GCPs aus der .map wunderbar extrahieren und damit ein GeoTiff erzeugen. Nur QLGT kann das dann nicht lesen. Das ist meiner Meinung nach der eigentliche Knackpunkt bei der Geschichte.


    Zitat von teleskopix

    ...und wenn qlgt zu einer Bilddatei eine *.gcp hat, macht qlgt im Handumdrehen daraus eine Geotiff


    Besteht das Handumdrehen dann in einer Reprojektion mit gdalwarp? Dann kann man alles allein mit GDAL machen.

  • Karte mit map Datei laden

    In GDAL 1.10 schreibt man jetzt immer die *.map in die Befehlszeile. Damit ist das endlich vereinheitlicht und funktionioniert auch mit anderen als ozf Dateien. Der Treiber heißt map driver.


    Ich habe nun einen Grund gefunden, warum QLandkarte GT manche dieser Ozidateien nicht akzeptiert. Das hat mit Ozi erstmal garnichts zu tun, sondern damit, daß es 2 verschiedene Arten gibt, eine Georeferenzierung in eine GeoTiff zu schreiben. Bei der ersten Variante werden Koordinaten im Stil eines Wordfiles eingetragen. Das können die meisten Programme inklusive QLGT lesen.


    Wenn man jedoch von einer map Datei ausgeht, dann trägt gdal_translate einfach die GCPs aus der *.map in die Tiff Datei ein. Das ist offenbar auch eine zulässige Variante, wird aber von QLGT nicht akzeptiert: keine Georeferenzinformationen gefunden. TTQV4 und QV6 interpretieren das auch nicht richtig. So eine GeoTiff hab ich mal angehängt; in gdalinfo sieht das dann so aus:



    Globalmapper liest sowas richtig, QLGT aber nicht! Erst wenn man das dann nochmal durch gdalwarp wurschtelt, dann wird die Referenzierung im Stil eines Worldfiles eingetragen und dann liest das auch QLGT. Ich vermute mal, daß gdal_translate nicht die Fähigkeit hat, sowas umzurechnen.

  • Karte mit map Datei laden

    Ja, eine ozf kann man nicht direkt laden, sondern nur die map, in welcher dann in der 2. oder 3.Zeile der Name der ozf stehen muß. Der Name kann dann auch anders sein. Für die ozf ist der Ozi Treiber zuständig, das ist ein völlig anderer Teil der Software.


    Mir ist es jetzt auch gelungen eine ozf2 zu laden - einfach über Datei|Karte laden und dann die map anklicken. Nicht geklappt hat es aber mit einer ozfx3. Da kommt die Meldung "keine Georeferenzinformationen gefunden", obwohl gdalinfo diese ausspuckt und gdal_translate sogar in der Lage ist, das in ein tif umzuwandeln.


    Nachtrag der Vollständigkeit halber: hier steht das mit den Ozi Datums:
    http://trac.osgeo.org/gdal/ticket/3929