wie beherrscht (::) OSM die Höhenangaben?

Hi,

RYStadium wrote:

ich frage daher ironisch: wie werden eigentlich Höhenangaben von OSM «beherrscht» 🤣 ?

Gar nicht.

OSM hat gar keine flächendeckenden Höhenangaben. Lediglich ein paar Punkte (theoretisch beliebige, aber in der Praxis oft nur einige wenige, Gipfel z.B.) tragen einen Wert für ele.

Viele Router liefern ein Höhenprofil für berechnete Strecken. Die holen sich die Werte aber nicht aus OSM, sondern von anderen Anbietern (SRTM z.B. von der NASA ist recht beliebt).

Grüße, Max

Liedberg als "Berg" zu bezeichnen ist sicherlich etwas übertrieben - ist ja nicht mehr aus ein "Sandhaufen" (Quarzitkuppe) mit gut 50 Meter über NN. Bezüglich der Steilheit einiger Wege gebe ich dir allerdings recht ... das ist für die niederrheinische Tiefebene schon ungewöhnlich. Aber dein Post war ja auch ironisch gemeint ...

Aber zu Thema: Höhenangaben sind m.E. für OSM durchaus interessant - z.B. in Form von "Trigonometrischen Referenzpunkten (mit bekannter Höheneinmessung)" oder sonstiger Punkte mit exakt vermessener Höhenangabe (mit Consumer-GPS-Geräten (Garmin etc.) geht das nicht). Wenn dir solche Punkte bekannt sind, solltest du die mappen ... ansonsten muß du, wie maxbe schon ausgeführt hat, Höhendaten aus anderen Quellen heranziehen.

Gruß Klaus

PS: http://forum.openstreetmap.org/viewtopic.php?id=8186

toc-rox wrote:

(mit Consumer-GPS-Geräten (Garmin etc.) geht das nicht).

Ich verwende (mangels anderer Angaben) durchaus auch schon mal Höhenangaben vom GPS für das ele Tag in OSM. Irgendwann zu Anfang meiner OSM Zeit hat hier mal jemand zu mir gesagt: Lieber ungenaue Angaben als gar keine. Mir ist die Ungenauigkeit von GPS Höhendaten durchaus bewußt, aber gerade zum Beispiel auf Berggipfeln ist die generelle Genauigkeit eines GPS recht gut. Vergleiche ich das mit bekannten Angaben liegen die Abweichungen oft bei unter 5 Metern. Zum Beispiel ist die Benediktenwand bekanntermaßen 1801 Meter hoch laut offiziellen Angaben. Mein GPS zeigte dort 1799 Meter. Das sind gerade mal 2 Meter Abweichung. Fazit: Da Höhenangaben meiner Meinung nach vor allem im Gebirge wichtig sind trage ich schon mal die Angaben meines GPS an Punkten die im Gebirge liegen und noch keine Höhe in OSM haben ein, aber nur wenn das GPS nicht gerade offensichtlich ungenau arbeitet (zum Beispiel in Schluchten bzw. generell wenn das GPS eine Ungenauigkeit von mehr als 5 Metern selber anzeigt). Das sind dann nicht nur Gipfel (die meisten haben bereits eine Höhenangabe) sondern auch schon mal Unterkunftshütten oder Wegweiser.

Gruß
unixasket

Das ist immer eine Frage des Zwecks. Den Gipfel eines Berges um 5 Meter falsch einzutragen schadet ja nicht. Wenn aber an einem eigentlich vollkommen flachen Weg jeder Punkt mit einer Höhenangabe versehen ist, die +- 5 Meter schwankt, ist das nicht ungenau, sondern einfach falsch.

unixasket wrote:

............

Ich verwende (mangels anderer Angaben) durchaus auch schon mal Höhenangaben vom GPS für das ele Tag in OSM. Irgendwann zu Anfang meiner OSM Zeit hat hier mal jemand zu mir gesagt: Lieber ungenaue Angaben als gar keine. Mir ist die Ungenauigkeit von GPS Höhendaten durchaus bewußt, aber gerade zum Beispiel auf Berggipfeln ist die generelle Genauigkeit eines GPS recht gut. Vergleiche ich das mit bekannten Angaben liegen die Abweichungen oft bei unter 5 Metern.

