Von der Grundidee über den Prototypen zum finalen Endprodukt

Heute möchte ich anhand einiger Bilder und Videos die Entwicklungstufen eines kleinen Softwareprojekts (GPS Daten basiertes 3D Höhenprofil) illustrieren.

Vorab ein kurzer Exkurs:

Wie einige von Euch vielleicht wissen, beschäftige ich mich schon seit sehr langer Zeit mit der Analyse von protokollierten (Outdoor)Sportdaten. Dabei war es mir immer wichtig, den Schwerpunkt auf eine userfreundliche Abbildung der Daten zu legen, was dazu führte, dass die Auswertung der Daten immer auch mit der eigentlichen Illustration der Daten verknüpft war. Ende der 90'ziger konnte man auf diversen Webseiten manchmal Höhenprofile sehen, die mit meiner HRMProfil Software erstellt wurden. HRMProfil wird nicht mehr aktiv weiterentwickelt, die Aufbereitung dieser Daten ist aber immer noch ein Hobby von mir, was letztlich dazu führte, dass es einen HRMProfil Nachfolger mit dem Namen TrainingLab Pro gibt.

[Achtung Werbung]: zwecks leichteren Zugriffs sind einige Produkte direkt mit den dazugehörenden Amazon-Angebotsseiten verlinkt. Wenn man die hier aufgeführten bei Amazon gelisteten Produkte über diesen Blog bestellt, erhalte ich im Rahmen des Amazon-Affiliate-Programms eine kleine Provision! Als Amazon-Partner verdiene ich an qualifizierten Verkäufen.

Mit den Herstellern der hier erwähnten Produkten stehe ich nicht in Verbindung und mir. 

Die (Ausgangs)Idee

Es gibt wirklich viele Möglichkeiten, Rad- und Wandertouren grafisch aufzubereiten. Bei bergigen Touren ist ein zweidimensionales Höhenprofil natürlich immer sinnvoll und da heute fast alle - oder sagen wir besser - wirklich sehr, sehr viele Bikecomputer mit GPS Funktionen auffahren können, wird man auch um eine Kartenansicht, die sinnvollerweise mit dem Höhenprofil verknüpft ist, nicht umhinkommen.

Das Höhenprofil in Kombination mit der verknüpften Karte ermöglicht dann schon mal einen sehr guten Überblick. 

Allerdings kann man das Höhenprofil auch direkt mit den GPS-Trackdaten verknüpfen, sodass ein 3D Höhenprofil das Produkt ist. Um es vorwegzunehmen, ich habe diese Art 3D-Höhenprofil natürlich nicht erfunden, aber die Umsetzung ist ja eigentlich naheliegend und aufgrund der Darstellungsart gibt es gar nicht so viele Varianten, die man hierbei aufgreifen kann. Man bedient sich eines 3D Koordinatensystems und bildet die GPS-Koordinaten samt der dazugehörenden Höhenwerte einfach darauf ab.

1.) Erster Rohentwurf

Mit dem Zeichnen habe ich es leider nicht so, man kann aber hoffentlich erkennen, worauf die Sache hinauslaufen sollte.

Im nächsten Schritt musste ich mir dann einen Kopf machen, welche der vorhandenen drei Achsen des 3D Koordinatenssystems mit welchen Wertereihen verknüpft werden sollen. Da wir nur drei Parameter abbilden müssen (Latitude, Longitude und Höhe) passt das ja sehr gut :-)

2.) Ohne Mathematik geht gar nichts

Auch wenn man das als Schüler nicht hören will, man lernt fürs Leben und vor allem die oftmals gehasste Mathematik - und leider auch die Physik - werden uns unser Leben lang begleiten. Je nachdem, was man hauptberuflich so tut, wird man später nicht umhinkommen, sich in bestimmte mathematische Themen wieder einzulesen. Selbst die Informatiker unter Euch, Handwerker sowieso, nur Politiker womöglich nicht (die benötigen dann aber bei Fragen wie 'Was ist eine Inflation' mitunter etwas (viel) Nachhilfe, weil die Finanzpolitik eben doch mit der Mathematik eng verknüpft ist) :)

