Spuren mit z-Wert

Das Datenmodell kennt momentan noch keine Höhen. Wird sicher irgendwann mal kommen, aber das kann noch dauern. Bis dahin wird nur die Lage gemappt, bei Gebäuden vielleicht noch die Höhe.
Auf den Höhenwerten der GPX-Tracks wirste nicht viel machen können, was da gespeichert wird hängt immer vom Empfänger ab und den kennt man ja nicht.

Das Datenmodell muß also geändert werden. Wen soll man anschreiben?

Rein teoretisch: Wie könnte man praktisch die empfängerspezifische Genauigkeit der Höheninformation ablegen?

Über mehrere Messungen könnte man ziemlich genaue 3D Geländemodelle entlang der Wegeachsen bauen...

tiototo wrote:

Das Datenmodell kennt momentan noch keine Höhen. Wird sicher irgendwann mal kommen, aber das kann noch dauern. Bis dahin wird nur die Lage gemappt, bei Gebäuden vielleicht noch die Höhe.
Auf den Höhenwerten der GPX-Tracks wirste nicht viel machen können, was da gespeichert wird hängt immer vom Empfänger ab und den kennt man ja nicht.

Das ist in dieser Allgemeinheit nicht ganz richtig.

Ein Punkt als Träger der Geokoordinaten enthält standardmäßig keine Höheninformation.
Allerdings kann man mit ele=<Meter> eine Höheninformation ergänzen.

Es macht auch wenig Sinn für eine zweidimensionale Karte an jedem Punkt (meist falsche/ungenaue) Höheninformationen anzubringen. Das wird besser über einen zusätzlichen Layer mit flächendeckenden Höheninformationen erledigt.

Nun haben allerdings dei SRMT-Daten als einzig frei verfügbare Quelle ohne NC-Einschränkung einige systematische Probleme.
Es wurde nicht die Erdoberfläche vermessen, sondern die oberste Lage von Objekten wie Häusern und Wäldern. Von daher ist das nur begrenzt nützlich. Auch kann man nicht wirklich erkennen, ob im Einzelfall die Höhe auf dem Hochhaus gemessen wurde, auf einer kleine Baumgruppe neben dem Hochhaus oder auf der Rasenfläche drumherum.

Es gibt natürlich recht zuverlässige digitale Höhenmodelle bei den Vermessungsämtern.
Die sind aber weder kostenfrei, noch dürfen die in der Regel weiterverbreitet werden.

Also alles sehr schwierig dieses Thema.

Edbert (EvanE)

Danke Edbert. Die Problematik der 3D Geländemodelle ist mir seit Jahren bekannt.
Ich bin mir ziemlich sicher, dass die Cloudwork- Messung; aus vielen Spuren gewonnene Höhenprofile, die Lösung für 3D Geländemodelle für OSM sind.

Grüße,
Marek

marek kleciak wrote:

Rein teoretisch: Wie könnte man praktisch die empfängerspezifische Genauigkeit der Höheninformation ablegen?

Ich hätte schon Angst, dass die Leute nichtmal genau wissen, welche Höhe ihr Navi da ausspuckt. Die über dem Ellipsoid oder die über dem Geoid (und wenn, wie genau interpoliert). Ich hab hier drei GPS-Empfänger nebeineinandergelegt. Zwei zeigen eine geoidkorrigierte Höhe, der dritte macht sich nicht die Mühe. Was dann diese Dinger ins GPX-Log schreiben, ist dann vielleicht wieder was anderes...

Grüße, Max

Hallo Max,
richtig, absolut richtig!

Deswegen müsste man für die verschiedene Arten der GPS Empfänger (es sind zum Glück nicht unenedlich viele auf dem Markt) ine etwa Kalibrierungstabellen haben, um die Höhen richtig interpretieren zu können. Die Arbeit ist zwar mühsam, aber der Gewinn für OSM wäre so ziemlich groß, oder?

marek kleciak wrote:

Hallo Max,
richtig, absolut richtig!

Deswegen müsste man für die verschiedene Arten der GPS Empfänger (es sind zum Glück nicht unenedlich viele auf dem Markt) ine etwa Kalibrierungstabellen haben, um die Höhen richtig interpretieren zu können. Die Arbeit ist zwar mühsam, aber der Gewinn für OSM wäre so ziemlich groß, oder?

Hi Marek,

ich bin da -wie fast immer- ein wenig pessimistisch:

