Ich habe hier OpenSuse Tumbleweed und ein aktuellstes qMapShack. Das will aber seit neustem nicht mehr cmaken.
Also bei Tumbleweed wird eigentlich schon alles installiert. Ich habe die Pakete libproj15, proj und proj-devel jeweils in der Version 6.0.0 installiert.
Hä? Auch nach mehrmaligem Lesen, verstehe ich nicht was Du willst.
Das Thema ist bekannt und wurde auf der Mailingliste diskutiert
https://sourceforge.net/p/qlan…iewmonth=201904&viewday=9
Kurz der Debian Betreuer ist der Meinung, dass nur das ins Paket kommt, was bei seiner Methode PROJ zu compilieren anfällt. Da er Autoconf und nicht CMak benutzt entsteht das nötige CMake Skript nicht und ist deshalb nicht Bestandteil des Developer Paketes.
Außerdem ist er der Meinung das CMake Skripten, die nicht dort landen, wo nach Debians Ansicht CMake Skripten liegen sollten, auch nicht ins Pakete gehen. Das ist der Fall bei QuaZip.
SuSE, das verwende ich, ist hier besser aufgestellt. Oder einfach pragmatischer. Zusätzlich habe ich den Betreuer bei Fedora gefragt, wie er das sieht. Ähnlich pragmatisch: Eine Distribution sollte eigentlich alles was möglich ist installieren, damit eben solche Sachen nicht passieren. Zur Not ist es die Aufgabe des Betreuers dafür zu sorgen, dass alles an seinem richtigen Platz zu finden ist.
Und grundsätzlich ist es vorzuziehen, solche Skripten nicht in jedem Projekt lokal zu halten, weil das recht flott veraltet. Bisher wurden die lokal gehalten, weil es zu dem Zeitpunkt als das Projekt anfing noch keine Skripten gab. Das hat sich in den letzten 10 Jahren aber geändert und ich würde gerne die Skripten benützen, die QuaZip und PROJ bereitstellen.
Mal schaun ob bei diesem Thema irgendwann Vernunft einkehrt.
Wer will kann die beiden Patches im Anhang anwenden, die die betreffenden Skripten wieder im Source hinterlegen.
Die Sammelablage habe noch nicht ganz verstanden - gibt es hier die 4 Möglichkeiten für alle DB's?
Dann mus das sehr gut überlegt sein wofür man das einsetzt.
Aktuell gibt es nur 4 Ablagen, dass ist richtig. Allerdings auch nicht in Stein gemeißelt. Sollte sich mal ein Use-Case erschließen, bei dem man mehr benötigt kann man den Code anpassen.
Alles anzeigen
Die Beschreibung würde ich gerne nutzen, bin aber da momentan ich einer Sackgasse gelandet und bräuchte eine kurze Navgationshilfe
Bei der Installation des QT developer package hat meine SSD leider Platzangst bekommen
Ist nur der QT Designer ausreichend?
Den hätte ich hier gefunden:
https://build-system.fman.io/qt-designer-download
Version ist 5.11.1
Es ist nur der Designer nötig. Den Rest brauch man nicht.
Und als nächtses würde ich gerne die built-in Textvorlagen kopieren und für meine Bedürfnisse adaptieren, ich finde die aber nicht.
Dazu müsst Du das Source Code Archiv von Bitbucket ziehen oder:
Bei diesen, zum größten Teil antiquaren Programmen, kann man eine Projektion festlegen, die dann zusammen mit der tfw Datei verwendet wird um die Tif Datei referenziert darzustellen.
Wenn Du uns sagen kannst in welcher Projektion deine Tif Datei angefertigt wurde, können wir dir die GDAL Befehlszeile sagen mit der Du die Datei in ein GeoTiff umwandeln kannst.
Das World File beinhaltet die Referenzpunkte zu der Karte. Aber leider nicht deren Projektion. Wenn man die Projektion kennt kann man mit GDAL daraus ein GeoTiff erstellen, welches dann alle Information beinhaltet.
Fluch und Segen eines empfindlicheren Empfängers. Das 64er hat halt auch bei schlechten Bedingungen noch einen Fix. Mit den damit einhergehenden größeren bis sehr großen Fehlern. Das 30er steckt einfach eher den Kopf in den Sand.
Wenn man seinen Tracks gleich aussagekräftige Namen und Beschreibungen verpasst kann man danach die Datenbank durchsuchen. Bei den Beschreibungen helfen die Vorlagen. Man kann auch eigene Vorlagen erstellen.
https://bitbucket.org/maproom/qmapshack/wiki/DocGisTemplates
Damit kann man verlorene Schafe wieder finden.
Ich suche nach einer Möglichkeit einfach alle Projekte, bzw. Projekte einer DB, zu markieren und damit den gesamten Inhalt anzuzeigen.
Gibt es diese Funktion?
Nein gibt es nicht. Macht wohl bei den meisten Datenbanken auch keinen Sinn weil dort auch Daten liegen können, die man nicht wirklich sehen will (z.b. Tracks von anderen Geräten, Planungstracks, etc).
Ich kann nur noch einmal die Sammelablagen ans Herz legen. Einmal aufgesetzt und dann konsequent gepflegt, kann man sich damit sehr gut einen Überblick verschaffen.
Mit ein wenig mehr Investition kannst Du dir auch schon ein Smartphone kaufen, dass neben dem L1 Band auch das L5 Band auswertet und damit Genauigkeiten um 1m erzielt.
Nebenbei hat man dann noch ein vollständiges Smartphone dabei, könnte Musik damit hören, Fotos machen usw.
Dann wird es aber schon wieder knapp mit einer Akkuladung pro Tag.
Außerdem versteht sich hoffentlich von selbst, dass ein Smartphone in der Situation versagt, wo man dringend ein GPS benötigt. Sprich bei kaltem, nassen Wetter mit sehr schlechter Sicht. Der Lipo Akku wird zusammenbrechen. Das kapazitive Display eine Tortur zum bedienen. Aber als Orientierungshilfe und Trackrecorder bei den üblichen Unternehmungen, sollte es darauf nicht ankommen.
Ja, das wäre ne Überlegung wert... wobei ein Handy bei intensiver Navigationsnutzung kaum 2-3 Tagestouren hält...
Wo ich mir auch nicht dicher bin, ist das Display. Gibt es tatsächlich Smartphone-Displays, die in der Sonne (gut) ablesbar sind? Grosse Displays haben die klar, bei 5-6 Zoll klappts auch mit der Altersweitsichtigkeit...:D
Bezüglich der Ablesbarkeit bei Sonne stehen sich neuere Smartphones und das Aventura in nichts nach. Ungefähr gleich gut, bzw schlecht. Wie man es sieht. Bei starker Sonne und einer Sonnenbrille (Kategorie 3) sind beide vom Kontrast her schwierig zu lesen. Junge Augen mögen da noch weniger Probleme haben.
Bei einer schwächer getönten Sonnenbrille, z.B. mit gelb/orangen Gläsern, Schnee und Sonne geht's so halbwegs.
Bei sommerlichen Bedingungen auf einem Gletscher (Gläser mit Tönung Kategorie 4 ) ist nichts mehr zu erkennen. Hier hilft nur noch echtes transreflektives Display, welches bei Smartphones oder den TwoNav Geräten nicht zu finden ist.
Kommt somit ein wenig darauf an was man damit anstellen will.
Hmm, für mich trotzdem nicht ganz nachvollziehbar. Ist die Ausrichtung nach Gitter, ist die Karte nicht mehr winkeltreu. Ich gehe mal davon aus, dass die Papierkarte richtig projeziert wurde. Dann sollte das digitale Pendant auch so sein.
Soweit richtig. Eine Karte mit UTM Projektion ist verglichen mit einer Mercator Karte nicht mehr winkeltreu. Mit anderen Worten "Norden ist nicht mehr oben"
Zusatzfrage: Beinhaltet die digitale Karte die Ausrichtung und macht das die Applikation? Ich glaube nicht, dass im ECW-File ein Parameter für Ausrichtung drinnen steht. Ergo die Applikation.
Die Karte hat eine Projektion und deine Applikation benützt eine Projektion. Wie ich schon hingewiesen habe, muss das nicht die gleiche sein. Deswegen kann es zu dieser Drehung kommen.
Es kommt einfach darauf an, nach welchem Koordinatengitter die Bildpunkte ausgerichtet und referenziert wurden. Stimmt das bei der Karte und der App nicht überein wird re-projiziert. Mit der schon beschriebenen Auswirkung.
Mit QMapShack kann man das übrigens sehr spielerisch ausprobieren, weil man dort in der Ansicht jede beliebige Projektion einstellen kann. Hat aber seine Grenzen weil QMapShack aus Preformance-Gründen keine echte Re-Projektion macht sondern mit einer linearen Transformation von kleinen, quadratischen Ausschnitten der Karte eine emuliert. Im Großen und Ganzen sieht man aber was passiert.
Ne, Masse ist nicht gleich Klasse. Die unterschiedlichen Satelliten können nicht so einfach zu einer Positionsbestimmung zusammengefasst werden. Man kann in jedem System die Position bestimmen und dann versuchen aus den Ergebnissen das Beste zu machen.
Im Falle der Häuserschlucht müsste man beurteilen welches System gerade die bessere Konstellation hat. Wie toll das (nicht) funktioniert kann man ja jetzt schon mit Navstar/GLONASS sehen.
Das Empfangen von mehreren Bändern ist eine tatsächliche technische Verbesserung, die etwas bringt. Nur muss dazu der Chipsatz fähig sein. Galileo alleine reicht nicht.
Die Aussage, dass Galileo besser sein wird als Navstar kommt übrigens daher, dass der Plan war, Galileo viel früher im Orbit zu haben und somit auch das E5 Band nützen zu können. Dadurch dass es sich verzögert hat, hat auch Navstar inzwischen viele seiner Satelliten ausgetauscht und damit das L5 Band an den Start gebracht. Der Vorteil ist somit für den Verbraucher weitgehend dahin. Die Frage ist nur noch wann es Geräte, die das L5/E5 Band auswerten können, gibt. Wer eine bessere Genauigkeit will muss darauf warten. Und da ist dann bestimmt auch Galileo dabei 
Es gibt bei der Anzeige von Karten 3 Projektionen.
1) Die Projektion des Gitters
2) Die Projektion der Karte
3) Die Projektion der Anzeige
Sind 2)/3) entweder Mercator/Transversal Mercator bzw Transversal Mercator/Mercator dann kommt es zu der Drehung. Das Gitter gibt in diesem Fall Auskunft über die Projektion von 3). Ist es "im Lot" ist die Projektion von 1) und 3) gleich.
Ok, wenn das so ist, dann ist die Abschaltung von Navstar natürlich das nächst größere Problem und wir sollten uns sofort auf die Anschaffung eines Galileo-tauglichen Gerätes konzentrieren. Mein Gott ich hasse es wenn ich mit der Todo-Liste hinterher bin....
hmhm... und morgen ist Weltuntergang.
U-Blox F9 kann wohl auch L1&L5 und ist seit dem Ende 2018 verfügbar. Scheint aber kein billiger Chipsatz zu sein. Bisher sind das komplette Nischenprodukte. Ich habe die Tage erst nach einem Bluetooth GPS Logger mit L5/E5 Unterstützung gesucht. Fehlanzeige. Die Sache hat einfach noch keine Marktdurchdringung.
Der Vorteil von Galileo ist halt der selbe wie bei GLONASS. Da haben ja auch einige geschworen alles wird besser. Letztlich macht aber nicht die Masse an Satelliten die Qualität, sondern die Technologie. Also zum einen eine gute Hardware inkl Antenne und zum anderen zusätzliche physikalische Erweiterungen, um systembedingte Fehler zu kompensieren. Wie das eben mit einem zusätzlichen Band, das auch noch weitere Korrekturinformation beinhaltet, möglich ist.
Und solange das nicht der Fall ist, braucht man sich nicht den Kopf darüber zu zerbrechen, ob jetzt der GPS Empfänger Navstar, GLONASS oder Galileo kann. Das geht alles gleich gut oder gleich schlecht. Und die Auswertung eines zusätzlichen Bandes wird es nicht als Firmwareupdate geben. Insofern handelt Garmin wirtschaftlich vernünftig. Auch wenn es damit selbst geweckte Erwartungen seitens der Kunden enttäuscht.
Ich habe vor kurzem ein Handy um weniger als 400€ gekauft das eben die zwei Frequenzbänder auch auswertet. Da sollte es doch auch für Garmin möglich sein die richtigen Chipsets im seinen Geräten zu verbauen.
Und hat das auch eine Genauigkeit im Submeterbereich? Weil "wir haben das verbaut" und "das funktioniert auch" sind immer 2 paar Schuhe.
