Christoph Eckert schrieb: > das Datenmodell gibt das her. In den Editoren wird es zwar etwas kniffelig > weil die allesamt 2D sind, aber falls nötig würde sich das sicher ändern > lassen.
Die Frage über den Nutzen von Höhenangaben geht mir schon länger durch den Kopf. Ich finde unser bisheriges System ist für Höhenangaben nicht geeignet, und auf die Art und Weise wie es mit nodes versucht wird erst recht nicht. Die Grundsätzliche Konzept, Rohdaten und Nutzdaten zu trennen wird vermischt. Bei 2D-Daten nehmen wir ja die Rohdaten als Schablone und richten unseren Weg danach aus. Höhenangaben dagegen sind Messwerte, und somit Rohdaten. Sie sollten nicht in den Nutzdaten als nodes vorkommen. Dies führt zu folgendem Problem: Wenn ein Weg in 2D korrigiert wird, so verschiebt man automatisch auch die Höhenangaben. Man erzeugt somit falsche Werte. Wenn wir Höhenangaben möchten, dann kann es nur über einen 3D-Editor laufen. Und zwar weiterhin unter Trennung der Nutz- und Rohdaten. Die könnte so funktionieren: Man bekommt mehrere GPX-Tracks einfach als 3-dimesionale Polylinien in einem Raumgitter angezeigt . Den eigentlichen Weg, richtet man dann wieder nach diesen Linien aus. Wer die 3D- Funktion nicht möchte kann ja dann alles senkrecht aus der Luft betrachten, und hat somit die gleiche Darstellung wie in einem 2D-Editor. Ein anderes Problem ist die Genauigkeit der Messerte allgemein. Wissenschaftlich sind Messerte ohne Fehlerangabe vollkommen nutzlos, denn es wird immer Geräte geben die große Ausreißer produzieren. Woher sollen wir wissen dass diese Werte nicht so genau gewertet werden sollen wie die eines besseren Gerätes? Dies ist ein allgemeines Problem des NMEA Protokolls. Für 2D Daten ist es jetzt nicht so dramatisch, aber bei nicht-barometrischen Höhenangaben mit Schwankungen von +-50m kann mans eigentlich vergessen. Beste Grüße, Simon _______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