- SEHR VIELE benutzen GPS-Daten um eigene Sachen in OSM zu erfassen.

- VIELE laden auch irgendwann die Tracks zum OSM-Server hoch

- EINIGE lassen die Rohdaten fast im Originalzustand (ich schalte nur die Timestamps ab)

- WENIGE interessieren sich für die Höhen-Koordinaten

- GANZ WENIGE kennen die genauen Details und geben beim Hochladen entsprechende Infos ab.

und genau die "ganz wenigen" Daten kannst du eigentlich nur gebrauchen - glaub ich zumindest.

Gruss
Walter

p.s. an sich ist die Idee, die eh vorhandenen ELE-Daten zu verwenden, schon bestechend.

Hallo Walter,
auf der einen Seite hast Du absolut Recht, auf der anderen muss ich gestehen, genauso habe ich ganz OSM zu Anfang auch gesehen.
Ich glaubte nicht, dass die breite CommunitySpaß daran haben kann, Geodaten zu sammeln.
Voraussetzung für den Erfolg dieser Idee wäre aber das Vorhandensein einer Infrastruktur in der analogisch wie jetzt mit 2D Karte die Veränderungen der Erdoberfläche sichtbar wären.
Und da ist der Weg lang. Irgend jemand müßte das machen. Ich kann eine solche Software spezifizieren aber jemand müßte sie schreiben. Welcher Weg dafür wäre sinvoll?

- Aufruf in der Community
- Kaffekränzchen mit Prof. Zipf
- OSM Foundation
- Fossgis?

Das Thema kommt seit Jahren immer mal wieder auf. Einige Beispiele, die ich gefunden habe, sind die Wiki-Seite zu Altitude, Thread 1 und
Thread 2.

Ich habe den Verdacht, dass die Komplexität für ein effektives Crowdsourcing zu groß ist. Die reine GPS-Messung der Höhe ist meines Wissens zu ungenau, wirklich brauchbare Daten, die einen deutlichen Qualitätssprung gegenüber SRTM bedeuten, dürften nur mit barometrischen Höhenmessern erreicht werden. Die sind zwar in viele GPS-Geräte eingebaut (z.B. Garmin Vista Hcx), aber die Bedienung ist doch recht mühsam: Vor jeder Messung musst du das Ding kalibrieren, entweder anhand einer bekannten Höhe oder des aktuellen Luftdrucks. Wenn du eine Weile unterwegs bist, ändert sich wahrscheinlich der Luftdruck, d.h. du musst den Druckverlauf mit einem stationären Gerät aufzeichnen und die Änderungen in deine Aufzeichnungen einrechnen. Das erfordert einen Aufwand und eine Sorgfalt, die die meisten Mapper abschrecken dürfte. Sogar wenn du dir die normalen GPS-Traces (also nur die lat/lon-Koordinaten) ansiehst, die zu OSM hochgeladen wurden, findest du jede Menge Müll: Aufzeichnungen von Segelfliegern, eingeschaltetes Snap-To-Road, riesige Messabstände usw. Aus einem solchen Bestand brauchbare Höhendaten zu extrahieren, halte ich für unmöglich.

Die Probleme mit den Bezugssystemen wurden ja schon in anderen Posts erwähnt.

Als weiteres Problem fällt mir ein, wo man misst: In Ostfriesland bekommst du wahrscheinlich gute Höhendaten, wenn du mit Auto oder Fahrrad rumfährst, aber sobald es hügelig wird, bewegen sich die meisten nicht ständig an der Erdoberfläche entlang, sondern über Brücken. Die Differenz muss nicht immer so spektakulär sein wie bei der Siduhe-Brücke (472 m), aber solche Diskrepanzen müssten irgendwie berücksichtigt werden.

Das Konzept, per Crowdsourcing Höhendaten zu sammeln, die beim Mappen quasi als Abfallprodukt anfallen, klingt faszinierend. Ich bin aber skeptisch, ob es angesichts der beschriebenen Probleme brauchbare Ergebnisse bringt. Falls du es trotzdem angehen willst, würde ich ein Schwesterprojekt zu OSM vorschlagen. Dieses Projekt könnte sich zum Ziel setzen, ein genaues Höhenmodell zu erstellen, das dann beispielsweise in Karten eingebunden werden kann. Als Ausgangspunkt könnte der SRTM-Datensatz dienen, der immer weiter korrigiert/verfeinert wird, wenn neue Messdaten zugeliefert werden.
Ich würde dir jedenfalls mit Vergnügen solche Daten von meinen Fahrradfahrten und Wanderungen liefern.

