Jump to content

Ortho4XP


Recommended Posts

Danke Daikan, ich hatte den Post auf dem Tablet getippt und das Programm nicht gestartet, deshalb die falsche Bezeichnung, natürlich meinte ich Build imagery/DSF. Die Lösung könnte tatsächlich Wrtite tile cfg sein, denn ich habe festgestellt, dass am Folgetag, wenn ich mit dem Verfeinern weitermachen will, die Custom ZL weg waren und ich alles nochmal neu anklicken musste, was ich gestern vorgegeben habe. Also kurz und gut! ich probiere es gleich aus. Herzlichen Dank für die schnelle Antwort.

 

Was ich auch probiert habe, im zOrtho4XP_+a-b-Ordner die beiden Unterordner terrain und textures zu löschen und mit dem Schritt Build imagey/DSF im Hauptprogramm zu starten. Hat prima geklappt, da ich die jpgs im  Ordner Orthophotos nie lösche. 

Link to comment
Share on other sites

32 minutes ago, Vollgas said:

 

Was ich auch probiert habe, im zOrtho4XP_+a-b-Ordner die beiden Unterordner terrain und textures zu löschen und mit dem Schritt Build imagey/DSF im Hauptprogramm zu starten. Hat prima geklappt, da ich die jpgs im  Ordner Orthophotos nie lösche. 

 

Das ist eigentlich unnötig und bringt nur etwas, falls die Config-Parameter in den Abschnitten "Vector data" und/oder  "Draw water masks" bzw. deren Datenquellen (OSM, Extents) geändert haben und/oder wenn die JPGs manuell nachbearbeitet wurden.

Link to comment
Share on other sites

Hallo Zusammen,  habe gehört, dass der GO2 Serverdienst ab einer bestimmten Datenmenge die Adresse sperrt. Weiss wer vielleicht die Größe im MB pro Tag, die noch keine Probleme bereitet?

 

Viele Grüße 

Vollgas 

Link to comment
Share on other sites

vor 1 minute, Vollgas sagte:

Hallo Zusammen,  habe gehört, dass der GO2 Serverdienst ab einer bestimmten Datenmenge die Adresse sperrt. Weiss wer vielleicht die Größe im MB pro Tag, die noch keine Probleme bereitet?

 

Ich habe schon über mehrere Tage Orthos generiert und wurde nicht begrenzt.

Vielleicht ist das abhängig davon, ob man bei Google angemeldet ist oder nicht.

 

Gruß Horst

Link to comment
Share on other sites

8 hours ago, Vollgas said:

Hallo Zusammen,  habe gehört, dass der GO2 Serverdienst ab einer bestimmten Datenmenge die Adresse sperrt. Weiss wer vielleicht die Größe im MB pro Tag, die noch keine Probleme bereitet?

 

Das wird dir vermutlich nur ein eingeweihter Google-Mitarbeiter sagen können, wenn sie/er überhaupt so naiv ist, dies (öffentlich) preiszugeben und es überhaupt eine solche (konstante) Limitierung gibt.

 

Dabei ist zu beachten, dass die systematische Art und Weise, wie Ortho4XP den Dienst "abgrast" (Scraping) eigentlich illegal ist und von Google nur so lange "geduldet" wird, bis das nicht weiter stört. Der verwendete Dienst ist eigentlich in erster Linie nur dafür gedacht, um eine anonyme, interaktive, öffentliche Nutzung von https://maps.google.com über einen normalen, Javascript-fähigen Browser zu ermöglichen. Es ist ganz klar nicht erlaubt, diesen Dienst ausserhalb dieses Kontexts zu nutzen.

 

Siehe:

https://cloud.google.com/maps-platform/terms#3.-license.

 

 

Quote

(a)  No Scraping. Customer will not export, extract, or otherwise scrape Google Maps Content for use outside the Services. For example, Customer will not: (i) pre-fetch, index, store, reshare, or rehost Google Maps Content outside the services; (ii) bulk download Google Maps tiles, Street View images, geocodes, directions, distance matrix results, roads information, places information, elevation values, and time zone details; (iii) copy and save business names, addresses, or user reviews; or (iv) use Google Maps Content with text-to-speech services.

 

(...)

 

(e) No Use With Non-Google Maps. To avoid quality issues and/or brand confusion, Customer will not use the Google Maps Core Services with or near a non-Google Map in a Customer Application. For example, Customer will not (i) display or use Places content on a non-Google map, (ii) display Street View imagery and non-Google maps on the same screen, or (iii) link a Google Map to non-Google Maps content or a non-Google map.

 

Das gilt auch mehr oder weniger für die meisten anderen Dienste, welche globale Orthophotos anbieten und in Ortho4XP eingebunden sind.

 

Also, den Ball schön flach halten und verantwortungsbewusst handeln :)

 

8 hours ago, Flightrookie said:

Vielleicht ist das abhängig davon, ob man bei Google angemeldet ist oder nicht.

 

Das ist gänzlich irrelevant. Die Anfragen, welche Ortho4XP an den Server schickt enthalten keinerlei Daten, die eine zweifelsfreie Assoziation mit deinem Google-Konto ermöglichen würden. Der Server sieht einzig die IP deines Routers/Proxys aber von dieser allein lässt sich kein eindeutiger Rückschluss auf ein Google-Konto herstellen...

  • Like 1
Link to comment
Share on other sites

Hallo Daikan,

 

herzlichen Dank für diese sehr verständlichen Worte, nun weiß ich jedenfalls Bescheid. Fazit, "verantwortungsbewusst handeln" sollte hier der richtige Hinweis sein.

 

Und wenn man auf der ganz sicheren Seite sein möchte, dann löscht man einfach das Programm Ortho4XP.

 

Viele Grüße

Vollgas

 

 

Link to comment
Share on other sites

  • 3 weeks later...
On 16.4.2021 at 12:27, Coverdale sagte:

Ja, ich habe mich in den letzten 3 Wochen mit Ortho4XP beschäftigt und schon etliche Kacheln erzeugt. Ist nur ärgerlich, das ich dadurch den Rechner nicht über Nacht laufen lassen kann. Auf ein Problem mit der Firewall bin ich gekommen, weil mir mein Virenprogramm dazu eine Meldung gegeben hat. Habe mir die Ereignisprotokolle mal angesehen, sind etliche Warnungen und Fehler drin, wo ich mal sehen muß, woher sie kommen. Hatte gestern zu wenig Zeit dafür.

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

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"

 

Bonn-Oberkassel.thumb.jpg.58c77baced75ac476d2d943e314800ac.jpg

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:

Leverkusen-Rheindorf.thumb.jpg.f958e48bab68e6e99ee0c086bc78716c.jpg

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 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.

 

OberkasselFerranti.thumb.jpg.25d1754d78b6b0b6abbb6b8c3777038d.jpg

 

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:

RheindorfDecals.thumb.jpg.1f660c6638add100f148238f3074dcd0.jpg

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

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
 Share

×
×
  • Create New...