Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - sonny

Pages: [1]
1
"Filterung der Höhendaten" - kann das nochmal jemand erklären - ist das zur Aufzeichnungszeit? Obwohl - er ermittelt doch die Höhendaten anhand der horizontalen Position, wenn ich "GPS-Daten ersetzen" nehme...

Also: Ich hatte immer "Kein Filter" eingestellt. Nun habe ich "Starker Filter" eingestellt. Ich dachte, wenn ich nun in einem Track die Höhen neu berechnen lasse, dass dann in der Statistik neue Werte entstehen. Passierte aber nicht, ich hatte bspw. vorher 1308 gewonnene Hm und nach der Neuberechnung auch. (Ein anstrengender Tag war das :-)

Ich habe mir das mit Filter selber mal anhand einer realen Runde im Freien ausgetestet. Die realistischten Höhen-Summenwerte bekam ich mit den Einstlellungen "GPS-Werte ersetzen" und "Starker Filter". gerade die zick-zack artigen Sprünge (entweder durch die GPS-Höhe oder auch dadurch, dass die horizontale Lage bei GPS-Empfang sagen wir +- 10 springt und dadurch auch die ermittlte Dateihöhe) sich doch ziemlich auf die Höhensumme auswirken.

Bestest Beispiel man geht immer eben horizontal entlang eines Flusstales, die Höhensumme sollte also 0m ergeben. Trotzdem wird die horizontale Lage der GPS-Koordinaten immer etwa um +/- 5-10 Meter schwanken und z.b. also auch öfters scheinbar an der Schrägkante zum Fluss hinunter sein. Schon hat man trotz bester Lidar-Höhendaten eine Höhe von zb. -2 Meter und danach wieder +2 Meter. Das wiederholt sich ständig und so hat man plötzlich +30 Meter trotz bester Höhendateien rechnerisch gemacht, obwohl man immer eben spazierte.  Und genau diesen (in der Realität nicht vorhandenen) Minisprünge soll die Filterung wegfiltern.

Soweit ich wird diese Filterung aber erst angewendet wenn ein Track gespeichert wird, also nicht schon live bei der Aufzeichnung. Bei der Speicherung wird ja bereits auf deine Lidar-Dateien zurückgegriffen, dadurch hat sich nachher mit "Höhen neu berechnen" nichts geändert, da dies ja genau dieselbe MEthode ist. Diese würde nur was ändern wenn du im Höhenmanager per per GPS (und nicht per Höhendateien) die Höhen aufgezeichnet hast. Oder wenn du von irgendwo im Internet einen Track her hast, der seine eigenen oder gar keine Höhen hatte.
The following users thanked this post: tapio, freischneider, flyingman_ch

