Jump to content

X-EUROPE OSM Verbesserungen


simHeaven

Recommended Posts

vor 7 Minuten, Frithjof sagte:

Zwischen Vrchlabi und der Schneekoppe ist auch kein Wald in der Scriptvariante.

Gucke mir das später mal an. Möglich, dass ich da schon einmal dran war. Ich bin mir eigentlich ziemlich sicher, dass die Ursache der fehlenden Wälder in OSM zu finden ist. Vor allem die beiden Flächen bei LOIH haben mich etliche Stunden Arbeit gekostet, um die vielleicht verursachenden OSM-Fehler auszumerzen. Ist aber die Frage, ob es etwas gebracht hat.

Im Moment sitze ich in OSM-Würzburg fest.

Link to comment
Share on other sites

  • Deputy Sheriffs
vor 23 Stunden , hmkaiser sagte:

Tippe da eher auf die "verqueren" OSM-Daten, mit denen das Script nicht zurecht kommt. Sind ja nur wenige Ausnahmen, die über das Script nicht geliefert werden.

Ja, das denke ich auch. Leider sind es dann meist riesige Waldflächen, die diese verqueren OSM-Daten darstellen und dann in der Szenerie bei den mit Script erzeugten Kacheln fehlen. 

 

Aktuell sind X-America, X-Australia-Oceania, X-Antarctica fertig erzeugt, X-Asia in den letzten Zügen und X-Africa bereits in der Erzeugung. Wenn das alles fertig und online ist, kommt nach einer Pause das große Update der X-Europe, wo ich dann peinlich genau auf die beiden Varianten der Wälder achte.

  • Like 1
Link to comment
Share on other sites

vor 35 Minuten, PilotBalu sagte:

Leider sind es dann meist riesige Waldflächen, die diese verqueren OSM-Daten darstellen und dann in der Szenerie bei den mit Script erzeugten Kacheln fehlen.

Ja und damit gibt es mehrere potentielle Störquellen. Alle fehlenden Waldflächen sind sehr komplex: Viele Nodes, jede Menge Überlappungen, nicht sauber erfasste inner-Flächen in Multipoygonen und dazu der Hang der Mapper, isolierte Waldflächen durch "schmalste Schläuche" an das Haupt-Waldgebiet anhängen zu müssen. Da gibt es, wie bei LOIH, "Schlauch-Nodes", die fast aufeinander gesetzt sind, um den Korridor auszubilden. Wenn das Script die Positionsdaten der Nodes dann nicht bis in die letzte Nachkomma-Stelle auswertet, kann allein das schon ein Grund sein.

Link to comment
Share on other sites

Hier ein ein Ausschnitt eines Forest-Multipolygons, östlich Velka Upa, das in der Script-Varinate nicht auftaucht:

Please login to display this image.

 

Die Outer-Linie des Multipoygons ist rot eingefärbt. Ist mir völlig unverständlich, warum derart krude Konstrukte in OSM erfasst werden. Der mittlere Forest-Bereich ist über 4 "Brücken" eingebunden, zwei dieser Brücken sind dünne "Schläuche". Die Außenlinie besteht aus 1533 Nodes, es gibt aktuell 42 inner-Flächen. Das Multipolygon ist nur als landuse=forest erfasst, keine Name, oder sonst irgend etwas. Formal scheint das Ding fehlerfrei zu sein, aber es ist fast unmöglich, mit solchen Dingern noch zu arbeiten ... außer radikal den ganzen Mist einzudampfen.

 

Update: Und gleich der erste Treffer. Der closed Way 26011282 ist als inner dem forest-Multipolygon zugeordnet, besitzt aber keine Eigenschaften. Dafür sind in dieser Fläche weitere Flächen und Multipolygone, die einfach so da sind ...

Link to comment
Share on other sites

vor 30 Minuten, Tatraplane sagte:

Es handelt sich um automatisierte Übernahme

Na dann gute Nacht: Es gibt innerhalb des "uhul, czuk"-forest-Multipolygon die Muiltipolygon-Fläche 423167389, landuse=meadow, source=Ipis. Die ist nicht als inner dem forest zugeordnet. Gleichzeitig liegt teilweise in dieser Fläche ein natural=wetland, source=didavod A06. Ist natürlich auch kein inner im forest, aber darauf kommt es dann wohl auch nicht mehr an.

Link to comment
Share on other sites

