Beiträge von kiozen

Zitat von macnetz

heute habe ich mit einer ECW-Version der Gesamtkarte getestet.
Dabei habe ich festgestellt dass die ECW-Karte viel schneller zoomt als die GeoTIFF.

Wenn man einem Geotiff die nötigen Übersichtsebenen spendiert, dann geht das genauso flugs. Wurde auch schon im Forum diskutiert:

http://www.naviboard.de/vb/showthread.php?t=50017

Zitat von macnetz

Die beschriebenen Fehler (Extra-Kacheln und Streifen) gab es dann beim Export mit 578 Tiles. Die Extra-Kacheln am rechten Rand sind diesmal 41 Pixel breit.
Bei 51 Tiles gab es nur schwarze Streifen.

Ich glaube so kommen wir nicht weiter. Versuch doch erst mal einem kleinen Beispiel das Problem handlicher zu machen. Ich bin immer noch der Meinung, dass GM die transparenten Werte an den Rändern der Teilkarten irgendwie mit in die Gesamtdatei wurstelt.

Mittlerweile konnte ich eine Sache bei GDAL herausfinden. gdalwarp nimmt irgendwie nicht den transparenten Farbindex von der Quelle mit zur Zieldatei. Das führt zu seltsamen Verfärbungen im transparenten Bereich. Siehe das angehängte Beispiel. Ähnliches durfte bei deiner Karte passieren, nur dass die transparenten Werte wohl auch mitten in der Karte liegen. Da muss ich mal suchen, warum das so ist.

Interessant wäre es auch zu wissen ob GDAL die Gesamtdatei ähnlich wie GM zusammensetzt. Kannst Du nicht mit GM mal 2 kleine Teilbereiche aus den Einzeldateien herausschneiden, so dass man 2 wenige MB große Dateien hat, mit denen sich das Problem nachstellen und analysieren lässt?

Grüße

Oliver

Dafür findet man in anderen Foren umso mehr.

http://forum.in-touch-with-adv…p?search_id=active_topics

Zitat von macnetz

Ich habe die Gesamtkarte von GM (GeoTiff mit UTM/WGS84) in QL GT angelegt und als Garmin-Rasterkarte exportiert. Dabei ist das Streifenproblem in der Mitte der Gesamtkarte aufgetreten. Das Problem mit den Extra-Kacheln tritt dabei nicht auf.

Das ist wirklich seltsam. In einer Gesamtkarte sollten die transparenten Pixel nicht mehr vorhanden sein, oder? Zumindest nicht in der Mitte der Karte. Am Rand ist es klar. Was passiert wenn Du die einzelnen Scanns mal auf der Kommandozeile mit GDAL zusammen fügst:

gdalwarp -co tiled=yes -co compress=LZW file1.tif file2.tif... outfile.tif

Zitat von macnetz

Weil ich die UTM-Projektion als Ursache ausschliessen wollte habe ich die Gesamtkarte in GM reprojeziert und als Plate Carree exportiert. Keine Änderung in QL GT.

UTM würde im Moment nur Probleme machen wenn die Karte aus mehreren Dateien geladen würde. Das sollt dann mit den Änderungen auch endlich gefixed werden.

Zitat von macnetz

Weil nun die GeoTiff-Gesamtkarte mehr als 1,5GB Dateigrösse hat habe ich dir den Link zur KMZ-Version geschickt. Gleichzeitig habe ich mit GM diese KMZ-Version importiert und als GeoTiff exportiert (Geografisch/WGS84). In GM habe ich dabei "Kachel-Tiff" angekreuzt. Mit dieser Gesamtkarte als GeoTiff tauchte zusätzlich zu den schwarzen Streifen das Extra-Kachelproblem auf.

Mir ist jetzt kein KMZ -> Geotiff Konverter bekannt. Insofern bringt mir das wenig. 2 oder 3 der Einzeldateien, an deren Grenzen das Problem auftritt, würden mehr helfen. Gerne auch parallel dazu diese Dateien zusammen als eine von GM. Dann hätte ich die Chance auf einen Vergleich mit der GDAL Version. Generell ist es seltsam dass diese Probleme, die typisch sind für Karten, die aus mehreren Dateien bestehen, bei einer Karte entstehen, die schon zu einer Datei zusammengesetzt wurde.

