Anteil Himmelsrichtung an Track

Hallo zusammen,

mal eine vielleicht blöde Frage: kann man mit irgendeinem Programm Tracks so auswerten, dass man sieht, wieviel km in Richtung Süden, wie viele in Richtung Norden etc gehen - also, sozusaagen den Anteil der einzelnen Himmelsrichtungen?

Anwendungszweck: Statistiknerdismus

Viele Grüße
Holger

Sowas mache ich mit ECXEL. GPX kann man in EXCEL mit einem geeigneten Filter (i.d.R. vorhanden) importieren, und dann ist es im Prinzip nur noch sphäriasche Geometrie, sich Entfernungen zwischen zwei Trackpunkten auszurechnen. Ich nehme die Erde als Kugel an, der Fehler ist praktisch zu vernachlässigen.

Gruß
Thoralf

Hm, das fällt bei mir zumindest nicht unter "nur noch" - muss ich mal recherchieren

Schreibe ich dir.

Merci - aber warte bitte erstmal - Mein Forscherdrang ist erweckt, mal schauen, was ich da finde

In dem Fall muss man aber auch noch die Peilung mitberechnen. Die Formel habe ich nicht gefunden, obwohl es einige Onlinerechner zu der Frage gibt.

Bin schon fertig... Aber wir können dann anhand eines Testtracks die Ergebnisse vergleichen.

Peilung? Was meinst du damit?

Ich würde einfach zwischen den Koordinaten-Punkten des Tracks die Ost-West und die Nord-Süd- Abstände aufsummieren, fertig. Die Kugelkoordinaten (nix anderes ist Länge/Breite ja) lassen sich da doch einfach umrechnen. (Wobei wir uns darüber unterhalten können, ob man da nicht wieder ein Rauschen aufsummiert, man kann den Algorithmus etwas cleverer gestalten).

Was richtig ist: Wenn ich nach NO fahre, ergibt diese Rechnung die gleichen Werte, wie wenn ich erst nur nach Osten fahre und bei Erreichen des Zielmeridians dann nach Norden. Obwohl der Gesamtweg im zweiten Fall deutlich länger ist. Aber der Fadenersteller will ja schlicht Zahlen sehen, einfach "weil er es kann".

Ah, ich glaube ich weiß was du meinst. Die Abweichung vom magnetischen Nordpol und dem geografischen? Ist hier aber unrelevant, wenn wir uns ausschließlich auf GPS-Daten und damit den geografischen Nordpol beziehen. Andere Effekte (wie die Tatsache, dass die Erde keine perfekte Kugel ist) halte ich hier für vernachlässigbar. Wirklich kritisch werden die Unterschiede unterschiedlicher Koordinatenstandards sowieso erst in der Nähe der Pole.

Sagen wir mal 50 km nach West und 50 km nach Nord im Vergleich zu ca, 70 km nach Nordwest - wenn ich es richtig verstehe, wären die Ergebnisse nach Deiner Methode dieselben? Habe gerade kein Excel, und schon die Wurzel im Kopf anzunähern, war fies - aber das möchte ich eigentlich nicht.

In diesem Beispiel hätte ich als Ergebnis für die Variante A gerne 50 % West und 50 % Nord und für die Variante B 100 % NW. Bin aber nicht sicher, ob ich Dich richtig verstanden habe. Letztlich müsste ich es natürlich aufteilen in N, NNW, NW, NWW etc.

Viele Grüße
Holger

War ein Begriff auf den ich gestoßen bin, als ich mit Himmelsrichtung beim Suchen nicht weiter kam.
z.B. http://gps-cache.de/geocaching/koordinaten-peilung.htm

