Jump to content

Recommended Posts

On 15.4.2021 at 12:43, Coverdale sagte:

Beim erstellen von Orthos habe ich oft das Problem, das beim herunterladen der Bilder die Verbindung abbricht. Wenn ich dann neu anfange, die Bilder herunter zu laden, geht garnichts mehr. Ich kann dann nur meinen Rechner neu starten und dann ist alles wieder i.O., bis der Rechner dann wieder hängt. Also wieder Rechner neu starten. So geht das immer weiter. Hat jemand noch eine Lösung parat?

 

P.S.: Habe in der Firewall die Ortho-exe noch mal frei gegeben, in der Hoffnung, das es dann funktioniert. Tut es aber nicht.

Ich muss das nochmal aufgreifen:  Ich habe nun festgestellt, das es mit der Firewall und dem Virenprogramm zusammen hängt. Habe nun alles ausgeknipst und kann nun mehrere Kacheln in einem Rutsch erstellen. Warum das so ist, keine Ahnung. Vielleicht hat noch jemand einen Tipp für mich.

Link to comment
Share on other sites

  • 1 month later...

@DaikanHallo Daikan, vielleicht kannst du mir auf die Sprünge helfen: Ich habe mit Ortho4XP zwischen Bonn und Leverkusen diese Probleme mit "use_masks_for_inland=true"

 

Please login to display this image.

Bonn-Oberkassel: Blick nach Süden. Die Darstellung der Wasseroberfläche südlich der Markierung entspricht der "normalen" XPlane-Wasseroberfläche mit Wellenmuster, abhängig von den Wetterbedingungen. Nördlich dieser Stelle ist der Rhein über die Maske eine absolut glatte Fläche, Spiegelungen sind aber aus extremen Winkeln sichtbar. Zwischen Bonn-Oberkassel (+50+007) und Leverkusen-Rheindorf (+51+006) bleibt die Darstellung Wasseroberfläche des Rheins unverändert, bis zu diesem Punkt:

Please login to display this image.

Leverkusen-Rheindorf: Blick nach Norden. Die Darstellung der Wasseroberfläche wechselt wieder auf "Normal".

 

Ich habe verschiedene Dinge erfolglos ausprobiert:

Diverse Korrekturen in OSM hinsichtlich der Wasserflächen (u.a. Entfernung des Rheins aus einer Brücken-Ralation "Kennedybrücke")

Einstellungen Ortho4XP: mask_zl, mask_width, masking_mode, Wechsel Sonny-.hgt-version, unterschiedliche curvature_tol, water_smoothing.

 

Die Masken sind vollständig in /Masks geladen, das Log gibt mir keinen brauchbaren Hinweis, außer dass es früher mal in +50+007.hgt zwei Fehler gibt, Ortho4XP da die Höhe auf 0 gesetzt hatte, aber Schnee von gestern. Ich benutze die aktuelle Ortho4XP 1.30, Script-Version.

Hast du eine Ahnung, was ich falsch mache?

 

 

 

Log.txt

Link to comment
Share on other sites

vor 2 Stunden , Daikan sagte:

Schwer zu sagen ohne die entsprechenden Masken (.PNG) und OSM-Daten aus dem Cache unter OSM_data der jeweiligen Kacheln.

Hier Masks und OSM für +50+007 aus dem Cache. 5504_8512.png ist die Maske für den betroffenen Bereich in Bonn-Oberkassel.

OSM+50+007.7z Masks+50+007.7z

Link to comment
Share on other sites

vor 10 Stunden , Daikan sagte:

Die exakten Koordinaten der unerwünschten Übergänge der Wasseroberfläche wären ebenfalls hilfreich.

Bonn-Oberkassel: https://www.openstreetmap.org/#map=18/50.70440/7.16709

Leverkusen-Rheindorf: https://www.openstreetmap.org/#map=18/51.05421/6.91885

 

Die Übergangsbereiche sind bei mir deutlich als ca.  50-100 Meter breite Zone ausgebildet.

