Wie haltet ihr es mit Höhenangaben ?

Ich trage alle Höhen in NN ein und ich rendere sie in allen meinen Karten ohne Umrechnung als NN. Es hat sich nie emand über falsche Höhen beschwert.

Das mit dem WGS84 ist laut Wiki Historie eine änderung eines einzelnen Users ohne Verweis auf eine Diskussion und IMHO völlig impraktikabel. Das sollte entfernt werden.

Bye, Nop

Das sehe ich nicht so. Wenn man mal an Objekten vorbei kommt, an denen keine Höhe dran steht, wird man diese mit großer Wahrscheinlichkeit mit einem Höhenmesser ermitteln, der in der Regel WGS84-Höhe liefert.

Die Diskussion hatten wir schon mal hier:
http://forum.openstreetmap.org/viewtopic.php?id=18946

Ich trage Höhen in Meter über NN ein, schreibe dies aber extra dazu, etwa so:

ele=1250
ele:NN=1250
ele:de=1250

Dadurch ist klar, das in ele Normalhöhennullmeter (und zwar nach deutschen Maßstab, deswegen das ele:de) stehen. Trägt man nur ele ein bleibt unklar was gemeint ist (meistens ist es dann ele:NN, aber kann man sich sicher sein?).

Gruß
unixasket

Tag,

so ziemlich alle Argumente wurden ja schonmal ausgetauscht. Ich bin für WGS84 (also das ganze WGS84, inklusive Geoid), dann können wir auch ohne Umrechnung (wie macht man das eigentlich in JOSM oder Potlatch?) eine Höhenangabe vor Ort einfach abschreiben.

Das passt dann auch zum ersten Beispiel für ele=* im Wiki und zu so ziemlich jeder mir bekannte Höhenangabe in unseren Daten.

Grüße, Max

aighes wrote:

Das sehe ich nicht so. Wenn man mal an Objekten vorbei kommt, an denen keine Höhe dran steht, wird man diese mit großer Wahrscheinlichkeit mit einem Höhenmesser ermitteln, der in der Regel WGS84-Höhe liefert.

Das hängt allerdings vom verwendeten Höhenmesser ab. Einen baromtrischen Höhenmesser zum Beispiel muß man vorher kalibrieren. Kalibriert man ihn nach NN zeigt er auch NN an, kalibriert man vorher WGS84 zeigt er eben dies an. Outdoor GPS Geräte zeigen meist NN an, es könnte aber auch WGS84 sein, das sollte man vorher prüfen. Garmins zeigen NN an.

Gruß
unixasket

Besser wäre wohl ele:de:NN=1250. Kann man sinnvoller auswerten, als wenn man prüfen muss, ob der Wert bei ele:NN mit einem anderen ele:* übereinstimmt. Was soll der AUswerter machen, wenn ele:NN mit keinem anderen Wert übereinstimmt? Usw.

Wenn es nur für den Mapper gedacht ist, dass ist die Info im note=* besser aufgehoben.

maxbe wrote:

und zu so ziemlich jeder mir bekannte Höhenangabe in unseren Daten.

Tatsächlich? Wo denn? Ich habe in OSM noch keine einzige Höhenangabe gesehen, die in WGS84 war.

Gruß
unixasket

Vielen Dank für die Beiträge und Verweise auf frühere Diskussionen.

Ich habe für mich den Schluß gezogen:

Der NN Wert ist eingeführt und praktikabel.
Der WGS84 ist genauer und universaler referenziert.

Die Menschen, die OSM-Karten benutzen sollen nach meiner Meinung Werte sehen, die mit denen übereinstimmen, die vor Ort und in gerduckten Kartenwerken angegeben sind, also hierzulande: NN.

Wenn der Wert nach den Vorschhlägen von unixasket und aighes angegeben wird, dann können die Werte als NN Werte erkannt und können bei Bedarf entsprechend ausgewertet und umgerechnet werden. (Wozu hat man die Computer?)

Pedentim

PS: Auch bei meinem GPS ist es so, dass der barometrische Höhenmesser NN mißt, wenn man das Gerät an einem bekannten Punkt kalibriert hat. Das ginge prinzipiel auch mit WGS84. Nur: wo finde ich denn Orte (Gipfel, Bahnhöfe etc.) wo der Wert mal in WGS84 angegeben ist?

unixasket wrote:

Tatsächlich? Wo denn? Ich habe in OSM noch keine einzige Höhenangabe gesehen, die in WGS84 war.

Ich meinte WGS84 mit Geoidkorrektur, also plus den üblichen 40 oder 50 Metern. Das kommt auch auf ein paar Dezimeter an das ran, was auf Schildern steht. Wir bräuchten ja die ganze Diskussion nicht, wenn die Leute bei den Bestandteilen des WGS84 nicht einfach beim ersten Punkt aufhören würden. Da steht : "WGS besteht aus einem Ellipsoid, einem Geoid und 12 Fundamentalstationen" (*). Leider sagen viele zur Höhe über dem Ellipsoid "WGS84-Höhe" und verzichten aufs Geoid.

Ob wir dann die WGS84-Höhe (also die mit Korrektur), müA, NN, NHN oder müM in ele=* eintragen ist mir ziemlich egal. Wenns auf dem Schild steht, kann man ja gerne ele:XX=* eintragen. Selbst gemessenes dürfte selten besser sein als ein paar Meter und selbst die gut vermessenen Karten weichen schon mal um einen Meter ab.

Grüße, Max

(*) Wers amtlich will statt Wikipedia NGA: DoD World Geodetic System 1984 (PDF, 1MB) Kapitel 6

unixasket wrote:

maxbe wrote:

und zu so ziemlich jeder mir bekannte Höhenangabe in unseren Daten.

Tatsächlich? Wo denn? Ich habe in OSM noch keine einzige Höhenangabe gesehen, die in WGS84 war.
..

www.openstreetmap.org .... Irland finden ... beliebigen Gipfel finden ... Daten dazu anschauen

Glückicherweise ist es dort erkennbar, dass es Daten relativ zum WGS84 Ellipsoid sind, aber ansonsten ist meistens allgemeines Rätselraten angesagt.

pedentim wrote:

Wie haltet ihr es?

Aufgrund des bunten Wirrwarrs (siehe oben: einzig richtig ist NN, einzig richtig ist NHN, einzig richtig ist WGS84, ...) habe ich es schlicht aufgegeben, irgendwelche Höhen in OSM einzutragen. Zumal früher oder später ohnehin jemand daher kommt und den barometrisch bestimmten Wert mit der Angabe aus irgendeiner Wanderkarte überschreibt.

SimonPoole wrote:

www.openstreetmap.org .... Irland finden ... beliebigen Gipfel finden ... Daten dazu anschauen

Glückicherweise ist es dort erkennbar, dass es Daten relativ zum WGS84 Ellipsoid sind, aber ansonsten ist meistens allgemeines Rätselraten angesagt.

Ah, tatsächlich:
http://www.openstreetmap.org/browse/node/332373395
Auf alle Fälle ist aber auch hier durch das Tagging klar erkennbar was gemeint ist. Wenn das in Irland generell so gemacht wird, ist es immerhin klar. In Deutschland sind aber die meisten (alle?) Höhenangaben in NN/NHN. Alleine deswegen ist es sinnvoll das auch weiter so handzuhaben (solange man es kenntlich macht). Ob es dann tatsächlich NN oder NHN oder wie maxbe meinte Geoid-korrigierte WGS84 sind, ist dabei in der Praxis irrelevant da es ja nur um Abweichungen im Dezimeterbereich geht. Ich finde man sollte da einfach praxisgerecht rangehen. Höhenangaben mit Kommastellen nach den Metern wird man selten bekommen können, außer die Vermessungsämter spendieren mal solche genauen Daten. Ich vermute mal in Irland gab es da wohl mal eine Datenspende so wie das Tagging da aussieht.

Gruß
unixasket

unixasket wrote:

Ich vermute mal in Irland gab es da wohl mal eine Datenspende so wie das Tagging da aussieht.

Richtig vermutet: http://www.osm.org/user/iemv_import
Weit über 1.000 Nodes (mit natural = peak) habe einheitlich den Weg zu OSM gefunden...

unixasket wrote:

Ich vermute mal in Irland gab es da wohl mal eine Datenspende so wie das Tagging da aussieht.

Schönes Beispiel für die Verwirrung: Der Spender hat 314 Meter über irgendeinem Meer ("TM75" sagt mir nichts) geliefert. Das wurde dann mühsam in ele = 367.2, ele:local = 314, ele:tm75 = 314, ele:wgs84 = 367.2, ele_local = 314 umgerechnet.

maxbe wrote:

... ("TM75" sagt mir nichts)...

Da war doch mal was: http://forum.openstreetmap.org/viewtopi … 64#p287264
Edit: und da:
http://georepository.com/transformation … -84-2.html
http://georepository.com/datum_6300/Geo … -1965.html

Oli-Wan wrote:

pedentim wrote:

Wie haltet ihr es?

Aufgrund des bunten Wirrwarrs (siehe oben: einzig richtig ist NN, einzig richtig ist NHN, einzig richtig ist WGS84, ...) habe ich es schlicht aufgegeben, irgendwelche Höhen in OSM einzutragen.

Dito.
Wobei ich es noch steigere: Ich betrachte mangels Standard JEDE Höhenangabe in der Datenbank als wahrscheinlich falsch. Denn selbst wenn sie nach irgendeinem der hier schon beschriebenen Referenzsystemen eingetragen zu sein scheint, so halte ich es für SEHR wahrscheinlich, dass der Mapper vor Ort lediglich das Tagging von einem anderen Node übernommen und nur den Wert angepasst hat, ohne sich der grundsätzlichen Problematik auch nur annähernd bewusst gewesen zu sein.

Mir begegnen beim Wandern mit den OSM Karten Ungenauigkeiten von 30 Metern hinsichtlich Nord, Ost, Süd und West - da kann ich auch mit einer Ungenauigkeit bei der Höhenangabe leben 😉

Bezüglich der Höhenangaben wird es m.E. nicht gelingen ein OSM-einheitliches Schema zu etablieren. Dies schon deshalb nicht, weil die verschiedenen Höhenangaben historisch gewachsen sind und sehr unterschiedliche Bezugsgrößen haben (WGS84, Amsterdamer Pegel, Triester Pegel, ...). Wichtig erscheint mir in diesem Zusammenhang die Erfassung des Bezugssystems. Hiermit wäre dann eine Umrechnung in die gewünschte Zielgröße möglich ...

Gruß Klaus

Aufgrund dieses Vorschlages hole ich diese Diskussion einfach mal hoch, da es sich um die aktuellste der drei Vorschläge handelt.
Dann einigt euch mal weiter...

Edit: korrekter link

Für die Höhenangaben aus dem NRW-Atlas werde ich ab sofort wohl ele:NHN eintragen.

Wikipedia wrote:

Die Unterschiede zu den bisherigen Systemen (NN) liegen im Flachland bei wenigen Millimetern

Somit ist die einzig relevante Frage ob der Wert der in ele steht geoid-korrigiert ist oder nicht (Abweichung 30-50m).

Ich trage alle Höhenangaben in m über NN ein, so wie sie auf irgendwelchen Schildern zu finden sind.

Ich rendere alle Höhenangaben auf der RWK unverändert als m über NN und es gab keine einzige Beschwerde.

Zur Lösung des Dilemmas schlage ich vor:
- ele enthält faktisch meist die ortsübliche Angabe aus den für Mapper vor Ort offenkundigen Quellen, also sollte es auch wieder so beschrieben werden
- eine Angabe gemäß einem bestimmten Bezugssystem sollte ein entsprechendes Tag benutzen z.B. ele:wgs84. Das irische Beispiel finde ich sehr gut gelöst. Damit haben die Experten exakte Angaben und der Normalmapper muß nichts umrechnen
- das Wiki sollte entsprechend korrigiert werden

bye, Nop

toc-rox wrote:

Bezüglich der Höhenangaben wird es m.E. nicht gelingen ein OSM-einheitliches Schema zu etablieren. Dies schon deshalb nicht, weil die verschiedenen Höhenangaben historisch gewachsen sind und sehr unterschiedliche Bezugsgrößen haben (WGS84, Amsterdamer Pegel, Triester Pegel, ...). Wichtig erscheint mir in diesem Zusammenhang die Erfassung des Bezugssystems. Hiermit wäre dann eine Umrechnung in die gewünschte Zielgröße möglich ...
Gruß Klaus

Ja, ich denke das steht außer Frage. Man braucht verlässliche Datengrundlagen.

Die Umrechnung ist aber relativ kompliziert. Es wäre für das System von Vorteil, wenn bei der Eingabe
die Software gleich in ein Einheitssystem konvertiert und sowohl den Eingabewert als auch
den standardisierten Wert speichert. Also wenn jemand N.N.-Angaben macht, dass dazu
automatisch ein WGS84-Eintrag generiert wird.

Dann könnte man so eine Datenbankabfrage machen wie "gib mir alle Berge über 3000m NN".
Das wäre schwieriger, wenn die Datenfelder nicht vereinheitlicht wären.

Was zunächst zu klären wäre: welches WGS84 überhaupt?
Ist die WGS84-Geoidhöhe näherungsweise gleich dem N.N., NHN oder DHHN?

Die verschiedenen nationalen System unterscheiden sich historisch seit der Preußenzeit
100 Jahre lang lediglich um ein paar cm.

Nop wrote:

Ich trage alle Höhenangaben in m über NN ein, so wie sie auf irgendwelchen Schildern zu finden sind.

Ich rendere alle Höhenangaben auf der RWK unverändert als m über NN und es gab keine einzige Beschwerde.

Zur Lösung des Dilemmas schlage ich vor:
- ele enthält faktisch meist die ortsübliche Angabe aus den für Mapper vor Ort offenkundigen Quellen
- eine Angabe gemäß einem bestimmten Bezugssystem sollte ein entsprechendes Tag benutzen z.B. ele:wgs84. [...]
- das Wiki sollte entsprechend korrigiert werden

Volle Zustimmung, bis auf

Das irische Beispiel finde ich sehr gut gelöst. Damit haben die Experten exakte Angaben und der Normalmapper muß nichts umrechnen

In Irland steht ele für "WGS84 über dem Ellipsoid", die Werte über dem Meer sind in "ele:local" und "ele:tm75" versteckt. Wer "ele" eintragen will, muss umrechnen, wobei mir einer erklären müsste, wie er das machen soll...

Mal ne Statistik gefällig? In meiner Gegend sieht es so aus:

156777 Nodes haben ein ele-Tag
208 haben ein "ele:NN". Dort ist ele=ele:NN. Einer davon hat kein ele.
75 haben ein "ele:wgs84". Fast sämtliche ele:wgs84 sind ohne Geoidkorrektur, bis auf einen. Ein weiterer liegt völlig daneben mit der Umrechnung.
16 haben ein "ele:local" allerdings haben alle diese Nodes kein ele
ele:nhn kommt gar nicht vor.

Über die 156777 Nodes ohne weitere spezielle Höhenangaben kann ich natürlich nichts sagen, allerdings sind mir auch noch nirgends falsche Höhen aufgefallen. Die 100% Übereinstimmung von ele und ele:NN ist aber schon deutlich...

Grüße, Max