Es gibt minestens zwei Wege das ganze aufzuschlüsseln. (Mindestens bedeutet mir fallen nicht mehr ein, aber das heißt nicht, dass es nicht mehr geht.

Weg eins. Du berechnest die Distanz zwischen zwei Punkten und die Peilung. Dann berechnest Du den Anteil, um wie viel Du dich nach Süden oder Norden bzw. Osten und Westen bewegt hast. In der Ebene Satz des Pythagoras.

Weg zwei. Du brechnest die Peilung und die Distanz. Ist die Peilung zwischen -45 und + 45 Grad, wird die Bewegung als eine Bewegung Richtung Norden aufgefasst. Dann bist Du die Distanz zwischen den Punkten nach Norden gefahren, obwohl es leicht vom Norden abweicht. Du kannst aber auch kleiner Segmente wählen. Also z.B. deine N, NNW, NW, NWW.

Eigentlich musst Du erst einmal definieren, was bedeutet für dich, sich nach Süden zu bewegen.

Weg 1 ist eine mathematisch geprägte Definiton, Weg 2 eher eine vom Sprachverständnis.

Genau, richtig verstanden.

Aber jetzt verstehe ich eher was du willst. Im Prinzip denkst du an so eine Art Kompassrose und an jeder eingetragenen Richtung steht absolut oder relativ der Anteil deines Tracks dran.
Sobald du die vier Zwischenhimmelsrichtungen NO, SO, SW, NW dazu nimmst, wird der Fehler auch kleiner, nicht mehr wurzel(2)=1,4... maximal, sondern eher so 1,15 (geschätzt, habe jetzt nicht explizit gerechnet), damit kann man wohl leben.

Also im Prinzip willst du ein zweistufiges Verfahren:
(1) Klassifikation aller Trackstückchen in welche Himmelsrichtung (8 Richtungen, oder gar 16) sie gehen
(2) Aufsummation deiner Klassen.

Das kann man dann so gestalten, dass der Fehler bei der Zuordnung zu den Himmelsrichtungsklassen liegt (NNNW würde z.B. N zugeordnet werden), die Summe der Wege in die Einzelrichtungen ergäbe aber wirklich deine Gesamttracklänge.

Um in meinem theoretischen Beispiel zu bleiben: Du fährst 20km nach NNNW, dann würde deine Auswertung 20km nach N liefern. Also passende Gesamtstrecke. Aber wenn du am Start die 20km nach Norden ansetzt, kommst du nicht genau da raus, wo du letztlich hingefahren bist (der geringe W-Anteil fehlt). Irgendwo muss man hier einen Kompromiss machen: Entweder die Gesamtstrecke stimmt, oder die Kombination aus Richtung und Strecken führt dich exakt zum Ziel. Beides zugleich ist nicht zu 100% erfüllbar.

P.S.: JZieps Beitrag lese ich erst jetzt. Ja, das trifft es im Kern auch. Nur ist es so, dass man bei seiner ersten Variante, wenn man sich auf die vier Himmelsrichtungen beschränkt, gar nicht erst die Peilung(=Fahrtrichtung) ausrechnen muss, denn die Anteile nach NS bzw. OW ergeben sich ja direkt aus den Koordinaten. Das Ergebnis wäre identisch mit meinem initialen Beispiel. Sobald man mehr Richtungsklassen nimmt, kommt man da aber um die Berechnung der Fahrtrichtung nicht drumrum.

Das dachte ich mir jetzt als Lösung. Die Distanz und die Peilung zwischen zwei Trackpunkten ausrechnen. die Peilung würde ich in 16 Segmente aufteilen, also N, NNW, NW, WNW, W, WSW, SW, SSW etc. Nord wäre dann - wenn Norden 0° ist - zwischen 348,75° und 11,25° und so weiter.

Das klingt nach nem netten Wochenendprojekt, vor allem eine hübsche grafische Aufbereitung würde mir gefallen. Dafür bietet sich ein Radar-Chart wohl an.

ich hoffe, dass es schneller geht

Ich teste das erstmal an fiktiven Daten - ist ein bisschen Arbeit, das einmal auszutüfteln in Excel. Entfernungsberechnung, Berechnung der Peilung, Einteilung der Peilung in Klassen ... aber es hört sich erstmal nicht unmöglich an. Wenn ich nicht irgendwas übersehen habe. Radar-Chart ist dann sicher eine gute Idee.

Viele Grüße
Holger

Für dich geht das sicher schneller, Du hast ja bereits vorgearbeitet. Ich dachte an ein Wochenendprojekt für mich, evtl. mit Webfrontent, direktem Einlesen einer gpx-Datei und ein paar Einstellmöglichkeiten.

Die anderen Punkte sind Kleinigkeiten, wenn man die Formeln hat. Die Einteilung in Klassen eigentlich auch. Dann kommt meiner Excelerfahrung nach der schwierige Punkt, wie die Klassen auswerten.

ich habe gestern versucht eine Liste mit:
1 NO
1 NW
1 NO
1 NW

so zu filtern, dass z.B. nur die Zeilen mit NO stehen bleiben. Ich habe es nicht hinbekommen. Was jetzt nicht heißt, weil ich solche Datenauswertungen nicht mache. Aber ich erlaube mir den Hinweis, probiere mal aus bei so einer simplen Liste nur die Zeilen, die einer bestimmten Richtungsklasse zugeordnet sind rauszufiltern. Denn der Rest erscheint mir trivial.

AUs dem STand würde ich das mit einer "SummeWenn"-Formel machen - also Zahlen Spalte x (Distanz) addieren, wenn Spalte y (Peilung) = NNW - und analog mit dem Rest. Das müsste eigentlich klappen. Schaue ich mir morgen mal an.

Die Formeln entwickeln ist noch ein kleiner Schritt Ich teste das in der Tat erstmal mit Dummy-Daten, bei denen ich einfach im Kopf auf Plausibilität prüfen kann.

Ich habe mir das einfacher gemacht. Beispiel:

Bewegung von (lat1,lon1) nach (lat2,lon2).

A. Gesamte Entfernung ist jetzt die Strecke (lat1,lon1)-(lat2,lon2) (aufsummiert über alle die Streckenlänge)

B. Ost-West-Entfernung ist die Strecke (lat1,lon1)-(lat1,lon2) (nur die Änderung in geograhischer Länge)

C. Nord-Süd- Entfernung ist die Strecke (lat1,lon1)-(lat2,lon1) (nur die Änderung in geograhischer Breite)

Da macht man für alle Punkte eines Tracks. Jetzt muss man die Vorzeichen bei B und C jeweils noch auswerten und auseinandersortieren (geht bei EXCEL mit der WENN-Funktion), und anschließend aufsummieren.

Sicherlich macht man einen kleinen Fehler dabei. Aber die Dichte der Trackpunkte ist so groß, dann man jedes einzelne kleine überstrichene Viereck als ebenes Quadrat Rechteck auffassen kann.(*) Das wird nur in absoluter Polnähe kritisch, aber da macht die Unterscheidung Ost-West ohnehin keinen Sinn mehr.

Gruß
Thoralf

PS: Ich habe probeweise für die überstrichenen Vierecke die Abweichung vom Quadrat zwischen Trapez und Rechteck berechnet. Für Mitteleuropa bei Abständen der Trackpunkte unter 500 m ist der Fehler unter 10-5.

Was meine Einkommenssteuer sehr erleichtert. Danke.

Es macht einen Unterschied, ob du zuerst den Anteil ausrechnest, der zum Längengrad gehört und dann auf dem Breitenkreis die Ost-West Entfernung bestimmst oder zuerst vom Startpunkt aus den Breiten- und dann den Längengrad entlang die Entfernungen berechnest.

Von den beiden Breitenkreisen, die da in Frage kommen, hat der Breitenkreis, der dem Äquator näher liegt, die längere Srecke. Wenn du eine Ost-West-Strecke (also den Abstand zweier Längengrade) auf dem 50. Breitengrad (Mainz) misst, ist sie ca. 1% länger, als auf der Höhe von Köln (51. Breitengrad). Die Nord-Süd Entferunung auf den Längengraden ist immer gleich, egal auf welchem Längengrad man sie bestimmt, da die Längengrade Großkreise sind.

Ich habe mal mir ein GPX-bezogenes Programm geschrieben. Ist die ganze Problematik nicht in den entsprechenden Formeln drin?

Ich sehe gerade, bis zu einem bestimmten Grad.

https://www.kompf.de/gps/distcalc.html

Ja, mit diesen Formeln wird explizit berücksichtigt, dass die Breitekreise nach Norden hin kürzer werden. Da steckt quasi auch die oben angesprochene Peilung drin.

Die Entfernung zwischen den Punkten (lat1,lon1) und (lat2,lon2) ist:

dges = rerde * arccos( sin(lat2) * sin(lat1) + cos(lat2) * cos(lat1) * cos(lon2 - lon1) )

Für die Bewegung in Ost-West-Richtung ist die Entfernung zwischen (lat1,lon1) und (lat1,lon2) relevant (Bewegung entlang des Breitenkreises):

dOW = rerde * arccos( sin²(lat1) + cos²(lat1) * cos(lon2 - lon1) )

Wie man sieht, steckt die geographische Breite hier noch drin. Grund ist, dass die Breitenkreise eben nicht gleich lang sind.

Für die Bewegung in Nord-Süd-Richtung ist die Entfernung zwischen (lat1,lon1) und (lat2,lon1) relevant (Bewegung entlang des Längenkreises):

dNS = rerde * arccos( sin(lat2) * sin(lat1) + cos(lat2) * cos(lat1) )

Hier steckt die geographische Länge NICHT mehr drin (kürzt sich raus, cos(0°)=1). Grund ist, dass die Längenkreise wirklich alle gleich lang sind.

Gruß
Thoralf

Nachtrag: Strenggenommen ist es nicht egal, ob ich erst 1° nach Osten fahre und dann 1° nach Norden; oder ob ich erst 1° nach Norden fahre und dann 1° nach Osten. Man kommt zwar am selben Punkt raus, aber die durchfahrene Strecke ist nicht gleich lang.

Insofern ist es Definitionssache, was man quantitativ als "nach Osten fahren" ansieht.

Wie ich oben schon schrieb, ist der relative Fehler, den man dabei macht aber sehr gering (<10-5 = 0.001%). Der Abstand zwischen zwei Trackpunkten ist in der Regel nicht viel mehr als ein paar hundert Meter. 1 km auf der Erdoberfläche entsprechen etwa 30 Bogensekunden (ca. 0.0085°) im Koordinatensystem. Damit ist dieser Effekt der unterschiedlichen Länge der Breitenkreise hier zu vernachlässigen.

Klar, wenn ich nur einen Trackpunkt in Mainz und einen Köln setze, dann ist der Unterschied schon größer, aber eben inner noch "nur" 1%.

Gruß
Thoralf

Als bekennender Excel-Hasser habe ich mich mal bei python umgesehen und habe folgendes gefunden:
- sehr leichtgewichtig geo.py
und hier:
- umfangreicher: LatLon
Mit einer gpx-library wie gpxpy sollte sich in ein paar Zeilen was zusammenhacken lassen, auch ohne der große Programmierer sein zu müssen. Dann spart man sich später auch das rumgeklicke mit Excel :-)