MetiorErgoSum wrote:

Falls du es trotzdem angehen willst, würde ich ein Schwesterprojekt zu OSM vorschlagen. Dieses Projekt könnte sich zum Ziel setzen, ein genaues Höhenmodell zu erstellen, das dann beispielsweise in Karten eingebunden werden kann. Als Ausgangspunkt könnte der SRTM-Datensatz dienen, der immer weiter korrigiert/verfeinert wird, wenn neue Messdaten zugeliefert werden.

Genau dieses Schwesterprojekt gibt es schon.

OpenDEM

Mir recht ähnlichen Ansätzen.

OpenDEM Info

Hallo MetiorErgoSum, hallo robgeb,
danke für Eure Hinweise!
Es ist gut dass OpenDEM existiert (war mir bekannt) und es ist klar, dass GPS Spuren zur 3D Modellierung nur in Verbindung mit ausgewerteter Information ("dieser Abschnitt ist eine Brücke", "dies ist ein Tunnel") funktionieren können.

Ich bin aufgrund bisheriger Arbeit mit 3D Modellen der Meinung, dass ein freies Geländemodell direkt mit der OSM Karte verknüpft werden muss und daher OpenDEM Schwierigkeiten haben wird: Ein Geländemodell und die von Menschen geschaffene Strukturen müssen gemeinsam betrachtet und modelliert werden.

Macht man 2D und 3D getrennt, führt dies üblicherweise zu großen Anpassungsproblemen.
Die richtige Lösung meiner Meinung nach wäre ein weiterer online Editor für OSM: zur Wahl P1, P2, JOSM oder Merkaator und ein 3D Modeller in dem die Tracks dreidimensional sichtbar sind, wo man 3D Gebäude sieht und wo man künstliche Bruchkanten im Gelände anhand von 2D Daten modellieren kann.

Der Punkt ist: Diese Software muss erst mal entstehen.

maxbe wrote:

marek kleciak wrote:

Rein teoretisch: Wie könnte man praktisch die empfängerspezifische Genauigkeit der Höheninformation ablegen?

Ich hätte schon Angst, dass die Leute nichtmal genau wissen, welche Höhe ihr Navi da ausspuckt. Die über dem Ellipsoid oder die über dem Geoid (und wenn, wie genau interpoliert). Ich hab hier drei GPS-Empfänger nebeineinandergelegt. Zwei zeigen eine geoidkorrigierte Höhe, der dritte macht sich nicht die Mühe. Was dann diese Dinger ins GPX-Log schreiben, ist dann vielleicht wieder was anderes...

Das Geoid-Modell in den Navis scheint wohl eher grob, i.e. ungenau zu sein...

Dazu kommt noch, daß manche Geräte wahlweise Höhen über GPS oder den Luftdruck bestimmen. Letzteres verlangt zudem eine Eichung, da sich der Luftdruck an gegebenem Punkt leider immer wieder ändert...

Ich glaube nicht, daß hier wirklich verläßliche Daten zusammenkommen können.

Marek, ich finde die Idee gut und würde mich freuen, wenn Du das weiter verfolgen würdest. Die Technik entwickelt sich weiter und wer hätte vor zwei Jahren gedacht, dass mal flächendeckend Häuser eingezeichnet werden oder Bäume aber erwähne ich besser nicht ;-) ste

schlauchboot wrote:

Letzteres verlangt zudem eine Eichung, da sich der Luftdruck an gegebenem Punkt leider immer wieder ändert...

Bitte, Kalibrierung. Zum Glück muß das Gerät nicht bei jedem Wetterumschwung einer Eichbehörde vorgeführt werden.

Baßtölpel

marek kleciak wrote:

Das Datenmodell muß also geändert werden. Wen soll man anschreiben?

Da gibts ein Brainstorming: http://wiki.openstreetmap.org/wiki/API_v0.7
Was auch immer dabei rauskommt. Allerdings bin ich da skeptisch, wie schnell wir auf dem Stand sind Höhen sauber zu erfassen. Das ele-Tag ist nur eine Krücke, die nicht wirklich dazu beiträgt 3D-Modelle zu bauen. Den Rest der Diskussion kommentiere ich nicht weiter, das ist mir zuviel Erbsenzählerei.

marek kleciak wrote:

