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

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.

Dann liege ich ja richtig mit meiner Vermutung. Nur sind mir Deine Angaben zurzeit noch zu hoch gegriffen bzw. weiss damit nichts anzufangen. :slight_smile:

Ich vermute für Flusi wählst du Wege aus OSM aus.
In deiner Aufzählung hast du (vermutlich) Wege ausgewählt, die du wahrscheinlich nicht benötigst.

Du möchtest den Helipad laden → das ist die way:id = way 435039800.

und das ist eine Fläche um den Helipad mit ele=816 →
https://www.file-upload.net/download-12386041/Helipad.jos.html
Diese runterladen und mit JOSM öffnen und als Datei speichern (nicht hochladen!)

Ansonsten solltest du schon nähere Angaben zu Flusi machen, das man sich dort einmal informieren kann - oder dann dort direkt nachfragen - hattest ja einen user der es schon gemacht hat.

Warten wir mal ab, ob sich der Verursacher (PaterMcFly) meldet und seine Eingaben am Walkebach selbst korrigiert.

Grüße
Peter

Weil vermutlich die genannten Way-Ids innerhalb der Kachel +47+9 liegen.
http://www.goeldenitz.org/map_grid.html

(nach unten scrollen)