2
  • ja, es stimmt das der automatische Locus-Download von Höhendateien bereits Lidar-Dateien downloaded wo diese verfügbar sind. Allerdings "nur" die 3 Bogensekunden Variante (Rasterweite der Höhenwerte ca. 75 meter) und nicht die deutlich genauere 1 Bogensekunde Variante (Rasterweite: ca. 25 meter). Die 1" Dateien sind zwar fast 10 mal so groß wie die 3" aber möglich sollte man sich doch die 1" manuell runterladen. 
  • Die "Automatische Korrektur" unter "unter "Offset" hat nichts mit der Barometer-Funktion zu tun. Es gleicht nur jene ca. 40-50 Meter KONSTANT "falschen" Höhenwerte aus, die der GPS-chip liefert (dieser liefert in der Regel nämlich nicht die Höhe basierend auf 0m Meereshöhe, sondern auf einer anderen Basis, die mit dem GPS-System zu tun hat). Normalerweise also hier auf "Automatisch".
    WICHTIG: dies ist daher nur relevant, falls als Höhenquelle der GPS-chip verwendet wird, also unter "Einstellungen" NICHT "GPS-Werte ersetzen" aktiv ist.
  • wenn man zusätzlich noch ein Barometer hat, kommt also noch eine 3 mögliche Quelle für Höhendaten neben den Höhendateien und dem GSP-chip dazu. Dessen großer Vorteil ist, das er Höhenänderungen sehr genau und schwankungsfrei abbildet, man kann super die Änderung sehen wenn man vom Erdgeschoss in den 1.Stock eines Hauses geht.

    Der Barometer selber kann aber keine absoluten Höhen messen (z.b. du bist jetzt genau "1000 m" über dem Meer.) sondern nur Differenzwerte zu einem vorher von dir selber (oder dem GPS) definierten Höhe. wenn du unter "Luftdruck" Automatisch wählst wird also das GPS dafür hergenommen.
    WICHTIG: auch dies ist (glaube ich) nur relevant, falls als Höhenquelle der GPS-chip verwendet wird, also unter "Einstellungen" NICHT "GPS-Werte ersetzen" aktiv ist. Sonst werden für die Höhe ja sowieso auschlißlich die Werte der Datei verwendet.

  • Ob in deinem Fall nun die Höhensumme basierend auf den Höhendateien (möglichst 1"-LiDAR falls vorhanden) oder doch die Barometer-Höhe mit automatischer GPS-Kalibrierung realistischer Werte liefert musst du anhand einer Testrunde selber raustesten  ;) Deine jetzigen Einstellungen verwenden also vermutlich gar nicht den Barometer, sonder nur die Dateien.

The following users thanked this post: freischneider, flyingman_ch

3
Da gibts 2 Punkte zu unterscheiden:

1)
In der Locus Einstellung ist "SRTM-Daten" wohl etwas missverständlich ausgedrückt. Besser wären "Höhen-Dateien".
Als Höhen-Dateien werden normalerweise die sog. "SRTM-Dateien" verwendet, da diese auch von Locus automatisch zum Download angeboten werden. Alternativ gibt es für eine Handvoll Länder aber bereits genauere "Lidar-Dateien", die aber genau den selben Zweck wie die "SRTM-Dateien" erfüllen. Diese musst du aber selber downloaden und in den entsprechenden Locus-Ordner kopieren. Also für z.b. Österrieich oder Schweiz besorgt man sich die genaueren Lidar-Dateien. Für Deutschland muss man unterscheiden in welchem Bundesland man ist. Nur für manche gibt es da bereits Lidar-Daten.

2)
Da man sich nun die bestmöglichen Höhendateien für ein Land besorgt hat (SRTM oder LiDAR), muss man nun noch unterscheiden: Welche Methode liefert im Schnitt genauere Höhenwerte: Entweder der im Handy eingebaute GPS-Chip oder doch die mehr oder weniger genauen Höhendateien.

Im Flachland haben wohl immer die Höhendateien die Nase vorne. Sobald es aber hügelig wird, oder gar ins Gebirge geht, haben speziell auch die SRTM-Höhendateien mehr oder wenige große Ungenauigkeiten. Hat man aber LiDAR-Höhendateien sind diese wiederum lagegenauer und haben  auch präzisiere Höhenwerte im Hügelland.

Die GPS-Chips haben oft in diesem Terrain (auch wegen Waldbewuchs, Felswände etc.) Empfangsschwierigkeiten und können die Höhe nicht genau liefern bzw. schwanken auch etwas stärker auf- und ab, was gerade bei Anwendung wie "wieviele Höhenmeter bin ich in Summe hinauf gestiegen" gröbere Fehler (meist zu große Summen-Werte) liefert.
Andererseits: wenn man z.b. auf einem Gipfel mit 2000m steht, wo es 5 Meter daneben steil bergab geht, so könnte die auf den Höhendateien basierende Methode z.b. nur eine Höhe von 1900m liefern, da ja die horizontale Lage nie auf den Meter genau gemessen werden kann und der Höhenwert von einem Punkt 10 m daneben her genommen wird. Der GPS-chip in diesem (seltenen) Fakk sicher einen genaueren Wert liefern.