Macht man 2D und 3D getrennt, führt dies üblicherweise zu großen Anpassungsproblemen.
Die richtige Lösung meiner Meinung nach wäre ein weiterer online Editor für OSM: zur Wahl P1, P2, JOSM oder Merkaator und ein 3D Modeller in dem die Tracks dreidimensional sichtbar sind, wo man 3D Gebäude sieht und wo man künstliche Bruchkanten im Gelände anhand von 2D Daten modellieren kann.

Der Punkt ist: Diese Software muss erst mal entstehen.

Genau so sieht es aus. Schreibe ein entsprechendes Plugin fuer JOSM (oder suche dir jemanden, der das schreiben kann) und die z-Wert-Eintraege werden schon kommen.

Die immer wieder vorgebrachten Einwaende, warum das nicht funktionieren koennen, uebersehen, dass ein (menschlicher) Mapper beim Vorliegen von genuegend Tracks den gesuchten z-Wert problemlos erkennen kann (genau wie in der x-y-Ebene). Das ist einfach nur eine Frage, wie gut die graphische Praesentation aussieht. Man braeuchte quasi eine Seitenansicht auf die Karte und die Tracks, dann sieht man auch, was passt und was nicht.

Gruss
Torsten

EvanE wrote:

Nun haben allerdings dei SRMT-Daten als einzig frei verfügbare Quelle ohne NC-Einschränkung einige systematische Probleme.
Es wurde nicht die Erdoberfläche vermessen, sondern die oberste Lage von Objekten wie Häusern und Wäldern. Von daher ist das nur begrenzt nützlich. Auch kann man nicht wirklich erkennen, ob im Einzelfall die Höhe auf dem Hochhaus gemessen wurde, auf einer kleine Baumgruppe neben dem Hochhaus oder auf der Rasenfläche drumherum.

Es gibt natürlich recht zuverlässige digitale Höhenmodelle bei den Vermessungsämtern.
Die sind aber weder kostenfrei, noch dürfen die in der Regel weiterverbreitet werden.

Das galt für die Orthofotos genauso. Jetzt haben wir in AT die amtlichen Orthofotos mit 20cm Auflösung zum Abzeichnen. Wer hätte das vor 1 Jahr gedacht? Mit den Laserscans wird das genauso sein. Es ist nur eine Frage der Zeit, bis welche für OSM verfügbar sind. Darum sind alle Versuche, mit GPS-Tracks Höhenmodelle zu erfassen, vergebliche Müh, ganz abgesehen davon, dass es technisch sowieso nicht möglich ist.

MetiorErgoSum wrote:

Das Konzept, per Crowdsourcing Höhendaten zu sammeln, die beim Mappen quasi als Abfallprodukt anfallen, klingt faszinierend. Ich bin aber skeptisch, ob es angesichts der beschriebenen Probleme brauchbare Ergebnisse bringt. Falls du es trotzdem angehen willst, würde ich ein Schwesterprojekt zu OSM vorschlagen. Dieses Projekt könnte sich zum Ziel setzen, ein genaues Höhenmodell zu erstellen, das dann beispielsweise in Karten eingebunden werden kann. Als Ausgangspunkt könnte der SRTM-Datensatz dienen, der immer weiter korrigiert/verfeinert wird, wenn neue Messdaten zugeliefert werden.
Ich würde dir jedenfalls mit Vergnügen solche Daten von meinen Fahrradfahrten und Wanderungen liefern.

Ich denke das wäre der Weg den man gehen müsste. Mit den SRTM-Daten hätte man schon ein brauchbare Datenbasis, welches man mit den GPS-Tracks, vor allem entlang von Straßen, verfeinern könnte. Damit könnte man sich vorerst mal auf ein reines Rechen-Projekt beschränken, welches die SRTM-Daten in einer hoffentlich schlau gewichteten Weise die GPS-Tracks nutzen kann um die Daten zu verfeinern. Wenn auf einem Weg viele Tracks vorhanden sind, dann sollten die damit erzielbaren Ergebnisse für den Bereich schon recht brauchbar sein. Ich weiß aber nicht so genau wie genau/ungenau die Höhendaten bei verschiedenen GPS-Modellen sind und ob man die verschiedenen Qualitäten am Track eventuell unterscheiden könnte. Aus meiner Erfahrung mit dem Dakota 20 denke ich dass die damit aufgezeichneten Höhendaten recht genau passen, zumindest dann wenn das Gerät mit guten Empfangsbedingungen für längere Zeit läuft und das ganz ohne dauernde Barometer-Rekalibrierung. Das Dakota adaptiert sich da wohl selber mit den GPS-Daten vom Sateliten, das dauert aber eben von Gerätestart weg so seine Zeit.