edit:
hier ist noch was mit Beispiel: https://stackoverflow.com/a/32127479

Auf der Webseite ist ein kleiner Fehler: Der Erdumfang entlang eines Längengrades (also von Pol zu Pol) wurde von den Franzosen benutzt, um den Urmeter zu definieren (1/10000 des Abstandes Pol - Äquator). Daher hat der Umfang theoretisch die glatte Länge von 40.000 km. Ein paar Messfehler von damals führen zu einer tatsächlichen Länge von 40.008 km. Bei 360° sind das nur 111,1 km für den Abstand der Breitengrade. Der Abstand der Längengrade am Äquator sind die ca. 40.075 km geteilt durch 360° = 111,3 km (der Wert stimmt). Macht knapp 2 Promille Abweichung, also auch den Kohl nicht fett.

Für das Distanzproblem gibt es die Haversine-Formel.

Ansonsten bevorzuge auch ich Python. Folgender Code gibt eine Liste mit 360 Einträgen aus. Der Index entspricht der Peilung, der entsprechende Wert ist die Distanz in Kilometer. Lauffähig ist das, die Korrektheit des Ergebnisses habe ich nicht überprüft.

Ich habe mal nachgerechnet... diese Haversine-Formel ist mit der oben angegebenen Formel der anderen Webseite identisch. Nur eben anders ausgedrückt, Haversine nutzt den Arkussinus, die andere andere Formel den Arkuskosinus.