Mal sehen, ob das etwas bringt. Ich habe jetzt nur die dem Forest-Multipolygon zugeordneten "inner"-Flächen ohne Key in OSM korrigiert. Es gibt darüber hinaus noch jede Menge Überlappungen und andere Macken, die ich im Gegensatz zu den beiden Flächen bei LOIH nicht anfassen möchte. Vielleicht lässt sich so feststellen, woran sich das Skript stört.

Link to comment
Share on other sites

Diese Multipolygon-Flächen sind durch einfache Digitalisierung von alten Karten entstanden. Die gleichen Probleme gibt es natürlich auch in der Slowakei.   

 

Das gleiche hast du auch hier:

 

https://www.openstreetmap.org/#map=9/67.1209/31.7834

 

oder auch hier

 

https://www.openstreetmap.org/#map=7/60.398/115.840

 

Nur die Dimensionen sind etwas größer.

 

 

Link to comment
Share on other sites

vor 17 Stunden , Tatraplane sagte:

Diese Multipolygon-Flächen sind durch einfache Digitalisierung von alten Karten entstanden. Die gleichen Probleme gibt es natürlich auch in der Slowakei. 

Ja, offenbar herrscht da ein munteres Treiben. Flächen werden manuell in OSM erfasst, dann kommt eine weitere Struktur per Import von der Seite hinzu. In dem o.a. Forest nordöstlich Velka Upa gibt es innerhalb des Multipolygons eine Inner-Fläche, die mehrere weitere, nicht als "inner" behandelte Flächen beinhaltet, von denen eine sogar als Multipolygon (outer) erfasst ist, wiederum mit inner-Flächen ...

Aber das wäre mir egal, denn interessant ist nur, warum die große Waldfläche nicht über die Script-Version generiert wird. Deshalb habe ich mich ausschließlich auf das forest-Multipolygon konzentriert, also alles, was als outer, oder inner darin auftaucht. Bleibt der Wald nach dem nächsten Update immer noch verschwunden, müssen die Ursachen auch außerhalb des direkt betroffenen forest-Multipolygons zu suchen sein.

Anders bei den beiden Multipolygon-Flächen östlich LOIH: Da habe ich zusätzlich versucht, alle Überlappungen zu entfernen. Außerdem habe ich mehrere, über dünne Korridore angehängte "Wald-Satelliten" separiert, also als eigenständige Fläche neu erfasst.

So gesehen gibt es zwei Szenarien, die nach dem nächsten Update interessant werden können.

 

War schon ein arbeitsreiches OSM-WE. Zwischen Würzburg und nördlich Thüngersheim mussten sich einige überbordende Groß-Weinberge massiv zerteilen lassen. Das sollte sich an den steilen rechten Uferlagen des Mains schon deutlich bemerkbar machen. Außerdem mussten bei mir die greenhouses längs der Piste des Global Airports Würzburg-Schenkenturm Armins Solar-Fassaden weichen.

  • Like 1
  • Upvote 1
Link to comment
Share on other sites

Der Screenshot "Wachau" hier im Forum kam mir komisch vor und musste da mal eine Runde drehen: In dem Bereich gibt es die Relation 4653252, ein Forest-Multipolygon südlich Ostra, https://www.openstreetmap.org/edit#map=14/48.4237/15.4854.

Der Wald taucht nicht in der Script-Version auf. In diesem Fall waren die 4 Segmente der Outer-Linie nicht in die richtige Reihenfolge gebracht. Außerdem gab es eine inner-Fläche, die keine Attribute besessen hat. Innerhalb dieser Fläche gab es 4 weitere Flächen, die keinem Multipolygon angehörten. Das habe ich geändert.

Allerdings war hier auffällig, dass das Forest-Multipolygon direkt mit anderen Forest-Multipolygonen gekoppelt ist. Dadurch hat der (Koppel-)Way 331581177 eine andere Linienrichtung, als die anderen 3 outer-Segmente. Mal sehen, ob das relevant ist.

Ziemlich schlimm sind in meinen Augen die Weinberge in dem gesamten Bereich.

 

Link to comment
Share on other sites

On 5.11.2021 at 20:21, hmkaiser sagte:

Hier noch einmal ein schlechtes Beispiel OSM-"vineyards" südöstlich LOAG, zwischen Wolfsgraben und Gedersdorf. Die Riesen-Fläche macht den gesamten Landschafts-Charakter kaputt.