Um das abzukürzen, auch ich musste mich wieder etwas in die Vektorenrechnung, Winkelfunktionen - Herr Sinus, Frau Cosinus und Tangens lassen grüßen - und einiges mehr, einlesen. Man kommt natürlich in das Thema wieder rein, man lernt aber auch Madame Google - oder die Suchmaschine seiner Wahl -, zu schätzen. Ob man sich mit dem Thema aber nach so langer Zeit wieder richtig anfreunden wird oder es nicht doch eher auf eine reine Zweckgemeinschaft hinauslaufen wird, das ist dann nochmal eine andere Frage (bei mir eher letzteres) :)

3.) Prototyping

Ich verlasse gerne sehr früh den theoretischen Pfad und werfe bei solchen Softwareprojekten schnell den Compiler an. Das hat Vor-, aber auch Nachteile: 

• ein großer Nachteil ist, dass man hinterher wieder einiges am Code komplett umstellen muss (das läßt sich bei Prototypen aber sowieso nie gänzlich vermeiden)
• den Vorteil, dass man sofort die Auswirkungen am Monitor nachvollziehen kann (gerade bei grafisch basierten Projekten). Natürlich hat man zwischenzeitlich etliche Papierskizzen angefertigt, die als Muster dienen, weil es auf dem Papier schneller geht. Auch wird man die nötigen Formeln erst einmal auf dem *Papier festhalten wollen. Aber irgendwann kommt der Moment, wo sich die Theorie, mit der wir uns primär auf dem Papier beschäftigen und die Praxis, das ein oder andere Mal gegenseitig im Weg stehen werden :) Im konkreten Fall war diese Phase mit dem Auftreten der Hidden Lines Removal Problematik erreicht.
  Da kann man noch soviel Literatur lesen und theoretische Ansätze aufgreifen, aber wenn dieses Thema bzw. dieses Problem für Euch Neuland sind, dann wird der Compiler, der eigentlich nichts anderes macht, als unsere Vorgaben dem Computer, in einem ihm verständlichen Dialekt aufzutischen, irgendwann zum neuen Feind erklärt (glaubt es mir :))
  
  * Was den Papierverbrauch betrifft: es gibt diese neuartigen Skizzenblöcke, die aus einem speziellen kunststoffartigen Papier bestehen, das mit einem feuchten Tuch wieder leergewischt werden kann. Ich verwende beim Prototyping - und vielen anderen Aufgaben - fast nur noch diese wiederverwendbaren Notizblöcke. Ein tolles Produkt, das den Prototypenstatus bereits hinter sich gelassen hat. Wahrscheinlich ist dieses Produkt dann auch direkt während eines Prototypenstadiums entstanden :) Bei Amazon gibt es z.B. eine sehr große Auswahl dieser genialen Skizzen- und Notizenblöcke: wiederverwendbarer Notizblock

Prototyp 1

Nachdem ich mich mit der für dieses Projekt notwendigen Mathematik wieder einigermassen angefreundet hatte, was dann doch relativ schnell vonstatten ging, war der erste Protoytp auch fix mit Hilfe einiger weniger Windows GDI + Funktionen hingedengelt (hingedengelt trifft es ganz gut). Nicht ganz ein sich drehender 3D Würfel im Raum, wie er öfters als Übungsobjekt fungiert, aber letztlich, was die Rotationen im Raum betrifft, dem doch sehr ähnlich. 

Da sich bei diesem Projekt eine Drahtgitterabbildung eigentlich nicht wirklich anbietet, bin ich sozusagen bereits im ersten Schritt an der Hidden Lines Removal Problematik angedockt.
An dieser Stelle verweise ich der einfachheitshalber auf dieses YouTube Video Hidden Lines and Surfaces und diesen Artikel 7. Hidden Line Removal.

Wenn man sich diesem Thema annimmt, dann wird man mit Literatur quasi totgeschlagen. Für einfache Hobbyprojekte wird es m.E. nicht nötig sein, dermassen tief in die Materie einzusteigen, aber etwas Einarbeitung ist dann doch unvermeidbar.

Prototyp 2

