Kann man beim Kalibrieren von Karten verschiedene Map Datum verwenden?

  • Zitat

    Original von macnetz
    gerade bei topografischen Karten in den USA musst du das Kartendatum beachten. NAD27 ist dort AFAIK noch weit verbreitet.
    Grüsse - Anton


    Wenn ein Punkt auf der NAD27-Karte mit dem richtigen Punkt aus einer WGS84-Referenz kalibriert wird, stimmt's aber wieder. Man darf nur nicht die long/lat-Werte aus dem Fremddatum als Kalibrierwerte ablesen. Auf kleinen Kacheln lässt sich das so gut kompensieren.


    Interessant ist es übrigens, die Punkte des Top50-Kachelrasters in GoogleEarth anzuschauen (mit meinem kal2index Skript). Da sieht man sehr schön die trapezförmige Mercatorprojektion der Top50-Kacheln auf dem Globus.


  • Ja sollange du die GPS Info von der Karte nimmst!


    Nein wenn du mit Hilfe von z.B. GoogleMap die Karten kalibrierst


    siehe vorigen Beitag von frank334


    Gruß
    Silver

    Regioausflug.de Wandertourenplaner für Odenwald, Rhön, Mittelrhein und Taunus!!!!


    Ein Stau ist nur hinten blöd - vorne gehts !!!!

    Einmal editiert, zuletzt von Silver34 ()

  • Hallo,


    wenn man es richtig macht, kann man auch mit Glopus die Fehler/Abweichungen gering halten.
    In der Kartografie selbst gibt es normalerweise keine Fehler/Abweichungen. Dafür sind die Projektions-Parameter und das Kartendatum da.
    Einem Hobby-Kartografen sträuben sich alle Haare, wenn mit präzisem Ausgangsmaterial so "Pi mal Daumen" gearbeitet wird. Ausserden wächst der Aufwand beträchtlich, wenn jedes Kartenschnipsel mit Referenzpunkten aus GoogleMaps kalibriert werden muss. Metergenaue Worldfiles sind eleganter und schneller.


    Grüsse - Anton

  • Da ihr jetzt doch wieder beim Datum seid: Das Kartendatum ist wie Frank schon schreibt nur eine Sache der Kalibrierung der Kacheln. Wird das Datum beim Kalibrieren berücksichtig (umgerechnet), wird auch Glopus so genau sein wie die Karte. (Nix da Pi mal Daumen.) Anders bei einer falschen Projektion, da wird bei großen Kacheln mit großem Maßstab eine Long/Lat Position von Glopus an eine Position gezeichnet, die einen gewissen Betrag von der tatsächlichen Position abweicht.
    Genauso falsch ist die pauschale Aussage: "...dass bei Glopus die Kalibrierung umso ungenauer wird, de weiter man sich den Polen nähert."

  • Also beim Top50-Abfotografieren ist es ja so, dass die Mercatorprojektion vom Geogrid-Viewer realisiert wird. Er rechnet die Pixelkoordinaten in die richtige Projektion um. An den Kalibrierpunkten stimmt es so exakt, unabhängig vom Kartendatum. Die Einzelkacheln sind näherungsweise geografisch projeziert, wenn klein genug. Die Näherung ist mit 4-Punkten sogar noch genauer, wenn die 4 Punkte eine Trapezverzerrung plus Rotation machen (weiss nicht, wie das intern verarbeitet wird). Das wäre dann so ein Mittelding zwischen geografisch und Mercator. Die Fehler sind vernachlässigbar (ich hab jedenfalls noch keine bemerkt).


    Bei Karten aus geografischer Projektion entsteht durch Glopus selbst kein Fehler.


    Bei großen gescannten Karten in Mercator-Projektion müsste man sich etwas anderes überlegen. Man könnte mit den OpenEV-Tools entzerren, aber dann hätte man immer noch eine Karte, die zu groß ist. Kann der GlopusMapManger das bei großen Karten einwandfrei zerstückeln?
    Eine andere Möglichkeit wäre es, die Mercator-Bitmap direkt zu zerstückeln (pnmcut aus Cygwin kann Bitmaps per Batch ausschneiden) und die Kalibrier-Eckpunkte mit einer Mercator-long/lat-Umrechnung bestimmen. Oder gibt es dafür schon automatische Tools? Da kenne ich mich nicht aus. Na jedenfalls hab ich hier noch eine große Deutschland-Mercatorkarte, die noch nicht Glopusifiziert ist. Wäre schön, wenn es geht.


    Für echte Geografen, Geodäten oder Kartografen (gibt's hier welche?) sind das wahrscheinlich Peanuts. Aber Geo-Laien (wie ich) würden eine knappe Anleitung brauchen, wie man Karten jeglichen Typs für Glopus nutzen kann. Natürlich ohne Profi-Tools im 1000-Maßstab.

  • Zitat

    Original von Peter Kirst
    Da ihr jetzt doch wieder beim Datum seid: Das Kartendatum ist wie Frank schon schreibt nur eine Sache der Kalibrierung der Kacheln.

    Hallo Peter,


    das Problem mit dem Kartendatum tritt auch bei der Übertragung von Koordinaten aus Karten mit anderer Projektion und Kartendatum auf. Selbst wenn du alle Karten in Glopus korrekt kalibriert hast, dann kannst du eine Position nicht korrekt eingeben und anzeigen lassen, wenn diese Position in einem anderen Kartendatum abgelesen oder anderweitig übermittelt wird.
    Wenn du z.B. in deinem Urlaubsgebiet eine tolle Karte mit Gitter kaufst, dann liest du die Koordinaten nach dem Gitter der Karte ab. Da hilft dir GoogleMaps nicht weiter. Einen normalen GPS-Handempfänger kann man dann entsprechend für die Eingabe und Anzeige von Koordinaten umschalten - obwohl der GPSR intern mit WGS84 arbeitet.


    Grüsse - Anton

  • So, hab gerade mal den Navi interessehalber mitfahren lassen:


    - Google-Umgebungsfoto per NH-Toptrans kalibriert: der Track stimmt sogar mit der Fahrspur überein
    - Top25/Top50 Mercator autom. kalibr.: der Track stimmt mit der Strasse überein, Linie auf Linie
    - Top200-Top1Mio Mercator: soweit man es auf der Karte erkennt stimmt es
    - 1 Schnipsel aus Europakarte: Stadt punktgenau getroffen


    Also, da kann man sich nicht wegen der Genauigkeit beklagen. Solange man nicht als Landvermesser mit Differential-GPS auf dem Rücken herumlaufen muss, ist das alltagstauchlich.


    Das war nicht immer so gut: früher als ich versucht hatte mit manueller 2-Punkt die Karte geradezubiegen war es immer irgendwie daneben.

  • Ich habe lange überlegt, ob ich mich in diesem Forum noch einmal zu Wort melden soll, aber der Beitrag von frank334 fordert eine Antwort.


    1. Der Strangeröffner kommt aus einem Forum von Radreisenden und Fernradlern, die in der ganzen Welt unterwegs sind. Für die sind die Ratschläge aus Bayern wenig sinnvoll. (Das ist so wie in der Politik)


    2. Wie MacNetz zutreffend bemerkt hat, hat die Fa. Garmin (der ich ja nun wirklich nicht zugeneigt bin) auch ihren preiswerteren Geräten einen Umschaltmodus zu unterschiedlichen Projektionen und MapDatums verpasst. Warum wohl?


    3. Programme wie OZI und TTQV stellen im Bereich Kalibrieren eine Vielzahl von Auswahlmöglichkeiten, incl. der Möglichkeit, eigene Daten einzuarbeiten, wenn die Daten oder die Projektion nicht vorhanden sind, zur Verfügung, was Kartendatum und Kartenprojektion anbelangt. Hinter diesen verbergen sich m.W. immense Rechenprozeduren. Warum haben die so viel Programmieraufwand betrieben?


    Mein Fazit. Es sollten doch einige Leute, die in diesem Strang schreiben, sich mal intensiver mit den Themen Kartendatum und Projektionen beschäftigen. Den in meinen Augen besten Link gebe ich gern weiter. Die Leute vom Explorermagazin beschäftigen sich schon länger mit der Problematik und können wohl mit Recht als Spezialisten bezeichnet werden.

    Einmal editiert, zuletzt von fermollneu ()


  • Hallo Anton,
    du hast natürlich Recht: um eine gekaufte Karte im Urlaub mit Glopus zu kalibrieren, bietet Glopus keine Umrechnung. (Für die 4 Punkte habe ich aber andere Programme.) Das Problem ist aber eher, dass ich in der Regel auch keinen Scanner mitnehme. Mir bleibt daher nur noch die Möglichkeit die Karte abzufotografieren und z.B. anhand meiner Ankuntsroute o.ä. zu kalibrieren. Ein Wunder, dass ich mich mit dieser Art der Kalibrierung bisher noch nicht verlaufen habe. Falls ich POIs im Zielgebiet brauche, besorge ich mir die übrigens schon zu Hause und da sind mir bisher noch keine mit einem anderen Datum untergekommen. Vielleicht bin ich aber nur altmodisch und sollte mal im Urlaub in einen lokalen Tante Emma Laden gehen und mir die POIs im dort typischen Format kaufen. Ach ja, mein Empfänger ist auch recht alt und kann nur GPS, so dass meine Position und Routen bisher immer genau waren. Die lokalen Satelliten, die das "richtige Datum" schicken, muss ich also leider ignorieren. Na ja, wenn du weiter so fleißig schreibst, werde ich mir vor dem nächsten Urlaub vielleicht mal ein richtiges Programm kaufen. ;D

  • Zitat

    Original von Peter Kirst
    Hallo Anton,
    du hast natürlich Recht:

    Hallo Peter,


    si tacuisses . . .


    SCNR - Anton

  • Frage an alle: Es gibt eine OpenSource lib, die alle gängigen Umrechnungen von Projektionen und Kartendatums unterstützt. Ich habe mich schon mal damit beschäftigt: Es ist kein Problem das is eine dll zu giesen (schon mal gemacht) und in Glopus zu nutzen (schon mal getestet). Ich habe mich bisher dagegen entschieden, weil ich das nicht brauche und es eine mühsame Arbeit ist, diese ganzen Eingabefelder zu basteln, zu testen und zu beschreiben, wenn es nur 10 Mann nutzen. Außerdem ist das mit den verfügbaren Quellen keine Herausforderung (wie z.B. die Glopus Render Engine), sondern eine reine Fleissarbeit. Das Zusammenrendern von verschiedenen Karten wird dann auf dem PPC (Performance) nicht mehr möglich sein (bis auf die aktuellen). Dafür könnte ich z.B. Kartenmaterial in schlechterer Komprimierung als Riesenkarte mit längeren Zugriffzeiten realisieren (hab ich schon mal angefangen).
    Wer ist dafür?
    (Ich fürchte nur m wird dann was anderes finden, was schlecht an Glopus ist. (Sorry, bin heute nicht gut drauf.))

  • Zitat

    Original von Peter Kirst
    Ich fürchte nur m wird dann was anderes finden, was schlecht an Glopus ist. (Sorry, bin heute nicht gut drauf.)

    Hallo Peter,


    ich habe niemals Glopus schlecht gemacht. Auch ein gutes Programm hat Grenzen. Und diese Grenzen habe ich ab und zu versucht zu beschreiben.


    Nichts für ungut
    Anton

  • Zitat

    Original von frank334
    ...... Google-Umgebungsfoto per NH-Toptrans kalibriert: der Track stimmt sogar mit der Fahrspur überein.......


    Hi frank334,


    ich dachte NH-Toptrans funktioniert dieses Jahr nicht mehr ("Timebomb"). Wieso läuft es bei Dir?


    Gruss Bernd

  • Zitat

    Original von bernd_mueller
    ich dachte NH-Toptrans funktioniert dieses Jahr nicht mehr ("Timebomb"). Wieso läuft es bei Dir?
    Gruss Bernd


    Das war noch zu der Zeit, als ich Toptrans für eine Freeware gehalten habe. Leider war's nur eine verkappte Trialware. 2007 habe ich es noch nicht gestartet. Im Notfall werde ich 2006 bestimmte Dinge getan haben werden. Der Notfall ist zum Glück noch nicht eingetreten. GPSBabel läuft ganz ordentlich, in Gegenwart und Zukunft. Und vor allem flotter: früher hatte ich meinen GPS-Track nicht mit 2 Mausklicks in GoogleEarth, jetzt per Registry-Patch geht das.


    Egal, Satfotos sind eigentlich überflüssig auf dem Navi. Eher was zum angeben als zum Wegfinden (mann, warum hat keiner die Bäume abgeholzt, damit ich den Waldweg erkenne .....). Genial sind nur die Topo-Karten 25/50 im Gelände. Manchmal nehme ich auch die Top200 für den Überblick. Und eben Navigon fürs Autofahrn. Keine Ahnung was man auf den Bahamas braucht. Mein Urlaubsgeld reicht nur für Alpen & Adria. Auf Übersee mit 4 köpfiger Family ist mir ein bissl teuer?

  • Zitat

    Original von macnetz
    Auch ein gutes Programm hat Grenzen. Und diese Grenzen habe ich ab und zu versucht zu beschreiben.
    Anton


    Schon Ok. Es ist gut, die Grenzen zu kennen. Wer Fremd-Datums braucht, muss eben Ozi nehmen. Ich bin aber ehrlich gesagt froh, dass diese Koordinaten-Kleinstaaterei langsam aufhört und Neuauflagen der Karten fast nur noch in WGS und UTM erscheinen. Es gibt bestimmte Dinge, die nicht wegzunormieren sind, wie die Kontinentaldrift zwischen GPS WGS-Datum und ED. Aber das sind nur ein paar cm. Zur Mercatorverzerrung sollte aber noch etwas gemacht werden. Das muss Peter nicht unbedingt in Glopus einarbeiten, sondern könnte auch bei einer Kartenerstellungsprozedur berücksichtigt werden (MapManager?). Wie gesagt, man müsste ein Skript machen, das eine große Mercator-Bitmap zerstückelt und die Eckkoordinaten der Kacheln umrechnet. Zerstückeln geht mit "pnmcut" und umrechnen mit "proj". Fehlt nur noch einer der das kann und Zeit dafür hat (ich vermute ca. 1 A4-Seite Code für ein Perlscript würde reichen). Eine Prozedur zum Entzerren einer Karte mit den OpenEV-Tools wurde sogar schon hier im Forum beschrieben (nur 2 Kommandos mit entsprechenden Parametern).