PS: Einige Höhenangaben könnten in dem Bereich fehlen. Ich werfe alles aus meiner Datenbank, was ich nicht irgendwie als Zahl interpretieren kann, schliesslich muss ich mit dem Wert rechnen können.

openzzz wrote:

Ist die WGS84-Geoidhöhe näherungsweise gleich dem N.N., NHN oder DHHN?

So gut genähert wie die alten Bezugsysteme zueinander (oder auch zu den Nachbarn, die ihre Pegel im Mittelmeer haben) auch sind. Ein paar Dezimeter.

maxbe wrote:

openzzz wrote:

Ist die WGS84-Geoidhöhe näherungsweise gleich dem N.N., NHN oder DHHN?

So gut genähert wie die alten Bezugsysteme zueinander (oder auch zu den Nachbarn, die ihre Pegel im Mittelmeer haben) auch sind. Ein paar Dezimeter.

Also würde die WGS84-Geoidhöhe im Prinzip unseren N.N.-Angaben entsprechen,
wenn wir in OSM Fehler <1m tolerieren?

Wir könnten dann ruhig an der einheitlichen Definition von ele= als WGS84-Geoidhöhe
festhalten, ohne dass die bisherhigen N.N.-Einträge grob falsch wären.
Das würde quasi die deutschen ele-Angaben retten. Nur die Iren müssten dann alles ändern.

Da noch nicht viele ele-Tags überhaupt in OSM stecken - ist eben fast alles in 2D-Koordinaten -
sollte man nicht danach gehen wer was ändern muss, sondern was langfristig gesehen das
Sinnvollste ist.

Als Beispiel: in NMEA steht auch die WGS84-Geoidhöhe, wobei die Geoid-zu-Elleipsoid-Differenz
als Datenfeld gleich mitgeliefert wird. So lässt sich dann auch gut umrechnen.
Aber wie sollte man die unkorrigierte WGS84-Ellipsoidhöhe taggen? ele:wgs84= ?
Dann müsste aber ziemlich deutlich gesagt werden, dass das keine WGS84-Geoidhöhe ist.

maxbe wrote:

openzzz wrote:

Ist die WGS84-Geoidhöhe näherungsweise gleich dem N.N., NHN oder DHHN?

So gut genähert wie die alten Bezugsysteme zueinander (oder auch zu den Nachbarn, die ihre Pegel im Mittelmeer haben) auch sind. Ein paar Dezimeter.

Reicht völlig, solange man keine Brücken bauen will... http://de.wikipedia.org/wiki/Hochrheinbr%C3%BCcke

openzzz wrote:

Also würde die WGS84-Geoidhöhe im Prinzip unseren N.N.-Angaben entsprechen, wenn wir in OSM Fehler <1m tolerieren?

Ja.

openzzz wrote:

Wir könnten dann ruhig an der einheitlichen Definition von ele= als WGS84-Geoidhöhe festhalten, ohne dass die bisherhigen N.N.-Einträge grob falsch wären.
Das würde quasi die deutschen ele-Angaben retten. Nur die Iren müssten dann alles ändern.

Und vielleicht noch ein paar andere Regionen mit eigener Auffassung, was ele ist. Das ist ja nicht das deutsche Wiki für das deutsche OSM. In anderen Gegenden müsste man erst nachsehen und das diskutieren. Deshalb bleibt sowas ja auch so lange stehen. "Wir hier" können uns ja einigen. Aber wer sagts den Iren und fragt in Südamerika und Asien nach?

openzzz wrote:

Als Beispiel: in NMEA steht auch die WGS84-Geoidhöhe, wobei die Geoid-zu-Elleipsoid-Differenz als Datenfeld gleich mitgeliefert wird. So lässt sich dann auch gut umrechnen.

Der Normalfall ist nicht der Mapper mit GPS, sondern der Mapper vor einem Schild. Noch seltener sind GPS-Besitzer, die auch noch sagen können, ob das was sie am Gerät sehen aufs Geoid oder aufs Ellipsoid bezogen ist. Nur wenige werden überhaupt die Frage verstehen.

openzzz wrote:

Aber wie sollte man die unkorrigierte WGS84-Ellipsoidhöhe taggen? ele:wgs84= ?

Ja. Die Idee, dass die Korrektur Teil der WGS84-Definition ist, ist hier ja recht deutlich eine Minderheitenmeinung.

Grüße, Max

maxbe wrote:

Der Normalfall ist nicht der Mapper mit GPS, sondern der Mapper vor einem Schild.

Das ist auch gut so, denn die mit einem Consumer-GPS-Gerät gemessenen Höhenangaben sollten m.E. nicht (vielleicht hilfsweise in Ausnahmefällen) in OSM eingetragen werden. Sie sind zu ungenau ... da bringt auch die Angabe des Bezugssystem nichts.

Gruß Klaus

Überlegen wir mal. Die Verarbeiter (gemeint ist Software) von Geodaten arbeiten mit EPSG-Codes. Mit diesem EPSG-Code ist ein System, sei es ein geographisches der ein projiziertes System der XY-Richtung oder ein vertikales der Z-Richtung definiert und mit den relevanten Berechnungsparameter hinterlegt.

Das hatte ich hier schon mal geschrieben.

Wie Wolf schon richtig schrieb:

Das klingt gut.
Wobei bei solchen Codes Tippfehler ein unangenehmes Problem sind.

Man muß Aufpassen.

eine DHHN92- Höhe könnte z.B. so aussehen:

ele:epsg:5783=311 Also Höhe nach EPSG-Code 5783 (gleich DHHN92; gleich NHN) beträgt 311 Meter.

Im Wiki steht dann, daß EPSG 5783 das DHHN92 ist und NHN...

Feddich.

Sven

Aus der INSPIRE-Spezifikation für Elevation:

http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_EL_v3.0rc3.pdf wrote:

As stated in the Commission Regulation (EU) No 1089/2010, on interoperability of spatial data sets and
services, the European Vertical Reference System (EVRS) shall be used to express gravity-related
heights for the vertical component on land, within its geographical scope (continental Europe). Outside
the geographical scope of EVRS (e.g. overseas territories), other vertical reference systems related to the
Earth gravity field shall be used, which shall be defined and documented according to EN ISO 19111 and
ISO 19127 by the Member State concerned. The Earth Gravitational Model (EGM Version 2008) is
recommended in that cases

Das genannte EVRS wird beim BKG beschrieben: http://www.bkg.bund.de/geodIS/EVRS/EN/H … __nnn=true .

Es gibt also mindestens europäische Höhenstandards, an die wir uns hängen sollten. Das doofe ist, das ich die Standards da nicht wirklich verstehe...es bräuchte also eineN GeodätIn, derdie sich damit auskennt und uns da erhellen könnte.

openzzz wrote:

maxbe wrote:

openzzz wrote:

Ist die WGS84-Geoidhöhe näherungsweise gleich dem N.N., NHN oder DHHN?

So gut genähert wie die alten Bezugsysteme zueinander (oder auch zu den Nachbarn, die ihre Pegel im Mittelmeer haben) auch sind. Ein paar Dezimeter.

Also würde die WGS84-Geoidhöhe im Prinzip unseren N.N.-Angaben entsprechen,
wenn wir in OSM Fehler <1m tolerieren?

Nein! Die Geoidundulation beträgt in Deutschland zwischen +34 und +51 Meter.
Quelle mit Visualisierung: http://www.bezreg-koeln.nrw.de/brk_inte … hoehen.pdf (Seite 2)

Nakaner wrote:

openzzz wrote:

maxbe wrote:

So gut genähert wie die alten Bezugsysteme zueinander (oder auch zu den Nachbarn, die ihre Pegel im Mittelmeer haben) auch sind. Ein paar Dezimeter.

Also würde die WGS84-Geoidhöhe im Prinzip unseren N.N.-Angaben entsprechen,
wenn wir in OSM Fehler <1m tolerieren?

Nein! Die Geoidundulation beträgt in Deutschland zwischen +34 und +51 Meter.
Quelle mit Visualisierung: http://www.bezreg-koeln.nrw.de/brk_inte … hoehen.pdf (Seite 2)

Ähhhh. "Korrigieren" heisst ja auch nicht, dass wir eine Konstante addieren, sondern dass wir eben diese 34 bis 51 Meter addieren... Oder was meinst Du mit "Nein!"

openzzz wrote:

toc-rox wrote:

Bezüglich der Höhenangaben wird es m.E. nicht gelingen ein OSM-einheitliches Schema zu etablieren. Dies schon deshalb nicht, weil die verschiedenen Höhenangaben historisch gewachsen sind und sehr unterschiedliche Bezugsgrößen haben (WGS84, Amsterdamer Pegel, Triester Pegel, ...). Wichtig erscheint mir in diesem Zusammenhang die Erfassung des Bezugssystems. Hiermit wäre dann eine Umrechnung in die gewünschte Zielgröße möglich ...
Gruß Klaus

Ja, ich denke das steht außer Frage. Man braucht verlässliche Datengrundlagen.

Die Umrechnung ist aber relativ kompliziert. Es wäre für das System von Vorteil, wenn bei der Eingabe
die Software gleich in ein Einheitssystem konvertiert und sowohl den Eingabewert als auch
den standardisierten Wert speichert. Also wenn jemand N.N.-Angaben macht, dass dazu
automatisch ein WGS84-Eintrag generiert wird.

Die Umrechnung Gebrauchshöhe (DHHN92, ...) in ellipsoidische Höhen (WGS84) ist einfach. Man nimmt die eine Höhe und addiert/subtrahiert einen Korrekturwert. Diesen Korrekturwert erhält man aus Tabellen die z.B. für ein 10x10 km-Raster die Korrekturwerte enthalten. Für alle Punkte dazwischen kannst man interpolieren.

Für ingenieurgeodätische Zwecke (Millimetergenauigkeit) reichen meistens (d.h. außerhalb von Berg- und Tagebaugegenden) 1 km-Raster aus.

maxbe wrote:

Nakaner wrote:

openzzz wrote:

Also würde die WGS84-Geoidhöhe im Prinzip unseren N.N.-Angaben entsprechen,
wenn wir in OSM Fehler <1m tolerieren?

Nein! Die Geoidundulation beträgt in Deutschland zwischen +34 und +51 Meter.
Quelle mit Visualisierung: http://www.bezreg-koeln.nrw.de/brk_inte … hoehen.pdf (Seite 2)

Ähhhh. "Korrigieren" heisst ja auch nicht, dass wir eine Konstante addieren, sondern dass wir eben diese 34 bis 51 Meter addieren... Oder was meinst Du mit "Nein!"

Ich hatte den Eindruck, dass openzzz gemeint hat, die Differenz DHHN92 zu WGS84 sei <1 m.

Nahmd,

toc-rox wrote:

Das ist auch gut so, denn die mit einem Consumer-GPS-Gerät gemessenen Höhenangaben sollten m.E. nicht (vielleicht hilfsweise in Ausnahmefällen) in OSM eingetragen werden. Sie sind zu ungenau ... da bringt auch die Angabe des Bezugssystem nichts.

Allen Unkenrufen zum Trotz: bei niedrigem Horizont ist die per GPS gemessene Höhe überraschend gut.

Unterwegs zeichne ich barometrisch auf und normalisiere die Höhenwerte im Track daheim anhand der Punkte mit (woher auch immer) bekannten Höhen und dazwischen angenommenen linearen Verlauf des Basisluftdrucks.

Die damit gewonnen Werte haben vielleicht ±10m Fehler, meist deutlich darunter.

Und natürlich trage ich diese Werte ein. Woher sollen die Werte denn sonst kommen? Nicht jeder weglose Übergang und nicht jede Wegweisertafel enthält eine Höhenangabe. Und wenn, dann das ist die Höhe auch gerne einer Karte entnommen und hat dann Höhenliniengenauigkeit (±20m).

BTW: ich hab auch schon versucht, den im "Basislager" konstanter Höhe kontinuierlich aufgezeichneten Luftdruck zur Korrektur zu verwenden, das führt aber zu keinem besseren Ergebnis. Bei langsamer Luftdruckänderung tun sich beide Methoden nichts, und plötzliche Luftdruckänderungen bei Wetterkapriolen geschehen in der Referenzstation zu einem anderen Zeitpunkt als draußen.

Dann hatte ich die Idee, die barometrischen Höhen aus dem Track mit den SRTM-Daten zusammenführen, um den Einfluss des Luftdruckes herauszurechnen. Kalman für Arme. Bin ich aber schon bei den Vorüberlegungen gescheitert. 🙁

(Das wäre was für die Vermessungs-Profis: wenn man die hunderttausende hochgeladenen Tracks mit den Höhendaten von SRTM oder ASTER ausgleichte, hätte man ein feineres Höhenmodell mit Stützstellen entlang der begangenen und befahrenen Wege. Das was die Router brauchen.)

Gruß Wolf

Nakaner wrote:

Ich hatte den Eindruck, dass openzzz gemeint hat, die Differenz DHHN92 zu WGS84 sei <1 m.

Ach so. Nee, wir müssten uns schon die Werte bei amerikanischen Behörden im 15-Minuten-Raster für umsonst holen oder bei unserem Staat im 1-Minuten-Raster kaufen 😉

Max, von 45.96m über dem Ellipsoid (kostenlos) oder 46.5m (kostenpflichtig) grüßend

maxbe wrote:

openzzz wrote:

Aber wie sollte man die unkorrigierte WGS84-Ellipsoidhöhe taggen? ele:wgs84= ?

Ja. Die Idee, dass die Korrektur Teil der WGS84-Definition ist, ist hier ja recht deutlich eine Minderheitenmeinung.
Grüße, Max

Was habt ihr immer mit "Meinungen"?
Es geht hier um Definitionen.

http://en.wikipedia.org/wiki/World_Geodetic_System

"Presently WGS 84 uses the EGM96 (Earth Gravitational Model 1996) geoid, revised in 2004. This geoid defines the nominal sea level surface by means of a spherical harmonics series of degree 360 (which provides about 100 km horizontal resolution).[7] The deviations of the EGM96 geoid from the WGS 84 reference ellipsoid range from about −105 m to about +85 m.[8] EGM96 differs from the original WGS 84 geoid, referred to as EGM84."

WGS84 definiert also sehr wohl die Korrektur zu einem Geoiden.
Es gibt also WGS84-Geoidhöhen und WGS84-Ellipsoidhöhen.
Nur ist das noch nicht die exakte Höhe nach DHHN92.

So ganz habe ich aber noch nicht raus, ob der Unterschied WGS84-Geoidhöhe zu DHHN92-Höhe wirklich für OSM praktisch von Bedeutung ist, also <1m.

Nakaner wrote:

openzzz wrote:

maxbe wrote:

So gut genähert wie die alten Bezugsysteme zueinander (oder auch zu den Nachbarn, die ihre Pegel im Mittelmeer haben) auch sind. Ein paar Dezimeter.

Also würde die WGS84-Geoidhöhe im Prinzip unseren N.N.-Angaben entsprechen,
wenn wir in OSM Fehler <1m tolerieren?

Nein! Die Geoidundulation beträgt in Deutschland zwischen +34 und +51 Meter.
Quelle mit Visualisierung: http://www.bezreg-koeln.nrw.de/brk_inte … hoehen.pdf (Seite 2)

Ich bin kein Geodät. Haben wir uns richtig verstanden? Das WGS84-Geoid ist doch an
das Schwerefeld der Erde angeglichen und damit "quasi" über Meeresspiegel,
anders als der WGS84-Ellipsoid. Ist dann trotzdem der Unterschied noch so groß?