Lange Rede, kurzer Sinn: Ich verwende in Österreich die LIDAR-Höhendateien und vertraue darauf unterm Strich in 99% der Fälle mehr als dem GPS-Empfänger. Daher habe ich Einstellung "GPS-Werte ersetzen". Falls man nur SRTM-Daten hat, muss man einfach selber ausprobieren welche Methode die genaueren und weniger schwankenderen Resultate liefert. Entweder auch "GPS-Werte ersetzen" oder "GPS-Höhenangabe optimieren" (diese Variante liefert fast immer die Höhen vom GPS-chip, nur ganz bei ganz groben Ausreißeren wird jene der SRTM-Dateien verwendet).

Was auch noch in beiden Fällen hilft: Bei Höhenfilter auf "Mittlerer Filter" oder noch besser "Starker Filter" (verwende ich) stellen. Damit erreicht man bei summierten Höhenwerten sehr gute Resultate, die nicht wie oft üblich viel zu hoch sind (z.b. 400 Höhenmeter obwohl die Wanderrunde in Summe nur 250 Höhenmeter hat)
The following users thanked this post: flyingman_ch

4
Switzerland and France are available now too:

http://data.opendataportal.at/dataset/dtm-france
http://data.opendataportal.at/dataset/dtm-switzerland
The following users thanked this post: Andrew Heard

5
... noch was: du kannst auch deinen Locustrack im Nachhinein noch mit den Lidar-Höhendaten korrigieren:
öffne die Trackdetailseite, klicke rechs unten im Menü auf das ^-Icon, "Mehr", "Höhenangabe einfügen"
The following users thanked this post: tbkrtz

6
Hallo, ich habe einen Blick darauf geworfen. Also der Garmin-Track ist ok, er weicht vom Lidar-Terrain höhenmäßig immer nur max. 10m ab und unterliegt aufgrund des eingebauten Barometers auch keinen gröberen Schwankungen aufgrund von schlechtem Sat-Empfang.

Beim Handy hast du 2 Probleme:

1.) fehlt dieser Barometer, ist also bzgl. Höhenmessung gerade in so hügeligem Gelände schon mal schlecht geeignet. Da du aber im Locus ein sehr präzises Lidar-DTM installiert hast (hast du eh die 1" und nicht die 3" für NRW runtergeladen?) kannst du dieses Höhemmodell im Locus zum korrigeren der eher ungenauen Handyhöhen verweden.

2.) Ich habe gesehen, dass dein Handy um ca. +40m eine zu große Höhe aufzeichnet. Das liegt wahrscheinlich darin das du im Locus die Offset-Korrektur nicht eingeschaltet hast und daher nicht die Höhe über dem Meeresspiegel verwednet wird, sondern eine "virtuelle" Höhe, die sog. GPS-Ellipsoidhöhe

Du kannst aber beide Probleme ganz gut in den Griff bekommen in dem du Locus richtig einstellst:

Und zwar unterEinstellungen > GPS und Ortung >  Höhen Manager:
"Höhenkorrektur verwenden" aktivieren; 
SRTM:daten: "GPS Höhenangabe optimieren" oder besser noch in NRW wo es das genaue Lidar-Model gibt "GPS-Werte ersetzen";
Höhenfilter: "Starker Filter";
Offset: "Automatische Korrektur" aktivieren

DAmit sollten nun das Garmin und das Handy ähnliche Werte aufzeichnen, also wenn du auf einem Gipfel bist z.b. nicht mehr als 10m abweichen.

The following users thanked this post: tbkrtz

7
siehe in diesem Thread, Posts 1 und 5:
http://forum.locusmap.eu/index.php?topic=5363.0
The following users thanked this post: tbkrtz

8
Troubles & Questions / Re: UTM projection is not precise
« on: June 28, 2017, 18:32:24 »
I think Locus is treating UTM-coordinates correct. But for checking with professional conversion software you should provide the coordinates in degree of your points too.

