GCC - Mitte von drei Punkten berechnen

Ist es möglich den Mittelpunkt von drei Koordinaten zu berechnen?
Ich finde nur die Option mit zwei Punkten.

Ein paar Tage musst du dich noch gedulden. Ein Release mit ua. der Funktion ist in Arbeit.

Also: Nein, NOCH nicht.

Klasse! Wir hatten nämlich gerade hier im Forum Bedarf für diese Funktion.

Tolle App, vielen Dank für die Mühen.

Suppi das man so von einem bevorstehenden neuen Release erfährt. [SMILING FACE WITH SMILING EYES]

gesendet mit Tapatalk

Ja, wir arbeiten dran... 3 kleine Sachen sind noch zu finalisieren, eine Sache schauen wir grad, ob wir die noch einbauen.

Mittelpunkt bei uns heißt aber: Der Punkt, der gleich weit von den drei anderen weg ist. In 2D Geometrie gedacht, also der Umkreis. Nicht der Schwerpunkt oder so.

Ich nehme an, es geht um den Thread: http://forum.geoclub.de/viewtopic.php?f=9&t=73982

Für die Koordinaten von "froschkoenigin":
N 48° 13,401 E 9° 00,700
N 48° 13,495 E 9° 00,990
N 48° 13,235 E 9° 00,990

Gibt GCC dann folgendes Ergebnis:
N 48° 13,365 E 9° 00,905251

"Mitte von drei Punkten" ist der Schwerpunkt und nicht der Umkreismittelpunkt. Der kann ganz wo anders als in der "Mitte von drei Punkten" liegen wenn die drei Punkte fast auf einer Linie liegen.

Natürlich weiß ich, dass der Umkreismittelpunkt nicht der Schwerpunkt ist... Deswegen habe ich auch erklärt, was GCC zukünftig darunter verstehen wird.

Für die Berechnung des Schwerpunkts habe ich noch keinen Algorithmus gefunden (bzw. noch nicht gesucht), der auch außerhalb der Ebene funktioniert (sprich: Sehr große Abstände der Punkte) GCC versucht ja allgemein arbeiten zu können und nciht die Einschränkungen hinzunehmen, die Geodäten scheinbar nehmen: Funktioniert nur auf der Ebene.

Echt, das ist lästig. Habe mir zig Geodäsie-Bücher bei Amazon bestellt, weil ich Formeln für Berechnungen auf Ellipsoiden haben wollte. Aber alle - wirklich alle - haben nur auf planen Flächen hantiert. Alle Formeln zu dem Thema, die ich fand waren nur für 2-Dimensionale Rechnungen gut... Das kann ich nicht in GCC einbauen. Da kommt dann einer, der 50km Abstände zwischen den Koordinaten hat und dann kommt da Müll bei raus.
Ich bin dann bei den theoretischen Informatikern besser aufgehoben gewesen

Fazit: Wenn einer den Schwerpunkt sucht, kann er nciht GCC benutzen bzw. in manchen Fällen schon, nur mit mehreren Berechnungsschritten . Wenn einer den Punkt sucht, der von allen anderen drei Punkten gleich weit weg ist, kann er GCC benutzen.

Wäre es nicht möglich, die WGS84-Koordinaten in UTM umzurechnen, z.B. mit dem Garmin? Dann erhält man einen metrischen Nord- und Ostwert und kann dann den Dreiecksmittelpunkt ohne Probleme errechnen. Und denn errechneten Punkt dann einfach wieder in WGS84-Koordinaten zurückrechnen. Das könnte man dann auch wieder dem Garmin überlassen.

Ja, das ist genau das Geodäten-Ding, was ich oben meinte Umrechnen von LatLon nach UTM geht gut, solange die Koordinaten einigermaßen gut nebeneinander liegen, aber bei sehr großen Distanzen geht das eben nicht mehr - meines Verständnisses nach.

Wenn die eine Koordinate in Brasilien, eine in Kanada und eine in Australien liegt, hilft da kein UTM mehr. Da braucht es schon Berechnungen auf dem geometrischen Erdkörper selbst - und die ist eben in irgendwelchen Geodäsie-Büchern zu vielen Problemen nicht zu finden.

Klar, kann man in GCC jetzt so eine Funktion einbauen, die für kleine Distanzen funktioniert, aber das würde sich für mich falsch anfühlen, unsauber, unfertig. Denn wo soll denn die Grenze sein? Was ist denn eine "kleine Distanz"? Und wie soll ich das dem User erklären, der plötzlich vor einem Rätsel steht, der die doppelte Distanz braucht? Der kriegt was falsches raus und meckert mich voll... Dann lieber nicht einbauen.

