Fehlerhafte Standardscenery korrigierbar?

[Lexif]

Ob hier nun ein Addon aktiv ist oder nicht, die Frage ist doch was hier an der falschen Stelle ist -- der Fluss oder der Flugplatz.

Ich habe mir den Platz mal im FS mit Ultimate Terrain Europe angeschaut und mit Google Earth verglichen. Die Bahn scheint ziemlich gut an der richtigen Stelle zu liegen (Grasbahnen sind ja nicht unbedingt so in den Flughafendaten enthalten und können sich ja auch verändern). Hier ein Bild:



Die Gewässer, Straßen, die Eisenbahnlinie und der Golfplatz kommen von UT Europe. Die Landclass ist von Frank Barth.



EDIT: SORRY!! Ich habe grade erst gesehen, dass bereits vorher schon gezeigt wurde, dass der Fluss nicht aus der Standardszenerie ist, mein erster Absatz ist also überflüssig.

[JOBIA]

Zur Info diese Rasenpolys um die eigentliche Runway drum herum haben nichts mit AFCAD kompatiblen Code zu tun. Es handelt sich bei diesen Rasenflächen um VTP Polygoncode der in ganz anderen BGL Files abgelegt ist.

Möchte man diese auch manipulieren muss man zusätzlich zu AFCAD mit Tools wie z.B Ground2K arbeiten.


Es gibt wenige Airports im FS2004 die hat Microsoft falsch positioniert. Sie haben Koordinaten die sich nicht auf das geodätische Datum WGS84 beziehen als WGS84 Koordinaten ausgelegt. In einigen Airportkartenwerken in Deutschland findet man auch das geodätische Datum ED50 legt man das als WGS84 aus passt es nicht mehr.

Dieser Fehler den Microsoft selten begangen hat, kann man eindeutig nachweisen.

Ich vermute hier aber auch eher das dieser vermutliche Addon Fluss falsch liegt . (was natürlich zu klären ist)

[sternhagel]

Hallo Leute,
vielen Dank für Eure Hilfe!
Am liebsten wäre mir natürlich ein Lösungs-Zweizeiler gewesen, aber jetzt weiss ich zumindest, dass man was machen kann. Mein nächster Schritt wäre nämlich gewesen, diesen kleinen Platz (der mir sehr am Herzen liegt) etwas auszubauen. Dafür wäre die jetzt fällige Arbeit mit den diversen Tools ohnehin nötig gewesen...

Nochmal vielen Dank!
Mal sehen, wie weit ich komme ;-)

Grüsse, Fred

[cpsassen]

Original geschrieben von JOBIA

Landclass Dateien haben rein garnichts mit Grasrunways von Airports oder diesem gezeigten VTP Linienfluss zu tun.

Mit dieser Aussage hast Du sicher recht.
Ich habe mich da auch etwas unglücklich und laienhaft ausgedrückt, da ich als ausgewiesener "Nichtszenerieexperte" alle Basisszenerieelemente wie Landklassen, VTP-Polygone, VTP-Strassen u.s.w. , die man mit dem gleichen Szenerieprogramm (das bereits erwähnte ground2k4) erstellen bzw. bearbeiten kann, immer in einen Topf schmeiße.

Original geschrieben von JOBIA

Landclass ist also bei diesem Problem komplett außen vor und hat mit dem Fehlerbild nichts zu tun.

Das stimmt so nicht. Wenn Du jetzt schon so genau bist, dann bemühe ich mich es auch zu sein.
Wenn man die geposteten Bilder von Erich (Standardszenerie), Lexif und Fred vergleicht, kann man m.E. eindeutig erkennen, dass hier 3 verschiedene Landclass-Dateien den Untergrund bestimmen. Standard-LC, Frank Barth-LC und ?????-LC.

Diese unbekannte LC-Datei befindet sich vermutlich mit der VTP-Datei, die die geänderte Lage des Flusses bestimmt in einem gemeinsamen Szenerieordner.
Der Airportuntergrund hingegen erscheint mir nach Vergleich der 3 Screenshots nicht von der Standard_Szenerie abzuweichen.

Mit dem von Dir geschilderten Verfahren sollte der Fehler allerdings einzukreisen sein

Claus-Peter

[JOBIA]

Wegen meiner alten Aussage:

"Landclass ist also bei diesem Problem komplett außen vor und hat mit dem Fehlerbild nichts zu tun"

und Deiner Reaktion darauf:

Original geschrieben von cpsassen

Das stimmt so nicht. Wenn Du jetzt schon so genau bist, dann bemühe ich mich es auch zu sein.
Wenn man die geposteten Bilder von Erich (Standardszenerie), Lexif und Fred vergleicht, kann man m.E. eindeutig erkennen, dass hier 3 verschiedene Landclass-Dateien den Untergrund bestimmen. Standard-LC, Frank Barth-LC und ?????-LC.
Claus-Peter

Meine Aussage ist korrekt. Sicherlich kommen hier verschiedene Landclassfiles zur Anwendung, da gebe ich Dir recht. Nur es ging hier um die Problematik dass der Fluss das Airportrasenpoly / Grasrunway schneidet, nicht um irgendeine Bodentexturoptik.

Damit haben die verschiedenen Landclass Files rein garnichts mit dem Hauptproblem zu tun.

Deshalb habe ich das erwähnt.