"Geoidundulation" ist doch der Unterschied Geoidhöhe zu Ellipsoidhöhe und nicht
der Unterschied zwischen verschiedenen Geoidmodellen.

Netzwolf wrote:

... Allen Unkenrufen zum Trotz: bei niedrigem Horizont ist die per GPS gemessene Höhe überraschend gut. Unterwegs zeichne ich barometrisch auf und normalisiere die Höhenwerte im Track daheim anhand der Punkte mit (woher auch immer) bekannten Höhen und dazwischen angenommenen linearen Verlauf des Basisluftdrucks. Die damit gewonnen Werte haben vielleicht ±10m Fehler, meist deutlich darunter. Und natürlich trage ich diese Werte ein. Woher sollen die Werte denn sonst kommen? Nicht jeder weglose Übergang und nicht jede Wegweisertafel enthält eine Höhenangabe. Und wenn, dann das ist die Höhe auch gerne einer Karte entnommen und hat dann Höhenliniengenauigkeit (±20m). ...

So in etwas meinte ich das mit "hilfsweise in Ausnahmefällen".

Gruß Klaus

openzzz wrote:

Was habt ihr immer mit "Meinungen"? Es geht hier um Definitionen.

Offensichtlich ist nicht jeder unserer Meinung, wie weit die Definition verbindlich ist. Selbst Hersteller von Navigationsgeräten scheinen unterschiedlicher Ansicht zu sein, welche Teile der Definition auch in ihren Geräten berücksichtigt werden sollen.

Ist es überhaupt sinnvoll, überhall Höhen zu mappen? Vollständigkeit wird die Karte so ohnehin nicht bekommen und zuverlässig scheint es auch nicht zu sein. Interessant ist es bei Bergen, damit es auf der Karte erscheint. Fürs Fahrrad-Routing, Höhenlinien und hillshading muss man externe Höhendaten heranziehen. OSM-eigene Höhen wären dafür nur tauglich wenn sie eine gewisse Vollständigkeit haben. Dafür ist OSM gar nicht ausgelegt, denn dafür müssten alle Koordinaten in 3D gespeichert werden, nicht nur einzelne ele-Tags.

Geoidkorrektur kostet halt. Daran erkennt man Hersteller die jeden Cent einsparen wollen.
Garmin macht es in der Regel, Android-Handies oft nicht.

maxbe wrote:

Offensichtlich ist nicht jeder unserer Meinung, wie weit die Definition verbindlich ist. Selbst Hersteller von Navigationsgeräten scheinen unterschiedlicher Ansicht zu sein, welche Teile der Definition auch in ihren Geräten berücksichtigt werden sollen.

Ich weiss. Die Nachlässigkeit gibt's nicht nur bei OSM, sondern auch bei bekannten Herstellern.
Das ist aber keinen Grund, solche Bugs als Normalzustand zu akzeptieren.
Man muss eben immer wieder betonen, Datenformate korrekt zu definieren.
Bei NMEA-Chips gibt es machmal die Möglichkeit, die Korrektur ein/auszuschalten.
Der NMEA-Standard ist aber eindeutig, dass Höhe eine WGS84-Geoidhöhe ist.
Als 2. Stufe gibt es dann noch eine Korrekturmöglichkeit in der Software, die NMEA-Daten
verarbeitet. Aber der muss man dann auch wieder sagen, wenn der Chipset falsch liefert.

toc-rox wrote:

maxbe wrote:

Der Normalfall ist nicht der Mapper mit GPS, sondern der Mapper vor einem Schild.

Das ist auch gut so, denn die mit einem Consumer-GPS-Gerät gemessenen Höhenangaben sollten m.E. nicht (vielleicht hilfsweise in Ausnahmefällen) in OSM eingetragen werden. Sie sind zu ungenau ... da bringt auch die Angabe des Bezugssystem nichts.

Nein, Die Angaben auf Schildern sind oft ungenauer. Ich habe an verschiedenen Berggipfeln die Höhe per GPS gemessen. Es hängt zum Teil auch vom GPS Gerät ab, manche sind genauer manche nicht. Gute Erfahrungen habe ich mit den Garmin eTrex (10/20) gemacht deren Höhenmessung recht genau ist. Dabei habe ich auf Berggipfeln meist weniger als 3 Meter Abweichung von dem was topografische Karten sagen. Auf Berggipfeln ist der Empfang auch meist recht gut. Anders sieht es natürlich an anderen Punkten aus, die zum Beispiel in Schluchten liegen. Da ist der Empfang zu schlecht.

In der Soierngruppe im Karwendel gibt es eine ganze Reihe von Höhenangaben auf Schildern. Bei diesen habe ich eine deutliche Ungenauigkeit (festgestellt durch mehrfache Messung mit verschiedenen Geräten und zwar barometrisch und GPS) festgestellt, die über die Ungenauigkeit meines GPS definitiv hinaus geht. Manchmal ist also die Angabe des GPS besser, als die die auf einem Schild steht.

Gruß
unixasket

maxbe wrote:

Volle Zustimmung, bis auf

Das irische Beispiel finde ich sehr gut gelöst. Damit haben die Experten exakte Angaben und der Normalmapper muß nichts umrechnen

In Irland steht ele für "WGS84 über dem Ellipsoid", die Werte über dem Meer sind in "ele:local" und "ele:tm75" versteckt. Wer "ele" eintragen will, muss umrechnen, wobei mir einer erklären müsste, wie er das machen soll...

Dann hatte ich das falsch aufgefaßt. Dann korrigiere ich mich auf: Der irische Ansatz, nur umgekehrt mit ele für die Otto-Normaluser-Höhe.

bye, Nop

Nahmd,

openzzz wrote:

Ist es überhaupt sinnvoll, überall Höhen zu mappen?

Relevanzdiskussion, ick hör Dir trappsen.

Gruß Wolf

Ich hab's mal hierhin umgeleitet

seichter wrote:

...Nach meiner Erfahrung sind VDOP und HDOP nur bedingt als Qualitätsanzeiger geeignet. Das sind Werte, die die Firmware formal berechnet, die aber nur wenig mit tatsächlichem Fehlerbereich zu tun haben. Als besserer Indikator hat sich die Höhe herausgestellt. Es gibt keinen geometrischen Grund, weshalb die Höhe schlechter sein sollte als die horizontalen Werte. Sie wird nur längst nicht so stark durch die Firmware geglättet wie die horizontalen Koordinaten. Wenn es da unmotivierte Höhenänderungen gibt, ist fast immer auch der horizontale Track auf Abwegen.
Es lohnt sich also, einen Blick auf die Höhen zu werfen, die DOP-Werte haben bei mir ausgedient.

http://www.sapos.de/pdf/5symposium/145- … ndorff.pdf
"Satellitengeometrie und -bahnfehler:
Naturbedingt können bei der Positionsbestimmung am Erdboden Satelliten nur oberhalb
des Antennenstandpunktes beobachtet werden. Diese Tatsache führt zu einer gegenüber
den Lagekomponenten um mindestens Faktor 2 schlechteren Höhengenauigkeit (Santerre
1991). "

Das ist eigentlich die beste geometrische Erklärung für die mangelnde Höhengenauigkeit. Eine Halbebene wird abgeschattet und darum sind die Sat-Emitter senkrecht dazu weniger räumlich verteilt. Im Extremfall, wenn die Emitter ganz in einer Ebene liegen würden hätte man die schlechtmöglichste Höhenbestimmung, also im Prinzip gar keine mehr. Das ist so als wenn alle Sats in einer Linie stehen würden, wo dann auch 2 Dimensionen verloren gehen. Damit könnte dann bestenfalls noch ein Winkel bestimmt werden, aber keine Ortung mehr.

openzzz wrote:

Ist es überhaupt sinnvoll, überhall Höhen zu mappen? Vollständigkeit wird die Karte so ohnehin nicht bekommen und zuverlässig scheint es auch nicht zu sein. Interessant ist es bei Bergen, damit es auf der Karte erscheint. Fürs Fahrrad-Routing, Höhenlinien und hillshading muss man externe Höhendaten heranziehen.

Du beschreibst es eigentlich schon völlig richtig. Ein Mappen ist nur für bestimmte Stellen/Objekte sinnvoll, bei denen die punktuelle, absolute Höhe eine Rolle spielt (Berge, Pässe, Ortschaften, Meßpunkte...).

Für Routing usw. braucht man einen flächigen Verlauf und oft nur die Höhenunterschiede, dafür sind gemappte Höhen nutzlos.

bye, Nop

openzzz wrote:

Ich hab's mal hierhin umgeleitet

seichter wrote:

...Nach meiner Erfahrung sind VDOP und HDOP nur bedingt als Qualitätsanzeiger geeignet. Das sind Werte, die die Firmware formal berechnet, die aber nur wenig mit tatsächlichem Fehlerbereich zu tun haben. Als besserer Indikator hat sich die Höhe herausgestellt. Es gibt keinen geometrischen Grund, weshalb die Höhe schlechter sein sollte als die horizontalen Werte. Sie wird nur längst nicht so stark durch die Firmware geglättet wie die horizontalen Koordinaten. Wenn es da unmotivierte Höhenänderungen gibt, ist fast immer auch der horizontale Track auf Abwegen.
Es lohnt sich also, einen Blick auf die Höhen zu werfen, die DOP-Werte haben bei mir ausgedient.

http://www.sapos.de/pdf/5symposium/145- … ndorff.pdf
"Satellitengeometrie und -bahnfehler:
Naturbedingt können bei der Positionsbestimmung am Erdboden Satelliten nur oberhalb
des Antennenstandpunktes beobachtet werden. Diese Tatsache führt zu einer gegenüber
den Lagekomponenten um mindestens Faktor 2 schlechteren Höhengenauigkeit (Santerre
1991). "

Das ist eigentlich die beste geometrische Erklärung für die mangelnde Höhengenauigkeit. Eine Halbebene wird abgeschattet und darum sind die Sat-Emitter senkrecht dazu weniger räumlich verteilt. Im Extremfall, wenn die Emitter ganz in einer Ebene liegen würden hätte man die schlechtmöglichste Höhenbestimmung, also im Prinzip gar keine mehr. Das ist so als wenn alle Sats in einer Linie stehen würden, wo dann auch 2 Dimensionen verloren gehen. Damit könnte dann bestenfalls noch ein Winkel bestimmt werden, aber keine Ortung mehr.

OK, weil für die z-Komponente nur 180° zur Verfügung stehen, für x und y aber 360°, ist die statistische Verteilung für die horizontalen Werte günstiger, d.h. die Satelliten stehen öfter in günstiger Position. Das gibt aber nur einen Faktor von etwa 2, die Höhenschwankungen, die ich beobachtet habe, waren aber deutlich größer. Theoretisch sollten die Höhen viel langsamer variieren als die Horizontalen (Kunstflug und Raketenstarts mal ausgenommen), das habe ich bisher aber nur bei einem barometrisch unterstützten Gerät (Garmin Oregon) gesehen, bei den anderen gab es in der Ebene schön glatte Tracks, während die Höhe deutlich zappelt. Tracks auf Abwegen sahen oft für sich gar nicht schlecht aus, nur die Höhenwerte wanderten unmotiviert nach oben oder unten aus.

seichter wrote:

OK, weil für die z-Komponente nur 180° zur Verfügung stehen, für x und y aber 360°, ist die statistische Verteilung für die horizontalen Werte günstiger, d.h. die Satelliten stehen öfter in günstiger Position. Das gibt aber nur einen Faktor von etwa 2, die Höhenschwankungen, die ich beobachtet habe, waren aber deutlich größer. Theoretisch sollten die Höhen viel langsamer variieren als die Horizontalen (Kunstflug und Raketenstarts mal ausgenommen), das habe ich bisher aber nur bei einem barometrisch unterstützten Gerät (Garmin Oregon) gesehen, bei den anderen gab es in der Ebene schön glatte Tracks, während die Höhe deutlich zappelt. Tracks auf Abwegen sahen oft für sich gar nicht schlecht aus, nur die Höhenwerte wanderten unmotiviert nach oben oder unten aus.

Ja, subjektiv fand ich auch bisher alles relativ ungenau in der Höhe, schlimmer als Faktor 2. Aber ich hatte das nie systematisch untersucht. Ich hatte auch viele verschiedene Geräte benutzt, GPS-Mäuse, externe GPS-Logger, Pocket PC (SIRF-2), Auto-Navi (SIRF-3), Android (gpsOne) .... Die haben eben alle ihre Eigenheiten. Ich vermute oft wenn man über die GPS-Höhe meckert liegt es auch am falschen Höhenmodell. Dazu kommen noch die verschiedenen Einstellmöglichkeiten zur Geoid-Korrektur, sowohl im Chipset (per serielles Kommando) als auch in der App. Bei diesem Chaos hab ich nun überhaupt keinen Überblick mehr wo im Einzelnen die möglichen Fehlerquellen liegen. Im Zweifel in den Alpen habe ich mich einfach auf die Papierkarte verlassen. In den Bergen ist Multipath ohnehin ein KO-Kriterium für die GPS-Ortung. Auf dem Gipfel sollte es bei wunderbarer Satelliten-Sicht wieder genau sein. Mit kleinen Kindern gibt's aber normalerweise keine Gipfelkletterei.

Du hattest mal vermutet dass in der Höhe weniger gemittelt wird. Bisher hatte ich keine Hinweise, dass die Höhe da irgendwie anders behandelt werden soll. Rechnerisch arbeitet man erstmal in kartesischen ECEF-Koordinaten (erdmittenzentriert), wo die Höhe sowieso keine bestimmte Achse hat. Eine echte Mittelung gibt es auch nicht, sondern die zuverlässigere Kalman-Filterung. Was nur passieren kann: wenn es nur 3 Sats gibt reicht es nicht für eine 3D-Ortung. Dann ist aber eine 2D-Ortung möglich. Ich weiss nicht, was der Chip dann mit der Höhe macht (leeres NMEA-Feld? Geoid-Höhe als Default?).

Interessant an moderneren Chips ist wohl, dass neben GPS auch Glonass-Satelliten empfangen werden. Mit der höheren Sat-Zahl sollte dann auch die Höhenmessung besser funktionieren. Die Russen haben ihre Sat-Orbits 10° höher inkliniert als GPS, gut für die Genauigkeit in höheren Breitengraden.

chris66 wrote:

Geoidkorrektur kostet halt. Daran erkennt man Hersteller die jeden Cent einsparen wollen.
Garmin macht es in der Regel, Android-Handies oft nicht.

Mein billiges Samsung mit gpsOne-Chip von Qualcomm hat eine Geoid-Höhe im entsprechenden
NMEA-Datenfeld (mit "NMEA Recorder" App gesichtet).

Ich habe nur nicht herausbekommen, ob dieses NMEA direkt vom GPS-Chip gpsOne ausgelesen wird,
so wie bei den SIRFs über einen seriellen Port, oder ob es andere Schnittstellen gibt und NMEA
lediglich vom Android-Betriebssystem in der API simuliert wird.

Merkwürdig fand ich das GPGGA-Feld zur geoid separation, dass nicht die erwarteten 47m zeigt,
sondern 100m, als ob das die Höhe über Ellipsoid wäre.

