Jump to content

Daikan

Members
  • Posts

    442
  • Joined

  • Last visited

Everything posted by Daikan

  1. 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.
  2. Die exakten Koordinaten der unerwünschten Übergänge der Wasseroberfläche wären ebenfalls hilfreich.
  3. Schwer zu sagen ohne die entsprechenden Masken (.PNG) und OSM-Daten aus dem Cache unter OSM_data der jeweiligen Kacheln.
  4. In dem Fall muss es wohl ein anderes Objekt sein. Dazu wäre es hilfreich, dessen exakte Position zu kennen.
  5. Das sieht eigentlich gut aus. Könnte also sein, dass dies überhaupt nix mit X-Europe zu tun hat und die Objekte von einer anderen Szenerie stammen...
  6. Bei mir leuchten die nicht. Muss wohl daran liegen, dass das Objekt in deinem Fall sowohl eine TEXTURE als auch eine TEXTURE_LIT Anweisung enthält, welche beide die gleiche Textur referenzieren - wieso auch immer. Häng mal folgende Datei an: simheaven_X-Europe-4-scenery/objects/landmarks/silo_5m.obj
  7. Das ist ein relativ selten genutztes Attribut, das weit davon entfernt ist, ein Höhenmodell zu sein. Zudem gibt es kein Werkzeug, das imstande wäre, diese Information in ein für X-Plane nutzbares Format zu bringen - weder für Strassenprofile noch für das Mesh. In W2XP könnte man damit höchstens Elemente filtern. Darüberhinaus ist in der OSM-Datenbank kein Höhenmodell "hinterlegt" bzw. verknüpft, weder SRTM noch sonstwas. Einige OSM-Kartenapplikationen blenden lediglich ein von SRTM-abgeleitetes Höhenmodell als visuelles Hilfsmittel ein (z.B. als Höhenkurven oder Graustufen-Raster). Die Werte für die ele=* Attribute müssen anderweitig ermittelt werden und haben mit SRTM erstmal nichts zu tun.
  8. OSM kennt kein Konzept eines "Höhenmodells". Alles ist 2D.
  9. Nein, das spielt hier keine Rolle. Das Problem ist, dass X-Plane's Logik hinsichtlich Sockelung nicht wirklich im Detail bekannt ist, da die Dokumentation des .net Fileformats nur einen winzigen Teil abdeckt und somit das Ganze mehrheitlich eine "Blackbox" ist - man kann also nur mutmassen, experimentieren und Reverse-Engineering betreiben... so ähnlich wie das dazumals Tony Wroblewski mit W2XP versucht hat - was ja nach all den Jahren bisher immer noch das einzige, öffentlich nutzbare Szenerie-Werkzeug weit und breit ist, das halbwegs brauchbare Strassen automatisiert aus OSM erzeugen kann. Das zeigt m.E. sehr gut auf, dass es keine einfache Aufgabe ist, das .net Format zu verstehen, sodass sich damit sinnvolle DSF's generieren lassen... Kommt noch dazu, das W2XP selber ja auch eine Blackbox ist, da der Quellcode nicht öffentlich ist... Somit können wir auch nur Vermutungen anstellen, wie die OSM-Daten zu DSF-Kommandos konvertiert werden....
  10. Klar. Einfach beachtem, dass X-Plane-spezifische Modifikationen eigentlich nichts in der offiziellen OSM-Datenbank zu suchen haben, es sei denn, die Änderungen sind vereinbar mit den allgemeinen OSM-Kartographie-Standards und -Richtlinien. Das Hinzufügen von zusätzlichen Knotenpunkten, nur um ein besseres, vertikales Strassenprofil in X-Plane hinzukriegen, gehört da ganz klar nicht dazu.
  11. Würde ich so nicht unterschreiben, denn jeder Knotenpunkt kostet auch CPU und vermutlich verwirft X-Plane irgendwann die Segmente sofern zwei Knoten einen gewissen Mindestabstand unterschreiten... Zudem ist kein Mesh perfekt und somit kann eine künstliche Glättung durchaus zu einem realistischeren/plausibleren Gesamtbild führen, als wenn exakt dem Meshprofil gefolgt wird....
  12. Das liegt vermutlich daran, dass X-Plane ungültige Segmente verwirft - kommt bei Strassen, welche durch W2XP aufgrund von unbereinigten OSM-Rohdaten erzeugt wurden, relativ häufig vor und kann anhand von Meldungen im log.txt wie z.B. der folgenden erkannt werden: 0:01:50.140 E/DSF: The DSF Custom Scenery/simHeaven_X-Europe-7-network/Earth nav data/+40+010/+46+010.dsf has a number of problems with its road network: 70 doubled nodes, 1 direction reverses, 0 short segments, 18 roads deleted.
  13. Es kann auch bei gekrümmtem Verlauf vorkommen, dass Knotenpunkte bereinigt wurden. Oder es kann auch an Änderungen am Mesh liegen. Oder du nutzt nicht die X-Europe Strassen, sondern den X-Plane Standard. Ohne exakte vorher/nachher Screenshots/Log.txt und exakte Koordinaten dürfte es aber eher schwierig sein genaueres zur Ursache zu sagen. Zur Info: X-Plane verfügt über eine eingebaute "Sockel-Logik", die gewisse Höhenunterschiede zwischen zwei Knotenpunkten ausgleicht. Mehr dazu: https://forums.x-plane.org/index.php?/forums/topic/143337-road-elevation-issue/ - vermutlich ist das auch abhängig vom Strassentyp gemäss roads.net bzw. dem Wert des highway-Schlüssels in OSM.
  14. Das liegt vermutlich daran, dass "unnötige" Knotenpunkte auf der gleichen Geraden "bereinigt" wurden - entweder in OSM selber oder durch das Preprocessing.
  15. 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. 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 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...
  16. Vielleicht noch eine allgemeine Anmerkung um allfälligen Missverständnissen vorzubeugen: Die Ordner (und auch Kacheln) sind immer nach den Koordinaten der südwestlichen "Ecke" benannt. Deshalb Vorsicht bei negativen Breiten und/oder Längen, denn das kann dort verwirren. Beispielsweise kommt eine Datei wie S45W005.hgt (oder bei Szenerien -45-005.dsf) in den Unterordner -50-010 zu liegen, und nicht etwa in "-40-000" wie man vielleicht aufgrund der angebenen Beispiele denken könnte...
  17. 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.
  18. Es existiert kein Schritt namens "ConvertDDS". Es reicht aber die Custom ZL Zone(n) zu definieren, diese zu speichern ("Apply" + "Exit" + Config -> "Write tile cfg") sowie den letzten Schritt (Build imagery/DSF) auszuführen. Dabei sollten die Config-Parameter "skip_downloads" und "skip_converts" beide auf "False" sein.
  19. Nein, die PNG sollte man nicht löschen - diese werden zur Maskierung der Orthotexturen über Gewässer/Meer verwendet.
  20. Wenn das Problem bei anderen Quellen ebenfalls auftritt dann liegt es mit ziemlicher Sicherheit an der schlechten Qualität der Internetverbindung.
  21. Entweder sind deine *.mesh Dateien korrupt (evt. ein Hardware-Problem?) oder es handelt sich um einen Bug in der .exe Version von Ortho4XP. Ein sehr ähnliches Problem wurde hier gemeldet und ich konnte es nur mit der .exe Version reproduzieren - mit der Skript-Variante lief das bei mir problemlos durch. Auch +50+011 und +49+012 laufen bei mir mit der Skript-Variante fehlerfrei durch, allerdings habe ich die Default-Einstellungen genommen (uns hast du deine Einstellungen bisher leider vorenthalten). Grundsätzlich empfehle ich wenn möglich die Skript-Variante ab Github zu installieren, denn diese hat einige Bugfixes gegenüber der .exe (die schon etwas älter ist).
  22. Das ist jetzt aber eine ganz andere Kachel und auch eine andere Fehlermeldung. Was ist mit +49+012?
  23. Was wurde im Hauptfenster ausgegeben? Irgendwelche Fehlermeldungen beim Erstellen des Meshs in Schritt 2?
  24. Ich denke die allerwenigsten wissen, dass X-America überhaupt angedacht ist, geschweige denn, dass zur Mitarbeit aufgerufen wird... Ich hab mal auf der .org beiläufig ein bisschen "Werbung" gemacht: https://forums.x-plane.org/index.php?/forums/topic/133095-houses-w2xp-vs-x-plane/&do=findComment&comment=2054867 Das Ganze wäre zudem sicherlich einen eigenen Topic im Scenery Development Forum wert.
  25. Schade... wo ich mir doch extra für die 4.6 am 19.5. die Mühe gemacht hatte, einige freihängende Skilift- und Seilbahnkabel zu "reparieren".... https://www.openstreetmap.org/user/d41k4n/history#map=12/46.7863/9.5361 Vielleicht kann man für die Kachel +46+009 eine kleine Ausnahme machen?
×
×
  • Create New...