Ich habe die Einzel-Flächensegmente des Rheins zwischen Bonn und Leverkusen in OSM kontolliert. Es gab im Verlauf des Rheins 3, oder 4 Flächen, die zusätzlich zu "natural=water, water=river" auch noch mit "waterway=riverbank" getagt waren, darunter war auch eine Fläche, die aus Südost kommend, den Übergangsbereich in Leverkusen-Rheindorf tangierte. Allerdings war das nicht im Raum Bonn der Fall. "waterwy=riverbank" habe ich letzte Woche aus den betroffenen OSM-Flächen entfernt.

Was mich auch erstaunt: Ich habe nirgends einen Hinweis entdecken können, dass ein anderer User schon einmal über dieses Phänomen gestolpert ist. Das würde darauf hindeuten, dass die Sache nur bei mir entsteht, bzw. ich selbst das Problem bin.

Meine Kacheln (ca. 200) sind alle in ZL16, masks, imprint masks to dds, decals, Sonny-.hgt generiert. Die Kachel +50+007 habe ich in den letzten Tagen mehr als 15x mit unterschiedlichen Ortho-Configs erstellt.

Ich werde jetzt noch einmal die Kachel ohne Sonny-.hgt, im Standard, erzeugen und dann, falls das nichts bringt, auf ZL17 gehen.

Link to comment
Share on other sites

Die Ferranti +50+007.hgt hat nichts gebracht. Anliegend noch einmal ein Shot aus +50.713 +7.1612, also die Stelle in Bonn-Oberkassel. Deutlich zu erkennen, dass die Art des dargestellten Wassers wechselt.

 

Please login to display this image.

 

Link to comment
Share on other sites

  • Deputy Sheriffs
vor 33 Minuten, hmkaiser sagte:

also die Stelle in Bonn-Oberkassel. Deutlich zu erkennen, dass die Art des dargestellten Wassers wechselt.

Das deutet darauf hin, dass das "Wasser" in OSM nicht passt, doch ich hab drüber gesehen, ist alles korrekt dort mit natural=water und water=river getaggt.

 

Ich hatte das Problem 2016, als ich mir alle Kacheln in Europa erstellte, dass Teile eines großen Flusses nicht korrekt als Wassr dargestellt wurde und es lag immer an den Daten in OSM. Nach Korrektur in OSM hat die erzeugte Kachel anschließend gepasst.

 

EDIT: Ich wollte die Kachel eh neu erzeugen, heute Abend kann ich Dir berichten wie es bei der neu erzeugten Kachel aussieht.

Link to comment
Share on other sites

vor 33 Minuten, PilotBalu sagte:

Das deutet darauf hin, dass das "Wasser" in OSM nicht passt, doch ich hab drüber gesehen, ist alles korrekt dort mit natural=water und water=river getaggt.

 

Ich hatte das Problem 2016, als ich mir alle Kacheln in Europa erstellte, dass Teile eines großen Flusses nicht korrekt als Wassr dargestellt wurde und es lag immer an den Daten in OSM. Nach Korrektur in OSM hat die erzeugte Kachel anschließend gepasst.

 

EDIT: Ich wollte die Kachel eh neu erzeugen, heute Abend kann ich Dir berichten wie es bei der neu erzeugten Kachel aussieht.

Bin mir auch sicher, dass es an OSM liegen muss. Der Rhein ist an den Stellen noch mit allerlei zusätzlichen OSM-Elementen ausgestattet. Im Bereich Bonn-Oberkassel gibt es z.B. eine innere Fläche "seamark_type=fairway", dazu genau an der Stelle eine "route=boat", alles allerdings älteren Datums. Dazu sind Einzel-Nodes im "waterway=river" auch noch mit allerlei "seamark:XYZ..."-Informationen getagt. Ich hatte da schon probehalber Nodes mit "seamark:XYZ..." aus dem waterway entfernt, sprich daneben gesetzt.

