Beiträge von kiozen

Zitat von wildgoose

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"

Zitat von wildgoose

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.

Zitat von Al Capone

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.

Zitat von ADroste

Fahrt mal in Frankfurt/Main in einigen Bereichen der Innenstadt zwischen den Bankentürmen hindurch und dann wißt Ihr, dass es gut wäre, soviel Satelliten zu empfangen, wie möglich. Wenn man noch nie die Begriffe "Alternate Path" oder "Multipath" gehört hat, wundert man sich einfach, warum man ein bestimmtes Ziel nicht erreicht und stattdessen drei- viermal um den Block geschickt wird.

Gruß
Armin

Das hat aber auch nichts mit Galileo oder Navstar zu tun, sondern ob der Empfänger das E5 bzw L5 Band auswertet. Und das machen die bisherigen Empfänger nicht. Es gibt nur sehr wenige Chipsets die das können und die sind noch lange nicht in der Preisklasse, dass sie bei Garmin in ein 0815 Navi verbaut werden. Es ist somit egal ob Galileo oder Navstar verwendet wird. Wichtiger wäre, das jeweils 2 Band auszuwerten.

Zitat von ray

Ansonsten hilft nur warm halten.
Ich kenne Leute die ihr GPS Gerät unter der Jacke körpernah tragen und nur bei Bedarf rausnehmen.
Ich fände das eher nervig.

Vor allem bei dem Wetter Da will man nichts öffnen, ausziehen etc.

Zitat von ray

Wird das Display sehr träge?
Lässt es sich noch bedienen?

Mir ist nichts aufgefallen. Das Touch Display benutze ich aber auch selten. Mehr die Knöpfe. Und da ist der linke seitliche Knopf mit Handschuhen nicht bedienbar und Joystick runter auch eher ein Kampf. Einfach schlampig gefertigt. Aber das hatten wir ja schon ausreichend diskutiert.

Es ist halt irgendwie ein Schönwettergerät. Nur abgesehen von der langen Akkulaufzeit, kann ich dann auch ein Smartphone verwenden.

-9 bis -2°C und Wind. Also keine großen sekundären Wärmeeffekte über Körperabstrahlung oder Sonnenwärme. Bei ca 2/3 der 8h Tour war Schluss. Im Warmen kam der Akku dann mit 45% wieder zurück.

Im Vergleich das GPSMap64s mit Litiumbatterien. Beide Geräte am Rucksackträger (eines links, das andere rechts) getragen. Das 64er hat natürlich die ganze Zeit durchgehalten. Auch wenn die Ladeanzeige in solchen Situationen weniger anzeigt als tatsächlich drinnen ist. Der Satz Lithiumbaterien hat insgesamt ca 20h bei dem Wetter ausgehalten und ist immer noch nicht verbraucht.

Mein Hoffnung war halt, dass der Akku mit seiner großen Kapazität ordentlich Bums mitbringt, um Minusgrade zu überstehen. Darauf verlassen kann man sich nicht.

Ladestandsanzeige kann ich auch bestätigen. Funktioniert endlich.

Leider kann ich nach dem Wochenende auch die Untauglichkeit des Akkus bei Minusgraden bestätigen. Also nix auf das man sich im Notfall verlassen kann.

https://www.naviboard.de/showpost.php?p=503856&postcount=102

Zitat von bagosi

Führe einfach den folgenden Befehl mit Python aus:

Die Antwort ist auf jeden Fall besser, als das was ich schreiben wollte Aber bitte nicht mehr diesen 2.7 Kram. Wird schließlich 2020 eingestellt.

Versuch es mal mit Tracks. Die kann man ja auch mit Routingunterstützung erstellen. Auf dem Track kannst Du dann Wegpunkte platzieren. Zudem kannst Du dem Track über die Filter Höhendaten und Zeitdaten zuweisen. In der Projektzusammenfassung kannst Du die Ansicht auf "Sortieren entlang des Tracks" einstellen. Dann hast Du so etwas wie einRoadbook.

