Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Dimitri Junker]

Hallo,

mit Hilfe eines Mitlesers habe ich endlich die DGM50-Daten gewandelt. Zuerst 
sahen die Ergebnisse sehr schlecht aus, nach dem ich aber ein vertauschtes x-
y korigiert hatte nicht mehr ganz so schlecht. Meine Daten sind im 
Durchschnitt 6m höher als die DGM50-Werte und haben eine Streuung um diese 
von etwa 25m. Das ist noch nicht gut, aber wenn man bedenkt, daß ich dazu 
nur alte GPX-Files verwendet hatte, wo also niemand darauf geachtet hatte, 
daß die Höhenkorrektur stimmt u.ä. ist das nicht so schlecht. Außerdem sind 
da ja noch die üblichen Pixelwolken drin, kurz nach dem Einschalten, oder 
bei schlechtem Empfang. Nachdem ich jetzt rausbekommen habe wie ich von 
Glopus auch vdop erhalte kann ich in einem nächsten Schritt darüber noch 
etwas filtern und besser gewichten, aber ich bräuchte da mehr Daten.
Alternativ könnte ich natürlich auch die Ortsauflösung von derzeit etwa 6m 
reduzieren, hätte so also für jeden Meßpunkt mehr Daten.

Gruß
Dimitri


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Dimitri Junker]

Hallo,

ich habe mir jetzt ein paar km^2 DGM50 Daten geleistet. Das erste Problem 
war Gauß-Krüger 2.
Nachdem was ich hier gelesen habe bin ich auf 

gegangen und habe die Daten konvertiert. Als Quellformat habe ich
2: Gauß-Krüger Nr.2/6 Grad (West-D)
und als Zielformat
-1: geographisch (Altgrad, dezimal)

gewählt ist das richtig um es mit GPX-Files abgleichen zu können oder muß 
ich als Zielformat irgendeines der WGS84 nehmen, aber wenn ich das richtig 
sehe klappt das nicht mit Quellformat GK2

In der Zwischenzeit schreib ich schonmal den Abgleich

Gruß
Dimitri


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Dimitri Junker]

>Aachen.gpx besteht aus tausenden Punkten Aachen4.gpx besteht nur da aus
>Punkten, wo auch Tracks waren.


Ach. Hab ich jemals was anderes behauptet? Ich hatte dazu geschrieben:


>Wenn das zip-File etwa 8MB groß ist enthält es alle 1024*1024 Pixel,
>also incl. der gefüllten Löcher zwischen den Tracks, ist es etwa 1MB
>groß sind nur die Bereiche der Tracks drin.




___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Tobias Wendorff]

Dimitri Junker schrieb:
> Kannst Du mir einen Screenshot machen wo Du so einen Bereich markierst. JOSM 
> ist die Datei zu groß, POIEdit schaft es auch nicht. Ahh ein Lichblick 
> GoogleEarth, es wird zwar sehr langsam zeigt aber dann doch für jeden Punkt 
> ein Fähnchen. Und diese liegen schön entlang der Straßen. Also scheint da 
> alles geklappt zu haben.

Aachen.gpx besteht aus tausenden Punkten
Aachen4.gpx besteht nur da aus Punkten, wo auch Tracks waren.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Tobias Wendorff]

Dimitri Junker schrieb:
> Soll ich jetzt ein eigenes Instizut gründen? Obwohl eigentich wäre es ja mal 
> Zeit eine wissenschaftliche Veröffentlichung zu schreiben ;-)

Veröffentlichen könnten wir es hier bei mir...

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Dimitri Junker]

Hallo,


>Neeeinn ... Glopus weiß ja nicht, ob das Gerät richtig oder falsch
>gerechnet hat! Woher soll es das wissen?


Weil es der User einstellt.

>120 EUR klingt für mich eher nach Mehrplatzlizenz mit
>Vervielfältigsrechten.


Nein, das ist der 1-Nutzer Preis, für 5 Nutzer kostet es 180 EUR und das 
geht dann bis zu 200 Nutzer 480EUR.

>Wie gesagt: Wenn Du eine wissenschaftliche Veröffentlichung machen
>würdest, wäre alles viel einfacher / kostenloser.


Soll ich jetzt ein eigenes Instizut gründen? Obwohl eigentich wäre es ja mal 
Zeit eine wissenschaftliche Veröffentlichung zu schreiben ;-)

Gruß
Dimitri

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Dimitri Junker]

Hallo,

>Trotzdem ist die Datei voller Punkte, wo keine hingehören :-)


Kannst Du mir einen Screenshot machen wo Du so einen Bereich markierst. JOSM 
ist die Datei zu groß, POIEdit schaft es auch nicht. Ahh ein Lichblick 
GoogleEarth, es wird zwar sehr langsam zeigt aber dann doch für jeden Punkt 
ein Fähnchen. Und diese liegen schön entlang der Straßen. Also scheint da 
alles geklappt zu haben.

Gruß
Dimitri

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Tobias Wendorff]

Dimitri Junker schrieb:
> Glaub mir über 1200m findest Du hier weit und breit nicht. So und jetzt 
> schau ich mir noch den NMEA-Log an Da steht die ungeänderte Höhe.
> $GPGGA,190914.000,5045.8833,N,00607.4018,E,1,04,1.7,216.2,M,47.6,M,,*50

Also doch nicht die Undulation, sondern nur ein Wert, der auf die
orthometrische Höhe addiert wird. Puh, ein Glück.

"Korrekt" müsste die WGS84-Undulation so aussehen: 46.70 [m]

An Deiner Position herrscht übrigens eine Undulation von 46.50 Metern.
Das heißt: Höhenausgleich von 1,1 Metern beachten.

Grüße
Tobias



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Dimitri Junker]

Hallo,


>Geloggt wird der evtl. gefilterte aber nicht veränderte Datenstrom von
>GPS-Empfänger.

Das ist aber nur die Halbe Wahrheit. 
Ich habe gerade Glopus gestartet, einen Höhenausgleich von 1000m eingestellt 
und dann den Track als gpx exportiert. Dabei kam folgendes raus.

2009-03-13T20:09:14Z
1216.2
4
1.7


Glaub mir über 1200m findest Du hier weit und breit nicht. So und jetzt 
schau ich mir noch den NMEA-Log an Da steht die ungeänderte Höhe.
$GPGGA,190914.000,5045.8833,N,00607.4018,E,1,04,1.7,216.2,M,47.6,M,,*50

Dann habe ich mich gefragt woher Glopus denn beim Export den 
Höhenausgleich kennt, denn im NMEA-Log steht nirgendwo 1000m. Also kam mir 
der Verdacht, daß nicht etwa der zum Logzeitpunkt aktuelle Höhenausgleich 
verwendet wird, sondern der vom Exportzeitpunkt. Also habe jetzt jetzt 
nochmal das gpx exportiert, nachdem ich wieder 'Auto' aktiviert habe. Und 
jetzt steht da:

2009-03-13T20:09:14Z
216.2
4
1.7


Das halte ich dann doch für einen Bug.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Tobias Wendorff]

Dimitri Junker schrieb:
> Stimmt, da stand Dateien nicht Punkte, aber dann macht es auch keinen Sinn, 
> denn was hat die Anzahl der Punkte mit dem Dateinamen zu tuen. Und die Logik 
> des Namens ist, daß die Nummer sozusagen eine Versionsnummer ist. Und warum 
> davor Aachen steht dürfte auch klar sein.

Trotzdem ist die Datei voller Punkte, wo keine hingehören :-)

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Tobias Wendorff]

Dimitri Junker schrieb:
>> die Geoidundulation liegt bei den meisten GPS-Geräten in Deutschland bei
>> 47.5 m (was aber falsch ist).
> 
> Also bietet Glopus die Möglichkeit diese falschen 47.5 m oder was auch immer 
> das Gerät liefert zu korigieren. Was ist daran verwerflich? 

