Wie haltet ihr es mit Höhenangaben ?

Nahmd,

Dem stimme ich zu.

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

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.

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. :sunglasses:

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.

Sehr schön.

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.

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)

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).

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.

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/planungspanne-rheinbruecke-mit-treppe-54-zentimeter-hoehenunterschied-a-281837.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_%28Geod%C3%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.

Amsterdam zu Kronstädter its 14 cm laut Wikipedia

Ps: bin wieder da :wink:

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. :slight_smile:

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? :roll_eyes:

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

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

Hallo Max

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

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?

  • 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…

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

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

Das zweite.

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

Hier etwas detaillierter: http://www.goce-projektbuero.de/7758–~goce~Goce~Anwendungsgebiete~Geodaesie.html

walter

Das ging ja schnell. :slight_smile:

Danke

1.Edit
die Gezeiten wären mir lieber gewesen :wink:

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 :sunglasses:

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