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
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
http://heiko-jacobs.de/kkisbin/trafo.tcl
gegangen und habe die Daten konvertiert. Als Quellformat habe ich
2: Gauß-Krüger Nr.2/6 Grad (West-D)
und
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? :-)
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:
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
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
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
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ß
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
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.
trkpt lat=50.764722
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
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
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
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
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
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
Hallo,
Was genau ist ein Höhenausgleich bei Dir?
das was Glopus so nennt:
http://www.glopus.de/heightview.htm
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
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
das was Glopus so nennt:
http://www.glopus.de/heightview.htm
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
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
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
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
Hallo,
Ich müsste mal die GPS-Tracks, die Du verwendet hast dazu laden :-)
Hab ich gerade hochgeladen:
http://www.oche.de/~junker/OSM/gpx.zip
Gruß
Dimitri
___
Talk-de mailing list
Talk-de@openstreetmap.org
Dimitri Junker schrieb:
Ich müsste mal die GPS-Tracks, die Du verwendet hast dazu laden :-)
Hab ich gerade hochgeladen:
http://www.oche.de/~junker/OSM/gpx.zip
Sind das denn die, die Du zur Berechnung der Punktematrix
verwendet hast?
Du kannst eigentlich nur dort Höhen berechnen und somit
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
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
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
Hallo,
Ich würde gerne etwas Statistik nachen, (Abhängigkeiten von hdop,vdop, sat
und den Meßfehlern) leider schreibt Glopus nur hdop und sat nicht aber
vdop ins gpx. OSMTracker schreibt keines der 3 rein. Kennt jemand ein
möglichst kostenloses Programm welches alle 3 protokoliert? Für Windows
Dimitri Junker schrieb:
Ich würde gerne etwas Statistik nachen, (Abhängigkeiten von hdop,vdop, sat
und den Meßfehlern) leider schreibt Glopus nur hdop und sat nicht aber
vdop ins gpx. OSMTracker schreibt keines der 3 rein. Kennt jemand ein
möglichst kostenloses Programm welches alle 3
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.
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.
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
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,
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
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
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
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 hdop und sat nicht aber
vdop ins gpx. OSMTracker schreibt keines der 3 rein. Kennt jemand ein
möglichst kostenloses Programm welches
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
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
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
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:
Dimitri Junker o...@dimitri-junker.de [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
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
Dimitri Junker o...@dimitri-junker.de [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
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
Dimitri Junker o...@dimitri-junker.de [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,
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
Dimitri Junker o...@dimitri-junker.de [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
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
Hallo,
ich habe den größten Müll entsorgt und alles neu durchlaufen lassen. Auf
http://www.oche.de/~junker/OSM/
gibt es die neuen Bilder, zusätzlich zu denen vom letzten mal noch ein
hoehen2 (also ohne l am Ende) in dem wie in pfadex die Höhe farbkodiert ist,
die Löcher aber schon aufgefüllt
Dimitri Junker schrieb:
Außerdem habe ich im letzten Augenblick noch einen bug gefunden der dazu
führte, daß die Nodes neben den Eckken falsch waren. Die habe ich einfach
aus dem gpx per Hand gelöscht. Für einen neuen Durchlauf hab ich jetzt keine
Zeit. Das gpx-File ist ungepackt über 80MB
Hallo,
Wo kann ich die aachen2.zip denn finden? Auf dem Server liegt nur eine
aachen.zip :-)
OK, dann hab ich eine '2' vergessen ;-)
Gruß
Dimitri
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Dimitri Junker schrieb:
Sag mir ein Datenformat und in welcher Stufe Du es haben willst, also vor
oder nach dem Auffüllen der Löcher. Reicht eine Liste der 1024*1024 Höhen
und die Koordinaten der Eckpunkte, oder willst Du zu jedem Punkt alle 3
Koordinaten?
Die letzte Stufe bitte. Da Du
Hallo,
Da Du Polylinien erzeugt hast, wäre DXF sinnvoll.
Nein hab ich nicht. Ich teile die Höhe aller Pixel durch den
Höhenlinienabstand, im Bsp 50m, dann schaue ich für jedes Pixel ob der
rechte oder untere Nachbar anders ist, wenn ja wird das Pixel gesetzt.
Ansonsten reicht natürlich auch
Dimitri Junker schrieb:
Auf http://www.oche.de/~junker/OSM/ könnt Ihr Euch aktuelle Screenshots
ansehen, einmal mit den Höhen entlang der Pfade, dabei ist die Höhe als
Rotton kodiert 0m=schwarz, 255m=rot. Das andere zeigt die Höhenlinien. Ich
weiß, da fehlen noch die Meterangaben.
Kannst
Hallo,
Ich kenne das einfacher,
Der Vorteil der komplizierteren Methode ist, daß ich eine Rückmeldung
bekomme ob die angenommenen Fehler richtig sind.
Gruß
Dimitri
___
Talk-de mailing list
Talk-de@openstreetmap.org
Hallo,
Kannst Du denn vielleicht nur einmal die Höhenlinen und/oder XYZ
Koordinaten zur Verfügung stellen?
Sag mir ein Datenformat und in welcher Stufe Du es haben willst, also vor
oder nach dem Auffüllen der Löcher. Reicht eine Liste der 1024*1024 Höhen
und die Koordinaten der Eckpunkte,
Am 02.03.2009 um 01:12 schrieb Dimitri Junker:
Aber jeden Höhenpunkt in Deinem 1024x1024-Gitter möchte man schon mit
einer Präzisionsangabe versehen haben.
Habe ich. Wobei die Qualität dieser Fehler natürlich davon abhängt ob
ich am
Anfang die Meßfehler richtig abgeschätzt habe, ob ich
Hallo,
mein Programm ist inzwischen soweit, daß ich Höhenlinien sehe und die Höhe
unter dem Mauszeiger angezeigt bekomme. Auf einer alten gekauften Karte habe
ich einige Höhenangaben gefunden, und die stimmen recht gut überein. Aber
viele der GPX-Files sind inzwischen rausgeflogen, u.a. hatte
Aber jeden Höhenpunkt in Deinem 1024x1024-Gitter möchte man schon mit
einer Präzisionsangabe versehen haben.
Habe ich. Wobei die Qualität dieser Fehler natürlich davon abhängt ob ich am
Anfang die Meßfehler richtig abgeschätzt habe, ob ich beim
Inter/Extrapolieren von den richtigen maximalen
Hallo,
Wenn jede Höhenlinie ihr eigenes Konfidenzintervall mitbringt, wird es
natürlich sehr fein. Nicht dass man das in einer Straßenkarte
dargestellt haben möchte :-)
Wie soll ich das machen? 1. Wie bestimme ich die Höhenlinie rechnerisch? 2.
Wie dann das Konfidenzintervall? Spätestens nach
Dimitri Junker o...@dimitri-junker.de [Sun, Mar 01, 2009 at 03:22:50AM CET]:
Hallo,
Wenn jede Höhenlinie ihr eigenes Konfidenzintervall mitbringt, wird es
natürlich sehr fein. Nicht dass man das in einer Straßenkarte
dargestellt haben möchte :-)
Wie soll ich das machen? 1. Wie
Hallo,
Der Gewichtungsfaktor ist also 1/Fehler. So hab ich das mal gelernt.
Das ist schon mal nicht ganz verkehrt.
1/Fehler^2 ist aber wohl besser.
Wo spielt in Deinen Modellen die Fehlerfortpflanzung eine Rolle?
Wenn man da den Fehler des Mittelwertes dazu zählt spielt sie eine Rolle.
Dimitri Junker o...@dimitri-junker.de [Sat, Feb 28, 2009 at 12:46:44PM CET]:
Hallo,
Der Gewichtungsfaktor ist also 1/Fehler. So hab ich das mal gelernt.
Das ist schon mal nicht ganz verkehrt.
1/Fehler^2 ist aber wohl besser.
Kommt drauf an, was Du unter Fehler verstehst. Wenn
Am 26. Februar 2009 23:31 schrieb Garry garr...@gmx.de:
macht bzw. kaum möglich ist wenn Du alle verfügbaren Tracks verwenden
willst. Auf freiwillige Angaben der Trackspender
kannst Du Dich nicht verlassen - die werden es häufig selbst nicht
wissen was sie für eine Korrektur im Logfile haben
Hallo,
Ist Dir inzwischen wenigstens klar dass es Geräte(bzw. sogar
firmwarespezifische) systematische Fehler gibt die Du *vor* Deiner
statistischen zusammenwürflung und Auswertung berücksichtigen musst?
Nein, bekannte systematische Meßfehler sollte man natürlich vorher
korigieren. Aber jedes
Am 27. Februar 2009 13:05 schrieb Dimitri Junker o...@dimitri-junker.de:
Ist Dir inzwischen wenigstens klar dass es Geräte(bzw. sogar
firmwarespezifische) systematische Fehler gibt die Du *vor* Deiner
statistischen zusammenwürflung und Auswertung berücksichtigen musst?
Nein, bekannte
Hallo,
mal wieder etwas verspätet, aber zur Info:
wir (Steffen Neubauer) haben letzten Sommer mal die GPX-Tracks von OSM
(Ziel: DTL) gezogen und in unsere SRTM-DB gespielt. Zum Zeitpunkt des
Versuchs konnten ca. 75.000 GPX Tracks zu 208 Mio. Punkte umgewandelt
und in eine DB geschrieben
Alexander Zipf schrieb:
Wir haben das erstmal nicht soo strikt weiter verfolgt, sondern sind
zunächst bei SRTM geblieben, sind aber durchaus weiter daran
interessiert und wollten hier sowieso wieder aktiv werden (Martin)
Habt ihr die 1er Karten? Ich habe mir vorgestern die SRTM-1er für
Martin Koppenhoefer schrieb:
oder man geht davon aus, dass diese hunderte verschiedenen GPS-Geraete
nicht gleichmaessig verteilt sind. Wenn 50 % dasselbe Geraet haben,
das einen bestimmten Fehler macht, und die anderen 50 % verteilen sich
auf hunderte verschiedene Geraete, dann funktioniert
Dimitri Junker schrieb:
Die GPS Empfänger arbeiten leider nicht alle gleich. Manche geben die
Meereshöhe, manche die Geoidhöhe aus, mache printen den Höhenausgleich
im Protokoll, wieder andere nicht. Im Pocketnavigation Forum wurden dazu
schon detaillierte Untersuchungen vorgenommen.
Nach
Hallo,
Nach dreimaligem Lesen von Garrys Text konnte ich nicht ermitteln, wo Du
dieses Zitat her hast...
Da stand doch ganz klar vor:
Ich hatte den Autor von Glopus gefragt, er antwortet:
Meereshöhe = Geoidhöhe.
Ich will mal annehmen, daß er sich da vertippt hat und es eigentlich besser
Am 24.02.2009 um 12:24 schrieb Dimitri Junker:
Also errechnest Du zu jeder Abweichung den Gewichtungsfaktor zum
Mittelwert?
Der Gewichtungsfaktor ist also 1/Fehler. So hab ich das mal gelernt.
Das ist schon mal nicht ganz verkehrt.
Werde mir jetzt aber auch nochmal etwas zum Thema
Dimitri Junker schrieb:
Hallo,
Das würde eh nur klappen, wenn der Messfehler nur durch die Geräte
erzeugt wird. Aber wir haben bei GPS ja noch xy andere Faktoren.
Ich hoffe doch, daß GPS i.W. statistische Fehler haben sollte, die sich also
beim Mitteln vieler Meßergebnisse
Also errechnest Du zu jeder Abweichung den Gewichtungsfaktor zum
Mittelwert?
Nein, bisher bilde ich nur den Mittelwert, als nächstes schaue ich mir
nochmal die Seite mit den Infos zu den GPS-Meßfehlern an und versuche dann
jedem Trackpunkt einen statistischen Fehler zuzuweisen in Abhängigkeit
Hallo,
Sonnenwinde, kosmische Strahlung (lässt sich ja bedingt berechnen),
Weltraumschrott (lässt sich auch berechnen), Flugzeuge die die
Signalbahn kreuzen (lassen sich auch berechnen).
Und 2-3 Tage vorher lassen sich sicher auch die Wettereinflüsse bedingt
berechnen.
Das sind alles
Dimitri Junker schrieb:
Das sind alles statistische Fehler, wenn man über genügend Messungen die
über einen Zeitraum gehen der größer ist als diese Effekte werden sich diese
Fehler rausmitteln. Schlimm sind nur Fehler die immer gleich sind.
Auf Wunsch kann ich Dir 178.000 Messwerte der
Hallo,
Auf Wunsch kann ich Dir 178.000 Messwerte der letzten 48 Stunden
schicken, mit denen Du Deine Statistiken testen kannst.
Kannst Du machen, aber darum kümmer ich mich erst im nächsten Schritt.
Kannst Du Deine Formeln bitte offenlegen, damit wir den Gedankengang
verfolgen können?
Noch
Dimitri Junker schrieb:
Noch ist da nicht viel besonderes, einfach ein gewichteter Mittelwert.
Sobald es interessanter ist werde ich natürlich alles offenlegen.
Also errechnest Du zu jeder Abweichung den Gewichtungsfaktor zum
Mittelwert?
___
Talk-de
grungelborz schrieb:
Mit Abweichung meine ich die Differenz zum Wert aus der topologischen
Karte, 1.3m. Die ist 5m. Ausreisser sind bei mir das obere und das
untere Drittel des Histograms. Die Begriffe waren nicht aus der
Statistik - ich hab das nicht studiert. Worauf es ankommt ist, daß man
Dimitri Junker schrieb:
Hallo,
Du bekommst einen Höhenteppich mit einer Dicke von Grössenordnung 80-
160m - ausgehend von einem Messfehler von 30m und und einer nicht
bekannten GPS-Höhenkorrektur
Der Fehler sinkt bekannterweise mit der Anzahl der Messwerte, irgendwann ist
er
Garry schrieb:
Fazit: Allein die Menge an verschieden Höhenaufzeichnungen pro Gebiet
ist kein Garant für eine Ausmittelungen des Messfehlers.
Das würde eh nur klappen, wenn der Messfehler nur durch die Geräte
erzeugt wird. Aber wir haben bei GPS ja noch xy andere Faktoren.
Tobias Wendorff schrieb:
grungelborz schrieb:
Mit Abweichung meine ich die Differenz zum Wert aus der topologischen
Karte, 1.3m. Die ist 5m. Ausreisser sind bei mir das obere und das
untere Drittel des Histograms. Die Begriffe waren nicht aus der
Statistik - ich hab das nicht studiert. Worauf
grungelborz schrieb:
Eine interessante Präsentation zum GPS-Höhenmessen findet sich außerdem
unter http://www.intergeo.de/archiv/2005/Drewes.pdf.
Die Versuche sind mit einem Consumer-GPS soweit vergleichbar, wie ein
Cheeseburger von einem Triple-Whopper entfernt ist.
Hallo,
Das würde eh nur klappen, wenn der Messfehler nur durch die Geräte
erzeugt wird. Aber wir haben bei GPS ja noch xy andere Faktoren.
Ich hoffe doch, daß GPS i.W. statistische Fehler haben sollte, die sich also
beim Mitteln vieler Meßergebnisse wegmitteln. Als systematischen Fehler sehe
Dimitri Junker schrieb:
Ich hoffe doch, daß GPS i.W. statistische Fehler haben sollte, die sich also
beim Mitteln vieler Meßergebnisse wegmitteln. Als systematischen Fehler sehe
ich nur falsche Einstellungen, sei es die Höhenkorektur oder ein ^falsche^
Referenzsystem (WGS84,...). Kennst Du
Johannes Huesing schrieb:
grungelborz grungelb...@arcor.de [Sat, Feb 21, 2009 at 12:37:41AM CET]:
In der ersten Messung meines Experiments unter
http://lists.openstreetmap.org/pipermail/talk-de/2008-December/030479.html
haben die Messwerte auch eine Streuung von 80 m (Histogram unten). Wenn
Hallo,
Du bekommst einen Höhenteppich mit einer Dicke von Grössenordnung 80-
160m - ausgehend von einem Messfehler von 30m und und einer nicht
bekannten GPS-Höhenkorrektur
Der Fehler sinkt bekannterweise mit der Anzahl der Messwerte, irgendwann ist
er akzeptabel. Ggf könnte man noch
Am 19. Februar 2009 14:43 schrieb Tobias Wendorff
tobias.wendo...@uni-dortmund.de:
Was ist Flachland für dich? 10 m Positionierungsfehler? Für eine
korrigierte SRTM-3, genau. Allerdings wird dann der ganze Wald
einen Fehler 10 m haben und als großer Klotz dastehen.
wenn ich mir meine nähere
Martin Koppenhoefer schrieb:
Am 19. Februar 2009 14:43 schrieb Tobias Wendorff
tobias.wendo...@uni-dortmund.de:
Was ist Flachland für dich? 10 m Positionierungsfehler? Für eine
korrigierte SRTM-3, genau. Allerdings wird dann der ganze Wald
einen Fehler 10 m haben und als großer Klotz
Dimitri Junker schrieb:
Der große Vorteil ist, daß man die Höhenkarte praktisch automatisch
entstehen lassen kann, sozusagen als Abfallprodukt von OSM. Man lädt sein
GPX-File das man für OSM aufgenommen hat hoch und das war es. Ggf trägt man
noch einmal ein was für ein Gerät man hat, wie
Torsten Leistikow schrieb:
Martin Koppenhoefer schrieb:
nicht zu vergessen die Radfahrer (nicht als Sport sondern zur
Fortbewegung), die mit den SRTM-Daten wenn es nicht gerade Hochgebirge
ist, nicht sehr viel anfangen können.
Gerade im Gebirge sind die SRTM-Daten (und alle
Am 20. Februar 2009 23:32 schrieb Jonas Krückel (John07)
o...@jonas-krueckel.de:
Martin Koppenhoefer schrieb:
Am 19. Februar 2009 14:43 schrieb Tobias Wendorff
tobias.wendo...@uni-dortmund.de:
Was ist Flachland für dich? 10 m Positionierungsfehler? Für eine
korrigierte SRTM-3, genau.
Garry schrieb:
Du bekommst einen Höhenteppich mit einer Dicke von Grössenordnung
80-160m - ausgehend von einem Messfehler
von 30m und und einer nicht bekannten GPS-Höhenkorrektur des jeweils
verwendenten Empfängers(knapp50m für Deutschland)...
Wenn man konsequent nur bekannte Quellen mit
grungelborz grungelb...@arcor.de [Sat, Feb 21, 2009 at 12:37:41AM CET]:
In der ersten Messung meines Experiments unter
http://lists.openstreetmap.org/pipermail/talk-de/2008-December/030479.html
haben die Messwerte auch eine Streuung von 80 m (Histogram unten). Wenn
man dann aber die Ausreisser
Martin Koppenhoefer schrieb:
Daher mein Standpunkt: Externe Höhendatenbank ja, da relativ einfach zu
handhaben.
Integrierte OSM-Höhendatenbank (abgesehnen von einzelnen POI-Höhen) nein
da mit zu viel Pflegeaufwand verbunden.
ja, das kann man mittlerweile wohl als Konsens festhalten.
Ich
Martin Koppenhoefer schrieb:
nicht zu vergessen die Radfahrer (nicht als Sport sondern zur
Fortbewegung), die mit den SRTM-Daten wenn es nicht gerade Hochgebirge
ist, nicht sehr viel anfangen können.
Gerade im Gebirge sind die SRTM-Daten (und alle anderen, nicht
strassenbezogenen Hoehendaten)
orsten Leistikow schrieb:
Martin Koppenhoefer schrieb:
nicht zu vergessen die Radfahrer (nicht als Sport sondern zur
Fortbewegung), die mit den SRTM-Daten wenn es nicht gerade Hochgebirge
ist, nicht sehr viel anfangen können.
Gerade im Gebirge sind die SRTM-Daten (und alle anderen, nicht
Garry schrieb:
Da würde ich dann für Deutschland ehr eine Differenz von an die 50m
erwarten...
Die GPS-Receiver interpolieren den Geoid für WGS84, da sonst eine
riesige Tabelle mitgeschleppt werden müsste. Ich würde schätzen, dass
90% der Receiver für Deutschland den Wert von 47,5 m haben.
Hallo,
Aber warum sollte man die so einstellen dass eine 10mDifferenz
übrigbleibt? Oder ist 40m die Durchschnittsabweichung über die ganze
Welt so das es in D zufällig die 10m sind?
Entweder das oder die Differenz zwischen Herstellungsland und D beträgt 10m.
Was sehr zu bedauern ist ist, daß
1 - 100 von 170 matches
Mail list logo