Allerdings lassen sich damit die Formel für Ost-West- und Nord-Süd-Bewegung vereinfachen:

dOW = rerde * (lat2-lat1)
...sofern lat im Bogenmaß gegeben ist

dNS = rerde * arcsin( cos(lat2) * sin((lon2-lon1)/2) )

Gruß
Thoralf

Du kannst dir offenbar nicht wirklich vorstellen, dass es Menschen gibt, die keine Python-Installation oder eine sonstige Programmiersprache auf ihrem Computer haben?

Gruß
Thoralf

Wie weit bist du denn bisher gekommen?

So ganz raffe ich immer noch nicht, was du mit der Peilung bezweckst. Wenn du die Peilung hast, dann kannst du mit dem Kosinus den Anteil in Nord-Süd-Richtung und mit dem Sinus den Anteil in Ost-West-Richtung ausrechnen. Aber dann bekommst du wieder nur die Bewegung auf den Breiten- und Längengraden raus, die du direkt aus den GPS-Koordinaten berechnen kannst (einfache Dreiecksgeometrie).

Oder habe ich da was falsch verstanden?

Vielleicht sollte man sich mal grundsätzlich einigen, was man unter deiner Ausgangsfrage überhaupt versteht.

Wenn du mir einen Beispieltrack schickst (vorzugsweise nicht zu lang), dann kann ich den durch mein Skript laufen lassen und sehen, was rauskommt.

Gruß
Thoralf