Neeeinn ... Glopus weiß ja nicht, ob das Gerät richtig oder falsch
gerechnet hat! Woher soll es das wissen?

> 1)der GPS-Receiver bestimmt die 3 Koordinaten mit der ellipsoide Höhe.

Genau.

> 2)Aus Länge und Breite ermittelt er aus einer Tabelle o.ä. die Geoidundulation

Nunja, er interpoliert sie aus einem groben Raster. WGS84 ist eigentlich
viel genauer definiert, aber das würde die Performance und die Kapazität
sprengen.

> 3)er schreibt in den NMEA-Datenstrum die orthometrische Höhe=ellipsoide Höhe-
> Geoidundulation) und die Geoidundulation selber

Genau, aber wie gesagt treten gerne mal Firmwareprobleme auf.

> Der komplizierte Teil ist Schritt 2. Schritt 3 ist dagegen trivial, auch 
> wenn Dein Polaris da versagt. Je nach gewünschter Genauigkeit werden bei 
> Schritt 2 aber fast alle Geräte versagen. Also ist es doch sinnvoll eine 
> Möglichkeit zu bieten dies zu korigieren. Dann stellt sich die Frage wie 
> macht das der normale User. Entweder ermittelt es die Geoidundulation aus 
> irgendeiner Datenbank und hat damit das richtige Ergebnis außer bei Deinem 
> Gerät, oder er mittelt die Höhe für einen Ort mit bekannter Höhe und 
> korigiert die Geoidundulation so, daß die richtige höhe rauskommt. Das würde 
> sogar bei Deinem Gerät funktionieren.

Dazu musst Du aber wissen, dass es falsch geht. Du hast ja hunderte
GPX-Tracks runtergeladen und weiß nicht, ob überhaupt die Hälfte der
Tracks korrekt berechnet wurden, ob eine Undulation beachtet wurde
und wenn ja, welche und wenn nein, wovon wurde dann ausgegangen.

Wenn Du weißt, dass Dein Gerät mist baut (dazu musst Du den NMEA-String
manuell untersuchen), dann kannst Du die Korrektur umdrehen, also z.B.
20 m addieren, dass es wieder klappt.

Das basiert aber auf der Annahme, dass Glopus eine Undulation wählen
lässt.

> Also beim LVA kostet der km^2 mit einem Raster von 5m 30EUR. Abgegeben wird 
> es in 4km^2 großen Paketen, also pro Paket 120EUR.
> s. 
> es gibt das ganze auch mit einem 50m Raster, aber das ist ja fast so grob 
> wie SRTM nur sind die Höheninfos wohl genauer. Topografische Karten sind 
> billiger, aber eine vernünfztige Auswertung bekommt man damit nicht hin, 
> dafür dürften die Linienabstände zu groß sein, oder wenn sie gut sind ist 
> man ewig am Abzeichnen. Dann würde ich schon eher die 120EUR zahlen.

120 EUR klingt für mich eher nach Mehrplatzlizenz mit
Vervielfältigsrechten. Schreib einfach hin, dass Du es zur Analyse
brauchst und die konkreten Daten und Karten intern bleiben. Dann
machen sie dir ein Angebot.

Wie gesagt: Wenn Du eine wissenschaftliche Veröffentlichung machen
würdest, wäre alles viel einfacher / kostenloser.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Gerd Steinburger]

Dimitri Junker schrieb:
> Hallo,
> 
>> Ach Du meine Güte ... den Wert dort einstellen? Das wäre kompletter
>> Irrsinn!
> 
> 
> Wo denn sonst? Dafür ist die Einstellmöglichkeit ja da.
> 
>> Nicht alle GPS-Geräte liefern korrekte Geoid- und orthometrische Höhen
>> im NMEA-Tag
> 
> 
> Ach, und deshalb gibt es die Einstellmöglichkeit,sonst wäre sie ja unnötig.
> 

Hallo,

der auf der Seite Höhenanzeige http://www.glopus.de/heightview.htm  eingegebene
Höhenausgleich dient lediglich dazu, dass innerhalb von Glopus von bekannten
Höhenpunkten die erwartete Höhe angezeigt wird. Also wenn sich GPS-Empfänger
nicht an den NMEA-Standard halten kann für die Anzeige nachjustiert werden.
Einfluß auf die gespeicherte/geloggten Werte hat der Höhenausgleich nicht.
Geloggt wird der evtl. gefilterte aber nicht veränderte Datenstrom von 
GPS-Empfänger.

Gruß

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Dimitri Junker]

>Du hast nicht verstanden, wie NMEA funktioniert.


Stimmt davon hab ich 0 Ahnung, aber nach Deiner Erklärung gibt es trotzdem 
keinen Grund den Höhenausgleich von Glopus zu verdammen. Die aktuelle 
Glopusversion bietet neben der Eingabe einer Höhe auch noch den Auto-Modus. 
Dann wird wohl die Höhe rein aus den NMEA-Daten berechnet. Was aber nach 
Deiner Aussage:

>die Geoidundulation liegt bei den meisten GPS-Geräten in Deutschland bei
>47.5 m (was aber falsch ist).

Also bietet Glopus die Möglichkeit diese falschen 47.5 m oder was auch immer 
das Gerät liefert zu korigieren. Was ist daran verwerflich? 

>Wenn nun aber, wie bei meinem Polaris, das 1. Feld richtig berechnet und
>ausgefüllt, das 2. Feld aber falsch ausgefüllt ist, baut er Mist.


Das willst Du jetzt aber nicht Glopus anlasten oder? Wenn ich Deine 
Erklärungen richtig verstehe passiert doch folgendes.
1)der GPS-Receiver bestimmt die 3 Koordinaten mit der ellipsoide Höhe.
2)Aus Länge und Breite ermittelt er aus einer Tabelle o.ä. die Geoidundulation
3)er schreibt in den NMEA-Datenstrum die orthometrische Höhe=ellipsoide Höhe-
Geoidundulation) und die Geoidundulation selber
4)Dies wird von Glopus o.ä. ausgelesen und angezeigt/protokoliert

Der komplizierte Teil ist Schritt 2. Schritt 3 ist dagegen trivial, auch 
wenn Dein Polaris da versagt. Je nach gewünschter Genauigkeit werden bei 
Schritt 2 aber fast alle Geräte versagen. Also ist es doch sinnvoll eine 
Möglichkeit zu bieten dies zu korigieren. Dann stellt sich die Frage wie 
macht das der normale User. Entweder ermittelt es die Geoidundulation aus 
irgendeiner Datenbank und hat damit das richtige Ergebnis außer bei Deinem 
Gerät, oder er mittelt die Höhe für einen Ort mit bekannter Höhe und 
korigiert die Geoidundulation so, daß die richtige höhe rauskommt. Das würde 
sogar bei Deinem Gerät funktionieren.

>Naja, die Höhenfolien kann man für ganz Aachen sicherlich für ein paar
>Euros kaufen


Also beim LVA kostet der km^2 mit einem Raster von 5m 30EUR. Abgegeben wird 
es in 4km^2 großen Paketen, also pro Paket 120EUR.
s. 
es gibt das ganze auch mit einem 50m Raster, aber das ist ja fast so grob 
wie SRTM nur sind die Höheninfos wohl genauer. Topografische Karten sind 
billiger, aber eine vernünfztige Auswertung bekommt man damit nicht hin, 
dafür dürften die Linienabstände zu groß sein, oder wenn sie gut sind ist 
man ewig am Abzeichnen. Dann würde ich schon eher die 120EUR zahlen.

Dimitri


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Dimitri Junker]

Hallo,


>Sag mal ... vor dem Wochenende schon Wodka? :-)
>
>Die Dateienamen vernünftig benennen! "Aachen4.gpx" :)


Stimmt, da stand Dateien nicht Punkte, aber dann macht es auch keinen Sinn, 
denn was hat die Anzahl der Punkte mit dem Dateinamen zu tuen. Und die Logik 
des Namens ist, daß die Nummer sozusagen eine Versionsnummer ist. Und warum 
davor Aachen steht dürfte auch klar sein.