Das ist nicht das Problem (Abweichungen in Bereich von ein paar Meter) sondern das viele ele Angaben nicht das WGS84 Ellipsoid verwenden. Sprich, es wird eingetragen was gerade auf dem Gerät angezeigt wird, was locker 50m daneben liegen kann.

Zum Beispiel ist die Benediktenwand bekanntermaßen 1801 Meter hoch laut offiziellen Angaben. Mein GPS zeigte dort 1799 Meter. Das sind gerade mal 2 Meter Abweichung.

QED (du hast die falsche Höhe eingetragen)

Simon

PS: ich behaupte nicht, dass die Definition des ele Tags sonderlich praxis nah ist ...

Höhen sind leider ein Beispiel dafür, was OSM nicht beherrscht sondern ordentlich versiebt.

Laut Wiki sollen Höhen in WGS84 eingetragen werden, nicht in NN. Laut Historie der Seite war diese Änderung die Idee eines einzelnen Mappers in 2009.

Nachdem aber sonst kein Mensch auf die Idee käme, sowas überhaupt im Wiki nachzuschlagen geschweige denn weiß was er da wie umrechnen müßte, gehe ich davon aus daß die meisten Höhen in NN eingetragen sind. Aber vielleicht mit genug Ausnahmen von Technikfreunden daß man jetzt generell mit den Höhen nicht wirklich was anfangen kann.

Siehe auch http://forum.openstreetmap.org/viewtopic.php?id=18946

bye, Nop

Soweit ich weiß nutzt www.osm-3d.org (und ich vermute sogar der OpenRouteService) das SRTM Höhenmodell um damit OSM mit zusätzlichen Höhen zu versehen. Auch einige andere Dienste nutzen elevation profiles: http://wiki.openstreetmap.org/wiki/Rout … ineRouters

Persönlich scheint mir der Ansatz geeigneter, als diese auch noch bei OSM zu pflegen. Das www.opendem.info will ja AFAIK langfristig dahin kommen, dass man dort Höhen editieren kann.

SimonPoole wrote:

Zum Beispiel ist die Benediktenwand bekanntermaßen 1801 Meter hoch laut offiziellen Angaben. Mein GPS zeigte dort 1799 Meter. Das sind gerade mal 2 Meter Abweichung.

QED (du hast die falsche Höhe eingetragen)

Ich befürchte, dass du recht hast. Zwar steht bei WP ebenfalls 1801 Meter, aber in den amtlichen Karten sind es "nur noch" 1800 Meter 😄

!i! wrote:

Soweit ich weiß nutzt www.osm-3d.org (und ich vermute sogar der OpenRouteService) das SRTM Höhenmodell um damit OSM mit zusätzlichen Höhen zu versehen. Auch einige andere Dienste nutzen elevation profiles: http://wiki.openstreetmap.org/wiki/Rout … ineRouters

Insbesondere SRTM Rohdaten sind mit Vorsicht zu genießen. Generell wird dort die Gesamthöhe gemessen, also z.B. Wald ab Oberkante Baumwipfel. Grade im Gebirge enthalten sie gravierende Fehler, es können komplette Berge in den Daten fehlen, z.B. unter Gletschern, oder es gibt auch "verfüllte" Täler mit Höhenlinien quer zum tatsächlichen Verlauf [1].

Gemessene Höhen dürfte einen deutlich geringeren Fehler haben als aus SRTM abgelesene Höhenangaben.

bye, Nop

[1] http://www.wanderreitkarte.de/forum/thr … 3&thema=28

reneman wrote:

SimonPoole wrote:

Zum Beispiel ist die Benediktenwand bekanntermaßen 1801 Meter hoch laut offiziellen Angaben. Mein GPS zeigte dort 1799 Meter. Das sind gerade mal 2 Meter Abweichung.

QED (du hast die falsche Höhe eingetragen)

Ich befürchte, dass du recht hast. Zwar steht bei WP ebenfalls 1801 Meter, aber in den amtlichen Karten sind es "nur noch" 1800 Meter 😄

Der richtige Wert dort dürfte ca. 1850m sein.

Simon

Nop wrote:

!i! wrote:

Soweit ich weiß nutzt www.osm-3d.org (und ich vermute sogar der OpenRouteService) das SRTM Höhenmodell um damit OSM mit zusätzlichen Höhen zu versehen. Auch einige andere Dienste nutzen elevation profiles: http://wiki.openstreetmap.org/wiki/Rout … ineRouters