Die Apps gehen auch unterschiedlich heran. Die App "GPS Test" zeigt mir die Höhe über Geoid,
nach NMEA-Standard, "GPS Status" ca. 50 m mehr. Orux wieder die NMEA-Höhe und OsmAnd
wieder einen zu hohen Wert. Aber was das alles ist, welche Systeme, darüber gibt es nichts
in den Datenblättern.

Es wäre schön, wenn sich die Chipsätze, Hersteller und App-Programmierer einfach
mal stur an Definitionen halten würden. Dann hätten wir das Chaos nicht.
Netzwolf mag das ja alles lustig finden, als "Dookratie". Aber mich nervt das total.
Den Ingenieuren und Programierern dürfte es zumutbar sein, vor der Arbeit einmal
die Definitionen der Datenfelder zu checken. NMEA ist da sehr eindeutig, als Höhe über WGS84-Geoid.
Alles andere könnte man umrechnen, wenn die Datengrundlage konsistent ist.

openzzz wrote:

Netzwolf mag das ja alles lustig finden, als "Dookratie". Aber mich nervt das total.
Den Ingenieuren und Programierern dürfte es zumutbar sein, vor der Arbeit einmal die Definitionen der Datenfelder zu checken. NMEA ist da sehr eindeutig, als Höhe über WGS84-Geoid.

Ich finde diese Diskussion auch lustig, sowas passiert, wenn sich Fachleute über die echte Welt unterhalten.

Für 95% der Mapper und 99.9% der Bevölkerung sieht eine Höhenangabe so aus:

ältere Leser werden vielleicht so etwas vor Augen haben:

Da steht kein Höhenbezugssystem, da ist auch keine Stellschraube am Barometer für WGS/NHN/MüA/NN. Die Leute kennen das gar nicht und die tragen das auch nicht ein (Irland hat das ja auch nicht durch mappen, sondern einen Import bekommen). Die nehmen einfach die 510 aus dem Höhenmesser oder die 1808 vom Schild und tragen das bei ele ein. Zum Glück lesen sie vorher nicht das Wiki und lassen sich verwirren 😉

Grüße, Max

Nahmd,

maxbe wrote:

[…] sowas passiert, wenn sich Fachleute über die echte Welt unterhalten.

😄 🤣 😎

Gruß Wolf

maxbe wrote:

Da steht kein Höhenbezugssystem, da ist auch keine Stellschraube am Barometer für WGS/NHN/MüA/NN. Die Leute kennen das gar nicht und die tragen das auch nicht ein (Irland hat das ja auch nicht durch mappen, sondern einen Import bekommen). Die nehmen einfach die 510 aus dem Höhenmesser oder die 1808 vom Schild und tragen das bei ele ein. Zum Glück lesen sie vorher nicht das Wiki und lassen sich verwirren 😉
Grüße, Max

Tja, das ist eben die Informationsgesellschaft. Wenn alles vernetzt wird muss man Standards harmonisieren. Sonst kommt so ein Murks raus, dass OSM entweder in Irland oder in Deutschland falsche Werte anzeigt. Wie die armen Mapper das vor Ort eintragen ist natürlich ein anderes Problem. Da sollten auch die Editoren Unterstützung liefern, dass man dort sein "Eingabesystem" konfigurieren kann. Muss ja gar nicht der Aufwand sein, dass für jede Angabe nach dem System gefragt wird, sondern per Default nach dem Motto "ich pinne nur von Schildern ab" oder "ich lese von meinem Gerät ab". Aber selbst da sollte sich der Mapper klar sein welche Höhen sein Gerät genau anzeigt. Sonst würde man Äpfel mit Birnen vergleichen. Ein bisschen Mitdenken kann man auch vom Mapper verlangen. Dass wir bei Eingabe und bei der Kartenansicht "Gebrauchshöhen" also DHHN92 anzeigen ist ja wohl Konsens von allen. Darum verstehe ich deinen Einwand nicht. Aber Informationssysteme brauchen eben klare Standards. Es geht nicht, dass die Iren einen anderen Standard als Deutsche für die gleiche Datenbank und das gleiche Datenfeld benutzen.

p.s. was haben die Bugs in den Geräten mit den OSM-Mappern zu tun?
Da wird seit Jahren im Umgang mit dem NMEA-Standard geschlampt. Ich will auch ohne OSM meine Höhe mit der Topo-Karte vergleichen können.
Das bisher einzig verlässliche ist die amtliche Topo-Karte, weil die Vermessungsingenieure streng ein Höhenmodell konsequent umgesetzt haben.

maxbe wrote:

Nakaner wrote:

Ich hatte den Eindruck, dass openzzz gemeint hat, die Differenz DHHN92 zu WGS84 sei <1 m.

Ach so. Nee, wir müssten uns schon die Werte bei amerikanischen Behörden im 15-Minuten-Raster für umsonst holen oder bei unserem Staat im 1-Minuten-Raster kaufen 😉

Max, von 45.96m über dem Ellipsoid (kostenlos) oder 46.5m (kostenpflichtig) grüßend

Lustig, nach 2 Posts habt ihr schon ein System durcheinandergebracht.

Meine Frage war nach dem Unterschied von WGS84 Höhe über Geoid zur DHHN92-Höhe. Das sind keine 45m.

WGS84 definiert zwei verschiedene Höhen, einmal die Höhe über WGS84/EGM96 Geoid und einmal Höhe über WGS84-Referenzellipsoid (GRS 80-Nachfolger). NMEA aus den GPS-Geräten liefert erstere. Ob Garmins daraus nochmal ein DHHN92 approximieren weiss ich nicht. Manche Consumer-Geräte liefern auch letzteren Wert, wobei das aber dem Standard widerspricht. Darum hat GPS-Software oft noch eine Korrektureinstellung als Workaround gegen diesen Fehler.

maxbe wrote:

Max, von 45.96m über dem Ellipsoid (kostenlos) oder 46.5m (kostenpflichtig) grüßend

Bald ist ja Weihnachten:

Den Deutsches Kombiniertes Quasigeoid 2011 gibt's im Online Shop für schlappe 750 Euros. 😎

Moin,

openzzz wrote:

maxbe wrote:

Die nehmen einfach die 510 aus dem Höhenmesser oder die 1808 vom Schild und tragen das bei ele ein. Zum Glück lesen sie vorher nicht das Wiki und lassen sich verwirren 😉

Tja, das ist eben die Informationsgesellschaft. Wenn alles vernetzt wird muss man Standards harmonisieren. Sonst kommt so ein Murks raus, dass OSM entweder in Irland oder in Deutschland falsche Werte anzeigt. Wie die armen Mapper das vor Ort eintragen ist natürlich ein anderes Problem. Da sollten auch die Editoren Unterstützung liefern, dass man dort sein "Eingabesystem" konfigurieren kann. Muss ja gar nicht der Aufwand sein, dass für jede Angabe nach dem System gefragt wird, sondern per Default nach dem Motto "ich pinne nur von Schildern ab" oder "ich lese von meinem Gerät ab". Aber selbst da sollte sich der Mapper klar sein welche Höhen sein Gerät genau anzeigt. Sonst würde man Äpfel mit Birnen vergleichen. Ein bisschen Mitdenken kann man auch vom Mapper verlangen.

ich würde mich eher mal von dem Gedanken lösen, jemals "definierte" Werte in ele=* vorzufinden.
Max hat die Ursache dafür völlig korrekt beschrieben - das bleibt bei PI*Auge.

Für definierte Werte gibt es die ele:xyz=*
Denn wenn sich "die Mapper" schon so technische Gedanken machen (müssen), kann man das auch gleich im Tag festhalten.
Dann kann wenigstens jeder "sein" Bezugssystem mit angeben - und alle können etwas damit anfangen.

Vor allem: Der Wert wird nicht gleich wieder vom nächsten "Feld-Wald-Wiesen-Mapper" (*) korrigiert!
"Auf dem Schild vor Ort steht doch was Anderes!" - was weiß der "Feld-Wald-Wiesen-Mapper" schon, auf welchem Standard die Angabe beruht.

Gruß
Georg

(*) Ist jetzt absolut nicht abwertend gemeint - bezüglich Höhenangaben würde auch ich selbst alles in ele verwursten, was ich so vor Ort finde.

GeorgFausB wrote:

ich würde mich eher mal von dem Gedanken lösen, jemals "definierte" Werte in ele=* vorzufinden.
Max hat die Ursache dafür völlig korrekt beschrieben - das bleibt bei PI*Auge.

Aber genau das vermurkst die OSM-Karte.

Die ele= Werte werden auf die Karte als Berghöhen geschrieben. Das muss einheitlich sein. Der Zustand jetzt ist doch unhaltbar. Da konfiguriert man auf Gebrauchshöhen und hat in Irland doch wieder ellipsoide Höhen.

Das muss klar definiert werden, entweder als "Gebrauchshöhe", also lokale Höhe, ellipsoide WGS84-Höhe oder geoide WGS84-Höhe.
Wenn sich alle daran halten kann man auch Karten danach zeichnen.

Was meinst du was ich von meiner topografischen Karte halten würde, wenn man sich auf die Höhenangaben da nicht mehr verlassen könnte.

Nun, was ist zu machen? Vermutlich macht es am meisten Sinn, die ele-Höhe wie im Wiki angedeutet als
WGS84-Geoid-Höhe zu definieren. Das passt zum NMEA-Standard und wäre eine weltweit durchsetzbare Definition
und würde Konsistenz im Datenbestand ermöglichen. Auch sonst ist OSM bei den 2D-Koordinaten im WGS84-Modell
festgelegt und nicht in den länderspezifischen Systemen (Gauß-Krüger, Lambert, ED50, etc.).

Ich vermute zum DHHN92 ist der Unterschied so klein (< 1m), dass wir ihn mit OSM-typischer Genauigkeit
vernachlässigen könnten. Lediglich die Iren müssten dann von ellipsoider zu geoider Höhe konvertieren.

Moins,

openzzz wrote:

[…] Wenn alles vernetzt wird muss man Standards harmonisieren. Sonst kommt so ein Murks raus, dass OSM entweder in Irland oder in Deutschland falsche Werte anzeigt. Wie die armen Mapper das vor Ort eintragen ist natürlich ein anderes Problem. Da sollten auch die Editoren Unterstützung liefern, dass man dort sein "Eingabesystem" konfigurieren kann. Muss ja gar nicht der Aufwand sein, dass für jede Angabe nach dem System gefragt wird, sondern per Default nach dem Motto "ich pinne nur von Schildern ab" oder "ich lese von meinem Gerät ab". Aber selbst da sollte sich der Mapper klar sein welche Höhen sein Gerät genau anzeigt. Sonst würde man Äpfel mit Birnen vergleichen. Ein bisschen Mitdenken kann man auch vom Mapper verlangen. Dass wir bei Eingabe und bei der Kartenansicht "Gebrauchshöhen" also DHHN92 anzeigen ist ja wohl Konsens von allen. Darum verstehe ich deinen Einwand nicht. Aber Informationssysteme brauchen eben klare Standards. Es geht nicht, dass die Iren einen anderen Standard als Deutsche für die gleiche Datenbank und das gleiche Datenfeld benutzen.

”Muss”, “sollte”, ”verlangen”, “geht nicht” … hey! Das ist schlecht für den Blutdruck!
Mach daraus ein “kann”, “wäre schön, wenn”, “kann man bitten”, “wäre schön, wenn nicht”, und Du lebst gesünder.

Bitte akzeptiere einfach, dass “ele” ein Feld ähnlich wie “name” ist und nichts mit irgendwelchen Elliposioden, Geoiden oder was auch immer zu tun. Oder vielleicht auch irgendwie schon. Oder doch nicht? Sind wir nicht alle ein bisschen?

Du vergeudest an dieser Stelle Deine Energie und schadest Deiner Gesundheit. Und das ist doof! Denn ich geh davon aus, dass Du sehr kompetent bist, wir brauchen kompetente Mitstreiter, und deshalb hoffe ich (ganz egoistisch), dass Du uns länger erhalten bleibst!

Gruß Wolf

GeorgFausB wrote:

Für definierte Werte gibt es die ele:xyz=*

In meiner Gemeinde gibt's mittlerweile über 300 ele:NHN Knoten.

Jetzt müsste mir zur Kontrolle und Visualisierung nur noch jemand eine Karte bauen,
welche das Straßennetz anzeigt, wobei die Segmente je nach Steigung
gefärbt sind. 😎

Edit: Update der Anzahl

chris66 wrote:

In meiner Gemeinde gibt's mittlerweile über 100 ele:NHN Knoten.

Du solltest zusätzliche Tags "ele" anlegen, ansonsten haben nicht alle was davon.

Gruß Klaus

Hallo Chris,

chris66 wrote:

In meiner Gemeinde gibt's mittlerweile über 100 ele:NHN Knoten.

Sehr schön.

http://wiki.openstreetmap.org/wiki/Key:ele:NHN so und nur so wird ein Schuh draus. Was noch schön wäre, ist ein Verweis im Wiki auf den entsprechenden EPGS-Code: 5783. Da in Deutschland nur relativ wenige verschiedene Höhensysteme auftreten (können), sollte mann diese auch gleich mit tabellarisch nennen.

Sven

openzzz wrote:

...
Nun, was ist zu machen? Vermutlich macht es am meisten Sinn, die ele-Höhe wie im Wiki angedeutet als
WGS84-Geoid-Höhe zu definieren. Das passt zum NMEA-Standard und wäre eine weltweit durchsetzbare Definition
und würde Konsistenz im Datenbestand ermöglichen. Auch sonst ist OSM bei den 2D-Koordinaten im WGS84-Modell
festgelegt und nicht in den länderspezifischen Systemen (Gauß-Krüger, Lambert, ED50, etc.).

Ich vermute zum DHHN92 ist der Unterschied so klein (< 1m), dass wir ihn mit OSM-typischer Genauigkeit
vernachlässigen könnten. Lediglich die Iren müssten dann von ellipsoider zu geoider Höhe konvertieren.

1+
(auch für nur einmal "müssten")
Weltweit zu denken finde ich nicht nur bei OSM wichtig.

Netzwolf wrote:

Moins,
”Muss”, “sollte”, ”verlangen”, “geht nicht” … hey! Das ist schlecht für den Blutdruck!
Mach daraus ein “kann”, “wäre schön, wenn”, “kann man bitten”, “wäre schön, wenn nicht”, und Du lebst gesünder.
Gruß Wolf

So schreibt man keine Standards. "Wäre schön, wenn ihr die IP-Adresse als 128 Bit auslegt". Meine Güte, das Internet würde zusammenbrechen, wenn jeder das auslegt wie er will. Die OSM-Karte ist zwar nicht so elementar, aber wenn ein Deutscher in Irland 50 Meter weiter als erwartet zum Gipfel klettern muss ist das auch nicht gut für den Blutdruck :-) Man kann sich den Murks auch schönreden. Es wäre schön, wenn OSM sich etwas am Anspruch der topografischen Karte orientiert, wo man sich auch auf ein einheitliches korrektes Koordinatensystem verlassen kann.

openzzz wrote:

So schreibt man keine Standards.

Wir schreiben keine Standards. Wir wenden sie an und die verwendeten Tags und Werte müssen ausreichend und nachvollziehbar dokumentiert werden und bereits etablierte Standards sollten so gut es geht ver- und angewendet werden.

Siehe auch Vorschläge und Umsetzungen zu den Höhenangaben: hier, hier und hier.