Gruß
Dimitri

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Tobias Wendorff]

Dimitri Junker schrieb:
>> Nicht alle GPS-Geräte liefern korrekte Geoid- und orthometrische Höhen
>> im NMEA-Tag
> 
> Ach, und deshalb gibt es die Einstellmöglichkeit,sonst wäre sie ja unnötig.

Du hast nicht verstanden, wie NMEA funktioniert. NMEA-Daten werden vom
GPS-Receiver an Glopus gesendet:

GGA,hhmmss.ss,.ll,a,y.yy,a,x,xx,x.x,x.x,M,x.x,M,x.x,*hh

Interessant für uns ist "x.x,M,x.x,M"

Das 1. x.x,M bedeutet: orthometrische Höhe in Metern
Das 2. x.x,M bedeutet: Geoidundulation in Metern

Das orthometrische Höhe wird intern bereits vom GPS-Gerät berechnet,
die Geoidundulation liegt bei den meisten GPS-Geräten in Deutschland
bei 47.5 m (was aber falsch ist).

Der GPS-Receiver sieht zunächst nur die ellipsoide Höhe, z.B. 120 m.
120 m - 47.5 m = 72.5 m - was dann in Dein 1. Feld eingetragen wird.

Glopus liest höchstwahrscheinlich diese 72.5 m aus und rechnet den
Eintrag aus dem 2. Feld wieder drauf, um wieder auf die ellipsoide
Höhe zu kommen. Anschließend zieht er Deinen Höhenausgleich wieder
ab, um dann auf die korrekte orthometrische Höhe zu kommen.



Wenn nun aber, wie bei meinem Polaris, das 1. Feld richtig berechnet
und ausgefüllt, das 2. Feld aber falsch ausgefüllt ist, baut er
Mist.

Mein Polaris zeigt:
1. Feld: 72.5 m
2. Feld: 25.0 m

Also hat beim Programmieren einer die Variablen vertauscht, denn
72.5 - 25.0 = 47.5 [m]

Wenn Glopus jetzt wieder rechnet geht das:
72.5 + 25.0 = 97.5 [m] - also eine komplett falsche, ellipsoide
Höhe.

Das stimmt natürlich nur, wenn es sich bei Glopus' Höhenausgleich
wirklich um die Geoidundulation und nicht um einen Faktor für die
orthometrische Höhe handelt. Du hast ja diese Vermutung angenommen.

> Den Vergleich mit den 3' SRTM-Daten habe ich gemacht, aber eben innerhalb 
> des Programms,also brauche ich dafür keine Exportfunktion, die Einzelwerte 
> werden auch nirgends zwischengespeichert. Was ich gerne hätte wäre ein 
> Vergleich mit besseren Daten,dafür habe ich die Exportfunktion geschrieben, 
> weil es Copyright-mäßig einfacher ist meine Daten an jemanden zu geben der 
> die guten Daten hat als umgekehrt.

Naja, die Höhenfolien kann man für ganz Aachen sicherlich für ein
paar Euros kaufen, abzeichnen und dann die Höhen dafür erstellen.
Ich habe für 16 km² letztes Mal 16 EUR bezahlt.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Tobias Wendorff]

Dimitri Junker schrieb:
> wo ist die versteckte Kamera? Soll ich jeden der hunderttausenden Punkte 
> Namen geben? Vieleicht einzeln abgehen und schauen ob da was markanntes ist? 
> Hast Du auch schonmal die NASA gebeten alle SRTM-Punkte zu benennen?

Sag mal ... vor dem Wochenende schon Wodka? :-)

Die Dateienamen vernünftig benennen! "Aachen4.gpx" :)

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Dimitri Junker]

Hallo,

>Ach Du meine Güte ... den Wert dort einstellen? Das wäre kompletter
>Irrsinn!


Wo denn sonst? Dafür ist die Einstellmöglichkeit ja da.

>Nicht alle GPS-Geräte liefern korrekte Geoid- und orthometrische Höhen
>im NMEA-Tag


Ach, und deshalb gibt es die Einstellmöglichkeit,sonst wäre sie ja unnötig.

>wie z.B. mein bradneuer Polaris. Die Höhen, die Glopus dann abspeichern
>würde, wären Müll.


Wenn Du den falschen Wert einstellt bekommst Du Müll, stellst Du den 
richtigen ein hoffentlich nicht.


>Aber laut dem Text war es doch das, was Du haben wolltest?


Den Vergleich mit den 3' SRTM-Daten habe ich gemacht, aber eben innerhalb 
des Programms,also brauche ich dafür keine Exportfunktion, die Einzelwerte 
werden auch nirgends zwischengespeichert. Was ich gerne hätte wäre ein 
Vergleich mit besseren Daten,dafür habe ich die Exportfunktion geschrieben, 
weil es Copyright-mäßig einfacher ist meine Daten an jemanden zu geben der 
die guten Daten hat als umgekehrt.

Gruß
Dimitri

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Dimitri Junker]

Hallo,

>In der Aachen4.gpx habe ich ein Raster mit mehreren tausend GPX-Punkten.
>
>Kannst Du die Dateien mal bitte vernünftig benennen? :-)

wo ist die versteckte Kamera? Soll ich jeden der hunderttausenden Punkte 
Namen geben? Vieleicht einzeln abgehen und schauen ob da was markanntes ist? 
Hast Du auch schonmal die NASA gebeten alle SRTM-Punkte zu benennen?

etwas verwirrt
Dimitri


___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Tobias Wendorff]

Dimitri Junker schrieb:
>> Aber wieso sind in Deiner GPX-Datei mit dem Höhenraster dann auch da
>> Höhenpunkte, wo kein Track war?
> 
> Wo? Sollte nicht, mit außnahme der besagten Interpolationen entlang des 
> Tracks und der jeweils 8 Nachbarpixel

In der Aachen4.gpx habe ich ein Raster mit mehreren tausend
GPX-Punkten.

Kannst Du die Dateien mal bitte vernünftig benennen? :-)

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Tobias Wendorff]

> das was Glopus so nennt:
> 

Ach Du meine Güte ... den Wert dort einstellen? Das wäre kompletter
Irrsinn!

Nicht alle GPS-Geräte liefern korrekte Geoid- und orthometrische
Höhen im NMEA-Tag, wie z.B. mein bradneuer Polaris. Die Höhen, die
Glopus dann abspeichern würde, wären Müll.

>> Hast Du denn auch eine Datei oder Tabelle, wo man die Abweichung der
>> SRTM-Daten zu den GPS-Daten sehen kann?
> 
> Nein, müßte ich noch programmieren.

Aber laut dem Text war es doch das, was Du haben wolltest?

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Dimitri Junker]

Hallo,


>Aber wieso sind in Deiner GPX-Datei mit dem Höhenraster dann auch da
>Höhenpunkte, wo kein Track war?


Wo? Sollte nicht, mit außnahme der besagten Interpolationen entlang des 
Tracks und der jeweils 8 Nachbarpixel

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Dimitri Junker]

Hallo,


>Was genau ist ein Höhenausgleich bei Dir? 

das was Glopus so nennt:


>Die Geoidundulation?
Ja das sollte es sein

>Hast Du denn auch eine Datei oder Tabelle, wo man die Abweichung der
>SRTM-Daten zu den GPS-Daten sehen kann?

Nein, müßte ich noch programmieren.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Tobias Wendorff]

Dimitri Junker schrieb:
> Natürlich ist es das, es sagt aus ob die Daten einen sytematischen Fehler 
> haben. Wenn ich z.B. GPS-Daten nehme die alle mit einem falsch eingestellten 
> Höhenausgleich ermittelt wurden wird sich dies im arithmetischen Mittel 
> zeigen.

Was genau ist ein Höhenausgleich bei Dir? Die Geoidundulation?

