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.
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.
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.
”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!
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.
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.
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.
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.
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.
Das Wiki enthält keine Standards. Das Wiki enthält freundliche Empfehlungen.
OSM gibt es schon ein paar Jahre. Und ist noch nicht zusammengebrochen. Es wächst und gedeiht.
(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.
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.
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!
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.