Wenn Deine Vermutung stimmt, dass Dein Flusi die Höhe aus dem ele tag ermittelt, dann sollte folgendes reichen:
vorhandene *.osm Datei mit JOSM öffnen
Objekt (den OSM way) finden, z.B. mit Ctrl+F (Suchen) und id:435039800 als Suchbegriff
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
Abschliessend die OSM Datei speichern
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
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.
wir würden sehr gern helfen - aber deine Informationen sind ein wenig unvollständig / irritierend:
Zur Klarstellung, wie ich Deine Informationen verstanden habe:
Du hast eine lokale OSM-Datei.
Du bearbeitest diese Datei mit JOSM
Du markierst den Heliport mit dem Polygon / Lasso - Werkzeug von JOSM?
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)?
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.
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.
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.
völlig falsch geglaubt:
Man muss doch wissen, wie das Python-Script und der Flusi arbeitet, wie die “vorhandene Kachel” mit der OSM-Datei gepatcht wird, um überhaupt aussagen zu können, wie denn die OSM-Datei zum patchen aussehen muss!
Einerseits sprichts Du von einem vorhandenen OSM-Objekt http://www.openstreetmap.org/way/435039800,
andererseits erzeugst Du mit dem “Punkte setzen” ein völlig neues Objekt!
Darf die OSM-Datei nur dieses eine einzige Objekt enthalten, dass du patchen willst
oder darf sie auch umgebende Objekte enthalten?
Muss das Objekt ein vorhandenes sein (gleiche ID) oder darf es ein neues sein, dass dann anhand der Koordinaten eingefügt wird?
Womit fütterst Du also das Python-Script zum patchen überhaupt?
Und kann das damit überhaupt umgehen?
Du (und wir) vermuten viel zu viel - ohne Grund unter den Füßen zu haben.
Dass die angemahnten Wege vermutlich in der Kachel enthalten sind, darf vermutlich den Patcher gar nicht stören, da der Patcher sie ja gar nicht anfassen soll - also sind sie vermutlich in deiner lokalen OSM-Datei enthalten und vermutlich will der patcher alle enthaltenen Objekte patchen, darf aber vermutlich nur geschlossene (aeroways) Objekte patchen …
Das ist wohl eher deine subjektive Meinung. Mir ist der Spaß an dieser Sache hier auch vergangen bei deinem Verhalten. Jetzt schreiben wir seit zwei Seiten herum und wissen immer noch nicht, worum es eigentlich genau geht.
PS: Kleiner Tipp – mach das Wetter schlechter und flieg über der Wolkendecke, dann brauchst du keine Kartendaten.