Bevor ich vergesse zu fragen: Die QLandkarte Version ist ja bestimmt die neueste, oder?

Anton, jetzt mal langsam mit den jungen Pferden, sonst komme ich gedanklich nicht mehr nach.

Hast Du meinen Rat aus dem anderen Thread befolgt und die einzelnen Geotiffdateien zu einer einzigen zusammengesetzt? Gerne auch in ihrer originalen UTM Projektion. Ich vermute nämlich dass die zusätzlichen Kacheln von einer überlappenden Kartendatei stammen.

Das ist für den Moment die einzige Möglichkeit auf ein ordentliches Ergebnis zu kommen. Ich werde die nächsten Tage den Export mal komplett überholen. Das ist schon aus ganz anderen Gründen nötig. Dabei wird dann auch sicherlich eine Lösung für so Patchworkkarten wie deine herausfallen.

Zitat von wasabi65

Hi zusammen
ähnliches hatte ich auch schon nach löschen von karten. Nach fehlermeldung gings dann ohne karte weiter (win vista). Wäre schön wenn QLGT keine bestimmten karte beim start erwarten würde.

Ich finde es eigentlich ganz angenehm das QLGT dort anfängt, wo ich aufgehört habe. Nur sollte es halt nicht abstürzen wenn was schief läuft. Und noch schlimmer: Ohne Registryhack nicht mehr starten.

Ich habe gestern Abend noch ein paar Änderungen eingebaut. Unter anderem, dass der Rgeitryeintrag vor dem Laden gelöscht wird und erst nach dem Laden wieder Gesetzt wird. Das verhindert nicht einen eventuellen Crash. Der lässt sich bei komplexen Dateien wie Karten nie 100% ausschließen. QLGT sollte aber beim Neustart dann ohne Karte wieder hochkommen.Mal schauen ob der Dauerbrenner damit zu erledigen ist.

Zitat von kiozen

Ein Bug. Die Kachelgrenzen werden anscheinen nicht richtig verschoben, wenn das Ende der Karte erreicht ist. Ich kümmere mich darum wenn Du endlich die Beschreibung vom Unterforum änderst.

Doch kein Bug. Die Kacheln werden sauber an den Kartengrenzen geschnitten. Besteht bei der Karte aber zwischen der eigentlichen Karte und dem Rand ein transparenter Streifen, dann wird der bei der Umwandlung nach Jpeg schwarz dargestellt, da Jpeg keinen Alphakanal kennt.

Das Problem tritt bei mir als solches nicht auf, da ich meine Karten entweder sauber schneide oder einen Flickenteppich zu einem großen Geotiff zusammenfüge. Da deine Karte original UTM ist würde ich sie so lassen aber alle Kartenteile zu einer Datei vereinen. Dann wird es zu diesen schwarzen Rändern nur am Rand der Gesamtkarte kommen. Üblicherweise liegt dort wenig von Interesse.

Zitat von Juventura

Hat schon jemand versucht mit Google Elevation die Höhen im Track nachzubearbeiten. Das geht automatisiert und relativ schnell mit dem Smartphone.
Ich hatte das mit dem S II und Locus (und WLan) für zwei kleinere Tracks mal getestet. Die dabei entstandenen Höhenangaben scheinen einigermaßen plausibel. Sie sind jedenfalls auch ohne Vorhandensein eines Barometers im Smartphone nicht jenseits von jeglicher Realität. Vielleicht kann ja mal jemand das mit seiner Hausstrecke nachstellen und vergleichen?
Würde mich über Rückmeldungen freuen.

Bei einfachem Gelände funktioniert das. Bei etwas "dramatischeren" Bergen nicht. So liegt der Gipfel des Monte Cristallino nicht bei 3007 m sondern in einem Tal bei 2858 m. Auch wird die Methode bei Brücken ihre Grenzen finden. Oder wenn der Abstieg via Gondel auch korrekt aufgezeichnet werden soll.

Zitat von macnetz

Die Änderung können AFAIK nur die Admins machen - ich bin hier nur Hausmeister

Dann wäre es schön wenn der Admin sich des Problems annimmt, bevor mir der Kragen platzt.

Zitat von macnetz