> Wenn sich die Aussage die ich aus dem Vergleich mit den SRTM-Daten gemacht 
> habe auch mit besseren Daten bestätigen würde hieße es, daß ich noch zu 
> wenig Daten benutze, aber eine Chance besteht mit mehr Daten ein gutes 
> Ergebnis zu erhalten. 

Hast Du denn auch eine Datei oder Tabelle, wo man die Abweichung der
SRTM-Daten zu den GPS-Daten sehen kann? Nenn' sie doch am besten
"height_error.gpx" damit, man sie wiedererkennt.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Tobias Wendorff]

Dimitri Junker schrieb:
> Genauer überall dort wo richtig oder falsch ein Punkt in einem Track ist.

Aber wieso sind in Deiner GPX-Datei mit dem Höhenraster dann auch da
Höhenpunkte, wo kein Track war?

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Dimitri Junker]

Hallo,

>Die Herleitung der Variablen habe ich noch nicht verstanden, aber das
>ist wohl das Geheimnis von Euch Statistikern :-)

Also die SRTM-Daten kommen ja als TIF-Bild, Du brauchst also x und y um eine 
Höhe zu bestimmen. Für diese Umrechnung steht im Header des TIF u.a. die 
Koordinaten der NW-Ecke (das was ich LON1,LAT1 genannt habe) und die größen 
der Pixel in Grad (das sind die FAKTX und FAKTY). Wenn ich hunderttausende 
Werte habe kann ich eine vernünftige Aussage zu deren Qualität nur mit 
Statistik machen. Leder war ich da schon ziemlich raus und mußte mich 
erstmal wieder einlesen.

>Wieso so umständlich mit Pixeln zu arbeiten? Du kannst doch einfach die
>SRTM-Daten in XYZ (LAT LON ELEV) umwandeln und jedem GPX-Punkt die
>genaue Höhe zuteilen.


Keine Ahnung ob Du die SRTM-Daten in einem anderen Format vorliegen hast. 
Aber egal wie Du sie hast, es sind immer Mittelwerte über ein Gebiet, dieses 
nenne ich Pixel weil es ja auch im TIF-Bild Pixel sind.


>Was auch gehen würde: Du verschneidest die GPX-Punktwolke einfach mit
>den SRTM-Daten und hast dann an jedem Punkt die SRTM-Daten. Das wäre
>vermutlich einfacher nachzuvollziehen.


Wenn ich mit den SRTM-Daten die Qualität der GPX-Daten bewerten will sollte 
ich da nicht schon SRTM-Daten mitverarbeiten.

>Was summierst Du worauf? x,y auf was?


Ich berechne zu jedem berechneten Punkt die Abweichung zwischen dieser aus 
den GPX-Daten berechneten Höhe und der SRTM-Höhe. AUs diesen bilde ich dann 
die verschiedenen Mittelwerte.


>Das sehe ich komplett anders. Das arithmetische Mittel ist in meinen
>Augen kein Indiz für irgendwas hier.


Natürlich ist es das, es sagt aus ob die Daten einen sytematischen Fehler 
haben. Wenn ich z.B. GPS-Daten nehme die alle mit einem falsch eingestellten 
Höhenausgleich ermittelt wurden wird sich dies im arithmetischen Mittel 
zeigen.

>Die Spannweite der Fehler lagen zwischen -20 und +20, der Durschnitt
>ergibt Null ... nutzlos.


s.o. Nachdem man also weiß ob man sich einen konstanten Fehler eingefangen 
hat ist die nächste Frage wie weit die Werte um diesen Durchschnitt streuen, 
dafür benutzt man den quadratischen Mittelwert, bei Deinem Bsp käme da 

sqrt((10^2+20^2+10^2+20^2)/4) =15.8 raus, das ist das was Du sehen willst. 
Aber diesen Wert bekommt man dadurch kleiner, daß man mehr Daten mittelt, 
wobei diese auch aus der gleichen ggf falsch kalibrierten Quelle kommen 
dürfen den anderen nicht, da hilft nur Daten von anderen Usern zu bekommen 
die ihr Gerät hoffentlich in die andere Richtung falsch kalibriert haben. 
Wenn sich die Aussage die ich aus dem Vergleich mit den SRTM-Daten gemacht 
habe auch mit besseren Daten bestätigen würde hieße es, daß ich noch zu 
wenig Daten benutze, aber eine Chance besteht mit mehr Daten ein gutes 
Ergebnis zu erhalten. Außerdem gibt es noch viele Methoden das Ergebnis zu 
verbessern. Z.B. ist ja bekannt, daß die ersten Trackpunkte nach einem Fix 
meist schlecht sind, man könnte sie also weglassen. Man kann auch ein 
Programm schreiben das erkennt wo eine Punktwolke erscheint die ja auch 
meist Müll ist, man kann vdop benutzen um den Fehler besser abschätzen zu 
können,... Aber all das würde sich nicht löhnen wenn bei den bisherigen 
Tests rauskäme, daß die Werte absolut daneben liegen. Auch ist es wichtig zu 
den berechneten Werten eine Angabe zur Genauigkeit zu machen, dann kann der 
User z.B. entscheiden ob er diesen Wert nimmt oder den von SRTM,...

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Dimitri Junker]

Hallo,

>Vermutlich ist bei Dir Glopus so konfiguriert, dass nicht alle
>Protokolle geschrieben werden. Insbesondere scheint die Protokollierung
>von GGA und RMC (UTC-Zeit)und GSA (vdop und pdop) bei Dir deaktiviert zu
>sein. Innerhalb von Glopus kann man auf der Seite "Einstellungen
>Datenquelle" die benötigten Protokolle anklicken (nur bei SAT-Fix!!!)


Das muß der Teil da unten sein wo ich noch nie verstanden habe was das soll, 
aber da habe ich gestern alles aktiviert, aber wohl vor dem Test ;-). Damit 
funktioniert es jetzt also über die TXT-Datei. Danke. Tja hätte Peter auch 
drauf kommen können;-)

Gruß
Dimitri




___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Dimitri Junker]

Hallo,

>Sind das denn die, die Du zur Berechnung der Punktematrix verwendet hast?



>Du kannst eigentlich nur dort Höhen berechnen und somit Punkte anzeigen,
>wo auch Straßen waren


Genauer überall dort wo richtig oder falsch ein Punkt in einem Track ist.

>also auch nur dort die Dreiecke bilden, z.B. zwischen zwei Straßen.

Was für Dreiecke?

>Es ist mir häufig aufgefallen, dass Du auch Punkte und Höhen gebildet
>hast, wo Dir nur SRTM-Daten zugrunde lagen.


In dem Dir vorliegenden File sind keine SRTM-Daten eingegangen. Nur die 
Punkte aus den GPX-Files, ihre 8 Nachbarn und Interpolation zwischen 2 
aufeinanderfolgenden Trackpunkten.

Dimitri



___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Gerd Steinburger]

Dimitri Junker schrieb:
> 
> also genau das was ich will, wenn ich das gleiche mit den GLOPUS-TXT Files 
> mache meckert GPS-Babel zuerst einmal:
> nmea: No date found within track (all points dropped)!
> nmea: Please use option "date" to preset a valid date for thoose tracks.
> Also habe ich das Datum eingetragen, dann funktionierte es zwar, aber:
> 
> 
>   164.50
> 2009-01-26T15:59:09.000Z
>   3d
>   8
>   1.00
> 
> 
> also ohne ,

Vermutlich ist bei Dir Glopus so konfiguriert, dass nicht alle Protokolle
geschrieben werden. Insbesondere scheint die Protokollierung von GGA
und RMC (UTC-Zeit)und GSA (vdop und pdop) bei Dir deaktiviert zu sein.
Innerhalb von Glopus kann man auf der Seite "Einstellungen Datenquelle"
die benötigten Protokolle anklicken (nur bei SAT-Fix!!!)