Ich habe mir den Tort angetan und dieses Multipolygon und zwei weitere bei Stein an der Donau entfernt, die Flächen in OSM völlig neu aufgebaut. Die Landschaft ist sehr kleinteilig strukturiert, die Weinberge entsprechend der Topologie den Hanglagen folgend. In Summe sind es deutlich mehr als 50.000 Nodes, die gesetzt werden mussten. Hat auch rund eine Woche gedauert. Dazu kommen dann die bereits erfolgten Detaillierungen bei Würzburg, Ochsenfurt und im Rheingau. Alles sollte nach dem nächsten X-Europe-Update der Landschaftsdarstellung in den Bereichen einen Schub geben. Allerdings gibt es noch viel mehr zu tun.

Link to comment
Share on other sites

@hmkaiser Guten Abend werter OSM-Landschaftsverbesserer,

als eifriger Leser dieses Forums und Nutzer der sim-heaven Scenerien ist es mir wichtig, an dieser Stelle mal meinen herzlichen Dank für den unermüdlichen Einsatz zur realistischen Abbildung unserer mitteleuopäischen Landschaft auszudrücken. Gerade solche "Kleinigkeiten" wie die Abbildung der kleinflächigen Rebflächen u.a. beeinflussen das Gesamtbild der Scenerien maßgeblich.

Hierfür nochmals Dank und Anerkennung meinerseits.

Ich wünsche eine frohe und gesunde Vorweihnachtszeit,

Wolfgang alias wokue 

Link to comment
Share on other sites

On 11.12.2021 at 11:41, Tatraplane sagte:

LZZH -Janova Lehota ist ein anderes Thema. Schauen über den Zaun um zu feststellen, daß MSFS auch im VFR-Bereich erhebliche Probleme hat.

Hallo Tatraplane, ich habe mir das mal angesehen:

Please login to display this image.

Es handelt sich um eine Weide-/Wiesenlandschaft, in einem Talkessel liegend.

Du hast in OSM ja schon angefangen, aber was ich hier noch machen würde:

  • Konsequent die Naturwald-Flächen (natural=wood), vor allem längs der Bäche, einzeichnen. Dazu gehören auch die Bereiche mit den Datschen. In OSM müsste landuse=allotments verwendet werden, dann aber werden über X-Europe zufällig Hütten gesetzt. Könnte man umgehen, indem man die Flächen als natural=wood tagt. Übrigens steht "forest" in OSM für einen forstwirtschaftlich genutzten Wald, während "wood" einen Naturwald beschreibt.
  • Dann fällt mir auf, dass fast alle "buildings=yes" getagt sind. Ich würde besonders bei den "farmyards" versuchen, die Gebäude richtig zu beschreiben, denn X-Europe weist ja danach die Fassaden und Objekte zu. Wenn z.B. Lüftungen in den Dächern eines farmyard-buildings erkennbar sind, handelt es sich wahrscheinlich um einen Stall (building=sty (Schweine), building=cowshed...)
  • Es gibt in dem farmyard "Trubin", Hausnummer 515, ein Groß-Gebäude "building=yes". Es handelt sich aber eindeutig um einen "man_made=bunker_silo"
  • Das Gebäude 515 ist 5-teilig. Ich würde das in Einzelgebäude, davon 3 als "building=sty" teilen.

 

 

Link to comment
Share on other sites

  • 4 weeks later...

... was alles so passiert: In den letzten Wochen habe ich intensiv in OSM gearbeitet, u.a. auch viele "building=yes" außerhalb von "residential"-Zonen, aber auch innerhalb von "landuse=farmyard" einen Gebäudetyp verpasst.

Gestern noch habe ich u.a. zwei dieser Objekte in Uttenweiler, Baden-Württemberg, auf "sty", bzw. "barn" gesetzt. Danach hat mich ein OSM-Mapper, offensichtlich aus der Region, (wieder) heftig kritisiert ("ob ich ein Ratespiel machen würde?") und mir erklärt, dass der "sty" eine "Scheuer" (? = Barn?), die "barn" ein "Maschinenschuppen" hätte sein müssen und gleichzeitig meinen gesamten Änderungssatz (mit diversen storage_tank-Änderungen) aus dem Verkehr gezogen, den ursprünglichen Zustand mit "building=yes" wieder reaktiviert. Blieb mir nichts anderes übrig, als mich artig zu bedanken, vor allem, weil Dank der Detail-Kenntnisse meines Kritikers, beide montierten "buildings" jetzt sachgerecht mit "=yes" typisiert sind. Also muss ich auf den VFR-Überflug von Uttenweiler in X-Europe 5.7 verzichten.

Sorry, war jetzt auch ein bisschen Sarkasmus dabei ...

Link to comment
Share on other sites

Ich weiß es ist bitter. Du bist aber nicht alleine.

 