Hallo,

als QLandkarteGT auf Windows XP mit einem Runtime Error (siehe Fehlermeldung) nicht mehr startete wusste ich mir nicht anders zu helfen als durch Löschung des Schlüssels in der Registry unter HCU-Software.

Gibt es eine einfachere Lösung dieses Problems?
Woher kommt es?

Grüsse
Anton

Alles anzeigen

Wahrscheinlich kann die zuletzt angezeigte Karte nicht mehr geladen. Dazu reicht es den Eintrag "visibleMaps" zu löschen.

Ärgerlich ist es allemal, weil QLGT beim Laden nicht abstürzen sollte. Deswegen wäre es wichtig zu wissen was zu dem Absturz geführt hat. Wurde die Karte einfach gelöscht? Wurden die Dateien von außerhalb verändert? Ist die Karte auch nach dem Löschen der Registry nicht ladbar? Was für eine Karte ist es (Geotiff, Garmin, Kachelkarte)?

Zitat von macnetz

Zuerst vermutete ich ein Problem mit der Projektion (das Orginal ist UTM) und habe daher die Karte über Nacht als Plate Carrée reprojeziert. Doch leider hat das nicht geholfen.

Ein Bug. Die Kachelgrenzen werden anscheinen nicht richtig verschoben, wenn das Ende der Karte erreicht ist. Ich kümmere mich darum wenn Du endlich die Beschreibung vom Unterforum änderst.

Zitat von macnetz

AFAIK ist der mit Hilfe der Dopplerverschiebung errechnete Geschwindigkeitsvektor 3-dimensional. Die 2D-Geschwindigkeit ist davon nur eine Projektion auf die Ellipsoid-Fläche.

Das ist richtig. Laut Auskunft eines befreundeten Entwicklungsingenieurs wird diese Z Komponente aber gerne verworfen, weil sie sich kaum verwerten lässt. Zum einen gilt das gleiche Problem wie schon bei der Laufzeitmessung. Die Geometrie der Satelliten zum Messpunkt liefert für die X und Y Achse bessere Werte als für die Z Achse. Zum anderen sind die normalen Steig- und Fallgeschwindigkeiten so gering, dass sie sich kaum über das Fehlerrauschen abheben (Signal to Noise Ratio). Damit ist eine ernsthafte Korrektur nicht möglich.

Selbes gilt ja auch für langsame Fußgänger. Auch dort unterscheidet sich die Varianz der Position nicht wirklich von der im Stand. Interessanter wird es mit dem Fahrrad. Im Auto weichen die Messpunkte selten von der richtigen Fahrbahnseite ab. Und wenn, dann wegen dem systematischen Fehler.

Nennenswerte Steig- und Fallgeschwindigkeiten werden wohl nur Luftfahrzeuge aller Art zustande bringen. Davon habe ich leider keine Aufzeichnungen. Aber ich vermute dass man auch dort keine Verbesserung in der Varianz erkennen kann. Wenn hier ein Sportflieger mitliest, der Tracks von einem Empfänger ohne Barometer hat, wäre es sicherlich interessant uns den einen oder anderen Track zum Auswerten zu überlassen.

Die vom Empfänger über Korrelation ermittelte 2D Position und Höhe ist unabhängig von der Bewegung. Diese Position unterliegt 2 hauptsächlichen Fehlern. Einem systematischen und einem statistischen. Während der systematische Fehler dafür sorgt dass die Position über einen gewissen Zeitraum einfach eine paar Meter daneben liegt, sorgt der statistische Fehler dafür dass die Position um den wirklichen Punkt springt (Varianz). Selbes gilt für die Höhe.

In Bewegung kommt es zu einer Dopplerverschiebung der Empfangsfrequenzen. Diese muss zum einen kompensiert werden, zum anderen lässt sich aber auch ein 2D Geschwindigkeitsvektor daraus berechnen, der zudem den Vorteil hat, statistisch unabhängig von der Positionsbestimmung zu sein. Mit dieser zusätzlichen Information kann man in der Tat den statistischen Fehler der Position mittels eines Kalmanfilters reduzieren. -> Richtige Aussage: die Varianz der Position nimmt bei zunehmender Geschwindigkeit ab. Der systematische Fehler bleibt.