> 
> Außerdem hatte ich ja den Autor gefragt ob er VDOP ins GPX schreiben könne, 
> was er aber nicht wollte, wenn es so einfach wäre hätte er mir das doch 
> hoffentlich gesagt oder?

Im Forum von Pocketnavigation.de kann man verfolgen wie emsig sich Peter
Kirst mit der Weiterentwicklung von Glopus beschäftigt. Auch dort werden
ständig Features-Wünsche geäußert und wenn es mehrere User wünschen auch
realisiert. Es kamen sogar schon Beschwerden, dass zu viele Neuerungen
eingebaut wurden, die nur von wenigen benötigt werden und den anderen
nur die Übersichtlichkeit nimmt.

Gruß

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Tobias Wendorff]

Dimitri Junker schrieb:
> Also beim Vergleich mit den SRTM Daten habe ich es so gemacht: ich habe von 
> den Koordinaten gerechnet in welches SRTM-Pixel es fällt und dann dessen 
> Höhe als Vergleich genommen:
> x=(lon-LON1)/FAKTX+.5;
> y=(lat-LAT1)/FAKTY+.5;

Die Herleitung der Variablen habe ich noch nicht verstanden, aber das
ist wohl das Geheimnis von Euch Statistikern :-)

Wieso so umständlich mit Pixeln zu arbeiten? Du kannst doch einfach die
SRTM-Daten in XYZ (LAT LON ELEV) umwandeln und jedem GPX-Punkt die
genaue Höhe zuteilen.

Was auch gehen würde: Du verschneidest die GPX-Punktwolke einfach mit
den SRTM-Daten und hast dann an jedem Punkt die SRTM-Daten. Das wäre
vermutlich einfacher nachzuvollziehen.

> Dann kann man das ganz einfach aufsummieren.

Was summierst Du worauf? x,y auf was?

> Das da einzelne Punkte schlecht und andere gut sind ist klar. Die Frage ist 
> wie sieht es im Durchschnitt aus.

Das sehe ich komplett anders. Das arithmetische Mittel ist in meinen
Augen kein Indiz für irgendwas hier. Gewichtet vielleicht noch, aber
hier ein Beispiel:

x;y;z;fehler
1;1;30;+10
1;2;50;-20
2;1;-12;-10
2;2;-100;+20
Arithmetisches Mittel: 0

Die Spannweite der Fehler lagen zwischen -20 und +20, der Durschnitt
ergibt Null ... nutzlos.

> Um in der Höhe besser zu werden als SRTM
> braucht man wohl schon einige Mexwerte für den gleichen Pixel, der 
> Hauptvorteil der GPS-Daten ist die höhere 2D-Auflösung.

Es ist ja in Aachen sicher häufiger vorgekommen, dass die Leute
über ein und denselben Weg gefahren sind. Wäre es nicht sinnvoll,
diesen Weg erstmal genauer anzugucken, als ganz Aachen?

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Tobias Wendorff]

Dimitri Junker schrieb:
>> Ich müsste mal die GPS-Tracks, die Du verwendet hast dazu laden :-)
> 
> 
> Hab ich gerade hochgeladen:
> 

Sind das denn die, die Du zur Berechnung der Punktematrix
verwendet hast?

Du kannst eigentlich nur dort Höhen berechnen und somit Punkte
anzeigen, wo auch Straßen waren - also auch nur dort die
Dreiecke bilden, z.B. zwischen zwei Straßen.

Es ist mir häufig aufgefallen, dass Du auch Punkte und Höhen
gebildet hast, wo Dir nur SRTM-Daten zugrunde lagen. Sinvoll
wäre zur Analyse zunächst, diese Punkte wegzulassen.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Dimitri Junker]

Hallo,

>Ich müsste mal die GPS-Tracks, die Du verwendet hast dazu laden :-)


Hab ich gerade hochgeladen:


Gruß
Dimitri

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Dimitri Junker]

Hallo,

>Glopus schreibt den Datenstrom vom GPS-Empfänger im NMEA-Format in eine
>txt-Datei zu finden im Verzeichnis, dass auf "Einstellungen Datenquelle"
>gewählt ist. Konvertieren kann man die NMEA-Datei dann mit den üblichen
>Verdächtigen.


Bist Du da sicher? Kurz bevor ich dies gelesen hatte habe ich diesen Weg 
nämlich mit OSMTracker versucht, also NMEA-Log-Datei per GPS-Babel nach GPX 
konvertiert, dabei kam so etwas raus:

  191.60
2009-03-10T21:05:16Z
  328.459991
  0.216067
  2d
  3
  4.40
  1.00
  4.50


also genau das was ich will, wenn ich das gleiche mit den GLOPUS-TXT Files 
mache meckert GPS-Babel zuerst einmal:
nmea: No date found within track (all points dropped)!
nmea: Please use option "date" to preset a valid date for thoose tracks.
Also habe ich das Datum eingetragen, dann funktionierte es zwar, aber:


  164.50
2009-01-26T15:59:09.000Z
  3d
  8
  1.00


also ohne ,

Außerdem hatte ich ja den Autor gefragt ob er VDOP ins GPX schreiben könne, 
was er aber nicht wollte, wenn es so einfach wäre hätte er mir das doch 
hoffentlich gesagt oder?
Egal, mit OSM-Tracker funktioniert es ja.

Gruß
Dimitri

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Dimitri Junker]

Hallo,


>Durchschnittlich sicherlich nicht, aber so einfach kann man das leider
>nicht durchführen, da die Daten mir nur als Raster vorliegen.


Also beim Vergleich mit den SRTM Daten habe ich es so gemacht: ich habe von 
den Koordinaten gerechnet in welches SRTM-Pixel es fällt und dann dessen 
Höhe als Vergleich genommen:
x=(lon-LON1)/FAKTX+.5;
y=(lat-LAT1)/FAKTY+.5;

mit LAT1,LON1 aus dem ModelTiepointTag und FAKTX,FAKTY aus 
dem ModelPixelScaleTag

Dann kann man das ganz einfach aufsummieren.

Das da einzelne Punkte schlecht und andere gut sind ist klar. Die Frage ist 
wie sieht es im Durchschnitt aus. Im Endeffekt wird man sicher GPS-und SRTM-
Daten kombinieren, SRTM einerseits für die Lücken und ggf um Ausreißer zu 
erkennen und zu auszufiltern. Um in der Höhe besser zu werden als SRTM 
braucht man wohl schon einige Mexwerte für den gleichen Pixel, der 
Hauptvorteil der GPS-Daten ist die höhere 2D-Auflösung.

Gruß
Dimitri

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Gerd Steinburger]

Dimitri Junker schrieb:
> Hallo,
> 
> Ich würde gerne etwas Statistik nachen, (Abhängigkeiten von hdop,vdop, sat 
> und den Meßfehlern) leider schreibt Glopus nur  und  nicht aber 
>  ins gpx. OSMTracker schreibt keines der 3 rein. Kennt jemand ein 
> möglichst kostenloses Programm welches alle 3 protokoliert? Für Windows 
> Mobile6

Wie wärs mit Glopus?
Glopus schreibt den Datenstrom vom GPS-Empfänger im NMEA-Format in eine 
txt-Datei zu finden im Verzeichnis, dass auf "Einstellungen Datenquelle" 
gewählt ist.
Konvertieren kann man die NMEA-Datei dann mit den üblichen Verdächtigen.

Gruß

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich mit SRTM

[Markus]

Hallo Dimitri,

ich freue mich von Euren Tests und den Ergebnissen zu lesen!

> von meinem Garten kenne ich die genaue Höhe z.B. nicht. 

Einfach den nächstgelegenen Höhenmessbolzen suchen:
http://wiki.openstreetmap.org/wiki/de:Altitude
Bei der Gemeinde nach der genauen Höhe fragen.
Dann vom Höhenmessbolzen mit einem barometrischen Höhenmesser
die Höhendifferenz zum Garten messen.
Und schon hast Du die genaue Höhe von Deinem Garten...