Man kann eine Route so wie einen Track editieren und Zwischenpunkte einfügen. Das ist aber nicht ganz das Selbe wie einen neuen Wegpunkt hinzuzufügen. Insofern ist dein Vorgehen das was geht.

Routen sind nach wie vor in QMapShack kaum entwickelt. Niemand hat bisher Interesse daran um Zeit zu investieren. Ein Hauptgrund ist die fehlende 1:1 Übertragbarkeit auf ein Gerät. Deswegen benützen die Leute eher Tracks zum Touren planen.

Als eine "Empfehlung" sehe ich die Abhängigkeit nicht. Wie der Thread hier zeigt, fehlt einfach Funktion, die gebraucht wird. Dass Kommandozeilentools in GUI Programme eingebettet werden, ist ein gängige Praxis in Unix. Und nur weil das nicht beim Starten der Software gleich bricht, bedeutet das noch lange nicht, dass nix fehlt.

Kommandozeilentools von Bibliotheken zu trennen kann man sicherlich machen. Nur macht es aus meiner Sicht selten Sinn, weil man eh beides benötigt. Zudem fängt man sich eben solche Abhängigkeitsprobleme ein. Für was? Für ein paar MB gespart, wenn man wider Erwarten die Tools doch nicht braucht. Und das für eine Distribution, die auf ein PC-System zielt. Aber gut, da habe ich nicht mitzureden. Das ist Distributionssache.

Den selben Käse gab es übrigens schon bei GDAL, wo mit den Bibliotheken leider nicht die Textdateien installiert wurden, die wichtig sind, um alle geodätischen Daten richtig zu verarbeiten. Das hat zum Schluss so überhand genommen, dass ich einen Sanity Check einführen musste, mit dem Hinweis, dass QMapShack erst startet, wenn der Package Maintainer es richtig gemacht hat. Aber es kann ja nicht zielführend sein, dass jede Software OS spezifische Sanity Checks für alles Details einbauen muss, oder?

Bitte schreib noch einen Bugreport bei Mint.

Naja, das war schon klar. Nur: Gibt es zu Routino noch eine weiteres Paket, das nicht als Abhängigkeit von QMapShack gelistet ist? Das ist die Frage.

Keine Ahnung was Mint so macht. Ich habe SuSE und einen Yast mit dem ich bequem nach Paketen suchen kann. Natürlich gibt es auch bei SuSE apt-get. Ob sich das bei Mint gleich verhält weiß ich nicht. Bei mir zeigt es, dass Routino in mehrere Pakete unterteilt ist:

apt-get se routino




Repository-Daten werden geladen...
Installierte Pakete werden gelesen...


S  | Name                  | Zusammenfassung                           | Typ       
---+-----------------------+-------------------------------------------+-----------
i+ | libroutino-devel      | Development files for the routino library | Paket     
i+ | libroutino0           | Shared routino library                    | Paket     
   | libroutino0-debuginfo | Debug information for package libroutino0 | Paket     
   | routino               | Router for OpenStreetMap Data             | Quellpaket
i+ | routino               | Router for OpenStreetMap Data             | Paket     
   | routino-debuginfo     | Debug information for package routino     | Paket     
   | routino-debugsource   | Debug sources for package routino         | Paket

Wichtig ist libroutino0 und routino. Diese Pakete können bei Mint anders heißen, bzw kann alles ganz anders strukturiert sein. Das ist aber Mint's Angelegenheit. Und wenn in Mint QMapShack nicht ordentlich mit allen Abhängigkeiten installiert ist, dann ist das ein Bug von Mint und sollte auch dort erwähnt werden, sonst ändert sich nichts in Zukunft.

Ich dachte eigentlich an deine Paketverwaltung. Dort könnte es zwei Pakete für Routino geben. Eines mit der Bibliothek und ein Zweites mit den Kommandozeilenprogrammen.

Dann fehlt planetsplitter tatsächlich. Manchmal teilen die Distributionen Software in Bibliotheken und Tools auf. Schau mal ob es noch ein weiteres Routino Paket gibt, dass nicht installiert wurde.