In general a UTM- grid is not exactly "rectangular" compared to the degree-grid of the same region. But it is more or less rotated, meaning the meridian of the UTM-grid are *not* running from geographical North to south. Please take a look at the image:

As you can see the black lines of degree-grid are not parallel but lightly rotated to the colored UTM-grid, especially on the sides of an UTM-zone.

The other point to consider is, that UTM is just a projection of the earth's surface which is nearly a sphere and can't 1:1 projected into a rectangular system. So simplified: 1 meter in UTM grid is just "at average" 1 m in reality, depending in which location within an UTM-zone you are measuring. The differeces are of course very low, but a distance on real earth of 5000 m could be a just distance of for example 4998 m in UTM-grid.

So we can't 1:1 convert UTM-meters in real-world meters. Also each grid system uses another model of Earth with slightly different diameters of their models.
The following users thanked this post: menion

9
Grundsätzlich: Ich weiß, dass die Bestimmung der richtigen Seehöhe eines Punktes selbst bei guten GPS-Empfangsbedingungen nicht immer genau und zuverlässig ist. Ganz zu schweigen wenn man sich innerhalb von Schluchten, dichten Wäldern oder am Rand von Felsmauern bewegt.
Gleiches gilt selbst bei Verwendung von sehr genauen .HGT-Dateien. Da deren Genauigkeit das eine ist, aber die Genauigkeit der per GPS ermittelten GPS-Position auch eine wesentliche Rolle spielt: Wenn man z.b, unterhalb einer hohen Felswand geht und die (horizontale) GPS-Position nur 15m falsch ist, wird selbst bei genauestem .hgt-DAten eine falsche Höhe von z.B. 50m oder mehr angezeigt. Diese kann wiederum von Sekunde zu Sekunde stark hin- und herschwanken allein wegen der Ungenauigkeit der Positionsermittlung des aktuellen Standortes mittels GPS.

Noch viel komplexer als die Ermittlung des Höhenwertes eines einzelen Punktes ist die Berechung von summierten Höhenwerten, sprich wieviele Höhenmeter habe ich während meiner Wanderung in Summe bewältigt.

Hier gibt es selbst bei besten Empfangsbedinungen je nach Methode der Filterung/Nachbearbeitung eines Tracks GEWALTIGE Unterschiede, was dazu führt das sich viele Leute immer über völlig unrealistische Höhensummen wundern, die ihnen das GPS anzeigt.

Ich habe z.B. einen längeren Spaziergang bei guten Empfangsbedingungen in eher flachen Gelände gemacht. Track habe ich mit Locus, nur GPS-keine SRTM Daten, aufgezeichnet. Alle Sekunde ein Trackpunkt, mittlere Filterung.

- Am Schluss zeigte mir Locus in den Trackeigenschaften einen Höhensumme von +484 m an - völlig unrealistisch.

