Anfänger: Wie weise ich einem Objekt oder einer Fläche eine Höhe zu ?

In OSM gibt es kein Gelände- oder Oberflächenmodell. Manche Objekte haben eine gemittelte Höhe, das ist alles. Die Welt in OSM ist also ziemlich flach (abhängig von der Projektion ;)). Deine Daten stammen also sicher nicht direkt aus OSM, daher kann dir OSM und die dort verwendeten Werkzeuge auch nicht weiterhelfen.

Die Ergänzung zum Flugsimulator hat demnach für Verwirrung gesorgt. Der Werdegang ist der, dass in OSM eine Fläche mittels Polygon(en) gewählt und als .osm lokal gesichert wird. Das weitere Vorgehen für den Gebrauch im Flugsimulator läuft dann über ein Python-Script, das dann einen Patch für die bereits vorhandene Kachel erzeugt. Die Höhe muss ich aber im ausgewählten Feld (Heliport) eingeben.

Würde mir also jetzt bitte, bitte mal jemand sagen, wie ich einem mittels Polygon ausgewählten Feld eine Höhe zuweisen kann, das ich dann lokal nutzen kann? Vielen Dank im voraus.

Hi theryma52, herzlich willkommen bei OSM. Viele hier im Forum sind langjährig erfahrene “Profis” und empfehlen dir gerne Sachen, die sie selber gut kennen und oft nutzen. JOSM ist ohne Zweifel ein mächtiger Editor, aber für einfache Aufgaben völliger Overkill. :slight_smile:

*Der Browser-Editor iD ist für deine Änderungen völlig ausreichend.
**
Die Höhe eines Objektes wird mit ele=
(Höhe über Meeresspiegel ohne Einheit) eingetragen, also für einen Hubschrauberlandeplatz/Heliport eine Fläche anlegen/editieren mit

aeroway=helipad
ele=500

Voraussetzung ist, dass die Höhe den realen Gegebenheiten vor Ort entspricht. Versteht sich von selber, dass hier keine Phantasie-Höhen eintragen werden, nur damit dein Simulator rund läuft. :wink:

Du kannst uns auch einen Karten-Link zu dem Helipad senden, dann können wir dir evtl. noch weitere Tipps geben. Dazu einfach auf openstreetmap.org Rechtsklick auf das Objekt → Abfrage-Funktionen → im linken Rahmen das Objekt auswählen und den Link aus dem Browser kopieren.

Viel Erfolg
geow

PS: @ Harald und Chris - bitte entschuldigt, ich fand eure Antworten an einen Anfänger nicht sooo hilfreich und habe versucht mich auf die das Wesentliche zu beschränken - keep it simple. :wink:

@Harald. Bearbeitungen in iD werden nicht sofort in der Datenbank wirksam, sondern erst nach Speichern → Hochladen, wobei eindeutig auf die Auswirkungen hingewiesen wird: Änderungen, die du hoch lädst, werden auf allen Karten sichtbar, die OpenStreetMap nutzen. Hier kann die Aktion noch mit Abbrechen beendet werden.

edit:typo

Hallo geow

Dir sei herzlichst gedankt – und sehr gerne hier der Link:

http://www.openstreetmap.org/way/435039800

Also mein Ziel ist in zwei Schritten gelistet:

  1. Fläche um den Heliport (inkl. der paar Häuser auf dem Areal) markieren und diesem eine Höhe zuweisen. Der Unterschied vom höchsten zum tiefsten Punkt sind geschätzte 10m. Der Heliport wird glaube ich mit 806m in Googlemaps aufgeführt. Also müsste man dem ganzen Feld die Höhe 816 m zuweisen.

  2. Mehr brauche ich nicht und das Getätigte dann als .osm-Datei speichern, das ich in meinem Python-Script weiterverwenden kann.

Grüsse, ryma

Danke für die Blumen, rhma! Wenn du im Link die Kartenebene (rechte Tool-Leiste) auf Radfahrkarte änderst, ergibt sich für den helipad eine Höhe basierend auf SRTM von 805 m → http://www.openstreetmap.org/#map=18/47.40858/9.47348&layers=C