Schön wäre es, wenn man die Z Komponente dieses Geschwindigkeitsvektors auch verwenden könnte. Diese ist bei den üblichen Bewegungen aber so schlecht ausgebildet, dass sie nicht weiter verwendet wird. Und deswegen passiert das, was viele die noch mit Geräten ohne Luftdrucksensor unterwegs waren, leidlich wissen: Ein realistisches Höhenprofil ist mit so einem Empfänger nicht wirklich zu erreichen.

Deswegen haben sich die Ingenieure überlegt, wie man eine weitere statistisch unabhängige Information über die Höhe bekommt, mit der man die GPS Höhe verbessern kann. Klar, wie auch schon früher zu analogen Zeiten ist der Luftdruck sehr genau zu erfassen. Der hat nur 2 Nachteile:

1. Wie finde ich den aktuellen Luftdruck an der Startposition heraus.
2. Ändert sich das Wetter, ändert sich der Luftdruck.

Zusammen mit einem GPS Empfänger kann man diese beiden Nachteile gut kompensieren. Die aktuelle Höhe kennt man in den Grenzen ihrer Genauigkeit vom GPS Empfänger. Punkt 2 ist problematischer. Wie kann das Gerät wissen, ob die aktuelle Diskrepanz zwischen GPS Höhe und Barometer aus dem systematischen Fehler des GPS, der sich natürlich auch auf die Höhe auswirkt, oder einer Luftdruckänderung resultiert? Es geht nicht richtig. Deswegen kommt es bei Rundtouren zum Teil zu recht unterschiedlichen Höhenwerten am Start und Endpunkt. Trotz Luftdrucksensor.

Zur reinen Straßennavigation ist das alles egal. Für ein Outdoorgerät, mit dem man seine Touren aufzeichnen will, ist eine ordentliche Erfassung der Höhe wichtig. Deswegen auch der Rat von vielen und nicht zuletzt von mir: Wer am Barometer spart, spart an der falschen Ecke. Und man wird den Nachteil nie kompensieren können, indem man schneller geht oder fährt.

Ich hänge hier noch auch noch einen Track an. Wie unschwer zu erkennen, wurde der auf einem See aufgezeichnet. Die Höhe sollte, bis auf einen leichten Wellengang, somit gleich sein. Aufgezeichnet wurde mit einer iBlue 747 GPS Maus ohne Luftdrucksensor. Es darf jetzt mal jeder versuchen einen Zusammenhang von Höhe und Geschwindigkeit zu finden.

Zitat von Delago

Hallo Oliver,
ich könnte mir vorstellen, dass es gar keine geschlossene Formel für die Lösung gibt.

Das ist vermutlich richtig. Für die Distanz entlang der Oberfläche gibt es zu mindestens keine geschlossene Formel.

Zitat von Delago

Aber hier komme ich doch ziemlich ins Schleudern. Wie reduziert man die Geoidhöhe auf die Höhe beider Punkte? Wie findet man überhaupt die korrespondieren Stellen auf dem Geoid (vgl. Wikipedia)?

Ist das nicht genau das was GPS macht? Es gibt mir eine Position auf diesem Ellipsoid an. Und zudem eine Höhe über dessen Oberfläche. Wenn ich mich folglich orthogonal zur Ellipsoidenoberfläche die angegebenen X Meter in die Erde grabe bin ich genau drauf.

Zitat von Delago

Im Naviboard wurde die Höhenermittlung ja bereits diskutiert. Aber irgendwie fühle ich mich fachlich überfordert.

Naja, hier wird das Problem diskutiert, dass üblicherweise die Höhenangaben die wir so kennen sich nicht auf einen Ellipsoiden beziehen. Man folglich den Höhenwert des GPS noch in das jeweilige Bezugssystem umwandeln. Was nicht immer ganz linear geht.

Für die Jungs und Mädels vom OPERA-Experiment sollte das aber nicht wirklich von Interesse sein. Wenn die hinreichend genau wissen, dass ihre Quelle und Senke auf dem Ellipsoiden liegen, dann sollte sich auch die Entfernung hinreichend genau berechnen lassen. Wie das alles zu irgendwelchen anderen Bezugssystemen steht ist dann egal.

Grüße