Das mit dem "großen Programmierer" war wohl etwas schlecht formuliert. Natürlich muss man da etwas programmieren, aber ich behaupte, dass die meisten das hinkriegen auch wenn sie kaum Programmiererfahrung haben und sich das eventuell nicht zutrauen würden. Sich da einzulesen sollte auch in einem Wochenendprojekt machbar sein, aber vielleicht schätze ich das auch falsch ein. Das mit Excel zu machen erfordert schließlich auch Einarbeitung, obwohl natürlich viele aus beruflichen Gründen mit Excel zu tun haben.
Das mit der Installation lass ich mal nur so halb gelten. Python zu installieren ist jetzt auch nicht komplizierter als MS Office und dazu noch kostenlos. In den Anfängertutorials steht das meistens dabei wie man eine Entwicklungsumgebung unter Windows installiert, ist auch nur eine exe runterladen und sich durch das Setup zu klicken vermute ich mal (ich bin mit Linux unterwegs).

Ich hab das vor Jahren Mal in Perl gemacht. Abstand und Himmelsrichtung, wenn man Erdkrümmung und Höhe über Meeresspiegel ignoriert, sind Zwei- oder Dreizeiler. Kann man sich selbst schreiben. Library ist gut zum Parsen von GPX/XML.

Peilung habe ich jetzt einfach als "Himmelsrichtung" verstanden, wie jziep oben kam ich mit letzterem Begriff nicht weiter. Vielleicht habe ich da auch etwas falsch verstanden. Damit will ich errechnen, in welcher Richtung sich Punkt B von Punkt A aus befindet - also Richtung N, NNW, NW, WNW etc. Ich habe dann für einen Wert für die Himmelsrichtung, die ich zwischen Punkt A und Punkt B fahre.

Dann rechne ich einfach die Entfernung zwischen Punkt A und Punkt B aus, das dachte ich bisher auch, sei ein einfacher Dreisatz. Und dann schaue ich, wieviele der Entfernungen zwischen PunktA und Punkt B, Punkt B und Punkt C ... Punkt y und Punkt Z in Richtung N gingne, wieviele in Richtung NW etc.

Das Ergebnis soll in etwa wein: AUf dem Track bin ich zu 45 % in Richtung Süden gefahren, zu 10 % in Richtung Südwest etc.

Viele Grüße
Holger

Vorsichtshalber, deine letzten Post klangen als hättest Du das Prinzip verstanden. Jetzt bin ich mir nicht mehr so sicher. Also.

Jein. Peilung gibt an, wie viel Grad deine Bewegungsrichtung von Norden abweicht. Darüber kannst Du dann entsprechend der gewählten Himmelsrichtungsrosette bestimmen, in was für eine Himmelsrichtung Du gefahren bist.

Habe ich schon so verstanden, denke ich - vielleicht etwas verkürzt ausgedrückt. Norden ist 0°. Und der rest von 1 bis 359 ist dann die Abweichung - die will ich dann in die einzelnen Himmelsrichtungen unterteilen. Also HImmelsrichtung Nord ist 348,75° bis 11,25 ° - wenn man 16 Himmelsrichtungen nimmt.

Richtig. Aber das Problem liegt in der Auswertung, hatten wir oben schon mal. Fährst du 70km stur nach N oder stur nach O, dann kommt bei deinem Verfahren auch die Auswertung 70km in die entsprechende Himmelsrichtung raus.
Fährst du aber 70km nach NO, dann wertet sich das zu etwa 50km nach Ost und 50km nach Nord aus. Formal alles ok, nur dass letzteres irgendwo suggerieren könnte, dass 100km gefahren worden seien - was ja weit mehr ist als real passiert ist.

Wenn ich mir jetzt ein Set von vier Richtungen vorgebe (N,S,O,W) und jede Peilung zwischen zwei Trackpunkten einer der Kategorien zuordne, dann kann ich den Track so zerlegen, dass die Summe der Einzelrichtungen wieder die Trackgesamtstrecke ergibt. 70km Ost bzw. 70km Nord wären genau das was man erwartet, bei den 70km nach NO hängt es dann von meiner Zuordnung ab (weil NO genau auf der Grenze liegt), könnte sich auf 35km nach Ost und 35km nach Nord zerlegen, aber auch 70km N und 0km Ost (wenn ich eher Richtung NNO gefahren war) oder 0km N und 70km Ost (wenn es mehr Richtung ONO war). Sobald ich mehr Himmelsrichtungen zulasse, bleibt weniger Strecke in die Einzelrichtungen übrig, dafür passt die Richtungszuordnung besser. Für seine individuelle Auswertung/Einschätzung kann man nachträglich ja z.B. NNO, NO und ONO wieder zu einer Einheit zusammenfassen.