Sven

Nahmd,

chris66 wrote:

In meiner Gemeinde gibt's mittlerweile über 100 ele:NHN Knoten.

Sehr schön.

Du hättest aber nach dem Vermessen die Theodolithen wegräumen können!

Gruß Wolf

streckenkundler wrote:

Wir schreiben keine Standards. Wir wenden sie an und die verwendeten Tags und Werte müssen ausreichend und nachvollziehbar dokumentiert werden und bereits etablierte Standards sollten so gut es geht ver- und angewendet werden.
Sven

Doch, projektinterne Standards. Die Straßentypen sind auch OSM-intern durchstandardisiert. So ist garantiert, dass aus einer Autobahn in der Datenbank eine Autobahn in der Karte wird. In den Anfängen waren die Straßenkategorien nicht so ganz klar definiert, was an länderspezifischen Unterschieden lag. OSM hat seinen Ursprung halt in England. OSM kann aber international nur funktionieren, wenn man sich auf Standards einigt. Der Betrachter ist zwar meist auf ein Land fixiert, aber die Software (Renderer, Smartphone-Apps, Routingapps) muss exakt wissen wie die Daten zu interpretieren sind. Es wäre doch schade, wenn eine OSM-App nur in Deutschland funktioniert und in England wieder eine Neue installiert werden muss.

Nahmd,

openzzz wrote:

So schreibt man keine Standards.

Das Wiki enthält keine Standards. Das Wiki enthält freundliche Empfehlungen.

Meine Güte, das Internet würde zusammenbrechen, wenn jeder das auslegt wie er will.

OSM gibt es schon ein paar Jahre. Und ist noch nicht zusammengebrochen. Es wächst und gedeiht.

Es wäre schön, wenn OSM sich etwas am Anspruch der topografischen Karte orientiert, wo man sich auch auf ein einheitliches korrektes Koordinatensystem verlassen kann.

Es wäre doch schade, wenn […]

(Hervorhebung durch mich)

Wer sagt's denn? Du bist auf dem richtigen Weg.

Wäre schön™, wenn Du so weitermachst.

Gruß Wolf

BTW: es wäre auch schön, wenn die Bearbeiter nur korrekte Tags und Values verwenden würden, dann bräuchte Oli-Wan nicht den Aufwand in den Aufräum-Robot zu stecken. Es wäre auch schön, wenn die API Konsistenzkriterien durchsetzen würden, z.B. nodelose oder minderbenodete Ways zurückweisen und defekte “type=multipolygon” Relationen ablehnen. Es wäre auch schön, wenn mehr Hausnummern erfasst würden, das würde hausnummerngenaues Routing erlauben. Wäre auch schön, wenn mehr lanes erfasst würde, das würde OSM-Navisoftware das "rechts halten, dann links halten" erlauben.

@Netzwolf. Danke für die Karte, hast Du bestimmt einige Sekunden dran gebastelt. 😉

Netzwolf wrote:

OSM gibt es schon ein paar Jahre. Und ist noch nicht zusammengebrochen. Es wächst und gedeiht.

Und Wildwuchs wird durch rechtzeitige Standardisierung eingedämmt.
Ich kann mich noch an das anfängliche Chaos mit den Straßenhierarchien erinnern,
wo man versucht hatte, die Deutschen Klassen auf die Englischen zu mappen.
Zum Glück ist das jetzt weitgehend durchstandardisiert.

Es ist zwar für Deutsche und US-Amerikaner sehr lustig, einen Feldweg als "highway"
zu titulieren. Es kommt aus dem British English und OSM hat das standardisiert.
Das Karten-Rendering funktioniert nur, wenn alle sich daran halten und
in Deutschland nicht alles "highways" als Autobahnen gerendert werden.

Nahmd,

chris66 wrote:

@Netzwolf. Danke für die Karte, hast Du bestimmt einige Sekunden dran gebastelt. 😉

Mindestens!

Beim Lesen Deines Beitrags hatte ich das “survey_point”-Symbol von JOSM vor Augen, und dann konnte ich nicht mehr wiederstehen. 🙂

Es sollte aber jemand ein Karte auf Basis der OP-API bauen, meine zeigt einen Tag alte Daten.

Gruß Wolf

Nahmd,

openzzz wrote:

wenn ein Deutscher in Irland 50 Meter weiter als erwartet zum Gipfel klettern muss ist das auch nicht gut für den Blutdruck :-)

Die Murkskarten von da oben kannste ohnehin inner Pfeife rauchen. In Nord-England (Lake-Distrikt) war ich auf nem 4000er. Kein Gletscher weit und breit zu sehn, der war bis oben hin grün. Aber als 4000er erfasst! Was für ein Müll!

Gruß Wolf

Netzwolf wrote:

Es sollte aber jemand ein Karte auf Basis der OP-API bauen, meine zeigt einen Tag alte Daten.

Skandal! Als nächstes läßt Du womöglich noch Wahlbezirke und Laternen rendern. Bist Du überhaupt ISO 9001-zertifiziert?

Netzwolf wrote:

In Nord-England (Lake-Distrikt) war ich auf nem 4000er. Kein Gletscher weit und breit zu sehn, der war bis oben hin grün.

Haben die vielleicht in Fuß gemessen?

Netzwolf wrote:

Aber als 4000er erfasst! Was für ein Müll!

m versus ft?

Gruss
walter

ps: bin mal gespannt, wann ihr von eurem "Höhenrausch" runterkommt - langsam wird's peinlich uninteressant.

Netzwolf wrote:

Das Wiki enthält keine Standards. Das Wiki enthält freundliche Empfehlungen.

Ok, hier mal etwas zum Nachlesen:
http://de.wikipedia.org/wiki/Standard

Das Internet wurde auf "Requests for Comments" ("Bitte um Kommentare") aufgebaut.
Die RFC sind de facto Standards. Kein Hersteller würde es wagen der
RFC 791 zu widersprechen, weil dann das ganze Internet zusammenbrechen würde.

"Standard" bedeutet nicht, dass eine internationale Standardisierungsbehörde
Vorschriften macht. Bei meinen eigenen Projekten setze ich mir auch am Anfang
Standards, um meine Daten auf eine sichere Grundlage zu stellen.
Für eine Community wie OSM ist das noch wichtiger, weil nur so eine
Zusammenarbeit möglich ist.

Es gibt immer Ignoranten, die sich um Standards nicht scheren oder es nicht
für nötig halten vor einer Datenerfassung nach den entsprechenden Felddefinitionen
zu fragen. Genau die sind halt dafür verantwortlich, dass Irische und Deutsche Berge
in verschiedenen Systemen gemappt werden. Der Fehler ist schon ziemlich signifikant.

Nahmd,

Oli-Wan wrote:

Skandal! Als nächstes läßt Du womöglich noch Wahlbezirke und Laternen rendern.

Darüber ließe sich reden. Aber bei der jetzt möglichen detaillgenauen Erfassung der Laternen muss ich zuerst einen Laternen-Icon-Generator bauen. Ein paar nicht mehr EU zugelassene Glühlampen ausm Keller tuns auch.

Bist Du überhaupt ISO 9001-zertifiziert?

ISO 9000 ist was für Anfänger!

Eine Längeneinheit ist an mir geeicht:

Netzwolf wrote:

In Nord-England (Lake-Distrikt) war ich auf nem 4000er. Kein Gletscher weit und breit zu sehn, der war bis oben hin grün.

Haben die vielleicht in Fuß gemessen?

Ahhhh! Das wird es sein. Hmpf! Da hätte ich selbst drauf kommen sollen. 🤔

Gruß Wolf

Edit: Elektroschrott ausm Keller einer verwendung zugeführt.

Netzwolf wrote:

Darüber ließe sich reden. Aber bei der jetzt möglichen detaillgenauen Erfassung der Laternen muss ich zuerst einen Laternen-Icon-Generator bauen.

Hilfe .......
Ich baue dann mal lieber meine Android-Radhalterung wieder aus
und schraube die alte Papierhalterung wieder ran.

Die topografischen Karten werden schon seit hunterten Jahren nicht
mit Wahlkreisen und Straßenlaternen zugekleistert.

Nahmd,

openzzz wrote:

Für eine Community wie OSM ist das noch wichtiger, weil nur so eine
Zusammenarbeit möglich ist.

Jetzt wo Du's sagst: womöglich liegt es daran, dass OSM seit acht Jahren auf der Stelle tritt und keinerlei bzw. nur völlig unbrauchbare Ergebnisse liefert.

Ganz im Gegensatz dazu das Galileo-Projekt, das durch vorbildliche Planung jeden einzelnen Projektmeilenstein bereits weit vor der gesetzten Frist erreicht hat. Dieses ist aber auch etwas besser finanziert als OSM, das muss man der Fairness halber dazuschreiben.

Gruß Wolf

@Wambacher: das OsmForenFilter-Greasemonkey-Skript läuft bereits. Ich will noch die Config aus dem Code raus und in ein Cookie reinnehmen, danach stelle ich das bereit. Damit kann man per Klick Themen oder Autoren ausblenden, eine wichtige Funktion, die die verwendete Foren-Software leider nicht unterstützt-

Ist mein Ironie-Detektor kaputt oder fehlt uns ein Facepalm-Smiley? Wenn Netzwolf sich eine Darstellung von etwas bastelt heisst das nicht, dass das plötzlich auf allen OSM-Karten auftaucht…

Netzwolf wrote:

...

openzzz wrote:

wenn ein Deutscher in Irland 50 Meter weiter als erwartet zum Gipfel klettern muss ist das auch nicht gut für den Blutdruck :-)

Die Murkskarten von da oben kannste ohnehin inner Pfeife rauchen. In Nord-England (Lake-Distrikt) war ich auf nem 4000er. Kein Gletscher weit und breit zu sehn, der war bis oben hin grün. Aber als 4000er erfasst! Was für ein Müll!

Bitte tu das den Iren nicht an 😬 Wirf sie nicht mit Engländern in einen Topf. 🙄 Das wäre so ähnlich wie Düsseldorfern und Kölnern Gemeinsamkeiten zu unterstellen 😛
Immerhin war Irland bei der großen Bereinigungsaktion ein (oder das?) Land mit den wenigsten Dingen, die weggeputzt werden mussten.

Netzwolf wrote:

Nahmd,

openzzz wrote:

Für eine Community wie OSM ist das noch wichtiger, weil nur so eine
Zusammenarbeit möglich ist.

Jetzt wo Du's sagst: womöglich liegt es daran, dass OSM seit acht Jahren auf der Stelle tritt und keinerlei bzw. nur völlig unbrauchbare Ergebnisse liefert.

Nein definitiv nicht. OSM funktioniert nur deshalb recht gut, weil man es geschafft hat aus dem anfänglichen Chaos weltweit akzeptierte Mapping-Standards für OSM durchzubringen. Auch durch Wiki-Hilfe, also kooperative Standardisierung. Bei den Straßentypen war das anfangs gar nicht so einfach.

Was hat das mit Galileo zu tun? Die Probleme da sind doch etwas komplexer, weil sich verschiedene Länder jahrelang nicht einigen konnten.

Apropos Greasemonkey: kann der auch Informatiker-Humor ausfiltern? Ich stehe eher auf britische Comedy.

Nochmal zum Thema. Das wird hier leicht vergessen:
gibt es hier Leute die sich mit den Höhenmodellen auskennen?
Konkret war die Frage nach dem Unterschied zwischen der Höhe über WGS84-Geoid
und den hiesigen amtlichen Normalhöhen.
Ist der Unterschied signifikant, oder regt man sich hier nur künstlich auf?
Im besten Falle könnte man die Definition im Wiki belassen (WGS84-Geoid) und den Fehler auf
der deutschen Karte tolerieren. Dann würde das zu korrekt nach NMEA-Norm arbeitenden
GPS-Receivern passen, die ebenfalls die WGS84-Geoid-Werte ausspucken.
Wer exakt nach DHHN92 taggt müsste das dann eben dazuschreiben.

Netzwolf wrote:

Nahmd,

openzzz wrote:

wenn ein Deutscher in Irland 50 Meter weiter als erwartet zum Gipfel klettern muss ist das auch nicht gut für den Blutdruck :-)

Die Murkskarten von da oben kannste ohnehin inner Pfeife rauchen. In Nord-England (Lake-Distrikt) war ich auf nem 4000er. Kein Gletscher weit und breit zu sehn, der war bis oben hin grün. Aber als 4000er erfasst! Was für ein Müll!

Gruß Wolf

Ruhig blut, du willst mit OSM-Karten ja nicht zum Mars fliegen.

Nahmd,

hurdygurdyman wrote:

Bitte tu das den Iren nicht an 😬 Wirf sie nicht mit Engländern in einen Topf. 🙄

Einheitentechnisch tun die sich nichts. 😛

Der Unterschied zwischen den Ländern ist mir spätestens bekannt, seit ich während der WM in London gefragt habe, was die weißen Fahnen mit dem roten Kreuz an den Autofenstern bedeuteten.

Was man den Engländern hoch anrechnen muss: ich hab es überlebt.

Gruß Wolf

Netzwolf wrote:

...was die weißen Fahnen mit dem roten Kreuz an den Autofenstern bedeuteten.

...ich hab es überlebt.

Na ja, Ersthelfer bemühen sich doch Leben zu retten, statt es zu zerstören 😄

openzzz wrote:

Nochmal zum Thema
Konkret war die Frage nach dem Unterschied zwischen der Höhe über WGS84-Geoid und den hiesigen amtlichen Normalhöhen. Ist der Unterschied signifikant, oder regt man sich hier nur künstlich auf?

Kannst ja ausprobieren: Hier ein paar Koordinaten eintippen (EGM96, über WGS84-Ellipsoid), und hiermit (GCG2011 über ETRS89) vergleichen. Meine 5 Testfälle lagen unter 1 Meter, zu mehr hatte ich keine Lust.

Grüße, Max

Danke für die seriöse Antwort.

Mit diesen Werten hatte ich auch schon gespielt. Ich war mir nur nicht sicher was ich als ellipsoidische Höhen eintragen soll. Aber anscheinend benutzt ETRS89/DHHN92 das gleiche Ellipsoid wie WGS84, nur eben ein etwas anderes Geoid. Meine eigene GPS-Messung (NMEA-Feld: Höhe über WGS84-Geoid) passte auch relativ gut zur Top50-Karte der Landesvermessung (aber erst mit der richtigen App, die sich an den NMEA-Standard hält, OsmAnd macht es nicht und zeigte irgendwas undefiniertes was auch nicht zur ellipsoid-Höhe passt). Also können wir die Wiki-Definition zum ele-Tag als WGS84-Geoidhöhe stehen lassen, so wie es auch in NMEA definiert ist, oder? D.h. in Deutschland liegt der Fehler <1m zum NHN-Höhensystem. Das wäre tolerierbar. Die Irischen WGS84-Ellipsoidhöhen sind dagegen signifikant verschieden und müssten dann in das WGS84-Geoid-System konvertiert werden, um endlich mal Konsistenz in die Höhendaten zu bekommen.

Also können wir die Wiki-Definition zum ele-Tag als WGS84-Geoidhöhe stehen lassen, so wie es auch in NMEA definiert ist, oder? D.h. in Deutschland liegt der Fehler <1m zum NHN-Höhensystem. Das wäre tolerierbar. Die Irischen WGS84-Ellipsoidhöhen sind dagegen signifikant verschieden und müssten dann in das WGS84-Geoid-System konvertiert werden, um endlich mal Konsistenz in die Höhendaten zu bekommen.