Denn es hat sich so angehört, als wenn man nur das Landclassfile ermitteln muss, welches diese Optik erzeugt, dann hat man den Fehler Scenery Kandidaten. Dem ist aber nicht so, da das Landclassfile mit dem Problem nichts zu tun hat.

Auch werden Landclassfiles die zu ein und dem selben Addon gehören speziell wegen des Speicherlecks oft von anderen Scenerien dieses Addons die z.B VTP Polys enthalten können getrennt. Von daher ist die Chance zu gering.


Da bei Landclass auch fast immer mit der Transparenz LC 254 in einem LC File gearbeitet wird, wäre selbst wenn man die LC Scenery des Addon ausfindig macht welches diese Bodentextur Optik im Umfeld des Airports erzeugt noch lange nicht gewährleistet, das von diesem Addon auch VTP Poly oder ev. der Fluss stammt.

Ich wollte nur verhindern, dass hier jetzt in die falsche Richtung gesucht wird.

[hagru]

Hallo,

mit Ground2k kann man ein default-Flugplatz-"Grundstück" überdecken, wenn man dem neuen Rasenpolyglon eine hohen Level, z.B. 24, zuweist.

[JOBIA]

Zu

Original geschrieben von hagru
Hallo,

mit Ground2k kann man ein default-Flugplatz-"Grundstück" überdecken, wenn man dem neuen Rasenpolyglon eine hohen Level, z.B. 24, zuweist.

Oder aber in dem man das neue Rasenpoly in dem Layer des Default Polys erstellt und hier gleich die Excludefunktion mit aktiviert.

Ist dann nur ein Byte im Code welches gesetzt wird und schon wird das Default Poly deaktiviert.




Das hat gegenüber Deiner Variante zwei Vorteile.

1) Man hält sich an die Vorgabe Layerstruktur von Microsoft.

Das kann nämlich sehr wichtig sein, wenn ein Addon wie z.B AROE oder was auch immer an so einen Airport eine real existierende VTP Zufahrtsstraße heranführen will.

Ist diese nämlich in einem niederen Layer wovon man ausgehen kann, dann endet die abrupt an Deinem neuen Rasenpoly. Sie erreicht also den Airport optisch überhaupt nicht mehr.


2) Es kann ja sein, dass so ein neues Rasenpoly weil es reale Flächen haben soll ev. kleiner als ein vorhandenes Rasenpoly ist oder die Flächen zumindest nicht deckungsgleich sind.

Dann sieht man bei Deiner Lösung beide flächenmäßigen Polyanteile.

Selbstverständlich das mit höherer Priorität oben.



Von daher wäre meine Lösung die sichere, wenn man denn überhaupt ein neues Poly erstellen möchte.


Ich denke sinnvoller wäre es hier erst mal zu kontrollieren, was wirklich falsch ist. Wenn man das ermittelt hat, zu ermitteln wo das Falsche her kommt. Erst dann sollte man handeln.

[hagru]

Hier meine Bearbeitung des Falles:

http://img522.imageshack.us/img522/1241/edspbd0.jpg

Wo der Fehler lag, ist mir klar geworden, als ich die Default-Koordinaten des Flugpaltzes aus AFCAF mit denen aus Google-Earth verglichen habe. Der Default-Flugplatz ist nämlich um ca. 280 m in etwa 070° gegenüber GE verschoben. Wenn Sternhagel dann ein Addon hat, in dem der Fluss nach GE ausgerichtet ist, kommt es zu dem beschrieben Konflikt.

[JOBIA]

ZU

Original geschrieben von hagru
Hier meine Bearbeitung des Falles:

http://img522.imageshack.us/img522/1241/edspbd0.jpg

Wo der Fehler lag, ist mir klar geworden, als ich die Default-Koordinaten des Flugpaltzes aus AFCAF mit denen aus Google-Earth verglichen habe. Der Default-Flugplatz ist nämlich um ca. 280 m in etwa 070° gegenüber GE verschoben. Wenn Sternhagel dann ein Addon hat, in dem der Fluss nach GE ausgerichtet ist, kommt es zu dem beschrieben Konflikt.

Dann würde vermutlich diese Aussage von mir zutreffen:

"Es gibt wenige Airports im FS2004 die hat Microsoft falsch positioniert. Sie haben Koordinaten die sich nicht auf das geodätische Datum WGS84 beziehen als WGS84 Koordinaten ausgelegt. In einigen Airportkartenwerken in Deutschland findet man auch das geodätische Datum ED50 legt man das als WGS84 aus passt es nicht mehr.

Dieser Fehler den Microsoft selten begangen hat, kann man eindeutig nachweisen."

Ich denke ich schaue jetzt spaßhalber mal selbst wirklich nach.

[JOBIA]

Leider ist in meinen digitalen Kartenwerken die Runway selbst nicht eingezeichnet. Da steht nur Sportflugplatz ohne genau Koordinate.
Auf jeden Fall kann man aber folgenden Sachverhalt nachweisen.

Wenn man die FS Koordinate in den digitalen Kartenwerken als Ref Point nimmt und diese Koordinate auf das geodätische Datum ED50 bezieht, wandert der Aiport weg von dem Fluss Rott.

Legt man diese FS Koordinate aber als WGS84 aus wandert er in Richtung Fluss Rott, was diese Problematik bestätigt. Microsoft scheint auch hier wie bei einem anderen süddeutschen Airport das geodätische Datum falsch ausgelegt zu haben.

Der Aiport selbst ist also falsch definiert.

Der Addon Fluss scheint richtig zu sein.