Markus

Was schwebt Euch eigentlich als Ziel vor? Eine Höhenkurve entlang eines Weges für das Höhenprofil einer Wanderung oder Radtour? Oder eine Vermessung/Interpolation der Fläche im 50-Meter-Raster?

Hallo maxbe,
ich weiß nicht was die anderen wollen, aber ich möchte weder das eine noch das andere:
Wir müssen uns von dem (aus der Sicht der Programmierer) Gedanken von einem Rastermodell verabschieden.
Es würde nälich bedeuten, dass der Mapper nur für eine bestimmte Koordinate eine Höhenwert entragen kann / darf.
Wir brauchen ein trianguliertes Modell der Erdoberfläche, denn besonders dort, wo alle Fehler sofort sichtbar sind (Beispiel: zwei parallele Wege, eine Spur aufsteigend, zweite fallend, dazwischen kein Freiraum, sondern nur senkrechte Wand) kann man mit einem Rastermodell nicht vernunftig modellieren. Die Straße soll in 3D in ihrem Verlauf modelliert werden inclusive Breite.

Ich habe 2007 eine Diplomarbeit betreeut die eine 3D Nachmodellierung von dem exisiterenden Gelände durch den Einsatz der bekannten 3D Geometrie der Straßenverläufe als Ziel hatte.
Wir haben gelernt, dass das Wegenetz so dicht ist, dass man ein gutes Modell bekommt, wenn man fast ausschließlich die Straßengeometrie zur Modellierung verwendet und die großeren Bereiche zwischen den Straßen interpoliert. Oder einfach ein viel simpleres, freies Modell darunter liegt und daraus die Höhenpunkte für große bereiche Ohne Straßen und Wege nimmt.
Das gute (wie de_muur schreibt) ist, dass in dem 3D Modell einem so ziemlich schnell Fehler auffallen und grob korrigiert werden können.
Es stimmt ja auch dass die Erfassungstechnologie sich weiterentwickelt und die Genauigkeit der Z-Wert Messung mit der Zeit steigen wird.
Es wäre gut darauf vorbereitet zu sein indem man gemeinsam eine Art "Potlatch3" schreibt mit dem 3D Modellierung möglich ist.

marek kleciak wrote:

Ich habe 2007 eine Diplomarbeit betreeut die eine 3D Nachmodellierung von dem exisiterenden Gelände durch den Einsatz der bekannten 3D Geometrie der Straßenverläufe als Ziel hatte.

Das interessiert mich natürlich. Die Arbeit ist nicht zufällig im Netz oder zumindest über Unibibliotheken verfügbar?

Meine aktuelle Meinung zu dem Thema lautet ansonsten: Eine vollständige Abdeckung mit Höhenkoordinaten ist ein Idealziel, aber ich sehe es nicht als mittelfristig umsetzbar an. Selbst in Gegenden, die als "gut gemappt" gelten, findet man noch fast nie z.B. Gebäude, die mehr Attribute als ein building-Tag haben, Steigungen oder Straßenflächen. An den Editoren oder Erfassungswerkzeugen liegt das nicht - die wären für diese einfacheren Aufgaben durchaus schon ausreichend. Der Engpass ist die verfügbare Arbeitskraft.

Daher halte ich es für sinnvoll, eine Lösung bei der Auswertung zu finden, die auch mit wenig Daten schon gute Ergebnisse liefert. Inwieweit es möglich ist, mit unvollständiger Information zurecht zu kommen, wird ja zwangsläufig auch eine wichtige Fragestellung im Rahmen meiner bevorstehenden Masterarbeit sein. Ich hoffe, dass dadurch auch etwas deutlicher wird, welche Erfassungsintensität eigentlich für brauchbare Ergebnisse nötig ist. Denn ich kann mir vorstellen, dass viel sogar schon in unserem bestehenden Datenmodell mit Attributierung zweidimensionaler Geometrie möglich ist.

marek kleciak wrote:

Wir müssen uns von dem (aus der Sicht der Programmierer) Gedanken von einem Rastermodell verabschieden.