Nun kannst Du Dein GPS jederzeit kalibrieren.

Gruss, Markus

PS: Umrechnung GK --> WGS-84 nicht vergessen!
(dafür wollte Tobias ein Umrechnungstool schreiben)

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Tobias Wendorff]

Dimitri Junker schrieb:
> Derzeit aktuell ist dort Aachen4.zip ohne Extrapolation. Wenn Du was anderes 
> haben möchtest sag es mir. Mein Programm ist da recht flexibel, ich kann 
> z.B. neben den GPX-Files auch SRTM-Daten einfügen, entweder am Anfang oder 
> am Ende, das macht einen Unterschied weil ich natürlich keine Löcher habe 
> wenn ich es am Anfang einfüge -> keine Extrapolation.
> In Zukunft könnte ich ja in das zip auch ein Readme einfügen wo ich 
> beschreibe welche Daten es sind.
> 
> Hier findest Du die Daten: 

Ich habe jetzt mal die Aachen4 auch trianguliert und sie mit der
DGK5 verglichen. Die Tendenz ist teilweise richtig, mal 10 Meter,
mal 20 Meter daneben. Böschungen & Co. sind gar nicht sichtbar.

Manchmal geht's hoch, wo es eigentlich runter geht. Dort können
vielleicht GPS-Daten gefehlt haben. Ich müsste mal die GPS-Tracks,
die Du verwendet hast dazu laden :-)

Kannst Du mir die mal schicken?

>> Die Ergebnisse dürfen dann aber nicht über OSM rausgehen, weil mir die
>> Daten nur zur Forschung zur Verfügung stehen.
> 
> Eine Aussage wie die Daten weichen durchschnittlich um ...m von den Daten 
> der LVermA ab sollte die Copyrightbestimmungen nicht verletzen oder? 

Durchschnittlich sicherlich nicht, aber so einfach kann man das leider
nicht durchführen, da die Daten mir nur als Raster vorliegen.

Also Handarbeit oder Stichproben.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich mit SRTM

[Tobias Wendorff]

Dimitri Junker schrieb:
> Bisher habe ich die Ergebnisse ja nur mit den SRTM-Daten verglichen, sie 
> werden aber bald auch mit genaueren Höheninfos (DGM5) überprüft. Die 
> bisherigen Ergebnisse sagen aus, daß wenn man GPS-Tracks verschiedener 
> Quellen aufsumiert man eine brauchbare Höhenkarte erstellen kann, zumindest 
> für ein Gelände wie um Aachen. In den Bergen mit Steilwänden wird es 
> natürlich schwerer. Nimmt man nur die eigenen Daten macht sich natürlich 
> eine falsche Kalibration (Höhenkorektur) bemerkbar.

Wie gesagt ist ja eh das Wichtigste, dass Du erst alles auf den
Ellipsoiden "runtergerechnet" und dann auf einen einheitlichen
Geoiden wieder "hochgerechnet" hast, da Du sonst die Werte mit
nichts vergleichen kannst.

>> Kann ich mit meinem GPS-Gerät jetzt korrekte Höhen messen?
> 
> 
> Eine einzelne Messung ist nie korrekt, aber wenn Du häufiger die gleiche 
> Strecke aufnimmst und die Daten mittelst sollte es klappen. Vorausgesetzt Du 
> hast die Höhenkorektur richtig eingestellt.

Höhenkorrektur einstellen? Reden wir vom selben Thema? Mein GPS hat
keine Korrektur, sondern wirft ortho. Höhe und Geoidhöhe aus.

 > Das Problem ist natürlich, daß ich an solchen Orten mein Gerät
> nicht lange liegen lassen möchte ;-) Und von meinem Garten kenne ich die 
> genaue Höhe z.B. nicht.

Seit 2 Wochen liegt ein Trimble-GPS-Gerät am gleichen Punkt. Referenz-
Höhe und Koordinaten bekannt. Wollte Dir die Werte zukommen lassen.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich mit SRTM

[Dimitri Junker]

Hallo,

Bisher habe ich die Ergebnisse ja nur mit den SRTM-Daten verglichen, sie 
werden aber bald auch mit genaueren Höheninfos (DGM5) überprüft. Die 
bisherigen Ergebnisse sagen aus, daß wenn man GPS-Tracks verschiedener 
Quellen aufsumiert man eine brauchbare Höhenkarte erstellen kann, zumindest 
für ein Gelände wie um Aachen. In den Bergen mit Steilwänden wird es 
natürlich schwerer. Nimmt man nur die eigenen Daten macht sich natürlich 
eine falsche Kalibration (Höhenkorektur) bemerkbar.

>Kann ich mit meinem GPS-Gerät jetzt korrekte Höhen messen?


Eine einzelne Messung ist nie korrekt, aber wenn Du häufiger die gleiche 
Strecke aufnimmst und die Daten mittelst sollte es klappen. Vorausgesetzt Du 
hast die Höhenkorektur richtig eingestellt. Die sicherste Methode dies zu 
machen ist wahrscheinlich das GPS-Gerät an einem Ort mit bekannter Höhe 
lange liegen zu lassen, die Höhen mitteln und die Differenz zur 'richtigen' 
Höhe bilden. Das Problem ist natürlich, daß ich an solchen Orten mein Gerät 
nicht lange liegen lassen möchte ;-) Und von meinem Garten kenne ich die 
genaue Höhe z.B. nicht. Eine alternative Kalibrierungsmöglichkeit wäre die 
Daten mit Hilfe von SRTM zu kalibrieren. Nachteil hier der systematische 
Fehler von SRTM weil es nicht die Bodenhöhe sondern ggf Dächer und 
Baumwipfel mißt. Hier wäre dann die Frage wie genau man die Werte braucht. 
Mal eine Abschätzung für den bearbeiteten Bereich um Aachen: Bebauung bzw 
Bewaldung von 50%, durchschnittliche Gebäudehöhe 4 Etagen = etwa 15m, das 
dürfte auch als baumhöhe passen. -> SRTM liefert etwa 5-10m zu große Höhen. 
Das sollte für die meisten Anwendungen genau genug sein, und wenn man dann 
noch z.B. von SRTM 8m abzieht sollte es noch genauer passen. 

Gruß
Dimitri

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Dimitri Junker]

Hallo,


>Wenn Du Deine Berechnungen mir offen lest (per Mail oder so), kann ich
>das z.B. über SRTM-1 Kacheln oder die LVermA Sachen rüber laufen lassen.


Wie gasagt will es schon jemand mit DGM5 Daten prüfen. Aber wenn Du willst 
kannst Du es natürlich auch machen. Ich lege ab und zu die aktuellen 
Ergebnisse auf meiner HP ab, derzeit als GPX-File mit dem Zusatz-Tag  
für den berechneten Fehler der Höhe. Wenn das zip-File etwa 8MB groß ist 
enthält es alle 1024*1024 Pixel, also incl. der gefüllten Löcher zwischen 
den Tracks, ist es etwa 1MB groß sind nur die Bereiche der Tracks drin. 
Derzeit aktuell ist dort Aachen4.zip ohne Extrapolation. Wenn Du was anderes 
haben möchtest sag es mir. Mein Programm ist da recht flexibel, ich kann 
z.B. neben den GPX-Files auch SRTM-Daten einfügen, entweder am Anfang oder 
am Ende, das macht einen Unterschied weil ich natürlich keine Löcher habe 
wenn ich es am Anfang einfüge -> keine Extrapolation.
In Zukunft könnte ich ja in das zip auch ein Readme einfügen wo ich 
beschreibe welche Daten es sind.

Hier findest Du die Daten: 


>Die Ergebnisse dürfen dann aber nicht über OSM rausgehen, weil mir die
>Daten nur zur Forschung zur Verfügung stehen.

Eine Aussage wie die Daten weichen durchschnittlich um ...m von den Daten 
der LVermA ab sollte die Copyrightbestimmungen nicht verletzen oder? 