Insbesondere SRTM Rohdaten sind mit Vorsicht zu genießen. Generell wird dort die Gesamthöhe gemessen, also z.B. Wald ab Oberkante Baumwipfel. Grade im Gebirge enthalten sie gravierende Fehler, es können komplette Berge in den Daten fehlen, z.B. unter Gletschern, oder es gibt auch "verfüllte" Täler mit Höhenlinien quer zum tatsächlichen Verlauf [1].

Gemessene Höhen dürfte einen deutlich geringeren Fehler haben als aus SRTM abgelesene Höhenangaben.

bye, Nop

[1] http://www.wanderreitkarte.de/forum/thr … 3&thema=28

Ich habe nie behauptet, dass sie perfekt sind. Aber es ist nun mal derzeit das einzige, was uns flächenmäßig zu Verfügung steht. In meinen Augen sind sie eine gute Grundlage, auf die man aufsetzen und dann manuell per crowdsourcing verfeinern kann. Und wer weiß, vielleicht gibt es ja in den nächsten Jahren auch eine OpenData Spende von Geländeprofilen 🙂

!i! wrote:

Ich habe nie behauptet, dass sie perfekt sind. Aber es ist nun mal derzeit das einzige, was uns flächenmäßig zu Verfügung steht. In meinen Augen sind sie eine gute Grundlage, auf die man aufsetzen und dann manuell per crowdsourcing verfeinern kann. Und wer weiß, vielleicht gibt es ja in den nächsten Jahren auch eine OpenData Spende von Geländeprofilen 🙂

So viel ich weiss, gibts durchaus lokale Quellen von hochpräzisen DEMs (z.B: Sächische Schweiz) die im Prinzip freiverfügbar sind. Das Problem ist wirklich eine Platform zu bauen, die einerseits die Verarbeitung von zusätzlichen DEM Quellen erlaubt, anderseits auch Crowdsourced Daten unterstützt.

Wegen der WGS84 Problematik braucht es vermutlich ein gewisses Mass an Heuristik um Messungen mit falscher Referenz entweder auszuschliessen oder entsprechend umzurechnen.

Simon

Nahmd,

unixasket wrote:

Mir ist die Ungenauigkeit von GPS Höhendaten durchaus bewußt, aber gerade zum Beispiel auf Berggipfeln ist die generelle Genauigkeit eines GPS recht gut. Vergleiche ich das mit bekannten Angaben liegen die Abweichungen oft bei unter 5 Metern.

Für brauchbare Höhendaten aus dem GPS brauchst Du (mindestens) einen möglichst niedrig stehenden Satelliten. Dumm ist, dass der sich oft hinterm Horizont versteckt.

Das ist bei der Positionsmessung nicht wirklich anders: auch da sind sind Satelliten mit 90° Anstand gerne gesehen, während drei auf einer Linie nicht wirklich Spaß machen.

Auf einem Berggipfel ist die Wahrscheinkeit groß, einen niedrigstehenden Satelliten zu sehen und damit eine brauchbare Höhe zu bekommen, in einem Tal eher gering.

Das zu wissen hilft natürlich nicht bei der fehlenden Angabe des Höhen-Bezugssystem. Das ist ja sogar zwischen DE und AT verschieden, so dass die Zugspitze in DE und AT unterschiedliche Höhen hat (aber weit unter 1m, also in einem Bereich, der uns nicht interessiert). Wirklich fies finde ich, dass die GPSe auf NN umrechnen, ohne den Fakt an sich geschweige denn das benutzte System anzugeben.

Gruß Wolf

SimonPoole wrote:

Das ist nicht das Problem (Abweichungen in Bereich von ein paar Meter) sondern das viele ele Angaben nicht das WGS84 Ellipsoid verwenden. Sprich, es wird eingetragen was gerade auf dem Gerät angezeigt wird, was locker 50m daneben liegen kann.

Zum Beispiel ist die Benediktenwand bekanntermaßen 1801 Meter hoch laut offiziellen Angaben. Mein GPS zeigte dort 1799 Meter. Das sind gerade mal 2 Meter Abweichung.

QED (du hast die falsche Höhe eingetragen)