In Leverkusen-Rheindorf ist die Situation etwas anders, weil genau in dem Beritt zwei Flächen "natural=water, water=river" aneienander stoßen, dazu gibt es aber in jeder der beiden "natural=water"-Flächen am linken Rheinufer eine Fläche "leisure=nature_reserve", die sich bis zur Flussmitte des Rheins erstreckt. Die sind erst in 2019, bzw. 2021 erfasst worden. Außerdem ist mir aufgefallen, dass einer Fläche "boundary=protected_area" fehlt. Wird mir jetzt erst so richtig deutlich, dass diese "leisure=nature_reserve" einen genaueren Blick verdienen.

 

Trotzdem, ich lasse die Hackerei in OSM erstmal sein und warte auf dein Ergebnis.

Link to comment
Share on other sites

34 minutes ago, Frithjof said:

Kann es eventuell am Ortho selbst liegen. Er legt bei "Mask for inland" ja das Ortho mit unter das Wasser.

 

Nein, das gilt nur wenn masks_for_inland=False ausgewählt wurde - was hier aber ausdrücklich nicht der Fall zu sein scheint. Und ausserdem fehlt ja gemäss weiterer Aussage der Wassereffekt komplett, was darauf hindeutet, dass hier Ortho4XP kein Wasser in OSM "erkannt" hat.

Link to comment
Share on other sites

vor 14 Minuten, Frithjof sagte:

Kann es eventuell am Ortho selbst liegen. Er legt bei "Mask for inland" ja das Ortho mit unter das Wasser.

Kann nicht sein, generiere mir alle Kacheln mit Mask_for_inland=True

vor 28 Minuten, Daikan sagte:

Nein, das gilt nur wenn masks_for_inland=False ausgewählt wurde - was hier aber ausdrücklich nicht der Fall zu sein scheint. Und ausserdem fehlt ja gemäss weiterer Aussage der Wassereffekt komplett, was darauf hindeutet, dass hier Ortho4XP kein Wasser in OSM "erkannt" hat.

 

Nein, Wasser ist schon da, die Art der Darstellung des Wassers ändert sich. Sturm gepeitschte See wechselt über einen breiteren Übergang auf Badewannen-Wasser. Es gibt auch Spiegelungen auf dem Badewannen-Wasser, allerdings scheint dieses Wasser in "Schmalspur" generiert worden zu sein.

 

Und zwischen Bonn-Oberkassel und Leverkusen-Rheindorf gibt es Unterschiede. Wird mir jetzt erst richtig deutlich in Leverkusen-Rheindorf +51.054 +6.9198:

Please login to display this image.

Die im Rhein deutlich abgesetzte Grenzlinie setzt sich über Land auf beiden Seiten fort: Den da entstehenden Land-Flächen fehlen die Decals auf den Orthofotos. Ist eindeutig. Der Verlauf der Grenzlinie scheint zufällig, in OSM gibt's jedenfalls nichts, was das verursachen könnte. Links, schwarzer Pfeil, Fläche mit Decals, rechts davon die Landflächen, roter Pfeil, ohne Decals. Versuche das gerade mal zu überblicken, aber es sieht so aus, als wären alle Gewässer innerhalb der Decal-freien-Zone Badewannen, außerhalb davon peitscht der Wind die Wellen.

Es hilft nichts, diese Macke mit der Kachel +51+006 kann definitiv nur auf oder vor meinem Rechner sein. Ortho4XP läuft als Scriptversion, Stand Juni 2019, abgesetzt unter Linux. Muss mal gucken, ob da noch irgendwo etwas gecacht wird (außer in den Unterverzeichnissen von Ortho4XP), bzw. die Ortho4XP-Installation genau prüfen. Irgendwann hatte ich mal etwas mit nvcompress ...

 

 

Link to comment
Share on other sites

  • Deputy Sheriffs

Hab Kachel +50+007 neu erzeugt, (wie erwartet) alles gut bei mir! 😀 Ich kann hier leider aktuell keinen Screenshot posten. Ich kann dir gerne die O4XP-Dateien schicken, wenn du mir ne kurze Mail schreibst.

 

Ich bin den Rhein von Mannheim bis Köln abgeflogen, außer einem Campingplatz der bei Mainz über den Rhein geht, 🤔 ist alles super! 👍

 