zu 1: ele=805 würde ich ohnehin beim helipad ergänzen. FYI: Google-Daten sind für OSM keine legale/nutzbare Quelle.

zu 2: Wenn du eine Fläche um den Heliport mit ele=* lokal als .osm-Datei speichern willst, dann geht das leider nicht mit iD aber z.B. mit JOSM. Sollte das eine einmalige Aktion sein, könnte ich dir eine entsprechende Datei zum Abruf hochladen. Solche virtuellen Flächen aber bitte NIE in die OSM-db laden. :slight_smile:

Gruß
geow

Das ist keine einmalige Aktion. Der Werdegang ist bei wenigen Flusianern durchaus bekannt. Nur mir infolge mangelnden Englischkenntnissen (noch) nicht.

Ich würde Dir sehr gerne zwei, drei grosse Paypal-Biere spendieren, wenn Du mir eine kurze Schritt-für-Schritt-Anleitung generieren könntest. Das wäre es mir wert.

Sollte es dann funzen, würde ich gerne weitere Heliports in Schräglage einebnen wollen. Wenn man eigene Szenerien für den Flusi generieren will und der Heliport bzw. Flughafen liegt in einer schrägen oder wellenartigen Hügellage, sind dann jene manuell hinzugefügten Objekte teilweise in der Luft. Deshalb braucht ein Szenerie-Entwickler möglichst ebene Flächen.

Und ich bin immer noch fest davon überzeugt, dass du bei OpenStreetMap an der völlig falschen Stelle nach einer Lösung suchst. OSM hat keine Höhendaten, daher kann da auch nichts schräg sein oder in der Luft stehen.

Aber zeig uns erstmal deinen Workflow (in einer Form, die detailliert genug ist um ihn zu reproduzieren) und die Quellen dafür.

Kannst du uns da mal eine Referenz/Dokumentation nennen? Insbesondere wäre interessant, welches Höhenmodell vom Simulator verwendet wird. Frei verfügbar sind weltweit nur die SRTM-Daten, die etwa eine horizontale Gitterweite von 25 m haben, siehe http://wiki.openstreetmap.org/wiki/SRTM. Viele Anwendungen, die auf OSM-Daten beruhen verwenden SRTM als topographische Grundlage.

Weiter wäre noch von Interesse, wie groß die “ebene Fläche” etwa sein soll und ob neben ele=* weitere Attribute benötigt werden?

Danke, ein verlockendes Angebot :stuck_out_tongue: In der Zwischenzeit kannst du schon mal JOSM installieren und dich hier etwas warm laufen:

http://learnosm.org/de/josm/start-josm/

Gruß
geow

In Openstreetmap setzt sich eine Fläche aus Punkten zusammen, die mit einer geschlossenen Linie verbunden sind.

Du kannst für jeden Punkt notieren, was für eien Höhe über Mehresspiegel der hat (über den tag ele). Bei einer Fläche kannst du so ja die Neigung jedenfalls in die Daten kriegen, wenn jeder Eckpunkt verschiedene Höhen hat.

Dieser Tag wird recht selten benutzt, daher ist das Zuweisen der Höhe im Editor ID nur über Umwege möglich. Du musst den Punkt auswählen “andere” wählen und kannst dann unter “alle Eigenschaften” in die linke Spalte ele und in die rechte den Wert eintragen.

Berggipfel und mache anderen markanten Punkte haben durchaus Angaben zur Höhe in der Datenbank hinterlegt, es ist also nicht verboten, die Höhe einzutragen. Ich mache dass an markanten Punkten wo ich das aus sicherer freier Quelle feststellen kann, um eine Referenz für meinen Höhenmesser zu haben.

Anscheinend bin ich einem zu alten Thread im Flusi-Forum gefolgt. In einem neueren Thread steht, dass die Höhenangabe nicht nötig wäre, weil das Python-Script dies automatisch anzugleichen versuche. Also den Heliport mit dem Polygon-Werkzeug umrahmen, zwei Tags namens “aeroway-aerodrome” und “icao-lsxt” setzen und gut soll es sein.

