Entfernungsberechnung zweier Koordinaten

  • Zitat

    Original von mfs
    ...und danach hört sich das Problem mit dem Ergebnis des Destinators an, wobei ich persönlich eine Berechnung der über die Breite der Kartenmitte - danach sieht es ja aus - aber schon für sehr "mutig" halte...)


    .... und mich zudem nachdenklich macht, warum die das denn so gemacht haben?


    Ich bin mir sehr sicher, dass es einen triftigen Grund gibt, und den werde ich auch noch herausfinden....


    Bei allem muss man immer bedenken, dass im konkreten Anwendungsfall die Berechnungen so einfach wie möglich gehalten werden müssen, da der PDA einfach nicht genügend Power hat. Und das Navi muss permanent mit viel Koordinaten rumrechnen - soll heissen, der Grund liegt sicher in der Performance und 'zig trigonometrische Funktionen und Gleitkommaoperationen verbieten sich.


    Andreas

  • Hi,


    Es sollte ziemlich egal sein, von welcher Koordinate die Reduktion nun berechnet wird, zumal es ja nur bei der Entfernungsabfrage notwendig ist...


    Aber für die Anwendung wird es sicherlich ausreichend genau sein.


    PS: 200 bis 400 MHz sind reichlich Power, meine erste Grafik-Workstation (CAD) war 1987 ein 386er mit 20MHz, damit habe ich Lagepläne von ganzen Ortschaften erstellt
    (ok, wirklich schnell ging das nicht ;) aber es funktionierte)



    lg,
    Martin

  • Zitat


    so wie's aussieht war's das... :bounce5 ....


    Das freut mich wirklich für dich und respekt, das war ist keine leichte Aufgabe. (hat dich ja bestimmt auch einige Stunden deines Lebes gekostet!)

    Zitat


    Die Berechnungen mache ich wie in einer meiner ersten Postings beschrieben. Meine Breitengrade stimmen mit denen von Destinator auf 5 Nachkommastellen überein, bei den Längengraden nur auf 4 Stellen.....


    Allerdings sind eine Veränderung von 0,0001° also 4 Stellen nach dem Komma, auch schon eine Veränderung von gut 11m auf der Erdoberfläche!!! Naja für Poi müßte das aber trotzdem reichen!

    Zitat


    Manuel: du hattest einen etwas anderen Rechenweg, Kannst du mir zufällig sagen, ob deiner mit meinem übereinstimmt?....


    Also ehrlich gesagt, deinen Rechenweg kann ich noch nicht ganz nachvollziehen. Ich denke das der Unterschied ist, das deine Berechnung wohl über den Erdumfang läuft und ich das über den Erdradius berechnet habe. Da diese beiden Werte ja voneinander abhängig sind, gehe ich davon aus, das die Berechnungen ähnlich sind. Es kommt ja auch das Gleiche raus. Auf der I.Seite die Martin genannt hat!
    steht folgende Formel
    =1,852*60*ARCCOS((SIN(62,421*PI()/180)*SIN(48,928*PI()/180))+COS(62,421*PI()/180)*COS(48,928*PI()/180)*COS(19,953*PI()/180))*180/PI()
    Das soll für die Berechnung in Excel gut sein. Ich habe zwar keinen Schimmer von Excel und kapiere die Formel auch nur in Teilen, aber in dieser Formel wird wie bei meiner Rechnung mit dem Wert "Roh" (180:pi)gerechnet, also läuft das auch irgendwie über die Bogenformel und den Radius!
    Was nun richtig oder besser ist. Keine Ahnung!! ?(
    Ich habe genau wie Martin nichts studiert :D und komme nun auch an meine Grenzen!

    Zitat


    Ach ja, Charly, danke für das Bild mit der Formel die ihr in eurer Tabelle verwendet habt. Für mich ist immer noch die Frage offen, ob diese Formel generell für beliebige Koordinaten gilt (ohne Randbedingungen?)Antwort?

    Hierzu kann ich das was Charly gesagt hat nur bestätigen, die Meridianstreifen sind nur in Gauß-Krüger und in UTM. Da jeder Meridianstreifen ein eigenes Koordinatensystem ist, darf man in seinen Berechnungen nicht von einem in den anderen gehen.
    So wie ich das sehe gibt es also keine Einschränkung für Charlys Formel, da wir ja mit Geograf. Koo. rechnen.

    Zitat


    Hat wer eine Idee, wie man das mit den beschriebenen Vorgaben am besten machen könnte? Ausserdem können ja wohl nur Performancegründe den Ausschlag gegeben haben, dass Destinator Offsets für die POI's und nicht "normale" Koordinaten verwendet, oder??


    Ich wundere mich sehr darüber, ich habe noch nie gesehen, das irgendetwas über die Kartenmitte berechnet wird. Also Vermessungstechnische Gründe hat das nicht. Allerdings kann ich mir Performancegründe auch nicht vorstellen, da dadurch ja die Berechnung nicht einfacher wird.Aber alles nur Vermutung! :-D) nichts studiert und von Computern null Ahnung :-D)


    Viele Grüße
    Manuel

    Einmal editiert, zuletzt von luckywellman ()

  • Zitat


    P.S. Und Manuel, viel Spass bei der Party....


    : drink : drink aUweIa dRöhNt mIr dEr sChÄdEl : drink : drink


    Wenn du absolute Sicherheit über deine Berechnungen haben willst, gehst du am besten zu einem "Öffentlich bestelltem Vermessungsingeneur" (gibt es in jeder Stadt).Der kann dir das 100% richtig rechnen. Aber laß dir dort einen Festpreis (20 Euro)machen, denn der wird das auch nicht aus dem Stehgreif können und ein weilchen brauchen.


    Ansonsten wünsche ich allen Rechnern ein schönes Wochenende!


    VlG
    Manuel

  • Hallo Manuel, hallo Charly,


    Zitat

    Original von luckywellman
    Das Programm will ich dann aber auch haben :D :D :D


    ich habe mittlerweile schon die zweite Version meines Programmes fertig (und habe mich sehr gefreut, dass ihr mir auf meinem Weg weitergeholfen habt). Unter anderem deshalb möchte ich meine Erkenntnisse nicht für mich behalten und möchte deinem Wunsch gerne nachkommen.


    Falls ihr was damit anfangen könnt, HIER ist der Thread dazu.


    Ach Manuel, eine Frage hätte ich doch noch: bei deiner Formel (in einem deiner frühen Postings) rechnest du bei der Breite mit "b= 170,773" und bei der Länge mit "b=310,742". Wie kommst du eigentlich auf die Zahlen und was bedeuten diese? Ist mir nicht klar.


    Grüße


    Andreas