Schön, das es jetzt wohl doch weiter in Richtung WG84 geht...
...aber die Iren müssen gar nichts.
Wenn wir das so wünschen, müssen wir den Rest der Welt ins Boot holen und weltweiten Konsens herbeiführen.

openzzz wrote:

... anscheinend benutzt ETRS89/DHHN92 das gleiche Ellipsoid wie WGS84, nur eben ein etwas anderes Geoid.

Ja, fast. ETRS89 ist zu WGS84 ein bisschen verschoben. Aber um den Meter in der Horizontalen müssen wir uns keine Sorgen machen, wenn wir bestenfalls alle paar Kilometer einen Punkt des Geoids haben.

openzzz wrote:

Also können wir die Wiki-Definition zum ele-Tag als WGS84-Geoidhöhe stehen lassen, so wie es auch in NMEA definiert ist, oder? D.h. in Deutschland liegt der Fehler <1m zum NHN-Höhensystem. Das wäre tolerierbar. Die Irischen WGS84-Ellipsoidhöhen sind dagegen signifikant verschieden und müssten dann in das WGS84-Geoid-System konvertiert werden, um endlich mal Konsistenz in die Höhendaten zu bekommen.

Jo. Wobei wir überhaupt nicht wissen, was andere Länder so in den ele-Werten haben. Im deutschsprachigen Bereich wissen wir es aus Erfahrung. Bei den Iren fällt es nur auf, weil die ihre Werte schön systematisch eingetragen haben (ausserhalb Irlands gibt es auch nur sporadische Vorkommen von "ele:wgs84"). Wenn man das standardisieren will, kommt man um eine weltweite Diskussion nicht rum.

openzzz wrote:

Die Irischen WGS84-Ellipsoidhöhen sind dagegen signifikant verschieden und müssten dann in das WGS84-Geoid-System konvertiert werden, um endlich mal Konsistenz in die Höhendaten zu bekommen.

Dir ist aber schon bewusst, dass OpenStreetMap ein freies Projekt ist, an dem nur Ehrenamtliche mitarbeiten? Müssen tut hier keiner was.

Wenn du jemanden zu etwas zwingen willst, wirst du schneller auf taube Ohren stoßen als dir lieb ist. An einer Konsensentscheidung wirst du in OSM nicht rumkommen.

Gruß JohnDoe

JohnDoe23 wrote:

openzzz wrote:

Die Irischen WGS84-Ellipsoidhöhen sind dagegen signifikant verschieden und müssten dann in das WGS84-Geoid-System konvertiert werden, um endlich mal Konsistenz in die Höhendaten zu bekommen.

Dir ist aber schon bewusst, dass OpenStreetMap ein freies Projekt ist, an dem nur Ehrenamtliche mitarbeiten? Müssen tut hier keiner was.
Wenn du jemanden zu etwas zwingen willst, wirst du schneller auf taube Ohren stoßen als dir lieb ist. An einer Konsensentscheidung wirst du in OSM nicht rumkommen.
Gruß JohnDoe

Ich denke da der Wiki-Eintrag schon jahrelang existiert dürfte das Konsens sein.
Natürlich kann jeder die OSM verunstalten wie er will. Bei Wikipedia wird da schnell wieder aufgeräumt.
Wer sagt etwas von Zwingen? Ich denke es liegt im Interesse Aller, dass die Höhenangaben konsistent sind, auch der Iren.
Vermutlich haben die auch nicht bewusst falsch gehandelt, eben nur einen Fehler beim Import der Daten gemacht,
in Unkenntnis des Höhenkoordinatensystems. Das ist korrigierbar. Umso leichter, wenn das ganze Land falsche Werte hat.

maxbe wrote:

Jo. Wobei wir überhaupt nicht wissen, was andere Länder so in den ele-Werten haben. Im deutschsprachigen Bereich wissen wir es aus Erfahrung. Bei den Iren fällt es nur auf, weil die ihre Werte schön systematisch eingetragen haben (ausserhalb Irlands gibt es auch nur sporadische Vorkommen von "ele:wgs84"). Wenn man das standardisieren will, kommt man um eine weltweite Diskussion nicht rum.

Das ist eigentlich schon genügend international ausdiskutiert. Da OSM auf WGS84 Horizontalkoordinaten festgelegt ist,
was wäre dann naheliegender als auch die Höhenkoordinaten nach WGS84 festzulegen?

Der WGS84-Geoid ist nach dem Schwerefeld der Erde angepasst. Zu den nationalen Höhen "Über Meeresspiegel" wird es weltweit keine sehr großen Abweichungen geben. Daher würde es auch weniger auffallen, wenn die Mapper dort ihre nationalen Koordinaten eintragen, die sich vom WGS84-Geoidmodell nur <1m unterscheiden.

openzzz wrote:

...
Ich denke es liegt im Interesse Aller, dass die Höhenangaben konsistent sind, auch der Iren.
Vermutlich haben die auch nicht bewusst falsch gehandelt, eben nur einen Fehler beim Import der Daten gemacht,
in Unkenntnis des Höhenkoordinatensystems. Das ist korrigierbar. Umso leichter, wenn das ganze Land falsche Werte hat.

Dann nimm doch mal Verbindung mit mackerski auf. Der Ire ist nicht nur sehr OSM-community-aktiv, sondern spricht/schreibt auch noch fließend deutsch.

edit: Name berichtigt

hurdygurdyman wrote:

Dann nimm doch mal Verbindung mit mackerski auf. Der Ire ist nicht nur sehr OSM-community-aktiv, sondern spricht/schreibt auch noch fließend deutsch.

Bevor wir die Iren zu einer Konvertierung drängen, sollten wir aber definitiv Klarheit über die Standardisierung dieses ele-Tags haben. Das ist nicht leicht wenn andauernd die Notwendigkeit einer Standardisierung bezweifelt wird. Wir brauchen da schon einen weltweiten Konsens innerhalb OSM. Wollt ihr etwa mit dem Argument nach Irland gehen "wir machen das so als Dookratie in Deutschland, also bitte macht das auch so"? Ein vernünftigeres Argument wäre "wir haben den ele-Tag OSM-weit zur WGS84-Geoidhöhe standardisiert, könnt ihr bitte konsistent dazu bleiben".

Ich habe erstmal die Programmierer gefragt, was sie von der Wiki-Definition halten. Für Software sind klare Einheiten und Koordinatensysteme des Datenbestandes enorm wichtig. Die Vorlieben der Mapper sind bekannt - sie wollen das Schild am Gipfel abpinnen - oder für die Couchsurfer unter uns - von der Wikipedia abschreiben. In Geoinformationssystemen gibt es darum interne Datenbestände vereinheitlicht und nach außen hin für den Benutzer konfigurierbar. Der "Geogrid Viewer" der amtlichen Karten (Top 25/50) kennt eine ganze Reihe von geodätischen Koordinatensystemen zur Anzeige und Eingabe, die umschaltbar sind. Gut, der JOSM ist nicht so ausgefeilt, aber bei Normung auf WGS84-Geoidhöhe würde man zu noch tolerierbaren Fehlern kommen, wenn Mapper das nationale System nicht kennen oder nicht angeben wollen.

Man könnte natürlich gleich das nationale System als ele-Höhe defnieren, aber das wäre international kein eleganter Ansatz und passt nicht zum WGS84 2D-Modell in OSM. OSM als GPS-gestützte Karte ist schon etwas Besonderes. Im Katasteramt könnte man das nicht machen, weil die Grundstücke dann bis zu 20cm/Jahr gegen das weltweite Koordinatensystem wegdriften würden. Über die Jahre hinweg summiert sich daraus durchaus Anlass für Grundstücksstreitigkeiten. Nationale Systeme bleiben also wichtig (siehe NRW-Atlas). Um exakt zu bleiben müsste man die Koordinaten auf einer OSM/GPS-Karte je nach Kontinentalplatte regelmäßig verschieben. Ich hoffe ich löse damit jetzt keinen Flamewar über 2D-Koordinaten aus. Bitte sachlich bleiben.

openzzz wrote:

hurdygurdyman wrote:

Dann nimm doch mal Verbindung mit mackerski auf. Der Ire ist nicht nur sehr OSM-community-aktiv, sondern spricht/schreibt auch noch fließend deutsch.

Bevor wir die Iren zu einer Konvertierung drängen, sollten wir aber definitiv Klarheit über die Standardisierung dieses ele-Tags haben. Das ist nicht leicht wenn andauernd die Notwendigkeit einer Standardisierung bezweifelt wird. Wir brauchen da schon einen weltweiten Konsens innerhalb OSM. Wollt ihr etwa mit dem Argument nach Irland gehen "wir machen das so als Dookratie in Deutschland, also bitte macht das auch so"? Ein vernünftigeres Argument wäre "wir haben den ele-Tag OSM-weit zur WGS84-Geoidhöhe standardisiert, könnt ihr bitte konsistent dazu bleiben".
...

Wer spricht denn von drängen? fakt ist, dass in Irland offensichtlich ein homogenes ele-tagging besteht, das bei den hier angedachten Lösungen komplett umgestrickt werden müsste, was aber wegen der Homogenität einfach wäre.

Auch dein Ansatz "könnt ihr bitte konsistent dazu bleiben" ist für mich noch eine Art von Drängelei. Besser wäre: "Könnt ihr euch auch vorstellen, das so auch mit zu machen, weil weltweit dieses und jenes dafür spricht und der gesamten community und den Auswertungen diese und jene Vorteile bringt."

Den Sprung in die Welt kann man dann ja auch noch machen, wobei eine Auswertung nach ele-tags pro Nation sicher für eine "Priortisierung" hilfreich wäre.

Leute, es ist völlig egal was für eine komplizierte Definition man sich ausdenkt und ins Wiki schreibt.

Ein normal denkender Mensch würde für extrem simple Dinge nie auf die Idee kommen, überhaupt im Wiki nachzusehen. Er mappt einfach das was er vor seiner Nase sieht. Zu diesen simplen, alltäglichen Dingen gehören z.B. Sackgassen, Einbahnstraßen und eben Höhenmeter.

Das heißt die einzige Wahl die man beim ele Tag noch hat ist,
1. ob das Wiki etwas akademisch unrealistisches beschreibt und es mehrheitlich ignoriert wird (jetziger Zustand)
2. ob man das beschreibt was der Realität entspricht oder
3. ob man es durch etwas noch viel komplizierteres ersetzt, daß dann erst recht mehrheitlich ignoriert wird.

Für exakte Expertenwerte ist ein neues Tag nötig, daß dann auch nur von den Experten gemäß ihrer Expertendefinition benutzt wird.

bye, Nop

hurdygurdyman wrote:

Wer spricht denn von drängen? fakt ist, dass in Irland offensichtlich ein homogenes ele-tagging besteht, das bei den hier angedachten Lösungen komplett umgestrickt werden müsste, was aber wegen der Homogenität einfach wäre.

Gut, drängen ist vielleicht zu hart ausgedrückt. Sagen wir, sie auf die Diskrepanz zur Wiki-Definition hinweisen, wenn wir alle sie im Konsens anerkennen. Dann werden sie schon aus Eigeninteresse ihre Karte zu korrigieren. Die großen Renderer und Smartphone-Apps werden definitiv nicht für Irland oder Deutschland eine Extrawurst rendern. Ich weiss nicht was die da oben auf ihren Schildern haben. OsmAnd kann von Meter auf Fuß umgestellt werden. Wenn alles perfekt harmonisiert ist, Einheiten und Koordinatensysteme richtig umgerechnet, stimmt dann auch die OsmAnd-Anzeige auf dem Berggipfel ungefähr zur Angabe auf dem Schild. Das erwarten wir doch alle von OSM, oder?

Der Aufwand zur Konvertierung ist vermutlich gering, wenn man Tools wie PROJ nutzen kann:
http://trac.osgeo.org/proj/
Das kann ganze Datensätze automatisch konvertieren. Mir hat es oft geholfen, Koordinaten aus
Gauß-Krüger-Karten (die amtlichen Topokarten) nach WGS84 zu konvertieren.
Noch etwas jünger ist der Support für die Vertikale:
http://trac.osgeo.org/proj/wiki/VerticalDatums
Die WGS84-Geoide sind wohl schon drin. Da die Iren nicht das Irish grid genommen haben
ist die Transformation damit machbar.

toc-rox wrote:

chris66 wrote:

In meiner Gemeinde gibt's mittlerweile über 100 ele:NHN Knoten.

Du solltest zusätzliche Tags "ele" anlegen, ansonsten haben nicht alle was davon.

Gruß Klaus

Ok, laut Wiki ist mit ele die Höhe über Sea-Level gemeint, also eindeutig die Geoid-korrigierte Höhe
und nicht die Höhe über dem WGS84 Ellipsoid.

Werde dann mal zu ele umtaggen. Und eventuell ele:source=NRW Atlas hinzufügen.

Chris

chris66 wrote:

Ok, laut Wiki ist mit ele die Höhe über Sea-Level gemeint, also eindeutig die Geoid-korrigierte Höhe
und nicht die Höhe über dem WGS84 Ellipsoid.
Werde dann mal zu ele umtaggen. Und eventuell ele:source=NRW Atlas hinzufügen.
Chris

Du kannst die NHN-Tags auch stehen lassen, wenn das die exakten Werte sind.
Die Tags können dann so interpretiert werden, das die Tags mit Systemangabe die exakten sind
und die ele-Tags zwar auf der Karte angezeigt werden, aber noch kleine Unterschiede
zwischen den Geoidmodellen haben (DHHN92-Geoid vs. WGS84-Geoid), die noch
in der Toleranzschwelle liegen (< 1m). Für die exakte Umrechnung in den WGS84-Geoiden
bräuchte man wohl den kommerziellen (teuren) Datensatz, was den Aufwand zu Nutzen
nicht rechtfertigt.

Jetzt müssten wir nur noch den Iren erklären, dass sie auf das WGS84-Geoidmodel umsteigen ...
Zum Glück gibt es dazu freie Tools wie PROJ, so dass keine kommerziellen Geoidmodelle nötig sind.

p.s. soll ich das Wiki etwas präzisieren?
Sinngemäß steht es schon so drin "as defined by WGS84", aber man könnte noch konkret
dazuschreiben dass wir das WGS84-Geoidmodel meinen und nicht das WGS84-Ellipsoidmodell.
Und eine wichtige Info, dass die lokalen Höhensysteme näher am WGS84-Geoidmodell liegen,
mit einem tolerierbaren Fehler. So käme dann keiner mehr auf die Idee, die Ellipsoidhöhen
in das ele-Tag zu schreiben. Und die etwas unbedarften Mapper wissen dann, dass sie auch
die Schilder abschreiben können. Man kann gerne bewußt Fehler machen, sollte aber wissen
in welcher Größenordnung die liegen. 40 m Höhenfehler durch Systemirrtum sind in meinen Augen
weit oberhalb der Toleranzgrenze. Das würden wir in OSM auch nicht für die Horizontale akzeptieren.

Ist "NHN" eigentlich eine international anerkannte Systemabkürzung? Vielleicht sollte man die
Tabelle im Wiki noch durch eine Spalte ergänzen in der Abkürzungen für ele:SYSTEM= definiert
werden. Etwas unklar ist mir "wgs84", weil in WGS84 zwei verschiedene Höhen definiert sind.