ABER: Es kann auch sein, dass ich etwas völlig Grundlegendes missverstanden habe und die Umrechnung in UTM immer funktioniert. Dann habe ich zwar Wochenlang umsonst Kopfstände in den Fakultäten für theoretische Informatik und vor meinem Rechner gemacht für verschiedenste Funktionen und kann einfach elementare Geometrie verwenden, das wäre natürlich top Würde mich über eine Widerlegung meiner Ansichten freuen. Es spricht allerdings schon dagegen, dass allein Projektionen auf Rotationsellipsoiden deutlich mehr Trigonometrie verwenden als einen einfachen Sinus, der ja auf der Ebene ausreichen würde.



PS: Disclaimer: Die Schwerpunktsthematik ist für GCC damit nicht ad acta gelegt. Ich habe mich derzeit schlicht und einfach noch nicht drum gekümmert. Und den Umkreismittelpunkt brauchte ich selbst irgendwann mal, also habe ich sie GCC spendiert... Kann mir schon vorstellen den Schwerpunkt und tausend andere Punkte im Dreieck früher oder später einzubauen. Ist eben nach meinem bisherigen Kenntnisstand nur "nicht mal eben fix mit einem Tafelwerk erledigt".

Darf ich fragen wie (mit welcher Formel) du den Umkreismittelpunnkt bestimmst?
In der Ebene (mit oder ohne UTM) hast du ja die selben Probleme mit der Distanz.

Kannst du gern.

Ich kann dich da allerdings enttäuschen, es ist keine "einfache" Formel, sondern eher ein Verfahren, das ich anwende. Aktuell ist es ein so genannter evolutionärer Algorithmus:
https://de.wikipedia.org/wiki/Evolution%C3%A4rer_Algorithmus

Hoffe, aber irgendwann alles auf intervallarithmetische Algorithmen umstellen zu können - mir fehlt aber beispielsweise in dem speziellen Fall eine gute Modellierung der Abbruchbedingung bzw. der Vergleichsfunktion für die aktuelle "Güte".
https://de.wikipedia.org/wiki/Intervallarithmetik

Gruß S-Man

S-Man42 schrieb:

Wenn die eine Koordinate in Brasilien, eine in Kanada und eine in Australien liegt, hilft da kein UTM mehr. Da braucht es schon Berechnungen auf dem geometrischen Erdkörper selbst - und die ist eben in irgendwelchen Geodäsie-Büchern zu vielen Problemen nicht zu finden.

Zum Vergrößern anklicken....

Nach meiner eigenen Erfahrung brauchst du nicht bis Australien zu gehen. Das funktioniert schon nicht mehr genau genug innerhalb einer UTM Kachel, bei 20-30 km Entfernung (hatte mal was ähnliches vor ein paar Jahren bei einem Cache...)

Gruß
ra_sch

Ja, genau so hab ich das verstanden. Das geht nur, wenn du in einer Zelle bleibst... Denke ich.

Das Bild in der Wiki https://de.wikipedia.org/wiki/Datei:Utmzonenugitterp.png macht das ja deutlich. Die Gitterzonen sind zueinander nicht sonderlich planar Also wird es schwierig, über diese hinaus mit "klassischer" Geometrie zu arbeiten... glaube ich...

So isses - bei UTM musste in der Zelle bleiben. Und das hat auch schon seinen Grund dass die Geodäten in der Fläche arbeiten ;-)
Der Mittelpunkt von drei richtig weit entfernten Punkten würde auch in der Erde liegen, der soll dann wieder auf die Oberfläche projeziert werden und die daraus abgeleiteten ellipsoidischen Koordinaten sollen dann die Lösung sein?

Und das ist der Denkfehler

Du verbindest jetzt drei Punkte auf der Erde und fängst wieder an mit 2D Geometrie. Klar, dann liegst du in der Erde.

Aber das mache ich nicht. Ich wende keine klassische Geometrie an. Sondern Näherungsalgorithmen.

Wenn du den Mittelpunkt der Strecke zwischen zwei Punkten nimmst (du willst den Punkt auf halber Strecke zwischen Berlin und New York wissen), würdest du ja auch nicht auf die Idee kommen, diese beiden Punkte direkt zu verbinden und dann die Mitte zu bestimmen. Dann liegst du ebenso in der Erde. Nein, du würdest die kürzeste Strecke auf dem Ellipsoiden nehmen zwischen B und NY und auf der Hälfte anhalten, richtig? Ich habe also den Punkt gefunden, der von B und NY gleich weit weg ist und nebenbei von allen möglichen Lösungen die kürzeste Distanz hat => Mittelpunkt zwischen zwei Punkten.