Dieses Hidden Lines Problem ist in der Grafikprogrammierung natürlich allgegenwärtig und Softwareentwicker, die primär im grafischen Umfeld arbeiten, werden damit wohl keine allzu großen Probleme haben (oder vielleicht doch?). Für mich als Anwendungsentwickler, der eher im Datenbankumfeld zuhause ist, war/ist das aber absolutes Neuland. Ich musste mich wirklich sehr intensiv in diese Materie einlesen, bei meinen einfachen Muster-GPS-Tracks, die aus wenigen Dummy-GPS Koordinaten bestanden, hatte ich die Clippingfehler irgendwann auch halbwegs im Griff. Mir hat dabei vor allem dieses Script sehr gute Dienste geleistet, auf das ich hier verweisen will: http://www.cs.cmu.edu/afs/cs/project/lri/members/lalit/Phd/software/simkit/graphics/class/y96/211/assign6/hw6.pdf

Prototyp 3 (kann auch Nummer 4 gewesen sein :) )

Leider traten bei echten GPS-Daten erneut diverse Clippingfehler auf. Ich nenne das Clippingfehler, wobei richtige Clippingfeher streng genommen etwas anderes sind. 
Ich will mich an dieser Stelle auch gar nicht weiter auslassen, nur soviel sagen, dass ich den akademischen* Pfad wieder etwas verlassen habe und mir die Eigenarten, der mit einem GPS Gerät protokollierten GPS-Daten, zunutze mache. Das hat den Vorteil, dass ich relativ einfach die Hidden Lines Problematik umschiffen kann, bei Ausgangsdaten, die nur auf wenigen GPS-Koordinaten basieren, allerdings bewußt Clippingfehler in Kauf nehmen muß. Damit kann ich aber leben. Im nächsten Schritt würde sich sowieso die Verwendung der OpenGL Schnittstelle anbieten, womit vieles einfacher wäre. Allerdings ist die OpenGL Programmierung auch wieder mit (viel) Programmierarbeit verbunden und derzeit für dieses kleine Projekt m.E. etwas überdimensioniert.

*Zum Sichtbarkeitsproblem (hidden lines removal) will ich an dieser Stelle noch soviel anmerken: Protokollierte GPS-Aufzeichnungen weisen mitunter die Eigenart auf, dass sich bestimmte Teilabschnitte  überschneiden - z.B. Hin- und Rückfahrt der gleichen (Teil)Strecke mit sich überlagernden Segmenten.

Ich habe wirklich einige Stunden mit der von mir angestrebten finalen Lösung dieses Sichtbarkeitsproblem verbracht, bis ich erkennen musste, dass sich bei protokollierten GPS-Daten dieses Problem mit vertretbaren Aufwand m.M. nicht beheben lassen wird. Mit einigen Tricks kann man die daraus resultierenden Clippingfehler auf ein Minimum reduzieren - oder besser gesagt kaschieren/maskieren -, aber eben nicht gänzlich vermeiden. Wer in eine ähnliche Situation kommt, weil er ein vergleichbares Projekt in Angriff nimmt, sollte sich dessen eventuell bewußt sein: viele klassische Ansätze diesem Informatik Problem beizukommen, werden m.E. ohne vorherige Säuberung der GPS-Koordinaten nämlich nicht funktionieren. Und das scheint mir für diese 3D-Ansicht dann doch etwas zu viel des Guten sein. Machen kann man in der Informatik heutzutage natürlich fast alles - sofern man die Zeit aufbringen kann -, da die CPUs/GPUs bei solchen Dingen nicht mehr der limitierende Faktor sind. 

Ich habe mich dann für den goldenen Mittelweg entschieden und beschränke mich in diesem Fall auf das Kaschieren der Auswirkungen dieser Überlagerungen.

4.) Projekteinbettung

Irgendwann steht der Prototyp auf soliden Beinen und je nachdem, inwieweit man bereits beim Prototyping einen objektorientierten Ansatz verfolgt hat, ist die Verpflanzung in das lebende Objekt (Projekt) etwas aufwendiger oder weniger aufwendig. 