Link to comment
Share on other sites

vor 37 Minuten, Frithjof sagte:

Hast du da vielleicht eine Szenerie am laufen die noch ein Ortho mit bringt?

Definitiv nicht.

 

vor 10 Minuten, PilotBalu sagte:

Hab Kachel neu erzeugt, (wie erwartet) alles gut bei mir!

Danke dir! Dann ist klar, dass bei mir etwas faul sein muss.

 

vor 11 Minuten, PilotBalu sagte:

Ich kann dir gerne die O4XP-Dateien schicken, wenn du mir ne kurze Mail schreibst.

Auch dafür vielen Dank! Allerdings wäre das der letzte Reißaus. Ich muss wissen, wo das Problem liegt.

 

Bin gerade wieder an der Kachel +51+006: Da ist es mir erst nach 2 Stunden gelungen, die OSM-Daten fehlerfrei zu bekommen. Praktisch jede OSM-Einzelanfrage wird mehrfach rejected und auch geskippt. Da lauert der Teufel im Unterholz.

Link to comment
Share on other sites

Problem gelöst: Es lag an meiner eigenen Dämlichkeit.

 

Ursächlich ist die AS-EDDK-Scenery. Die bringt ihren einen eigenen Ortho- und Mesh-Layer mit. Den Mesh-Layer hatte ich wohl in 2019 ausgeknipst, aber im EDDK-Config-Tool die Einstellung Anzeige "Ortho inkl. Surroundings" auf ON belassen. Erschwerend kam hinzu, dass in dem Config-Tool die Ortho-Qualitätsstufe nur auf "mittel" stand. Der Sache bin ich erst auf die Spur zu kommen, nachdem wirklich alle Ortho-Kacheln aus custom scenery entfernt waren. Und auch dann habe ich erst noch den ganzen PC umgekrempelt, bevor ich auf den Trichter kam, AS-EDDK unter die Lupe zu nehmen. Mir ist es überhaupt nicht in den Sinn gekommen, dass die AS-EDDK-Orthos so eine große Fläche überspannen.

Haut natürlich gewaltig in die Kerbe: Man sollte auch mal einen Blick ins Handbuch werfen ...

Übrigens: Der Rhein sieht heute in Bonn-Oberkassel und Leverkusen-Rheindorf richtig klasse aus.

 

Sorry, dass ich euch mit diesem Kram behelligt habe.

Link to comment
Share on other sites

  • 1 month later...

Ich versuche grad krampfhaft die Python Variante von Ortho4XP 1.30 zum korrekten Laufen zu bewegen. 

Windows 10 64bit

Python 3.75 ist installiert und auch die 6 dazu gehörigen plugins inkl GDAL 3.3.2

pip install gdal sagt auch aus das gdal 3.3.2 installiert sei. 

 

Trotzdem bekomme ich bei Auswahl von NED 1 die Meldung unsupportet Raster (install GDAL)

 

Bei der Binary Version funktioniert alles. Wo ist mein Fehler? 

 

Link to comment
Share on other sites

Bitte den *markierten* Text genau gelesen. Die PATH Umgebungsvariable muss ggf. manuell so angepasst werden, dass auf der Kommandozeile die Befehle "gdal_translate" und "gdalwarp" gefunden werden. Beispiel: Wenn Python unter C:\Python37 installiert wurde, dann muss der Pfad C:\Python37\lib\site-packages\osgeo an die PATH-Umgebungsvariable angehängt werden, wobei ein Semikolon als Trennzeichen zwischen verschiedenen Pfaden dient. Kenntnis darüber, wie man die Umgebungsvariablen unter Windows editiert, wird dabei als Grundvoraussetzung betrachtet. Wenn das nicht gegeben ist - Google hilft.

 

Link to comment
Share on other sites

und hier rufe ich einfach mal gdalinfo mit der Versions Nummer direkt aus dem Ortho4XP Verzeichnis auf. Das klappt ja seltsamerweise.

 

Please login to display this image.

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