Mir ist bekannt das die Höhen laut Wiki in WGS84 Höhen eingetragen werden sollen und ich kenne auch diesen Umrechner dafür:
http://www.bkg.bund.de/DE/Bundesamt/Geo … __nnn=true
Aber: Auch wenn ich mich sonst immer genau an das was im Wiki steht halte: In diesem Fall halte ich mich mit Absicht nicht dran. Ich halte dies für völlig Praxisfern! Die meisten Höhenangaben in OSM sind in Normalhöhennull gemacht. Damit aber klar ist das ich auch meine Angaben in Normalhöhennull eintrage schreibe ich immer 2 Höhenangaben rein. Zum Beispiel für die Benediktenwand:
ele=1801
ele:NN=1801
Mit ele:XX kann das Referenzmodel explizit angegeben werden.
Damit wird bei solchen Angaben von mir klar das in ele Normalhöhenull angegeben ist.
Das mache ich so seit dieser Diskussion:
http://forum.openstreetmap.org/viewtopic.php?id=18946

Gruß
unixasket

Ich glaube, es ist egal, wieviele Werte wir in OSM eintragen, das Problem aus #1 werden wir nicht lösen. Da wir niemals ein flächendeckendes Gitter vermessen können, müssen Router auch weiterhin aus externen Daten interpolieren.

Ich hab mal ein Bildchen gemalt:

Der einzige aus OSM bekannte Wert in der Karte ist unixaskets Benediktenwand mit 1801m.

Um das Höhenprofil des blauen Weges zu berechnen bräuchten wir entweder ganz viele Höhenwerte am Weg, oder wir nehmen eben externe Daten (die ganzen Punkte mit den Zahlen dran sind die Werte aus openDEM).
Die liegen nicht auf dem Weg, sondern rund um die Strecke verstreut. Dafür hat man auch Werte (und damit Höhenlinien, Schummerung...) an Stellen, die niemals ein Mapper betreten wird.

Grüße, Max

PS: Die SRTM-Werte in dieser Gegend sind deutlich zu niedrig. Abweichungen sind ein typischen Problem für bergige Gegenden, weil ein Mess"punkt" auf der Karte entspricht in der wirklichen Welt einem gemittelten Fussballfeld und an manche Stellen sieht der Satellit auch nicht gut hin. Da ich nur linear interpoliere, wird auch kein Fehler wieder rausgerechnet.

!i! wrote:

Soweit ich weiß nutzt www.osm-3d.org (und ich vermute sogar der OpenRouteService) das SRTM Höhenmodell um damit OSM mit zusätzlichen Höhen zu versehen.

SRTM nutze ich - trotz der bekannten Qualitätsprobleme - für die aktuell in Entwicklung befindliche Geländeuntersützung in OSM2World ebenfalls, weil es eben der einzige von der Lizenz her unproblematische globale Höhendatensatz ist. Dieselbe Technologie könnte man aber auch für andere Datenquellen als SRTM einsetzen.

Zusätzlich will ich aber auch Tags in OSM mit einfließen lassen (allerdings nicht ele, die sind derzeit unbrauchbar). Für das Ausgangsproblem würden mir dann z.B. incline-Tags an einer Straße helfen, die durch das grobe Geländemodell vermittelte falsche Annahme zu korrigieren.

Persönlich scheint mir der Ansatz geeigneter, als diese auch noch bei OSM zu pflegen. Das www.opendem.info will ja AFAIK langfristig dahin kommen, dass man dort Höhen editieren kann.

Also, ich bin der Meinung dass "bloß" ein editierbares DEM auch nicht reicht, denn dann hat man ja zwei getrennte Datenquellen und das Geländemodell passt sich nicht ohne umständliche manuelle Eingriffe an, wenn z.B. die Straße in OSM verschoben wird.

Für unbebautes Gebiet wäre so ein editierbares DEM natürlich das Mittel der Wahl, zumal die automatisch erzeugten Daten an Bergen etc. oft sogar Messfehler und Datenlücken haben. Dort könnte man dann auch lokale Datenspenden einpflegen. Aus meiner Sicht ist von daher die Kombination aus möglichst gutem freien Raster-DEM und Berücksichtigung von OSM-Daten richtige Lösung.

Nahmd,

unixasket wrote:

Zum Beispiel für die Benediktenwand:
ele=1801
ele:NN=1801
Mit ele:XX kann das Referenzmodel explizit angegeben werden.