Ganz im Gegenteil, das Rastermodell ist die Lösung. Aber nicht mit dem jämmerlichen 50m-Raster von SRTM. Laserscans haben heute eine Auflösung von 1m. Beispiel: www.intermap1.noel.gv.at => dort auf "Karten Center: Alle Karten" klicken und "Laserscan" auswählen

Es würde nälich bedeuten, dass der Mapper nur für eine bestimmte Koordinate eine Höhenwert entragen kann / darf.

Ein Laserscan wird maschinell erstellt. Die Mapper können sich um andere Dinge kümmern.

Tordanik wrote:

An den Editoren oder Erfassungswerkzeugen liegt das nicht

Die Erfassungsgeräte möchte ich sehen, mit denen ein gewöhnlicher Mapper eine halbwegs genaue Seehöhe ermitteln kann. Ich bin ziemlich viel im Gebirge unterwegs und messe dort die Höhen von Gipfeln, Höhlen usw. Damit man überhaupt eine Chance hat, die Höhen einzelner Punkte auf 5m genau zu ermitteln, muss man mehrmals täglich amtliche Höhenkoten aufsuchen und daheim jeden Track auf komplizierte Weise analysieren. An manchen Tagen ist es überhaupt völlig aussichtslos.

Verrennt euch nicht in alte Technologien. Die Laserscans gibt es schon, es fehlt nur noch die Erlaubnis sie zu nutzen. Richtet eure Anstrengungen besser da hin, da bringt es was.

Hallo fkv

"Ganz im Gegenteil, das Rastermodell ist die Lösung."- Nein, ist nicht. Zumindest nicht für die Ziele, die ich beschreibe.
Laserscans hatten auch vor mehr als 12 Jahren die Auflösung von 1 meter und ich hatte die Gelegenheit mehr als genug mit solchen Daten zu arbeiten. Die gab es bevor die Firma Intermap die Du ziterst (mit der ich im Übrigem ziemlich von Anfang an in Kooperation stand) ihre (qualitativ SEHR gute) 3D Geländemodelle zum Verkauf angeboten hat.

Die Rastermodelle siehen auf den ersten Blick gut aus, nur haben sie in städtischen Gebieten in denen wir sie primär benötigen etwa so viel Wert, wie ein Pixelbild vierglichen mit einem Vektorbild: Du hast sehr viele Informationen die Du meistens nicht brauchst. Das erlebt man aber erst dann, wenn man versucht, hoch aufgelöste 3D Stadtmodelle daraus zu bauen. Ud das ist aus meiner Sicht primär das Ziel.

Außerhalb der Städte, auf freiem Gelände, in den Bergen sieht die Sache schon anders aus, aber dort braucht man meistens so viele Daten nicht. Die Autoindustrie, die in diesem Bereich führend ist, hat sich von Rastermodellen verabschiedet. Und dafür gibt es gute Gründe über die wir weiter gern diskutieren können.

Recht hast Du hingegen, wenn Du auf die Komplieziertheit und extreme Ungenauigkeit der Messung hinweist. Das stimmt natürlich und wird sich auf absehbare Zeit nicht wesentlich ändern.
Du hast aber hoffentlich begiriffen - wir reden hier über eine interative Verbesserung eines freien 3D Modells mit der Zeit. Basierend auf allen möglichen Messergebnissen. Und wenn als Methode die Auswertung dutzender Spuren zur Verfügung steht, dann eben diese Methode.

Es ist natürlich richtig zu hoffen, dass wir irgendwann die Erlaubnis bekommen die Lasercan Modelle zu benutzen. Wenn Du dazu beitragen könntest- nur zu!

de_muur wrote:

Schreibe ein entsprechendes Plugin fuer JOSM (oder suche dir jemanden, der das schreiben kann) und die z-Wert-Eintraege werden schon kommen.

Problematisch ist das aber bei Verschiebung von OSM-Objekten. Sonst würde ich da manuell initiierte automatische Hinzufügen von ele=*-Tags zum nächsten OSM-Punkt in Trackpunktnähe auch gutfinden. Scheinbar haben dafür vereinzelt auch schon Leute (in Russland bei Regressionsedits gesehen) Scripte am Laufen. Es ist auch leichter Höhendaten zu spenden, als Tracks erst mühsam für den Upload zu säubern. Automatisches Extrahieren könnte man auch versuchen (Metadaten zur Höhe werden mit beim Upload angegeben), aber dann müßte man die ganzen Trackpunktdaten erst mal vom statistischen Müll (man denke nur an die Innenstadtdreieckspuren...) befreien.