Ich musste hier nochmal etwas Nachsitzen, aber da ich nur ein paar wenige Windows GDI Funktionen verwende, war die Transformation in eine eigene Klasse doch relativ schnell erledigt. Der Prototyp ist jetzt quasi mit dem Hauptprojekt verheiratet und ich hoffe, dass ich in nicht allzuferner Zukunft, ein Update der TrainingLab Pro anstoßen kann. 

Noch ist aber etwas Feintuning nötig. In einem weiteren Schritt möchte ich dann noch meine Android App Namens WRPElevationChart mit diesem Prototypen verheiraten. Da ich den Code bewußt flach gehalten habe und eigentlich nur zwei oder drei GDI Funktionen für die Grafik nutze, sollte es kein allzugroßes Probem sein, den Code auf Java Android zu konvertieren.

Hier ein paar weitere Screenshots (dem fast fertigen Hauptprojekt entnommen):

Ötztaler Radmarathon

Mein Hausberg (Feldberg im Taunus)

Alpe d'Huez

Die Android App WRPElevevationChart steht auch kurz vor der Fertigstellung. Stand heute (22.01.2022) läuft im Google Play Store gerade ein öffentlicher Betatest.

 

Über Sinn und Zweck dieser Übung kann man freilich diskutieren, aber mir hat's Spass gemacht und nachdem das geniale GPS-Track-Analyse.Net von Blackwilli, von dem ich mich zweifelsohne inspirieren lassen habe, leider nicht mehr weiterentwickelt wird und es in diesem Bereich auch nicht soviele - mir bekannte - Tools gibt, hat es mich jetzt einfach zu sehr in den Fingern gejuckt, dieses Projekt selbst anzupacken.

In echt wird das dann in etwa so aussehen: TrainingLab Pro (new GPS data based 3D elevation view)

5.) Fazit

Wie man sehen kann, ist es von der ersten Idee, hin zu den ersten Prototypen mitunter ein etwas steiniger Weg. Im professionellen Umfeld wird der Weg eher noch steiniger sein, da vieles bereits im Anfangsstadium spezifiziert werden muss. Wohl dem, der in einer Firma arbeitet, die für solche Prototypen Projekte eine eigene Abteilung unterhält, wo dann auch etwas weniger zielstrebig experimentiert werden kann und darf.

In meinem Fall sprechen wir aber von einem privaten Hobbyprojekt, was zur Folge hat, dass ich eben nicht alles bis ins Detail spezifizieren musste und in erster Linie die vorhandene bzw. eben nicht vorhandene (Frei)Zeit der limitierende Faktor ist. Von der Grundidee, die allerdings schon lange in meinem Kopf umherschwirrte, bis zum (fast) fertigen Projekt sind jetzt ca. drei Wochen verstrichen. Wobei ich noch anmerken will, dass ich nur stunden- und phasenweise an diesem kleinen Projekt gearbeitet habe. Eben wie es gerade zeitlich passte. 

Der aufwendigeste Part war sicherlich die Auffrischung der eher spezifischen Mahematikkenntnisse. 

Wer frisch von der Schulbank kommt, der wird vermutlich den ersten etwas abgewandelten 3D Würfel schnell in die Entwicklungsumgebung seiner Wahl eingetippt haben, dann aber vielleicht auf andere Hürden, wie fehlende Motivation, etc. stoßen. So ist das Leben, gleicht sich dann doch vieles - zumindest ein klein wenig - aus :)

6.) Zum Abschluß noch ein paar Links

Falls es interessiert, ich hatte ein paar Entwicklungschritte auf Twitter geteilt, sodass eine Art Verlaufsprotokoll zustande gekommen ist. Hilft mir jetzt im Nachhinein, das zeitlich besser zuordnen zu können.

• Erster Tweet: Mathematik
• Zweiter Tweet: Wochende = Wiederaufnahme des Projekts
• Dritter Tweet: Der Feldberg im Pocketformat
• Vierter Tweet: Der Ötztaler und das Hidden Lines Problem
• Fünfter Tweet: Langsam wird es
• Dieses mal kein Tweet: Erste formelle Ankündigung auf unserer Projektseite

Danke fürs Lesen und wie immer etwas gute Musik am Ende meines Blogartikels :)