Sobald ich jedoch das Tag “aeroway-aerodrome” setze, verwandelt sich das Polygon in eine gestrichelte Linie mit fettem Balken, was zur Folge hat, dass beim Patchen mittels Python-Script die folgende Meldung erscheint:

“Way id=475654201 was not treated because it is not closed.”
(und für jeden weiteren gesetzten Punkt dasselbe)

Natürlich war das Polygon zuvor geschlossen.

Wenn Deine Vermutung stimmt, dass Dein Flusi die Höhe aus dem ele tag ermittelt, dann sollte folgendes reichen:

  1. vorhandene *.osm Datei mit JOSM öffnen
  2. Objekt (den OSM way) finden, z.B. mit Ctrl+F (Suchen) und id:435039800 als Suchbegriff
  3. In diesem Fall also den Weg auswählen und dann rechts im Fenster wo “aeroway” “helipad” steht auf den “+Hinzufügen” Knopf klicken
    und im Popup den Schlüssel “ele” mit dem Wert “805” eintragen, anschließend OK
  4. Abschliessend die OSM Datei speichern
  5. JOSM beenden und im Warn-Dialog “Ungespeicherte Änderungen” auf “Beenden!” drücken, da Du die Änderungen ja nicht in der OSM DB ablegen willst.

Hinweis:
Falls die *.osm Datei nicht zu groß ist, kannst Du sie mit einen normalen Text-editor öffnen und ganz oben aus upload=‘true’
upload=‘false’ machen, dann weiß JOSM, dass die Dateien nicht in die OSM DB sollen.
Ausserdem kannst Du dann auch sehen, dass Deine Änderungen die Zeile

ergänzt haben.

ciao,
Gerd

Hallo Gerd
Vermutlich hast Du meine vorherige Nachricht übersehen, in der ich schrieb, “Anscheinend bin ich einem zu alten Thread im Flusi-Forum gefolgt. In einem neueren Thread steht, dass die Höhenangabe nicht nötig wäre, weil das Python-Script dies automatisch anzugleichen versuche.” Das Tag ele fällt also auf jeden Fall weg.

Hier die volle Auflistung der Meldungen beim Patchen der Flusi-Kachel:

Way id=475654201 was not treated because it is not closed.
Way id=475654202 was not treated because it is not closed.
Way id=475654203 was not treated because it is not closed.
Way id=475654204 was not treated because it is not closed.
Way id=475654205 was not treated because it is not closed.
Way id=475654206 was not treated because it is not closed.
Way id=475654207 was not treated because it is not closed.
Way id=475654208 was not treated because it is not closed.
Way id=475654209 was not treated because it is not closed.
Way id=475662137 was not treated because it is not closed.
Way id=475662138 was not treated because it is not closed.
Way id=475662139 was not treated because it is not closed.
Way id=475662140 was not treated because it is not closed.
Way id=475662143 was not treated because it is not closed.
Way id=475662146 was not treated because it is not closed.

Was hat es mit der gestrichelten Linie auf sich? Ist das der Grund für die Fehlermeldung?
Oder ist der LSXT-Heliport irgendwie nicht komplett erfasst?

Nachtrag:
Habe soeben festgestellt, dass die gestrichelte Linie nur eine Sache der Ansicht ist. Im Menü Ansicht die Drahtdarstellung aktivieren und weg ist sie. Also muss es ein OSM-Problem sein, nicht wahr?

Tja, jetzt kann ich Dir nicht leider mehr folgen. Ich kenne diesen Flusi nicht und habe nicht die geringste Ahnung, was Deine Skripte mit den modifizierten OSM Daten machen. Vermutlich solltst Du entweder einen neuen Weg anlegen und mit irgendwelchen Tags versehen oder
vorhandene Wege in einer type=multipolygon Relation zu einer geschlossenen Fläche zusammenbauen.