In der Slowakei bei OSM läuft jetzt eine lange Unterhaltung über nicht namentlich genannte User, die die Grenzen in Waldnaturschutzgebieten verändern. Die Lage ist noch komplizierter, da die einzelne Waldstücke insgesamt einen Naturschutzgebiet bilden, aber die Felder dazwischen nicht. Dazu kommt, dass die Naturschutzgebiete reformiert und die einzelne  Waldflächen jetzt aus dem altem Naturschutzgebiet rausgenommen wurden und virtuell zu "Urwälder der Slowakei" unter Naturschutz umdeklariert wurden. Die bei OSM-Slowakei ist damit jetzt beschäftigt. Dabei ist denen (noch) nicht aufgefallen, daß die eingezeichnete naturgeschützte Waldflächen nicht unbedingt mit der Realität übereinstimmten. Ich habe teilweise die Waldflächen zurechtgebogen, aber die damit verknüpfte Naturschutzgebiete weitgehend in ursprünglichem Zustand gelassen.  Zumindest ist jetzt meine Arbeit für X-Europe 5.7 gesichert.

 

Speichere deine Änderungen offline auf deiner Festplatte und dann kannst du die mit wenigen Mausklicks noch einmal und noch einmal einspielen. Dazu gibt es auch einen Verein "OSM-Deutschland". Einfach dort vortragen und damit die sich mit deinem Problem beschäftigen. Es hilft nicht für X-Europe 5.7 aber möglicherweise für X-Europe 6.0.  

Link to comment
Share on other sites

vor 56 Minuten, Tatraplane sagte:

Dazu gibt es auch einen Verein "OSM-Deutschland". Einfach dort vortragen und damit die sich mit deinem Problem beschäftigen. Es hilft nicht für X-Europe 5.7 aber möglicherweise für X-Europe 6.0.  

Ja, ist bekannt. Ich habe aber eigentlich keine Lust da mitzumachen, weil die Debatten die gleichen sind, die ich jetzt schon mit dem einen User führe - ohne zu einem Ergebnis zu gelangen: Hier prallt die Sicht eines "Kataster-Beamten", gestützt von (Kataster-)Maps4BW, auf den Rest der Welt. Letzlich gibt es aber für alles Argumente, aber kein richtig, oder falsch.

Link to comment
Share on other sites

  • Deputy Sheriffs
On 10.1.2022 at 09:03, hmkaiser sagte:

In den letzten Wochen habe ich intensiv in OSM gearbeitet, u.a. auch viele "building=yes" außerhalb von "residential"-Zonen, aber auch innerhalb von "landuse=farmyard" einen Gebäudetyp verpasst.

Dürfte nicht so schlimm sein, dass deine Änderungen nun (noch) nicht einfließen. Nur sehr ärgerlich für dich. Wenn ein "building=yes" innerhalb "landuse=farmyard" ist, wird trotzdem ein "landwirtschaftliches" Gebäude daraus gemacht. Vielleicht ist es besser, nur immer Häppchen zu machen und hochzuladen.

 

Übrigens, in Belgien hat sich viel getan, da scheint einiges importiert worden zu sein, das wird wahrscheinlich in der 5.7 "OSM only" werden.

Link to comment
Share on other sites

vor 4 Stunden , simHeaven sagte:

Dürfte nicht so schlimm sein, dass deine Änderungen nun (noch) nicht einfließen. Nur sehr ärgerlich für dich. Wenn ein "building=yes" innerhalb "landuse=farmyard" ist, wird trotzdem ein "landwirtschaftliches" Gebäude daraus gemacht. Vielleicht ist es besser, nur immer Häppchen zu machen und hochzuladen.

Mache es auch in Häppchen. Insofern ist jetzt nur Uttenweiler betroffen. Bei "landuse=farmyard" wäre es mir auch fast egal, aber allein stehende "building=yes", ohne schützenden farmyard, ..., verdienen eigentlich ein besseres X-Europe-Schicksal. Auf der anderen Seite: Die paar OSM-Ärger-Nodes bilden noch nicht einmal einen Tropfen auf dem heißen Stein. Immerhin: Wir stehen jetzt in "zivilisiertem" Kontakt. Dem OSM-Retournator konnte ich mittlerweile stressfrei ein paar Dinge zum Verdauen geben. So anhand eines von mir editierten, vorher aber von ihm erfassten buildings in Reutlingendorf die Frage erörtern, ob Maps4BW die "Wahrheit" repräsentiert, oder nicht. Dazu musste die Lage des Dachfirsts und die symmetrische Anordnung der Dachflächen in Relation zu Maps4BW herhalten.