Eine Verknüpfung bzw. ein Datenabgleich zu OSM müßte ja auch dann gemacht werden, wenn z.B. eine Brücke abgerissen oder neu gebaut wird, dann müssen ja die alten Höhendaten an der Stelle entsorgt werden.

Fabi2 wrote:

Problematisch ist das aber bei Verschiebung von OSM-Objekten. Sonst würde ich da manuell initiierte automatische Hinzufügen von ele=*-Tags zum nächsten OSM-Punkt in Trackpunktnähe auch gutfinden.

Das ist nicht das, was mir vorstelle. In der X-Y-Lage arbeiten wir ja auch nicht (oder zumindest kaum) mit Automatismen.

Ich denke da eher an eine Erweiterung, die es dem Mapper erlaubt, graphisch die Hoehe fuer einzelne Objekte festzulegen.

Nehmen wir als Beispiel mal ein punktfoermiges Objekt:
Waehlt der Mapper dieses Objekt an, so hat er dazu ein Fenster mit einer zweidimensionalen Seitenansicht. Nach Oben wird natuerlich der z-Wert dargestellt, seitlich die Entfernung der anderen Punkte zu dem Zielobjekt. In diesem Diagramm werden nun neben dem Zielobjekt alle GPS-Track-Punkte, alle anderen OSM-Punkte sowie die SRTM-Hoehe oder andere verfügbare Höhenwerte dargestellt. Auf Grundlage dieser Anzeige kann dann der Mapper wunderbar den Z-Wert für das Zielobjekt einstellen/korregieren.
Als Einstellmöglichkeiten fuer dien Anzeige sollte man noch die Richtung der Abstandsachse sowie die Reichweite bzw. den Massstab des betrachteten Bereichs einstellen können (entsprechend dem Zoomen in der X-Y-Lage).

Wenn das zu bearbeitende Objekt Teil eines linienfoermigen Objektes ist:
Hier kann man ein Höhendiagramm entlang der Linie des Objektes darstellen. Die GPS-Track-Punkte, benachbarte OSM-Punkte, SRTM-Werte usw. werden dann auf diese Linie projeziert dargestelt. So kann der Mapper dann gezielt den Z-Wert des Objektes mit den Z-Werten der anderen Punkte der Linie abgleichen.

Wenn das zu bearbeitende Objekt Teil mehrerer linienfoermigen Objekte ist (Kreuzung):
Man kann einfach fuer jede Linie ein eigenes 2-D-Diagramm anzeigen, so dass der Mapper sehen kann, wie sich der gewaehlte Hoehenwert in die verschiedenen Richtungen einfuegt.

Das Ganze soll dazu dienen, dass der Mapper (als Mensch) ueber eine graphische Ansicht entscheiden kann, wie die verschiedenen Z-Werte zu bewerten sind (z.B. ob die Tracks ueber Geoid oder Ellipsoid gemessen sind, oder ob die Rasterwerte die Strasse oder den benachbarten Bahndamm erfasst haben), und daraus dann manuell den Z-Wert fuer das OSM-Objekt bestimmt.

So stelle ich zumindest mir die Loesung vor.

Gruss
Torsten

Hallo allerseits,
ich werde zwei sog. Ingenieurarbeiten (Informatik, TU) zu diesem Thema betreuuen.
Ich möchte Euch also um das Sammeln der GPS - Spuren mit Höheninformation bitten, damit sie durch die beiden Studenten ausgewertet werden können.

Kann jemand von Euch auf einem Gebiet mehrere Spuren entlang einiger Strecken sammeln?
Was man bräuchte wären etwa mehr als 20 Spuren entlang einer (oder mehrerer) Strecken, damit man die statistische Auswertung machen kann.
Ich möchte euch auch um Vorschläge zur möglichen User Interface bitten.
die Ideee von de_muur finde ich erst mal gut.
Habt Ihr noch weitere Vorschläge?

marek kleciak wrote:

Kann jemand von Euch auf einem Gebiet mehrere Spuren entlang einiger Strecken sammeln?

Wohin soll man die schicken? Auf meinen GPS müssten jede Menge zu finden sein. Falls die nicht reichen, einfach Bescheid geben

Haben wir keine möglichkeit die Spuren incl. z-Wert in OSM zu Laden? Wenn nicht bitte an mich schicken..