Wenn Du mal Deinen Link zu dem Flusi-Forum postest, kann ich schauen, ob ich daraus schlau werde.

Gerd

Moin,

wir würden sehr gern helfen - aber deine Informationen sind ein wenig unvollständig / irritierend:

Zur Klarstellung, wie ich Deine Informationen verstanden habe:

  1. Du hast eine lokale OSM-Datei.
  2. Du bearbeitest diese Datei mit JOSM
  3. Du markierst den Heliport mit dem Polygon / Lasso - Werkzeug von JOSM?
  4. Mit “Hinzufügen” fügst Du die Tags “aeroway=aerodrom” und “icao=lsxt” hinzu?

Zumindest wäre diese Vorgehensweise falsch, da damit nicht nur das Heliport-Polygon, sondern auch dessen nodes/Punkte die tags bekommen.
Aber ich fürchte, dass Du ganz woanders bist, denn:

a) Welches Polygon verwandelt sich in eine gestrichelte Linie mit fettem Balken?

Die angegebenen OSM-Way-IDs sind allerdings tatsächlich ziemlich weit entfernte Wege/Straßen - und somit nicht geschlossene Polygone - warum sollte der Patch-Prozess sie also überhaupt verändern (wollen)?

Grüße, Georg

Das will ich Dir echt nicht antun wollen. Ich bin ja auf dieses Forum gewechselt, weil ich im Flusi-Forum jenen Usern, die schon zigmal Heliports und Flughafengelände begradigt haben, jedes Einzelteil aus der Nase saugen muss. Ich bin mir sicher, sie wollen einfach nicht aus der Trickkiste plaudern. Zudem ist es auch unübersehbar, dass wenn man nicht zur Elite gehört, kaum beachtet wird.

Betr. “type=multipolygon Relation” scheint mir vom Gefühl her plausibel zu sein. Denn wenn ich den Kartenteil von LSXT Trogen herunterlade, sehe ich im vorderen Teil vereinzelte Punkte liegen. Könnte es etwas damit zu tun haben?

Jedenfalls gebe ich nicht auf. JOSM gefällt mir und es gibt im Netz auch tolle Tutorials dazu.

way 475654201 - ist ein (komischer) Flußlauf - http://www.openstreetmap.org/way/475654201#map=19/47.39778/9.30085 und kann keine geschlossen Linie sein.

way 475662146 ebenso.

PS: zu dem “komisch” habe ich einen CS-Kommentar: http://www.openstreetmap.org/changeset/46222110#map=13/47.4273/9.3367

Die Way-IDs gehören zumindest teilweise zum Walkebach. Dessen OSM-Daten sind teilweise falsch:
https://www.openstreetmap.org/way/475654201/history

Zu einem Bach gehören eigentlich nur die Einträge waterway=stream + name=*
Die Teilstücke, die in einer Röhre unter einer Straße hindurch fließen bekommen zusätzlich tunnel=culvert + layer=-1
Waterway: http://wiki.openstreetmap.org/wiki/DE:Waterways
Tunnel=culvert: http://wiki.openstreetmap.org/wiki/DE:Tag:tunnel%3Dculvert

Grüße aus Oberschwaben
Peter

Mit dem Werkzeug “Punkte setzen” und am Schluss schliessen.

Ja, “aeroway=aerodrom” oder “aeroway=heliport”. Das muss ich gemäss eines Flusi-Users, der schon etliche Heliports begradigt haben will, tun.

Das mit der gestrichelten Linie habe ich oben beschrieben, dass es lediglich eine Sache der Ansicht bzw. Darstellung ist und somit keinen Einfluss haben kann auf die Fehlermeldung (glaube ich jedenfalls).

Ja, eben. Ich glaube nicht, dass nähere Angaben zum Flusi vonnöten sind, da es meiner Meinung nach am OSM-File oder an den hinterlegten OSM-Daten liegt.

Habe auch einen CS-Kommentar bei Walkebach eingetragen - Ersteller ist PaterMcFly und nicht theryma52

Ich hab doch nie etwas eingetragen.