Ich glaube, wir reden immer noch aneinander vorbei... oder Computerfreaks können sich die Welt von Nichtcomputerfreaks absolut nicht vorstellen.


...Copy und Paste.

Entschuldige bitte, aber eine Tabellenkalkulation zu bedienen (gibt ja auch andere als Ecxel) ist schon noch eine ganz andere (tiefere) Liga als ein Programm zu schreiben.

Es geht ja nicht nur darum, zwei einzelne Koordinaten in den Quellcode zu tippen. Man muss die GPX-Datei ja auch irgendwie erst mal einlesen, die entsprechen Befehle und Datenstrukturen kennen und sich durch die Struktur der Datei fitzen.

In Excel sind das Einlesen nur zwei Mausklicks (der Filter ist vorhanden), ich habe es gerade noch mal versucht. In Python ist das garantiert mehr Arbeit, da würde ich jede Wette eingehen.

Ich musste ähnliches in einem früheren Job mal machen. Obwohl ich sehr gut Pascal und ein bisschen C konnte, bin ich mangels Erklärung mit Python nicht wirklich weitergekommen. Die Syntax-Hürde war zu hoch.

Da gehen so einfache Sachen, die man nur sporadisch mal braucht, mit einer Tabellenkalkulation, die vermutlich ohnehin vorhanden ist, einfach schneller.

Radarplots sind hier verwirrender als ich dachte. Verlinkt seht ihr ein erstes Ergebnis, hier sind die Distanzen je 10°-Kreissegment aufsummiert.



Und damit wir die vergleichen können, habe ich die gpx-Datei aus dem Wikieintrag zur Vennquerbahn genommen.

Definiere "mehr Arbeit", aber jede Wette würde ich da an deine Stelle nicht eingehen:

Man muss halt die gpxpy-Bibliothek kennen bzw. ergoogeln, damit ist das Parsen der Datei dann recht einfach und besagter 3-Zeiler.

Ansonsten ist Python schon eine super Sprache zum Einstieg, schreibt sich ja fast wie Pseudocode.

Meines Erachtens ist das bissl Geschmackssache, in welcher Welt man sich da wohler fühlt: Excel, dem zweitbesten Tool für jeden Anwendungszweck, oder eben der direkten Programmierung, wo man alle Freiheiten hat.

Ich finde auch Python schicker, da kann man dann z.B. schneller damit rumexperimentieren, mit wie vielen Richtungsklassen man z.B. operieren will. Wenn ich an den Formeln rumschrauben will, dann ist Excel da immer bissl sperrig.

10° finde ich eigentlich schon fast zu granular, hätte erst mal 8 oder bestenfalls 16 Richtungsklassen (45° bzw. 22,5°) genommen.
Aber was stört dich denn an der Darstellung? Der Beispieltrack geht doch fast schnurgerade nach Westen, das sieht man ja auch. Genauer hingeschaut merkt man auch, dass ungefähr 50% direkt nach West und dann 50% nach etwa WNW gehen.

Würde ich schon. Also für meinen teil, ich habe in den 90gern ein wenig Basic in der Schule gelernt. Das hat gereicht, dass ich mir hie und da ein eigenes Programm mit Visualbasic (dabei war auch eine Anwendung für GPX) schreibe, mein eigenes Wordpresstheme in php und eigene MySQL-Anwendungen. Ich verwende Latex und Lilypond. Aber so alle paar Jahre werfe ich mich in die Untiefen von Programmieren. Dabei muss ich mich jedes Mal erneut einarbeiten.

Ich würde perse Excel bevorzugen. Das einzige was in einer Programmiersprache angenehmer wäre, ist, wie man die Bedingungen schreibt , um die Peilung der Himmelsrichtung zuzuordnen. Es ist in einfach übersichtlicher.



Es ist mehr Arbeit, abgesehen dass es mehr Tastenanschläge sind. Ich weiß vermutlich, was in dem Code passiert, aber ich hätte ihn etwas anders erwartet.

Das mit dem "for" sind vermutlich ineinander verschachtelte oder hintereinander abgearbeitete Schleifen. Schon alleine dass ich nicht entscheiden kann, ob verschachtelt oder hintereinander ausgeführt macht klar, was für ein Arbeitsaufwand für einen absoluten Laien bei deine Pythonidee entsteht. Weil der muss erst einmal herausfinden, dass man Schleifen braucht, dann wie man die schreibt, und die Syntax, wie man die Felder in den arrays(?) benennen muss.