Vor 4 Wochen hatte ich schon die erste "Feindberührung". In einer anderen Ortschaft befinden sich 4 Stück Gewächshäuser, alle identisch groß und, so sagen es alle Fotoquellen, in gleichem Abstand zueinander aufgestellt. Nur Maps4BW behauptet, dass eins der vier Gewächshäuser 10 Meter abseits stehen muss. Ich hatte mir damals frevelhafter Weise erlaubt, Maps4BW nicht zu berücksichtigen. War ein großer Fehler.

Link to comment
Share on other sites

Tja, in der Slowakei haben wir diesen Prozess hinter uns. Kapor="Kataster Portal" wird nicht mehr als maß aller Dinge betrachtet. Es war auch in der Slowakei lange so, egal welchen Blödsinn in Kapor stand. Kapor hatte immer Recht. Jetzt mit freien LIDAR-Daten ist die Lage anders. Vielleicht soll BW zuerst die LIDAR-Daten rausrücken. Das passiert aber nicht so schnell, da sonst würde jeder sehen, welchen Schrott die dort verwalten.

Link to comment
Share on other sites

vor 20 Minuten, Tatraplane sagte:

Daß passiert aber nicht so schnell, da sonst würde jeder sehen, welchen Schrott die dort verwalten.

Das geht auch nicht: Ohne mentale Vorbereitung würde bestimmt so mancher OSM-Mapper-Zeitgenosse einen Herzinfarkt erleiden.

Link to comment
Share on other sites

vor 28 Minuten, hmkaiser sagte:

Das geht auch nicht: Ohne mentale Vorbereitung würde bestimmt so mancher OSM-Mapper-Zeitgenosse einen Herzinfarkt erleiden

Davon kann ich auch ein Lied singen. Immer diese "Regionalfürsten" in OSM; hatte auch schon einige Kontakte hinter mir, mal freundlich, mal weniger freundlich

  • Upvote 1
Link to comment
Share on other sites

On 10.1.2022 at 10:47, Tatraplane sagte:

In der Slowakei bei OSM läuft jetzt eine lange Unterhaltung über nicht namentlich genannte User, die die Grenzen in Waldnaturschutzgebieten verändern. Die Lage ist noch komplizierter, da die einzelne Waldstücke insgesamt einen Naturschutzgebiet bilden, aber die Felder dazwischen nicht. Dazu kommt, dass die Naturschutzgebiete reformiert und die einzelne  Waldflächen jetzt aus dem altem Naturschutzgebiet rausgenommen wurden und virtuell zu "Urwälder der Slowakei" unter Naturschutz umdeklariert wurden. Die bei OSM-Slowakei ist damit jetzt beschäftigt. Dabei ist denen (noch) nicht aufgefallen, daß die eingezeichnete naturgeschützte Waldflächen nicht unbedingt mit der Realität übereinstimmten. Ich habe teilweise die Waldflächen zurechtgebogen, aber die damit verknüpfte Naturschutzgebiete weitgehend in ursprünglichem Zustand gelassen.  Zumindest ist jetzt meine Arbeit für X-Europe 5.7 gesichert.

Da würde ich gelassen abwarten. Große OSM-Flächen mit den vielen Besonderheiten sind ganz schwieriges Terrain. Was mich umtreibt ist, dass OSM letztlich nur Eigenschaften an bestimmten Stellen auf der Weltkugel abbildet. Insofern dürfte eine OSM-Fläche auf der Weltkugel immer nur so groß sein, dass alle (!) in OSM zu vergebenden Eigenschaften dieser Fläche eindeutig bleiben. Wenn man es so betrachtet, müssten praktisch alle großen Waldflächen in viele einzelne Teiflächen aufgeteilt werden. Es gibt nämlich z.B. "landuse=forest" und "natural=wood" in trauter Eintracht nebeneinander. Dazu kommen Eigenschaften wie Nadel-, Laub-, oder eben Mischwald. Man kann das Ganze soweit treiben, dass sogar die vorhanden Baumarten in OSM einfließen. Und XPlane könnte eine Menge davon abbilden.

Wird eine in OSM zu erfassende Fläche aber z.B. über eine Namensbezeichnung definiert, z.B. "Thüringer Wald", werden x-km²-großen Flächen erst einmal über einen Kamm geschoren. Und hinterher gibt´s großes Gewusel mit Multipolygonen und sonstigen Krücken.

 

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy & Terms of Use