Ähnlich arbeitet mein Algorithmus:
Ganz einfach gesagt: Ich nehme mir einen beliebigen Punkt, berechne zu diesem Punkt die Entfernung zu den drei gegebenen Punkten *auf der Oberfläche des Ellipsoiden*. Wenn alle drei Distanzen identisch sind, habe ich den Mittelpunkt (remember: lt. meiner Aufgabenstellung ist das der Punkt, der gleich weit weg von den drei Punkten weg ist), wenn nicht, muss ich einen anderen Punkt suchen. Da wird kein Dreieck in dem Sinne benutzt.

Im Grunde kann man sich das dann so vorstellen:
http://goo.gl/Qo0cYL

A, B, C sind willkürlich gewählt. D wurde von GCC berechnet. Wie man rechts schön sehen kann, haben die Linien AD, BD, CD die gleichen Längen, D ist also von allen drei Punkten gleich weit weg.
Natürlich gibt es noch einen zweiten Punkt der das erfüllt...

@S-Man42
Das Problem wird allerdings werden, so wie es heute schon ist, daß Du eine sehr hohe Genauigkeit und Realität der Berechnungen erzeugst, aber womit hat der Cache-Owner gerechnet!!??
Ich rechne z.B. seit 2 Sommerurlauben an diesem hier: http://coord.info/GC1F4Y4 und komme nicht zur Lösung. In Summe sind es bei mir ca. 239km die zusammen kommen und da ist viel Raum für "Rechenungenauigkeit".
Hier in Thüringen gibt es seit kurzen einen Cache mit Berechnung von einem Kreis von ca. 55km Durchmesser und das hat der Owner auch nur mit einem 2D-Programm berechnet.
Die Frage wird also immer sein: Wie oder womit hat es der Owner gemacht??

Dennoch Dein Eifer ist sehr lobenswert!!

Berglöwe

Ja, da gebe ich dir natürlich recht. Aber da kann ich mit GCC ja kaum gegensteuern. Ich kann eben nur versuchen, bestmögliche Ergebnisse zu erzielen, um nicht eine zusätzliche Ungenauigkeit einfließen zu lassen. Wäre GCC jetzt auch ungenau (Disclaimer: Ich behaupte nicht, dass jede Funktion perfekt arbeitet! Über Fehlerhinweise bin ich immer dankbar!), muss diese Ungenauigkeit auch noch beachtet werden. Das würde zu noch mehr Fehlerbereichen führen.

Deswegen veröffentliche auch ungern Code, der nur in bestimmten Bereichen funktioniert, eben wie die hier besprochene Thematik.

Zu deinem Flugplatzproblem: Da hat man schon Schwierigkeiten. Er sagt, er rechnet nach GK (welchen Parametersatz verwendet er?), dann weiß man nicht, ob er seine Peilungen auf dem Bessel-Ellipsoiden macht (eben GK...) oder immer wieder zwischen WGS und Bessel hinundher arbeitet. Warum will er auf GK rechnen? Rechnet er immer nur planar, oder immer auf dem Bessel oder oder oder... Es gibt viele Möglichkeiten, hier Fehler einzubauen. Du solltest mal versuchen, das ganze mit klassischer 2D-Geometrie durchzurechnen. Als erst GK umwandeln und dann eben mit einfacher Geometrie projizieren. Strecke und Winkel kennst du ja.

Das ist auch meine Erfahrung mit solcherlei Caches. Das Problem ist dann oft nicht, herauszufinden, wie es richtig wäre, sondern welchen (unpassenden) Algorithmus der Owner angewendet hat (ich hatte mal einen Cache, der hat die Finalposition einfach mal als Gegenposition eines Berggipels auf der Kugel gerechnet (ganz abgesehen davon, dass schon die Position des Gipfels je nach Quelle zwihmlich schwanken kann). Insofern hätte eine Implementierung in GCC den Vorteil der normativen Kraft

ra_sch

Sofern die Norm in Ordnung ist Ich betone immer wieder gern: Aktuell sitzt da nur ein einzelner hinter, der sich da irgendwas aus zig Quellen zusammenreimt und hofft, dass es stimmt

Und das finde ich genial: Der Programmieraufwand selbst dürfte recht übersichtlich sein, die theoretischen Grundlagen dahinter aber so vielfältig, dass ich immer noch nicht glauben kann, dass du alleine so viel Zeugs hinbekommst. Respekt und vielen Dank!