Nahmd,

chris66 wrote:

toc-rox wrote:

chris66 wrote:

In meiner Gemeinde gibt's mittlerweile über 100 ele:NHN Knoten.

Du solltest zusätzliche Tags "ele" anlegen, ansonsten haben nicht alle was davon.

Dem stimme ich zu.

chris66 wrote:

Werde dann mal zu ele umtaggen. Und eventuell ele:source=NRW Atlas hinzufügen.

Kopieren ist richtig. Umtaggen vernichtet Information und ist deshalb falsch.

Wenn ich irgendwo eine offensichtlich aus einem Schulatlas abgepinnte Höhe vorfinde (ele:source=NRW Atlas), werde ich die nämlich möglicherweise durch die hochpräzise (±2m) Höhe meines barometrischen Höhenmessers überschreiben.

Lass das “ele:NHN” stehen. Zersöre nicht Deine eigene Arbeit.

Gruß Wolf

openzzz wrote:

Ist "NHN" eigentlich eine international anerkannte Systemabkürzung? Vielleicht sollte man die
Tabelle im Wiki noch durch eine Spalte ergänzen in der Abkürzungen für ele:SYSTEM= definiert
werden. Etwas unklar ist mir "wgs84", weil in WGS84 zwei verschiedene Höhen definiert sind.

NHN steht für "Normalhöhennull" (HN=Höhennull, NN=Normalnull). Statt NHN wird oft auch die Bezeichnung DHNN92 (Deutsches Haupthöhnnetz 1992) verwendet. Beides sind deutsche Abkürzungen, für die es anscheinend keine offiziellen englischen Übersetzungen gibt. Auf der Beschreibungsseite zu EPSG:5783 steht "DHHN92 height". Ich würde es frei als "German Main Height Network 1992" übersetzen.

streckenkundler wrote:

http://wiki.openstreetmap.org/wiki/Key:ele:NHN so und nur so wird ein Schuh draus. Was noch schön wäre, ist ein Verweis im Wiki auf den entsprechenden EPGS-Code: 5783. Da in Deutschland nur relativ wenige verschiedene Höhensysteme auftreten (können), sollte mann diese auch gleich mit tabellarisch nennen.
Sven

Nakaner wrote:

NHN steht für "Normalhöhennull" (HN=Höhennull, NN=Normalnull). Statt NHN wird oft auch die Bezeichnung DHNN92 (Deutsches Haupthöhnnetz 1992) verwendet. Beides sind deutsche Abkürzungen, für die es anscheinend keine offiziellen englischen Übersetzungen gibt. Auf der Beschreibungsseite zu EPSG:5783 steht "DHHN92 height". Ich würde es frei als "German Main Height Network 1992" übersetzen.

Hmm, das hatte ich befürchtet. Für ele:SYSTEM=... braucht man eine international akzeptierte Klassifikation.
NN wäre nicht eindeutig. Und NHN ein deutsches Phänomen.
Bei den GIS-Profis hat sich der EPSG-Code durchgesetzt. Alternativ könnte man den auch setzen oder in der Wiki-Tabelle erwähnen.
Für den OSM-Gebrauch sind die wohl eher unpraktisch. Ich könnte mir solche Zahlen nicht merken.

Die Tabelle hat eine Spalte mit dem Systemnamen. Leider können die nicht alle als ele-Subkey genutzt werden.
Was gibt es da eigentlich für Namensregeln. Leerzeichen ist sicher nicht erlaubt, das "-" auch? Klein/Großschreibung?
Am besten nimmt man da eine klare Kurzform, so wie "DHHN92". Also noch eine Spalte wo genau
die ele:SYSTEM Subkeys definiert werden.
Wie kommt man eigentlich dorthin: http://wiki.openstreetmap.org/wiki/Key:ele:NHN ?
Von der ele-Seite gibt es da keine Referenz. Der Mapper braucht irgendwie eine Übersicht dazu.

"WGS84" ist nicht ganz klar. Die WGS84-Geoidhöhe wurde schon als "ele"-Tag festelegt.
"WGS84" könnte dann die WGS84-Ellipsoidhöhe sein, aber das wird nirgendwo klargestellt.
Die Iren haben es in ele:wgs84 praktiziert, diese dann aber gleich noch ins ele-Tag dupliziert.
Eindeutiger wäre etwas wie ele:wgs84_ellipsoid, ele:wgs84_geoid, schreibt sich aber nicht so schön.
Eine elegante Lösung fällt mir momentan nicht ein.

Ich habe das DE/EN-Wiki mal präzisiert was die Geoid/Ellipsoid-Höhen in WGS84 angeht.
Es ist wichtig, dass Mapper die beiden nicht verwechseln und wissen, dass der Unterschied
von WGS84-Geoidhöhe zur "Gebrauchshöhe" tolerierbar klein ist, d.h. dass er auch die
Schilder-Angaben ins ele-Tag schreiben darf. Eine eindeutige Definition ist aber wichtig für Software,
damit sie keine Länderspezifischen Render-Regeln als Workaround fahren muss.

openzzz wrote:

Wie kommt man eigentlich dorthin: http://wiki.openstreetmap.org/wiki/Key:ele:NHN ?
Von der ele-Seite gibt es da keine Referenz.

Wenn Du in taginfo nach ele:NHN suchst und dann auf Wiki klickst.
Ist eine "Schnellschuss-Seite" von mir. Mittlerweile tendiere ich ja schon wieder Richtung ele. 😎

chris66 wrote:

Wenn Du in taginfo nach ele:NHN suchst und dann auf Wiki klickst.
Ist eine "Schnellschuss-Seite" von mir. Mittlerweile tendiere ich ja schon wieder Richtung ele. 😎

Die Tags selbst brauchen eine klare Definition.
Wie man die dann einsetzt könnte man als "best practice" Empfehlung geben.

Bei NHN/DHHN92 aus amtlichen Karten würde es Sinn machen sowohl ele als auch ele:DHHN92 zu taggen
z.b. für die trigonometrischen Meßpunkte.
Denn der ele-Tag ist der einzige der gerendert wird, also den primären Nutzen hat.
Der Tag mit Systemangabe gibt an, dass man sich auf die Genauigkeit eher verlassen kann, wenn
man diesen Punkt irgendwie als Referenz oder Eichwert benutzen will. Und dann wäre der Zahlenwert direkt
mit den amtlichen Höhen der Berge vergleichbar. Mit umgerechneten, approximativen oder unsicheren Werten
aus den ele-Tags hätte man immer Zweifel.
Dass es auf den Meter ankommt zeigen die Niederländer: Ihren höchsten Punkt im Aachener Dreiländereck
haben sie mit einem künstlichen Hügel ca. einen Meter angehoben. Wohl aus dem Grund, weil sonst der
Höchste Punkt der Niederlande nicht die "Berg"spitze wäre, die dann stattdessen in Belgien oder Deutschland liegen würde.
Mit ele:NHN und ele:source=dutch_fake hätte man etwas mehr Gewissheit um die entscheidenden letzten Meter.

Zum Taginfo:
man muss ele:NHN schon explizit aufrufen, sonst gibt's ein Sammelsurium von Tags
nach "ele" keyword (ele, elevation, election ...). Außerdem gibts das Akronym gleich doppelt:
"ele:NHN" und "ele:nhn" in unterschiedlichen Fallzahlen. Ist OSM case-sensitive?
Naja, das hat man dann davon wenn man Keys nicht klar durchdefiniert.
Gibt's eigentlich eine Regel für die Subkey-Syntax? "ele:local" und "ele_local" kommen
etwa gleich häufig vor (und scheint mir auch nicht sauber definiert zu sein).

Taginfo liefert keine übersichtliche Liste der Subkeys, die man für ele verwenden könnte.
Das müssten wir dann schon im Wiki machen.

Ja, OSM (die DB) ist case-sensitiv.

Ich habe das DE/EN-Wiki mal präzisiert

Sehr schön.

openzzz wrote:

"WGS84" ist nicht ganz klar. Die WGS84-Geoidhöhe wurde schon als "ele"-Tag festelegt.
"WGS84" könnte dann die WGS84-Ellipsoidhöhe sein, aber das wird nirgendwo klargestellt.
Die Iren haben es in ele:wgs84 praktiziert, diese dann aber gleich noch ins ele-Tag dupliziert.
Eindeutiger wäre etwas wie ele:wgs84_ellipsoid, ele:wgs84_geoid, schreibt sich aber nicht so schön.
Eine elegante Lösung fällt mir momentan nicht ein.

Ich möchte WGS84e und WGS84g vorschlagen.
Sinnvoller Weise sollte man sich auch auf eine Schreibweise einigen. Für die Großschreibung spricht die Tatsache, dass es sich um eine Abkürzung handelt. Gegen die Großschreibung spricht einerseits der Aufwand so etwas zu tippen und andererseits die OSM-Regel die Kleinschreibung zu bevorzugen.

openzzz wrote:

Ich habe das DE/EN-Wiki mal präzisiert ,was die Geoid/Ellipsoid-Höhen in WGS84 angeht.
Es ist wichtig, dass Mapper die beiden nicht verwechseln und wissen, dass der Unterschied
von WGS84-Geoidhöhe zur "Gebrauchshöhe" tolerierbar klein ist, d.h. dass er auch die
Schilder-Angaben ins ele-Tag schreiben darf. Eine eindeutige Definition ist aber wichtig für Software,
damit sie keine Länderspezifischen Render-Regeln als Workaround fahren muss.

Schön, dass wir jetzt nach langer Diskussion zum konstruktiven Teil kommen.

Sehr gut, dass du auf die beiden WGS84 Höhen (Ellipsoid und Geoid-korrigiert) besonders eingehst. Der Unterschied war mir erst durch die aktuelle Diskussion klar geworden. Aus der älteren Wiki-Definition konnte ich das nicht entnehmen.

Ob die Aussage, dass die WGS-Geoid-Höhe nur gering von den lokalen Systemen abweicht auch für andere Länder als Deutschland gilt, insbesondere wenn die einen anderen Bezugpegel verwenden (Kronštadt für Polen, Tschechei, Slovakei, Ungarn und Russland, Marseile/Ajaccio für Frankreich/Korsika, ...) wäre noch zu klären/prüfen.
Insbesondere außerhalb Europas liegt das WGS84-Geoid sicherlich ebenso näher am lokalen System als das Referenz-Elipsoid wie in Europa. Ob das jedoch auch mit so geringen (für OSM tolerierbaren) Unterschieden wie in Deutschland (<1m) ist, bleibt noch zu prüfen.

Es geht voran
Edbert (EvanE)

EvanE wrote:

Ich möchte WGS84e und WGS84g vorschlagen.
Sinnvoller Weise sollte man sich auch auf eine Schreibweise einigen. Für die Großschreibung spricht die Tatsache, dass es sich um eine Abkürzung handelt. Gegen die Großschreibung spricht einerseits der Aufwand so etwas zu tippen und andererseits die OSM-Regel die Kleinschreibung zu bevorzugen.

Ok. Nehmen wir mal als Vorschlag. Normalerweise neige ich dazu, die Schlüsselwörter von Datenfeldern auszuschreiben, weil das die eindeutigste Kennzeichung ist. Physiker machen gerne 1-Buchstaben-Kürzel, wo man später immer rätseln muss was gemeint war, und vor allem Konflikte mit anderen Bezeichnern unausweichlich sind. Für OSM muss es natürlich bequem einzutippen sein.

Vielleicht gibt's aus der GIS-Community noch ein paar praktische Erfahrungen wie man die beiden abkürzen würde (außer mit EPSG-Codes).

EvanE wrote:

Sehr gut, dass du auf die beiden WGS84 Höhen (Ellipsoid und Geoid-korrigiert) besonders eingehst. Der Unterschied war mir erst durch die aktuelle Diskussion klar geworden. Aus der älteren Wiki-Definition konnte ich das nicht entnehmen.

Standardisierung ist für mich immer Teil einer Entwicklung. Große Softwaresysteme, Datenbanken und Projekte können nur so funktionieren. Das ist auch Arbeit, genauso wie das Programmieren oder Datenbanken mit Inhalten zu füllen. Wenn man das nicht gründlich macht hat man später nur mehr Arbeit, indem Umprogrammiert werden muss oder Datenbestände umgearbeitet werden müssen. Wo etwas unpassend definiert worden ist oder die Definition unklar ist muss man nacharbeiten. Das würde ich nicht schleifen lassen. Siehe Inkonsistenz der Deutschen und Irischen Höhenwerte.

EvanE wrote:

Ob die Aussage, dass die WGS-Geoid-Höhe nur gering von den lokalen Systemen abweicht auch für andere Länder als Deutschland gilt, insbesondere wenn die einen anderen Bezugpegel verwenden (Kronštadt für Polen, Tschechei, Slovakei, Ungarn und Russland, Marseile/Ajaccio für Frankreich/Korsika, ...) wäre noch zu klären/prüfen.
Insbesondere außerhalb Europas liegt das WGS84-Geoid sicherlich ebenso näher am lokalen System als das Referenz-Elipsoid wie in Europa. Ob das jedoch auch mit so geringen (für OSM tolerierbaren) Unterschieden wie in Deutschland (<1m) ist, bleibt noch zu prüfen.

Da bin ich mir selbst auch noch unsicher. Leider habe ich dazu bisher nur eine einzige seriöse Antwort bekommen.
Die deutschen Systeme untereinander haben ja wirklich nur minimale Abweichungen im Zentimeter-Bereich.
Wenn ich das richtig verstehe sind hier beide Geoide so um die 50m vom Ellipsoiden entfernt
(wobei die Geoide verschieden sind und der Ellipsoid vom DHHN92 offenbar der Gleiche wie in WGS84).
Bei meinem GPS-Logger kommt das hin, aber mein Android zeigt 100m "geoidal separation" im entsprechenden
NMEA GPGGA-Feld. Für die Geoidhöhe zeigen beide wieder das gleiche an.
Ich vermute einfach dass Android die NMEA-Logs selbst generiert hat und nicht vom gpsOne Chipset durchreicht.
Und bei der Gelegenheit gleich den NMEA-Standard missachtet. Schlamperei bei NMEA ist leider bei den
Herstellern weit verbreitet.

Soweit ich das verstehe orientiert sich der WGS84-Geoid am Schwerepotential. Das lässt sich weltweit gut durchsetzen.
Auch der Meeresspiegel richtet sich grundsätzlich danach aus. Im "mean sea level" wurde der Tidenhub schon ausgemittelt.
Der Unterschied Mittelmeer/Nordsee liegt bei 27 cm:
http://www.spiegel.de/panorama/planungs … 81837.html
So in der Größenordnung hätten wir dann Abweichungen in europäischen Systemen.

Hat jemand Erfahrung aus Übersee?

Übrigens gibt's hier eine schöne Erklärung zur geodätischen Höhe.
Unsere Restfrage dreht sich dann wohl nur noch um den Unterschied Geoid vs. Quasigeoid.
http://de.wikipedia.org/wiki/H%C3%B6he_ … 3%A4sie%29

