Zweidimensional. Die Z-Koordinate wird meines Wissens gar nicht oder zumindest anders behandelt. Würde mich nicht wundern, wenn bereits der GPS-Empfangschip eine Vorverarbeitung der Daten durchführt. Für die Z-Koordinate will das Gerät dann aber noch die Infos vom zumindest möglichen barometrischen Höhenmesser mit integrieren. Schon allein deshalb ist es auch sinnvoll, die Höhe getrennt zu behandeln. Ich vermute aber, dass die üblichen GPS-Geräte hier durchaus nicht sonderlich elegant arbeiten und Potential verschenkt wird.

Rauschen in Bewegungsrichtung ist nicht weiter schlimm, das mittelt sich bei der Aufsummation raus. Wichtig ist nur, dass das Rauschen nicht die kommenden Punkte "überholt" oder hinter die vorherigen "zurückfällt". Das ist aber in der Regel (solange man in Bewegung ist) nicht der Fall. Anders beim Höhensignal, hier führt das Rauschen dazu, dass man beim Blick auf die aufgenommenen Daten den Eindruck gewinnen kann, dass es von Messpunkt zu Messpunkt mal rauf, mal runter geht (Rauschen ist groß im Vergleich zur realen Höhenänderung). Das bewirkt die Probleme und ist der qualitative Unterschied zwischen der Stärke des Rauschens auf dem Höhensignal und dem auf dem Positionssignal.


Dieser Rechenalgorithmus arbeitet beständig. Effektiv findet dabei eine Mittelung mehrerer zurückliegender Messwerte statt. Ich vermute, dass ein Ausgleichsrechnungsalgorithmus zum Einsatz kommt, der die zurückliegenden Messwerte am besten mit einer bestimmten Bewegungskurve (wahrscheinlich ein konstanter Ansatz für die Geschwindigkeit, sprich linearer Ansatz für den Ort) in Einklang bringt. Dass auf jeden Fall so etwas stattfindet, siehst du anhand der Punktewolken, die sich im Stillstand ergeben. Hier kann der Algorithmus keine Geschwindigkeit zuordnen und zeigt daher gut das Rauschen des Signals in jede Himmelsrichtung an. Kann der Algorithmus einmal von einer bestimmten Geschwindigkeit ausgehen, können die Fehler senkrecht zu dieser Bewegungsrichtung herausgerechnet werden.


Meine Ausführungen bezogen sich auf die Höhenmeterberechnung. Da spielt weder das gefahrene Tempo, noch das Vorhandensein von Kurven eine Rolle. Es geht ausschließlich um die Auswertung der Funktion "Höhe in Abhängigkeit vom Aufzeichnungspunkt". Will man ein Höhenprofil plotten (oder mit Steigungswerten hantieren), dann kommt dem Abstand der Aufzeichnungspunkte noch eine Bedeutung zu.


Häh?


Das ist ja gerade mein Punkt, der Fehler hat nur sehr indirekt etwas mit der gefahrenen Strecke zu tun. Das betrifft übrigens beide Werte: Die Längenmessung und die Höhenmetermessung. Ich mache es mal an der Höhenmetermessung fest.
Das eine Extremum: Du fährst in absoluter Ebene stupide geradeaus. Real: 0hm. Durch naives Aufsummieren des Rauschens (nehmen wir mal beispielhaft mit +/-1m an) machst du einen Fehler, der direkt mit der Anzahl der Trackpunkte korrespondiert. Halb so viel Trackpunkte, halb so viel errechnete Höhenmeter, 10% Trackdaten, 10% der Höhenmeter.
Anderes Extremum: Du fährst einen steilen Pass rauf. Ich spinne jetzt mal, zwischen zwei Messzeitpunkten machst du stets etwa 3hm gut, das Höhensignal rauscht aber nur +/-1m. Selbst wenn du hier ganz naiv einfach die Höhendifferenzen aufsummierst, wirst du am Ende ein (fast) exaktes Ergebnis bekommen, unabhängig davon, wie weit du den Track ausdünnst.

Ähnlich verhält es sich bei der GPS-Streckenmessung. Geht es hauptsächlich kurvenlos geradeaus, machst du einen sehr kleinen Streckenlängenberechnungsfehler. Der ist offensichtlich auch nicht von der Aufzeichnungsdichte abhängig.
Ist der Streckenverlauf sehr kurvig und obendrein in den Kurven die Aufzeichnungsdichte noch gering (weil z.B. nur alle 10s ein Trackpunkt erfasst wird), ist ein größerer Fehler zu erwarten.

Ergo: Der Berechnungsfehler hängt sehr wesentlich vom Streckenverlauf ab und man kann nicht pauschal sagen, wie Berechnungsfehler und Trackaufzeichnungsdichte korrespondieren. Je nach Radfahrgegend mag es da gewisse "Erfahrungswerte" geben, das sind aber keine universell gültigen Prinzipien und Vergleiche zwischen verschiedenen Topografien/Streckenverläufen faktisch nicht möglich.