Gruß
Dimitri

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Tobias Wendorff]

Dimitri Junker schrieb:
> Und? SRTM ist die beste mir bekannte Quelle um meine Daten zu prüfen. Wir 
> kennen alle deren Nachteile. Nehmen wir an, die SRTM-Daten liefern für das 
> berechnete Gebiet im Durchschnitt eine um 5m zu große Höhe (Häuser/Bäume). 
> Dann erhöht sich der Fehler entsprechend. Damit sind wir aber immer noch 
> weit entfernt von den vor kurzem hier raufgeschworenen Fehlern, und das mit 
> relativ wenig Daten die zum größten Teil aus Altbeständen bestehen von denen 
> nicht bekannt ist wie die Geräte kalibriert (Höhenkorektur,...) waren.

Wenn Du Deine Berechnungen mir offen lest (per Mail oder so), kann ich
das z.B. über SRTM-1 Kacheln oder die LVermA Sachen rüber laufen lassen.
Die Ergebnisse dürfen dann aber nicht über OSM rausgehen, weil mir die
Daten nur zur Forschung zur Verfügung stehen.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Tobias Wendorff]

Johannes Huesing schrieb:
> aber wegen wechselnder Höhe der Bäume und Häuser doch stark schwankend.
> Das ist schon eine Einschränkung der Messgenauigkeit in beiden Fällen.

Das würde sich aber nur bei SRTM-1 richtig bemerkbar machen. Bei
SRTM-3 ist alles zu stark zusammengefasst.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Tobias Wendorff]

Dimitri Junker schrieb:
> Ich würde gerne etwas Statistik nachen, (Abhängigkeiten von hdop,vdop, sat 
> und den Meßfehlern) leider schreibt Glopus nur  und  nicht aber 
>  ins gpx. OSMTracker schreibt keines der 3 rein. Kennt jemand ein 
> möglichst kostenloses Programm welches alle 3 protokoliert? Für Windows 
> Mobile6

Ich logge immer NMEA. XML hat teilweise soviel Overhead, dass es auf's
gleiche rauskommt - aber man ist "nachher" hundertmal flexibler, gerade
wenn man Dinge auswerten will.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Dimitri Junker]

Hallo,

Ich würde gerne etwas Statistik nachen, (Abhängigkeiten von hdop,vdop, sat 
und den Meßfehlern) leider schreibt Glopus nur  und  nicht aber 
 ins gpx. OSMTracker schreibt keines der 3 rein. Kennt jemand ein 
möglichst kostenloses Programm welches alle 3 protokoliert? Für Windows 
Mobile6

Gruß Dimitri

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ??mit SRTM

[Johannes Huesing]

Dimitri Junker  [Tue, Mar 10, 2009 at 02:09:44AM CET]:
[...]
> 
> >und mit nicht UTF8-Zeichen rum ...
> 
> 
> in welchem Tag?
> 

Also jetzt habe ich ihn händisch korrigiert, frag mich nicht,
war irgend eine Straße, die Emacs mit Oktal \223 anzeigte.

-- 
Johannes Hüsing   There is something fascinating about science. 
  One gets such wholesale returns of conjecture 
mailto:johan...@huesing.name  from such a trifling investment of fact.  
  
http://derwisch.wikidot.com (Mark Twain, "Life on the Mississippi")

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Dimitri Junker]

Hallo,

>Hm, und ich bin noch dabei, die Daten einzulesen, und ärgermich mit
>Tracks ohne ele-Information


Hallo, ich setze vorher ele auf DBL_MAX und wenn es nachher immer noch so 
ist schmeiß ich den Punkt weg.

>und mit nicht UTF8-Zeichen rum ...


in welchem Tag?

Gruß
Dimitri

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Johannes Huesing]

Dimitri Junker  [Mon, Mar 09, 2009 at 04:54:56PM CET]:
> Hallo,
> 
> hat etwas gedauert bis ich bemerkte, daß in Deiner Aussage:
> >Wenn die Standardabweichung gemeint ist, kannst Du davon ausgehen, dass
> >die 21 m sich nach der Fehleraddition durch 21^2 = 15^2 + x^2 ergeben
> >können,
> 
> 
> die Lösung steckte. Bei der Berechnung der durchschnittlichen Fehlerbreite:
> >FehlerBreite=abw/berechneterFehler
> 
> habe ich jetzt den SRTM-Fehler mit 25m hinzuaddiert, also
> FehlerBreite=abw/(berechneterFehler+25)
> 
> und das für alle Pixel qaudratisch gemittelt. Und dann kommen schöne Werte 
> raus: nämlich 0.58 bzw 0.72 (ohne/mit Extrapolation in die Löcher). Das ist 
> glaube ich akzeptabel

Hm, und ich bin noch dabei, die Daten einzulesen, und ärgermich mit
Tracks ohne ele-Information und mit nicht UTF8-Zeichen rum ...

-- 
Johannes Hüsing   There is something fascinating about science. 
  One gets such wholesale returns of conjecture 
mailto:johan...@huesing.name  from such a trifling investment of fact.  
  
http://derwisch.wikidot.com (Mark Twain, "Life on the Mississippi")

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich mit SRTM

[Dimitri Junker]

Hallo,

hat etwas gedauert bis ich bemerkte, daß in Deiner Aussage:
>Wenn die Standardabweichung gemeint ist, kannst Du davon ausgehen, dass
>die 21 m sich nach der Fehleraddition durch 21^2 = 15^2 + x^2 ergeben
>können,


die Lösung steckte. Bei der Berechnung der durchschnittlichen Fehlerbreite:
>FehlerBreite=abw/berechneterFehler

habe ich jetzt den SRTM-Fehler mit 25m hinzuaddiert, also
FehlerBreite=abw/(berechneterFehler+25)

und das für alle Pixel qaudratisch gemittelt. Und dann kommen schöne Werte 
raus: nämlich 0.58 bzw 0.72 (ohne/mit Extrapolation in die Löcher). Das ist 
glaube ich akzeptabel

>Möglicherweise sind die beiden Messfehler auch positiv assoziiert:
>Häuserschluchten und Wälder schränken die Messgenauigkeit für beide
>Verfahren ein.


Ja aber ggf etwas anders als Du meintest. Die Tracks verlaufen normalerweise 
unter freiem Himmel, sonst hätte das GPS nicht funktioniert. Hier sollten 
GPS und SRTM also die gleiche Höhe liefern. Was wegen der geringen Auflösung 
von SRTM natürlich nicht ganz stimmt. In den Gebieten zwischen den Tracks 
dürfte der Anteil Bebauung und Bäume aber im Durchschnitt höher sein. Dies 
könnte ggf. erklären warum der systematische Fehler bei den Werten mit/ohne 
Extrapolation unterschiedlich ist.

Gruß
Dimitri

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich mit SRTM

[Dimitri Junker]

Hallo,

habe noch einen kleinen Bug bei dem Vergleich mit SRTM gefunden:
>FehlerBreite=abw/berechneterFehler
Zum Mitteln sollte man hier natürlich das quadratische Mittel nehmen.

Damit werden die Breiten dann nicht mehr 0.61(vor dem Füllen von Löchern) 
bzw 0.055 (nach dem Füllen) sondern 4.5 und 7.1 Die ausgegebenen Fehler 
wären also um diesen Faktor zu klein. Aber bevor ich jetzt die 
angenommenen Fehler der Einzelmessung raufsetze warte ich erstmal den 
Vergleich mit besseren Daten als SRTM ab. So lange alle Fehler um den 
gleichen Faktor raufgesetzt werden würde dies sowieso nichts am Ergebnis 
ändern. Wichtig wird das erst wenn man bei verschiedenen Meßpunkten 
verschiedene Fehler annimmt, z.B. in Abhängigkeit von , , der Art 
des Gps-Gerätes,... Die Hauptaussage, daß die Abweichung zu SRTM 1-6m 
(Mittel) bzw 21m (quadratisches Mittel) beträgt bleibt davon unberücksichtigt