Oliver

Gleich vorne weg, ich weiß es auch nicht wirklich. Aber ein wenig raten und fabulieren kann man ja mal.

Dieser Rotationsellipsoid ist ja so beschafften, dass er in die Erde passt. Die Erde mag eine beulige Kartoffel sein, irgendwo in ihrem Inneren (oder auch über der Erdoberfläche?) verläuft die ideale Oberfläche dieses Ellipsoiden. Wenn ich die Lage auf dem Ellipsoide kenne und den Abstand zu seiner Oberfläche, dann sollte so eine Berechnung möglich sein. Im Idealfall buddel ich solange, bis ich meine Quelle und meinem Detektor genau auf der Fläche des Ellipsoide positioniert habe. Dann wird es einfacher.

Frag mich jetzt bitte nicht nach der Formel. Die müsste ich selber erst mühsam googeln.

Grüße

Oliver

Zitat von mike_hd

Naja, aber die Genauigkeit der Höhe hängt direkt von der Genauigkeit der Position ab, wobei die Abweichung rund doppelt so groß wie bei der Position ist. Unter ungünstigen Bedingungen dürfte die Abweichung der GPS-Höhe noch größer sein.

Das ist sicherlich richtig. Aber es ging darum in wie weit sich die Bewegung auf die Position, bzw auf die Höhe auswirkt.

Zitat

Consumer Navis ohne Staticnavigation sind im Stand am ungenausten. Will jemand eine genaue Wegpunktposition, ist das sofortige Auslösen der Waypointgenerierung beim stoppen eine gute Lösung oder die spätere Veränderung am PC;) . Verhält sich ähnlich mit einer reinen GPS-Höhe im Stand.

Der letzte Satz ist meiner Meinung nach einfach Blödsinn. Die Ungenauigkeit der Höhe ist nicht von der Bewegung abhängig, weil diese nicht durch den Bewegungsvektor kompensiert wird.

Zitat von Sardinien

Oliver,
in Bewegung ist ein consumer GPS-Gerät deutlich genauer als im Stand. Der Genauigkeits-Unterschied kann im Stand gegenüber in Bewegung schon mal bei 10-20 m liegen.

Gerd, die Position ist genauer. Nicht die Höhe. Aus der Dopplerverschiebung der Empfangsfrequenzen lässt sich nur ein brauchbarer 2D Vektor berechnen. Wie üblich lasse ich mich auch gerne vom Genteil überzeugen. Aber bitte durch technische Details und nicht nur durch Wiederholen von Behauptungen.

Zitat von Sardinien

Oliver,
im Stand wandert die Trackaufzeichnung, speziell bei schlechten Empfangsbedingungen, und zeichnet dabei nicht stimmende GPS Höhenwerte auf. Wird mit Barometer die Höhe ermittelt, spielt die Tänzelei keine Rolle.

Gerd, meine Frage war welcher technische Hintergrund Dich zu der Aussage verleitet, dass gerade im Stand der Höhenwert schlechter sein soll als in Bewegung.

Zitat von Sardinien

Verhält sich ähnlich mit einer reinen GPS-Höhe im Stand.

Erkläre mal wie Du auf diese Aussage kommst?

Zitat von Sardinien

Oliver,
die Sardinien- und Kroatien Map stelle ich gerne auf Anfrage als RMAP zur Verfügung. Natürlich ist es kein Problem die restlichen Maps käuflich zu erwerben bzw. downloads via WMS, teilweise Mobac.

Eine der genannten Quellen ist als legal zu bezeichnen. Ob diese Karten sich allerdings einfacher und ohne Trickserei in CGPSL oder irgendeiner anderen Software einbinden lassen, halte ich für eine gewagte Aussage. Das alles sollte man vielleicht einem Rooky wie dem Steve fairerweise auch verraten, oder?

Zitat von trailsurfer

Mit meinem 62er am MTB-Lenker hatte ich wegen der Antenne, die dann etwa waagerecht in Fahrtrichtung zeigt, noch kein Problem.
Die Tracks werden in jedem Gelände sauber aufgezeichnet.

Wenn der Empfang und damit die Aufzeichnung bei Dir immer gut ist, scheinst Du aber nicht in jedem Gelände unterwegs zu sein