p.s. es gab innerhalb OSM mal Verwirrung um die Sprachregelung "elevation" vs. "altitude".
Die Engl. Wikipedia hat dazu ein schönes Schaubild:
http://en.wikipedia.org/wiki/Altitude
demach:
- height: Höhe über Grund
- altitude: absolute (Flug)Höhe (über NN) eines Objektes
- elevation: absolute Höhe (über NN) im Sinne von Erhebung eines Berges
Mir selber war das auch unklar. Ich kannte "elevation" nur als Höhenwinkel.

für andere Länder als Deutschland gilt, insbesondere wenn die einen anderen Bezugpegel verwenden (Kronštadt für Polen, Tschechei, Slovakei, Ungarn und Russland, Marseile/Ajaccio für Frankreich/Korsika, ...) wäre noch zu klären/prüfen.

Amsterdam zu Kronstädter its 14 cm laut Wikipedia

Ps: bin wieder da ;-)

Edit:
Mist, ausersehen auf Code gedrückt

Edit:
Code weggemacht

habe mal etwas im Internet rumgelesen und da sind dann Begriffe wie
homogen, sphärisch, gerechnet .... und lauter so unverständliche Wörter aufgetaucht. 🙂

bedeutet das jetzt das eine gemessene Höhe von Freiberg zum Fichtelberg sagen wir mal 1500 Meter sind
und bei WGS84 10 Meter mehr sind weil das hingerechnet ist? 🙄

1. Edit
natürlich habe ich neu geschrieben wer soll es denn sonst mitbekommen das ich was geschrieben habe

FGOSM22 wrote:

bedeutet das jetzt das eine gemessene Höhe von Freiberg zum Fichtelberg sagen wir mal 1500 Meter sind
und bei WGS84 10 Meter mehr sind weil das hingerechnet ist?

Freiberg liegt 400 Meter über dem Meer, der Fichtelberg 1214m (sagt Wikipedia). In Freiberg ist die Differenz zwischen Meereshöhe und dem WGS84-Ellipsoid 44.35 Meter, am Fichtelberg 45.96 Meter (sagt die NGA). In dieser Größenordnung um 1m liegen die Fehler, wenn man sich in einer kleineren Region um die 100km bewegt.

Grüße, Max

maxbe wrote:

FGOSM22 wrote:

bedeutet das jetzt das eine gemessene Höhe von Freiberg zum Fichtelberg sagen wir mal 1500 Meter sind
und bei WGS84 10 Meter mehr sind weil das hingerechnet ist?

Freiberg liegt 400 Meter über dem Meer, der Fichtelberg 1214m (sagt Wikipedia). In Freiberg ist die Differenz zwischen Meereshöhe und dem WGS84-Ellipsoid 44.35 Meter, am Fichtelberg 45.96 Meter (sagt die NGA). In dieser Größenordnung um 1m liegen die Fehler, wenn man sich in einer kleineren Region um die 100km bewegt.

Hallo Max

In DE:Key:ele steht jedoch, man soll die 'korrigierte' Höhe über dem Geoid nehmen.

"Für das Markieren in OpenStreetMap sollte der Bezugspunkt zur Meereshöhe gesetzt werden, so wie es mit dem World Geodetic System in der revision WGS 84 definiert ist (Höhe über WGS84/EGM96 Geoid, auch als "korrigierte" WGS84-Höhe bezeichnet)."

Mit der korrigierten Höhe (das Geoid berücksichtigt) sollte die Differenz nicht bei rund 44-45m wie bei einer Höhe über dem rein rechnerischen Elipsoid liegen sondern in der Größenordnung von ca. einem Meter.
Leider ist die Aussage "Höhe nach WGS84" alleine nicht eindeutig, ob das über dem Elipsoid oder dem Geoid (EGM96) gerechnet ist (wie die wiederkehrenden Diskussionen zeigen). Für OSM-Zwecke soll nur die korrigierte Geoid-Höhe verwendet werden, die weltweit sehr viel näher an den regionalen Höhenreferenz-Systemen liegt, als die Höhe über dem (rein rechnerischen) WGS-Elipsoid.

Edbert (EvanE)

Die Höhe die am Fichtelberg steht ist mir egal da ist eben der 0,00 Punkt wo anders.

Das aber eine höhen Differenz von einem Meter vom gemessenen zum gerechneten Elipsoid zwischen Freiberg und dem Fichtelberg sein soll?

FGOSM22 wrote:

Die Höhe die am Fichtelberg steht ist mir egal da ist eben der 0,00 Punkt wo anders.

Das aber eine höhen Differenz von einem Meter vom gemessenen zum gerechneten Elipsoid zwischen Freiberg und dem Fichtelberg sein soll?

• Wenn Du Wikipedia oder einen Reiseführer oder eine Karte liest (*), gehst Du in Freiberg bei 400m weg und kommst auf dem Fichtelberg auf 1214m an. Du kannst auf stolz auf 1214-400=814 Höhenmeter zurückblicken.
• Wenn Du einen Höhenmesser hast, der den Luftdruck misst, wird er je nach Wetterlage andere Werte anzeigen. Du befolgst aber die Gebrauchsanleitung, stellst ihn in Freiberg auf irgendeine Höhe (z.B. 400), und er wird Dir am Fichtelberg eine Höhe anzeigen, die um 814 Meter höher liegt (z.B. 1214).
• Falls Dein GPS-Empfänger eine Geoid-Korrektur eingebaut hat, wird er Dir in Freiberg 400 anzeigen und auf dem Fichtelberg 1214. Du hast 814 Höhenmeter zurückgelegt.
• Falls Dein GPS-Empfänger keine Geoid-Korrektur eingebaut hat, zeigt er Dir in Freiberg 400+44.35=444.35 Meter an und auf dem Fichtelberg 1214+45.96=1259.96 Meter. Du hast also 815.6 Meter zurückgelegt. 160cm mehr.

Es gibt übrigens kein "errechnetes und gemessenes Ellipsoid". Das was man misst, ist eben leider kein schöner einfacher elliptischer Körper oder sogar eine Kugel, sondern die wirklich vorhandene Erdform voller Dellen und Beulen (damit sind nicht die Berge und Täler gemeint, sondern die Form, die der Meeresspiegel annehmen würde, wenn man einen schmalen und tiefen Kanal von der Küste über Freiberg bis zum Fichtelberg graben würde). Ein Ellipsoid ist eine Näherung an diese verbeulte Form, damit man damit einfacher rechnen kann.
Nach dem Rechnen korrigiert man seine Ergebnisse um die Höhe der Dellen und Beulen, um wieder auf die Werte zu kommen, die man auch messen würde. Dummerweise sparen sich manche GPS-Geräte diese Korrektur und geben die Höhe über dem Ellipsoid aus.

Grüße, Max

(*) Ich bin sicher, es gibt auch Reiseführer und Karten, die für Freiberg 395 oder 405 und für den Fichtelberg 1215 oder 1210 angeben...

maxbe wrote:

sondern die Form, die der Meeresspiegel annehmen würde, wenn man einen schmalen und tiefen Kanal von der Küste über Freiberg bis zum Fichtelberg graben würde). Ein Ellipsoid ist eine Näherung an diese verbeulte Form, damit man damit einfacher rechnen kann.

.

Grüße, Max

(*) Ich bin sicher, es gibt auch Reiseführer und Karten, die für Freiberg 395 oder 405 und für den Fichtelberg 1215 oder 1210 angeben...

LOL, also diese Erklärung ist ja mal das beste was ich bis jetzt gelesen habe. Danke
@maxbe du bist der beste. 🙂

Eine kleine Frage noch,
Die Beulen und Dellen die da der graben im Profil hätte
kommen die von den Gezeiten oder vom Schwerefeld, oder wie sich das nennt?
Oder von beiden

Besten Dank

FGOSM22 wrote:

Die Beulen und Dellen die da der graben im Profil hätte
kommen die von den Gezeiten oder vom Schwerefeld, oder wie sich das nennt?

Das zweite.

FGOSM22 wrote:

kommen die von den Gezeiten oder vom Schwerefeld, oder wie sich das nennt?

Falls du es noch nicht wusstest: Die Erde ist eine Kartoffel.

Hier etwas detaillierter: http://www.goce-projektbuero.de/7758--~ … aesie.html

walter

Thomas8122 wrote:

FGOSM22 wrote:

Die Beulen und Dellen die da der graben im Profil hätte
kommen die von den Gezeiten oder vom Schwerefeld, oder wie sich das nennt?

Das zweite.

Das ging ja schnell. 🙂

Danke

1.Edit
die Gezeiten wären mir lieber gewesen ;-)

wambacher wrote:

FGOSM22 wrote:

kommen die von den Gezeiten oder vom Schwerefeld, oder wie sich das nennt?

Falls du es noch nicht wusstest: Die Erde ist eine Kartoffel.

Hier etwas detaillierter: http://www.goce-projektbuero.de/7758--~ … aesie.html

walter

Das wusste ich.
Was mir aber noch niemand erklär e n konnte:
Wenn ich ne Runde durch die Galaxis drehe. Sieht die Erde immer rund aus.

Kannste mir das erklären.

Bisher wurde ich immer weggeschickt wenn ich danach gefragt habe
Vielleicht auch weil es ein ungünstiger Zeitpunkt was 😎

Wenn man einen Fußball maßstabsgetreu verformen würde sieht er halt immer noch rund aus.

chris66 wrote:

Wenn man einen Fußball maßstabsgetreu verformen würde sieht er halt immer noch rund aus.

der is aber auch vorher rund

und mit der Rotationsgeschwindigkeit kann das ja auch nix zu tun haben?
da müssten wir uns alle festhalten 😛

FGOSM22 wrote:

chris66 wrote:

Wenn man einen Fußball maßstabsgetreu verformen würde sieht er halt immer noch rund aus.

der is aber auch vorher rund

Ein Fussball hat 22cm Durchmesser. Wenn du ihn um 220mm/300=0.7 mm zusammendrückst, hast Du ungefähr die Form der elliptischen Erde.

Jetzt nimmst Du den gequetschten Ball und kratzt 0.002mm tiefe Dellen rein. Das entspricht ungefähr der Abweichung von Elipsoid und Erdform (bei 12000km Erddurchmesser und 100m Abweichung: 100Meter Abweichung /12000000Meter Erddurchmesser * 220mm Balldurchmesser).

Seit 2006 darf ein Weltmeisterschaftsball nur noch 0.1% von der Kugel abweichen, sagt Wikipedia. Mit 1/300=0.3% wäre die "Erdkugel" also nicht mehr FIFA-tauglich, aber sehen würdest Du weder die Abflachung noch die Mikrometer grossen Dellen.

Grüße, Max

Edit: Geoid Ellipsoid

FGOSM22 wrote:

Was mir aber noch niemand erklär e n konnte:
Wenn ich ne Runde durch die Galaxis drehe. Sieht die Erde immer rund aus.

Die Erde hat einen Durchmesser von ca. 13000 km, da müsste man schon sehr genau hinsehen, wenn man Abweichungen im Meterbereich sehen wollte. Mit bloßem Auge aus dem Weltall sieht man nicht einmal die elliptische Abweichung von der Kugelgestalt (einige zig km) auf Grund der Erddrehung. Aber messbar ist es u.a. mit speziellen Satellitensensoren (Altimeter) und über Bahnstörungen von Satelliten allgemein.

seichter wrote:

FGOSM22 wrote:

Was mir aber noch niemand erklär e n konnte:
Wenn ich ne Runde durch die Galaxis drehe. Sieht die Erde immer rund aus.

Die Erde hat einen Durchmesser von ca. 13000 km, da müsste man schon sehr genau hinsehen, wenn man Abweichungen im Meterbereich sehen wollte. Mit bloßem Auge aus dem Weltall sieht man nicht einmal die elliptische Abweichung von der Kugelgestalt (einige zig km) auf Grund der Erddrehung. Aber messbar ist es u.a. mit speziellen Satellitensensoren (Altimeter) und über Bahnstörungen von Satelliten allgemein.

Wenn sie wirklich eine "Runde durch die Galaxis drehen" würde, könnte sie die Erde aus der Entfernung eh nicht sehen und wäre selbst bei fast Lichtgeschwindigkeit ca 100.000 Jahre unterwegs. Was ein Segen für OSM 😉

Duck&Cover
Walter

Edit: Habe gerade einen tierisch lauten Schrei aus östlicher Richtung vernommen. Rolläden runter, Alarmanlage an, ab ins Bett und Decke über den Kopf.

maxbe wrote:

Jetzt nimmst Du den gequetschten Ball und kratzt 0.002mm tiefe Dellen rein. Das entspricht ungefähr der Abweichung von Elipsoid und Erdform (bei 12000km Erddurchmesser und 100m Abweichung: 100Meter Abweichung /12000000Meter Erddurchmesser * 220mm Balldurchmesser).

hmm, da wären ja die 10.000ter nur rund 0,83 Prozent vom Erddurchmesser. Klingt eigentlich gar nicht mehr so viel wenn man das mal nachrechnet.

gibt es hier zum Jahresende eine Wahl zum Forenmitglied mit den hifreichesten Antworten? Da liegt maxbe ganz weit vorn 😎
und ray natürlich

mich würde da wohl keiner wählen 🙄

so jetzt noch mal OT:

@wambacher du musst das mal machen wie ich und ich finde das ich da ein sehr gutes Beispiel bin. Die Erde würde wohl noch 15 Mrd Jahre existieren und dann von der Sonne verschlungen werden. Jetzt gehst du mal davon aus das es OSM fast genau so lange gibt (ober LOL)
da bin ich eigentlich nur ganz kurz weg 🤣
rechne mal nach
ein Wimpernaufschlag ist das
oder einmal Decke übern Kopf ziehen

PS: ich schau mir das dann von weitem an ;-)

1. - 10. Edit
habe den Text immermalwieder verbessert

FGOSM22 wrote:

[ Die Erde würde wohl noch 15 Mrd Jahre existieren und dann von der Sonne verschlungen werden.

15 Milliarden Jahre ist etwas optimistisch. Die Sonne hat noch ca 4-5 Mld. Jahre Zeit aber in etwa 1 Mld. ist es auf der Erde so heiß, daß hier Schluß ist.
Ich schätze aber, daß wir bis dahin eine bessere Ecke gefunden haben - wenn wir die nächsten 100 Jahre durchkommen.

Die Erweiterung von OSM auf andere Himmelsobjekte (Mond, Mars) ist ja schon jetzt sinnvoll, da es ja bereits Tracks und Bilder zum Erfassen gibt.

Gruss
walter

wambacher wrote:

FGOSM22 wrote:

[ Die Erde würde wohl noch 15 Mrd Jahre existieren und dann von der Sonne verschlungen werden.

15 Milliarden Jahre ist etwas optimistisch. Die Sonne hat noch ca 4-5 Mld. Jahre Zeit aber in etwa 1 Mld. ist es auf der Erde so heiß, daß hier Schluß ist.
Ich schätze aber, daß wir bis dahin eine bessere Ecke gefunden haben - wenn wir die nächsten 100 Jahre durchkommen.

Die Erweiterung von OSM auf andere Himmelsobjekte (Mond, Mars) ist ja schon jetzt sinnvoll, da es ja bereits Tracks und Bilder zum Erfassen gibt.

Gruss
walter

da muss ich dir recht geben, habs noch mal nachgerechnet, Kommafehler, Mist

also beim Mond siehst du ja immer nur das Gesicht, das wird ne halbe sache mit dem Kartieren

und der Mars? naja is ni so mein Ding