Darf ich in Deinen Club eintreten?
Ne im Ernst: ich werde mich Dir anschließen.

Vielleicht ist aber "ele:de" oder "ele:nn:de" besser wegen der unterschiedlichen Bezugspegel in unterschiedlichen Ländern?

Gruß Wolf

Nahmd,

Tordanik wrote:

Aus meiner Sicht ist von daher die Kombination aus möglichst gutem freien Raster-DEM und Berücksichtigung von OSM-Daten richtige Lösung.

Oder gleich ein eigenes Höhennetz?

Anfangen kann man mit dem Sammeln von Tracks mit Höhenangaben. Idealerweise mit Höhen aus barometrischen Höhenmessern. Denn die relative Genauigkeit der Höhendaten ist recht gut, und die absoluten Werte sind (fast) ohne Bedeutung, wenn man das Netz an Festpunkten aufhängt und dazwischen über die Tracks verfeinert.

Um die nötige Ausgleichsrechnung könnte ein Geographieinstitut sich kümmern. Ich kann die Schwierigkeit nicht beurteilen, denke aber, sowas schreit nach Diplom- und/oder Doktorarbeit.

Für die Festpunkte müssten man schlimmstenfalls ein paar Euronen in einen Topf werfen und ein Profi-GPS beschaffen und damit erst einmal die Autobahnen abfahren. Vielleicht bekommt man aber auch Festpunkte spendiert. .oO( oder ein Profi-GPS )

Um an möglichst viele Tracks zu kommen, braucht es Mitstreiter auch außerhalb der OSM-Gemeinde: Radler, Wanderer, Autofahrer. Die sollte man aber über die richtigen Onlime-Magazine erreichen können?

Der Riesengewinn dabei: die präzisen Höhenwerte fallen genau da an, wo sie gebraucht werden, nämlich an Straßen und Wegen, und genau auf den Wegen, die auch befahren werden 🙂

Gruß Wolf

"ele:de" ist vermütlich besser, da verschiedene Bezugspegel existieren.
Es ist wichtig, dieses Problem global zu lösen.
Und sollte irgendwann ein Gesamtmodell stehen wird sich ele=<value> nach diesem Modell richten und wir werden kein Problem mit der Bereinigung der Daten haben...

Hi,

Netzwolf wrote:

Für brauchbare Höhendaten aus dem GPS brauchst Du (mindestens) einen möglichst niedrig stehenden Satelliten.

Ich denke, es ist umgekehrt. Die niedrig stehenden tragen wenig zur Höhengenauigkeit bei, da übereinanderliegende Punkte etwa denselben Abstand zu diesen Satelliten haben. (Und man bekommt von jeden Sat nur den Abstand in Abhängigkeit von der Uhrzeit -- Richtungen werden nicht ermittelt.) Für die Höhe braucht man Satelliten in einigermaßen senkrechten Richtungen. Die unten bekommt man aber naturgemäß nie und hat deshalb notorisch wenig Daten.

Weide

marek kleciak wrote:

"ele:de" ist vermütlich besser, da verschiedene Bezugspegel existieren.
Es ist wichtig, dieses Problem global zu lösen.
Und sollte irgendwann ein Gesamtmodell stehen wird sich ele=<value> nach diesem Modell richten und wir werden kein Problem mit der Bereinigung der Daten haben...

Das Wiki schreibt dazu ele:local. Vielleicht sollte dazu mal ein Konsens getroffen werden und die entsprechende Wikiseite überarbeitet werden.

Gruß
unixasket

Hallo,

marek kleciak wrote:

"ele:de" ist vermütlich besser, da verschiedene Bezugspegel existieren.
Es ist wichtig, dieses Problem global zu lösen.

nicht nur die xy-Koordinatensysteme haben doch einen epsg-Code, auch die Z-Systeme, also Höhensysteme haben einen solchen. Ich wäre dafür, diesen zu verwenden, da der EPSG-Code mit den relevanten rechnerischen Parametern hinterlegt sind:

Das DHHN92 hat z.B. den EPSG-Code http://www.spatialreference.org/ref/epsg/5783/

Damit lassen sich alle gängigen und gebräuchlichen Systeme beschreiben. Diese EPSG-Codes sind weltweit quasi-Standard.

meint Sven

Nahmd.