Letztendlich auch wenn man Python kann, muss man herausfinden, dass es die Bibliothek gibt. Erst durch die wird es ja so elegant. Ohne eine Bibliothek wird es umständlich.

Sagen wir es mal so, hätte ich die entsprechenden Formeln, würde ich die Exceldatei in 15 Minuten schreiben. In dem mir vertrautem Visual Basic, indem ich auch schon mal XML-Dateien bearbeitet habe, vermutlich einen Tag.

Allein das Du von einem Wochenendprojekt sprichst, trotz deiner Pythonkenntnisse, warnt mich, mich, mich nicht darauf einzulassen.

Naja, GPX ist letztlich ja auch nur XML. Der Pythonparser greift diese Struktur auf: innerhalb der GPX-Datei gibt es Tracks, diese bestehen aus Segmenten, diese wiederum aus einer Abfolge von Points. Darüber hinaus kann es noch andere Dinge geben, z. B. einzelne POIs oder andere Metadaten.

Und genau darauf greift der Code dann zu: Er geht durch alle Tracks, alle Segmente, alle Punkte. Und ich habe die volle Freiheit z.B. alle Segmente "auf einen Rutsch" oder getrennt zu verarbeiten.
Bei Excel bin ich wahrscheinlich darauf angewiesen mit dem geparsten Ergbnis selbst zu leben. Wenn der nur Geopunkte einliest, muss ich mögliche POIs manuel rauslöschen, Segmente womöglich zerlegen. Kurzum: Ich bin darauf angewiesen, dass der Excelparser das liefert, was ich dann auswerten will.

Ach ja, die Schleifen sind natürlich verschachtelt. Wie es übliche Konvention beim Coden mit den Einrückungen ist (und wie es Python übrigens auch von der Syntax her vorsieht, sonst gibts nen Syntax-Error). Und wie es auch logisch ist, wenn man sich über den Aufbau einer GPX-Datei wie oben geschildert klar ist.

Es ging darum, wie viel Aufwand es ist. Der Aufwand ist weniger das Tippen, sondern sich das Vorwissen anzuschaffen. Will man es mit einer Programmiersprache machen, dann musst Du schon einige Konzepte des Programmierens kennen. Bei Excel kennt man die wichtigsten Grundfunktionen, wenn man damit gearbeitet hat. Wenn es sehr rudimentäres Arbeiten war, dann muss man vermutlich rausfinden, dass man Zellen mit Bedingungen auswerten kann.

Und das geparste Ergebnis von Excel ist erstaunlich übersichtlich, wenn man alle drei Sachen in die GPX-Datei reinpackt. Wegpunkt, Route und Track. Gerade ausprobiert wegen deines Einwands.

Das ist ein Argument, sich mit dem Mittel seiner Wahl etwas auszukennen, aber keines für Excel. Und natürlich kann Excel mit den entsprechenden Vorkenntnissen hier das Mittel der Wahl sein. Oder halt nicht.

Eine Frage ist, wie man die Segmente ausrichtet. Teil man z.B in 4 Segemente, werden die Segemente nach N, E, S und W ausgerichtet oder nach NW, SW, SE, NE?

Darum gibt es je zwei Varianten der Plots mit 8 und 16 Segementen.

Und was wird jemand getan haben, der sich für Excel entscheidet. Genau sich diese Frage beantwortet haben. Dabei wird er höchstwahrscheinlich nicht vergessen haben, dass er, wenn vorhanden, Programmierkenntnisse hat.

Ihm dann von einer unbekannten Programmiersprache vorzuschwärmen, es wäre alles so easy, ist was?

Na intuitiv würde ich die Segmente immer so ausrichten, dass die Kernhimmelsrichtungen zentriert liegen. Bei vier Richtungen also die Zuordnung zu N von NW bis NO.

Sieht doch nett aus, was du da ausrechnen lassen hast. Kernerkenntnis ist ja: Geht nach Westen.

Nach Landkarte (ohne Mathestudium) gehts nach WestNordWest.

Für mich ist es das Aufzeigen weiterer Möglichkeiten. Ich habe beispielsweise zuvor schon erfahren, was Leute mit Excel alles machen können.

Was es mit Sicherheit nicht ist, ist ein Angriff auf persönlicher Ebene.

So ganz nebenbei gefragt - wer will hier wem, was und warum beweisen ?

Na ja , es ging darum, zu verdeutlichen, warum die Hilfe für die wenigsten wirklich irgendwie hilfreich ist. Und dass dies ziemlich offensichtlich ist.