- Ich habe dann den selben Track mit den Höhenwerten meines LIDAR-Hgt von Österreich füllen lassen. Ergebnis: Höhensumme nur mehr: +163 m: viel besser! Trotzdem bleibt noch die oben erklärte Ungenauigkeit aufgrund der schwankenden horizontalen GPS-Position (eine in wirklichkeit gerade Strecke ist nach der TRackaufezeichnung immer leicht zick-zack förmig. Das führt dazu das die summierten Höhen immer größer sind als in der Realität.

- Ich habe deswegen den Zick-zack-Track noch vereinfacht (hatte danach nur mehr ca. 20% der ursprünglichen Trackpunkte
dies führte dazu, das auch die Anzahl der fehlerhaften Höhenpunkte abseits der wirklichen Strecke deutlich reduziert wurde. Höhensumme nun: +110 m was sehr gut der Relität entspricht.

Wie man sieht gibts hier selbst bei sehr guten Empfangsbedingungen haarsträubende Unterschiede. Der Laie der sich über die Hintergründe nicht bewusst ist, sagt er hat heute eine Wanderung mit fast 500 Höhenmetern gemacht, obwohl es in wirklichkeit nur knapp über 100 Höhenmeter waren.

Das war ein Einschub um zu zeigen wie extrem schwierig es für Geräte, Software und Benutzer ist für einen Track einigermaßen sinnvolle Höhensummen zu erhalten. Wer nur GPS zur Verfügung hat und keine LIDAR-Höhendaten hat, ist wirklich arm dran wenn sie nicht einen sehr starken Höhenfilter verwenden und am besten Trackpunktaufzeichnung nur alle 10 Sekunden oder so.
Selbst bei Verwendung von genauen SRTM-Dateien bedarf es noch der Einstellung von schlauen Trackaufzeichnunsintervallen und Filterungen.

Du hast aber recht: Wenn man ein Gerät mit Luftdrucksensor hat kann man Höhenmessungen+Summen davon am zuverlässigesten messen. Der Drucksensor erzeugt keine sprunghaften Höhenunterschiede, selbst wenn der horizontale GPS-Empfang zick-zack Sprünge macht.
Und die größte Unsicherheit bei Geräten mit Drucksensor: Der sich bei Wetterumschwung ändernde (Meeres)luftdruck wird durch die schlaue automatische Kalibrierung von Locus mit Hilfe von .hgt-Daten kontinuierlich angeglichen.

Also: Pressure sensor in den Einstellungen aktivieren, und "Automatic calibration".
Einzig offener Punkt: ob man bei "SRTM  Data" in der Praxis besser "optimize GPS values" (GPS wird hauptsächlich verwendet) oder doch "Replace GPS values" (nur .SRTM-Files werden verwendet) bzw. ob diese Einstellung überhaupt für die automatische Kalibrierung verwendet wird müsste man ausprobieren.
The following users thanked this post: freischneider

10
gibts schon seit einigen Monate da, viel Spaß!
http://data.opendataportal.at/dataset/dtm-spain
The following users thanked this post: togtog

11
Hallo, ich versuche es so "kurz"  ;) und verständlich wie möglich zu erklären:

Für jene Gebiete wo es bereits meine LIDAR-DTMs gibt, z.b. für Österreich http://data.opendataportal.at/dataset/dtm-austria , lädst du dir jeweils die 1"-DTM runter. Hier findest du übrigens auch einen Link zum Kartenvergleich meiner LIDAR-Daten zu denen der SRTM-Kacheln: http://goo.gl/DM2YxD

Das 1" ist das genaueste DTM, es gäbe auch noch die 3" die aber ungenauer sind. Mit den 20m und 50m-DTMs kann Locus sowieso nicht umgehen.

Du entpackst alle Dateien und schiebst die .hgt Dateien rüber in den data/srtm-Ordner von Locus. Dort liegen ev. schon Dateien mit dem gleichen Kachelnamen drin, die überschreibst du einfach, denn dabei handelt es sich vermutlich um die "alten" wesentlich ungenaueren SRTM-Höhendaten.

Sodala, da war's schon. Ab nun nimmt Locus zur dynamischen Anzeige der Höhe deiner aktuellen Position ("Dynamic Elevation", zur Berechung von Höhenunterschieden eines Tracks, zum Erzeugung der Kartenschattierungen ("Map shading") dieso genauen Höhenkacheln her.

Diese Höhendaten sind so gut wie immer genauer und zuverlässiger als die Höhenbestimmung per GPS oder auch per Barometer (dieser folgt zwar Höhenänderungen sehr genau, muss aber manchmal nachkalibriert werden, da sich der örtliche Luftdruck ändern kann).
In den Locus-Einstellungen (Menü > Settings > GPS > Altitude manager > "SRTM DATA" kannst du einstellen:
"Optimimize GPS values" (gerade in Zusammenspiel mit einem Barometer sicher eine interessante Sache) oder gleich "Replace GPS values", dann werden ausschließlich diese Höhenkacheln zu Höhenberechnung herangezogen.

Etwas anderes ist die Lage für Länder, wo es solche LIDAR-basierten DTMs noch nicht gibt, sonder nur die SRTM-Kacheln. Diese können zuverlässiger sein als GPS-Höhenempfang, aber auch ungenauer sein, da die SRTM-Kacheln stellenweise Abweichungen von 50m,100m oder mehr haben können, z.B. im alpinen Gelände, in Schluchten etc.
Speziell in gebirgenen Regionen und/oder dicht bewaldeten Flächen würde ich hier zuerst auf barometrische Höhenmessung zurückgreifen falls im Gerät vorhanden.

Zu deinen Zusatzfragen:

- Es kann immer nur eine gleichbenannte Kachel geben und diese erwartet Locus im data/srtm ordner.
Dabei sollte es sich hier immer um die genauest möglichen Kacheln eines Landes handeln (1"-Lidar besser als 3"-Lidar besser als 1"-SRTM besser als 3"-SRTM)
- Wenn du einen Track z.B. für eine Navigation im Vorhinein erzeugst, dann basiert das Höhendiagramm definitiv auf den Höhenkacheln.
Wie dies aber bei der Aufzeichnung eines Tracks ist während du unterwegs bist, weiß ich nicht. Entweder es werden auch hier standardmäßig nur die Höhenkacheln genommen oder aber jene Höhe die Locus live ermittelt anhand der obigen einstelllungen bei (Menü > Settings > GPS > Altitude manager > SRTM).

Müsstest du menion dazu fragen, oder jemand anders der das weiß.
The following users thanked this post: balloni55, michaelbechtold, LocusUser#1

12
I added terrain models of Luxembourg and some German provinces:

http://data.opendataportal.at/dataset/dtm-germany
http://data.opendataportal.at/dataset/dtm-luxembourg
The following users thanked this post: LocusUser#1, jonny.blue

13
Dear Locus map creators and users!

I want to tell you, that I've created several Digital Terrain Models (DTMs), which are based on precise Opendata LiDAR-elevation data of the country's Geographical Institutes. Right now these are:
The improvements in accuracy, quality and fine details of my model's elevations compared to those of the popular SRTM-datasets are enormous. Especially in mountainous terrain.

You can use these new DTMs to create improved, more accurate contour lines in maps. Or you can copy the files for the area of your interest into the correct folder of Locus to improve dynamic elavation values and the shading of the maps in these areas.

The latest versions of Openandromaps in these countries are already based on my DTMs and people say the improvement of contour lines' (and dynamic elevation as well as hill shading) quality in the new maps are excellent.

Have a look at some map comparisons: Map using SRTM-DTM >>> Map using Laser-DTM: http://goo.gl/DM2YxD

There's also a thread regarding the implementation of these DTMs into Openandromaps (in German):
http://www.openandromaps.org/oam-forums/topic/neues-genaueres-hoehenmodell-fuer-oesterreich

14
Hi,

I noticed that a few of the Locus-Waypoint icons having a wrong or missleading Hotspot (the pixel that is exactely marking the coordinates an icon's waypoint on the map).

These are the "x"-icon, the ring-icon, and the circle-icon of each color. Their optical hotspot is in the center of these icons. But Locus uses a Pixel at the bottom of these icons as the coordinate hotspot

Look at following example Screenshot:



you can see, there is a difference of about 60 Meters in reality between the center of the icon and the real coordinates of the icon's waypoint indicated by the cross-hair. In extreme cases somebody could by mistake think that the waypoint is somewhere within the parallel street of a town.

Please correct the Hotspots of these icons.

The other Locus icons (arrows and marker-like icons) as well as the Garmin-icons, which having their optical hotspot in their center, are already treated correctly in Locus.
The following users thanked this post: gynta

Pages: [1]