unixasket wrote:

Das Wiki schreibt dazu ele:local.

"Sehr" hilfreich in der Plene im Grenzgebiet 🤔

Vielleicht sollte dazu mal ein Konsens getroffen werden und die entsprechende Wikiseite überarbeitet werden.

Ja.

Aber was "nachhaltiges" und nicht ein Lückenfüller.

streckenkundler wrote:

Damit lassen sich alle gängigen und gebräuchlichen Systeme beschreiben. Diese EPSG-Codes sind weltweit quasi-Standard.

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

Gruß Wolf

Hallo

Irgendwie scheinen mir die obigen Überlegungen am Problem vorbei zu laufen. Was will ich im (ungenauen) Kartenwesen mit Höhenangaben? Ganz sicher nicht wissen, wie hoch es hier, gleich wo, exakt ist. Was kann man mit solchen Angaben in der Praxis wirklich anfangen? Ich, als Privatperson kenne einen Zweck: einen ROUTENVERLAUF ermitteln, wissen wie viel Höhenunterschied ich nutzen kann oder überwinden muss, wenn ich von A nach B gehe oder fahre, wie das die

http://www.ebay.de/itm/Karte-Mittelbach … 2c6a080687

früher machte. Wer eine solche alte Mittelbach's-Strassenprofilkarte schon in der Hand gehabt hat, weiss wie grob und ungenau, genauso wie unkontrollierbar, ganz offensichtlich die Profilangaben waren. Wer aber die Strecken mit eigener Muskelkraft zurücklegte, weiss, wie interessant es ist, im voraus zu wissen, worauf man sich einlässt...

viele Menschen brauchen es heute nicht mehr zu wissen. sie haben sowieso viel zu viele PS unter der Haube. es gibt aber Menschen, wie meine 86 j. Schwiegermutter, die trotz hohem Alter 100 km Touren mit dem Pedelec immer noch fahren, und sehr erpicht sind, zu wissen, ob die Batterieladung ausreichen wird (die letzten 5 km sind immer ein der stärksten Anstiege: sie wohnt auf einem dieser Berge entlang der Donau; die Aufladung MUSS so lange ausreichen, sonst war ein der Gründe der Pedelec-Investition für die Katze), andere werden da ersetzen, ob die eigenen Kräfte ausreichen werden. Traue ich mir den Ruhrtal von Monschau oder gar Quelle nach Roermond in einem Tag zu? Das ja, reine Sitzfleischsache oder fast. Aber traue ich den Ruhrtal von Roermond nach Monschau oder gar Quelle zu? Das ist die echte Frage... Und dazu brauche Vergleichsmöglichkeiten!

Es dreht sich nicht darum, alle Vermögen verschlingenden, unzähligen Geometer-Aufträge, die exakte Messungen liefern, der hochverschuldeten Stadt Möchengladbach durch ehrenamtliche so gut wie amateuristische OSM-Leistung zu ersetzen 🤣 (obwohl diese Stadt das sehr gut wirklich gebrauchen könnte! Gibt es Stellen hier bei uns, die sich verschieben, oder noch nicht vermessen wurden?): Es dreht sich darum, highway-Karten zu liefern, die noch mehr als nur Entfernung und Richtung, grob gesagt, vermitteln, viel mehr, als wo ein Briefkasten, Telefonzelle, usw. anzutreffen sind. Heute betrachtet es jeder als völlig normal, dass alle diese Randinformationen zu finden sind! Warum dann nicht der zu erwartende Strassenprofil: Es war seit über 100 Jahren der Sinn von vielen Spezialkarten! Und auf Genauigkeit kommt es hier dabei nicht an, sondern auf realistische Relationen.

Gruß

Netzwolf wrote:

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

Das stimmt.

mit EPSG 5783 ist man bei DHHN92
mit EPSG 5784 ist man bei DHHN85

Das kann dir bei Buchstabenkürzeln aber auch passieren: hier einige in Deutschland gebräuchliche (oder ehemals gebräuchliche) Kürzel: HN, NHN, NN, DHHN, SNN...

Ich vermute aber, daß es sich bezogen auf die große Masse eh auf wenige gängige Systeme reduzieren wird, die dann unterstützt werden. Mit den EPSG-Codes hat man auch die eheste Chance, definierteT Transformationen (~parameter) zu haben.

Sven