Die Frage ist doch, warum etwas, das für die einen offensichtlich ist, anderen nicht auch einleuchtet. Hier: Unter mehreren Werkzeugen, mit denen man eine Aufgabe lösen kann, dasjenige zu wählen, mit dem man in Summe den geringsten Aufwand hat. Wenn ich es mit Excel in einer halben Stunde erledigt habe und die Aufgabe sich nur zwei oder drei Mal pro Jahr stellen wird, dann mache ich es mit Excel. Wenn ich die Aufgabe in Zukunft einmal pro Woche erledigen muss, dann lohnt es sich zwei Tage Aufwand in die Programmierung mit Sprache X zu stecken.

Wenn's um Geld geht, leuchtet das jedem ein, z.B. ob sich der Kauf eines Werkzeugs lohnt, das man definitiv nur einmal einsetzt, dessen Preis aber die Kosten einer Reparatur in der Werkstatt um ein Vielfaches übersteigt. Obwohl, wenn ich an manche Fäden zu solchen Themen hier denke...

So, vielen Dank allen für die Hilfe. Habe ein zufriedenstellendes Ergebnis erhalten - selbstverständlich mit Excel (um das klarzustellen: ich habe gar nichts gegen Vorschläge, wie man es auch anders lösen kann - das kann ja für den einen oder anderen sinnvoll sein. Ich habe jedoch keine Sekunde einen Gedanken daran verschwendet )

Die Entfernung habe ich nach der einfachen Methode aus dem hier auch schon geposteten Link berechnet: https://www.kompf.de/gps/distcalc.html

Das war völlig ausreichend, die Entfernungen zwischen den Trackpunkten liegen ja in der Regel im ein- oder zweistelligen Meterbereich. Die Summe der errechneten Entfernungen wich um 1-3 km von der aufgezeichneten Entfernung ab.

Den Kurswinkel habe ich nach der Formel hier berechnet: https://de.wikipedia.org/wiki/Orthodrome (ohne sie zu verstehen )

Dann musste noch Ost und West unterschieden werden, da diese Formel keine Unterschiede zwischen rechts und links macht - das ist aber mit einer WENN-Bedingung in Excel recht einfach.

Dann habe ich 16 Himmelsrichtungen eingeteilt, dabei war etwas Nord -11,25° bis 11,25° und so weiter. Das habe ich auch mit einer WENN-Bedingung errechnet (wenn innerhalb des Bereichs, dann 1, wenn außerhalb, dann 0). DAs musste ich dann nur noch mit der Distanz multiplizieren.

Ein größeres Thema war die Fehlereliminierung. Diese Orthodrome-Funktion funktioniert für wenige Zahlen nicht, warum auch immer. Deshalb spuckte Excel einige Fehler aus. Die verhinderten das Errechnen der Summe. Diese Fehler rauszubekommen war etwas tricky für mich, habe lange mit Kombinationen von WENN, ODER und FEHLER herumprobiert und es dann in zwei Schritte aufgeteilt. Erst alle Fehler gleich 0 gesetzt - dann folgte der Schrit mit der Multiplikation mit der Distanz. Dann Summen bilden, und Prozentanteile ausrechnen.

Bei Deutschland Nord-Süd bin ich also überraschenderweise hauptsächlich in Richtung Süden gefahren. Rein nach Süden (also die 11,25 Grad rechts und links von "rein nach Süden") waren 31,1 %. Nimmt man OSO und WSW dazu, sind es schon 60,8 %. Und mit SW und SO 79,1 %.

Immerhin 2,2 % gingen direkt nach Norden, insgesamt waren das 26 km, davon 20 auf der ersten Etappe, von Westerland zum Lister Ellenbogen.

Die Frage, was das alles bringt, kann ich wohl nur mit einem Achselzucken beantworten

Jetzt muss ich mir noch eine Darstellugnsform überlegen, dieses Radarchart ist vielleicht ganz nett.

Radarchart kostet aber bei den Chart-Plugins, die ich getestet habe, extra. Daher ist's nun ein langweiliges Säulenchart geworden. 2 Monate danach ein Fazit und die Statistik:

http://les21lacets.de/deutschland-nord-sued-ein-fazit-und-etwas-statistik/

Ich bin ja erklärter Gegner davon, meine eigenen Reisen in x Dimensionen zu erfassen. Auf der anderen Seite finde ich Datenauswertungen oft sehr toll und spannend. Hier zum Beispiel.