Gruß
Dimitri

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Dimitri Junker]

>Ein kleines Sigma eben. Das steht im allgemeinen für die
>Standardabweichung, die bei Deinen Überlegungen ja auch eine Rolle
>spielt.


Ok, aber da anz in der Größenordnung 10-1Million ist konnte es nur Sigma 
sein.


>aber wegen wechselnder Höhe der Bäume und Häuser doch stark schwankend.
>Das ist schon eine Einschränkung der Messgenauigkeit in beiden Fällen.


Und? SRTM ist die beste mir bekannte Quelle um meine Daten zu prüfen. Wir 
kennen alle deren Nachteile. Nehmen wir an, die SRTM-Daten liefern für das 
berechnete Gebiet im Durchschnitt eine um 5m zu große Höhe (Häuser/Bäume). 
Dann erhöht sich der Fehler entsprechend. Damit sind wir aber immer noch 
weit entfernt von den vor kurzem hier raufgeschworenen Fehlern, und das mit 
relativ wenig Daten die zum größten Teil aus Altbeständen bestehen von denen 
nicht bekannt ist wie die Geräte kalibriert (Höhenkorektur,...) waren.

>Genau, wenn ich die Höhenangabe auf Fuß stelle, kann ich meine
>Kniebeugen ablesen.


Wieso kann Dein Gerät/Software keine Nachkommastellen? Glopus liefert 5 
Nachkommastellen, damit kann ich erkennen ob ich auf einem Blatt Papier 
stehe. ;-)

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich ?mit SRTM

[Johannes Huesing]

Dimitri Junker  [Sun, Mar 08, 2009 at 06:06:14PM CET]:
> Hallo,
> 
> 
> >Oder soll das ein großes Sigma = Summenzeichen sein?
> 
> 
> Ja was denn sonst?
> 

Ein kleines Sigma eben. Das steht im allgemeinen für die Standardabweichung,
die bei Deinen Überlegungen ja auch eine Rolle spielt.

> 
> >Demnach tun sich die beiden Fehler nichts,
> 
> 
> Ganz meine Aussage.
> 
> >Möglicherweise sind die beiden Messfehler auch positiv assoziiert:
> >Häuserschluchten und Wälder schränken die Messgenauigkeit für beide
> >Verfahren ein.
> 
> 
> Nö, bei SRTM ergeben sie einen systematischen Fehler weil die Oberkannte der 
> Häuser/Bäume gemessen wird, 

aber wegen wechselnder Höhe der Bäume und Häuser doch stark schwankend.
Das ist schon eine Einschränkung der Messgenauigkeit in beiden Fällen.

> bei GPS ergeben sie 'nur' einen größeren 
> statistischen Fehler ohne Vorzugsrichtung. Ein entsprechender systematischer 
> Fehler der GPS-Messungen ist die Höhe des Gps-Empfängers über dem Boden ;-) 
> 

Genau, wenn ich die Höhenangabe auf Fuß stelle, kann ich meine Kniebeugen 
ablesen.


-- 
Johannes Hüsing   There is something fascinating about science. 
  One gets such wholesale returns of conjecture 
mailto:johan...@huesing.name  from such a trifling investment of fact.  
  
http://derwisch.wikidot.com (Mark Twain, "Life on the Mississippi")

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich mit SRTM

[Dimitri Junker]

Hallo,


>Oder soll das ein großes Sigma = Summenzeichen sein?


Ja was denn sonst?


>Demnach tun sich die beiden Fehler nichts,


Ganz meine Aussage.

>Möglicherweise sind die beiden Messfehler auch positiv assoziiert:
>Häuserschluchten und Wälder schränken die Messgenauigkeit für beide
>Verfahren ein.


Nö, bei SRTM ergeben sie einen systematischen Fehler weil die Oberkannte der 
Häuser/Bäume gemessen wird, bei GPS ergeben sie 'nur' einen größeren 
statistischen Fehler ohne Vorzugsrichtung. Ein entsprechender systematischer 
Fehler der GPS-Messungen ist die Höhe des Gps-Empfängers über dem Boden ;-) 

Dimitri

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich mit SRTM

[Johannes Huesing]

Dimitri Junker  [Sun, Mar 08, 2009 at 02:47:28PM CET]:
> PS
> 
> die genannten Abweichungen zwischen meinen aus GPS-Meßwerten und SRTM-Werten 
> von 5.68 bzw 0.93m sind ja
> sigma(gpsHöhe-srtmHöhe)/anz
> sie sagen also nur aus, ob es einen systematischen Fehler gibt, hier also, 
> daß die ausgegebenen Höhen z.B. im Duchschnitt 5.68m zu hoch sind. 

Ich kann nicht genau nachvollziehen, was Du da gemacht hast,
aber eine Formel zu einem systematischen Fehler sollte nicht
mit anz -> oo gegen Null gehen. Wenn ein systematischer Fehler
drin ist, hilft viel messen nur bis zu einem bestimmten Punkt.

Oder soll das ein großes Sigma = Summenzeichen sein?

> Interessant ist aber auch:
> sigma( abs(gpsHöhe-srtmHöhe) )/anz
> 
> Also wie weit die Werte im duchschnitt absolut von den SRTM-Daten abweichen, 
> es sind 13 bzw 14m. Bedenkt man, daß die SRTM-Daten einen Fehler von 15m 
> haben sollen, wäre dies vereinbar mit der Aussage, die GPS-Werte sind 
> genauer als die SRTM-Daten und lassen sich deshalb nicht mehr wirklich über 
> diese bewerten.
> 
> sqrt(sigma( (gpsHöhe-srtmHöhe)^2 )/anz)
> kommt etwa 21m raus.

Tja, was bezeichnet denn den "Fehler" bei SRTM? 

Wenn die Standardabweichung gemeint ist, kannst Du davon ausgehen, dass
die 21 m sich nach der Fehleraddition durch 21^2 = 15^2 + x^2 ergeben
können, wobei x dann die Standardabweichung für GPS wäre. Demnach tun
sich die beiden Fehler nichts, mit x=15 kommt man etwa auf das richtige
Ergebnis.

Möglicherweise sind die beiden Messfehler auch positiv assoziiert: 
Häuserschluchten und Wälder schränken die Messgenauigkeit für beide 
Verfahren ein. 

-- 
Johannes Hüsing   There is something fascinating about science. 
  One gets such wholesale returns of conjecture 
mailto:johan...@huesing.name  from such a trifling investment of fact.  
  
http://derwisch.wikidot.com (Mark Twain, "Life on the Mississippi")

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Höhennetz/Höhendatenbank Vergleich mit SRTM

[Dimitri Junker]

PS

die genannten Abweichungen zwischen meinen aus GPS-Meßwerten und SRTM-Werten 
von 5.68 bzw 0.93m sind ja
sigma(gpsHöhe-srtmHöhe)/anz
sie sagen also nur aus, ob es einen systematischen Fehler gibt, hier also, 
daß die ausgegebenen Höhen z.B. im Duchschnitt 5.68m zu hoch sind. 
Interessant ist aber auch:
sigma( abs(gpsHöhe-srtmHöhe) )/anz

Also wie weit die Werte im duchschnitt absolut von den SRTM-Daten abweichen, 
es sind 13 bzw 14m. Bedenkt man, daß die SRTM-Daten einen Fehler von 15m 
haben sollen, wäre dies vereinbar mit der Aussage, die GPS-Werte sind 
genauer als die SRTM-Daten und lassen sich deshalb nicht mehr wirklich über 
diese bewerten.
bei

sqrt(sigma( (gpsHöhe-srtmHöhe)^2 )/anz)
kommt etwa 21m raus.

Fazit das Verfahren scheint zu funktionieren, es sei denn ich hätte Bugs 
drin die sich zufällig gegenseitig aufheben.
Dimitri

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de