Joachim,
Also das Demo Projekt und Terrain schaffe ich derzeit nicht.
Ich muss jedoch noch die verwendeten Bitmaps (die beigelegt sind) abändern, vielleicht funktioniert dies dann fehlerfrei.
Vielleicht verursachen solche Bitmaps Fehler.
Auch das TerraScene Bitmap muss ich noch probieren.

Wollte eigentlich nur hinweisen, dass die beigelegten Inc Dateien veraltet sind. Hier gibt es einen neue Version von TDFMacros:
http://library.avsim.net/search.php?...zip&CatID=Root

Horst

@Holger
Bezüglich verschiedenen Mesh, habe ich Joachims Foto wieder gefunden auf meinem PC.
Ich hoffe er hat nichts dagegen, wenn ich dies noch einmal anhänge.
Dies ist schon ein Problem auf engen Raum.

Horst

Tachchen!

Habe gerade meine Jungfernfahrt mit Autoasm (v1.00, December 20, 2003 6:33:32 PM) hinter mich gebracht.

Also, wenn ich die obigen Texte richtig verstanden habe, geht es um:

1. ungewuenschte LWM Polys beim kompilieren der Beispiele
2. die hohe Anzahl der Punkte bei den VTP2-Linien

Zunaechst habe ich erst mal Autoasm eigestellt mit den Ordnern:
F:\AutoAsm
F:\Program Files\FS2004\Addon Scenery\aaa Autoasm test scenery\scenery
F:\AutoAsm\terrain
F:\Program Files\FS2004

Diese Einstellung habe ich in autoasm.ini uebertragen und gespeichert, damit ich nicht fuer jedes Projekt neu Ordner einstellen muss.

Ansonsten hatte ich nur Schwierigkeiten mit der VTP Generierung von ts_demo, wo mir zunaechst ein Speicherfehler (#7) in die Quere kam. Habe dann aber in einer Avsim-Diskussion den Tip gelesen, die Memory-Einstellung zu erhoehen; bei mir musste ich von 100,000 auf 5,000,000 erhoehen, um ts_demo erfolgreich abzuschliessen: http://forums.avsim.net/dcboard.php?...6520&mode=full


Meine Ergebnisse:

Die 'circle' Demo fuehrt zu zwei zusaetzlichen kleinen LWMs am unteren Rand der LOD8 Zellen rechts unten und links oben.

Die 'ts_demo' Demo generiert keine (!) zusaetzlichen LWMs, allerdings fehlt eine LOD13 Area im westlichen Arm des grossen Sees.

Zu den VTP-Linien von 'ts_demo' kann ich nur sagen, dass zum einen die Strassendichte schon ganz nett ist, die Strassen selber aber eher wie eine Studie von Dali aussehen (siehe angehaengtes Bild) - oops, war das jetzt genoergelt? :rolleyes:

Wenn das Eingabe .bmp so genau ist, frage ich mich, wieso so viele Strassen unverbunden bleiben? Und dass die so krakelig aussehen, haengt wohl mit der 1:1-Umsetzung der Punktdichte zusammen? Na ja, vielleicht laesst sich da mit verschiedenen Einstellungen oder Linientypen mehr herauskitzeln. Ist also nur eine vorlauefige Beobachtung.

Die Seeufer-VTPs scheinen etwas konsistenter generiert als in "Strip" (habe allerdings Strip noch nicht mit ts_demo.bmp getestet), sind aber recht schmal und oft zu weit im Wasser oder landeinwaerts (die Breite kann man aber vor der VTP-Generierung aendern).

Soviel fuers Erste.

Horst, besten Dank fuer das angehaengte Bild des Mesh-Mosaiks. Sehr interessant; jedenfalls muesste man sich beim Einsatz von Strip auf einen Rohdatensatz festlegen, es sei denn man nutzt Jim's tmfdecompress.exe, um sich da (illegal) selber eine Kombi-Mesh zurechtzubasteln.

Habt ihr uebrigens schon die Meshdarstellung der neuen LWMViewer-Version gesehen? Sehr nett! Ich habe Jim noch ein paar typische DEM-Farbskalen zur Auswahl geschickt, da die gegenwaertige zu wenig Farbabstufungen durchlaeuft (meiner Meinung nach): http://www.jimkeir.co.uk/FlightSim/LWMViewer.html

Und dann gibt's auch noch Edgars neuen Childpoint Converter V1.0, der angeblich das Problem mit den wildgewordenen VTP2-Autogen von Ground2K loest: http://forums.avsim.net/dcboard.php?...id=17057&page=

Tools, tools, tools.

Ciao, Holger

... und hier noch das Ergebnis von ts_demo. Beachtet die fehlende Wasserzelle im westlichen Seearm.

Huch! Interessant - diese (erste) Version hat gar keine fehlende Zelle, die zweite Version aber doch. Hmmm...

... also hier dann noch die gegenwaertige LWM Version mit Loch.

Ciao, Holger

Zu Holger

"Habe gerade meine Jungfernfahrt mit Autoasm (v1.00, December 20, 2003 6:33:32 PM) hinter mich gebracht".

Das verwundert mich. Der Chris hat ja nirgends direkt seine Versionsnummer abgelegt. Als Gymmick hat er in meiner Version eine Bitmap die über die Info Schaltfläche ausgelesen wird (ähnlich der Sceneryauslesung). Da wird bei mir Version 0.6 vom 22.12.03 gemeldet. Auch die Word Doc spricht bei mir von der Version 0.6

Du hast eine Version 1.00 die aber vom Datum her älter als meine Version ist. Deine Versionsnummer ist wiederrum höher. Sehr seltsam.

Kannst Du mir den Link nennen wo Du die her hast.

Ich hatte sie wie gesagt über den Link geladen den er selbst im AVSIM Forum genannt hatte.

Lässt man das Zip File aus der Adresse aus landet man direkt auf seiner Homepage. Dort ist allerdings überhaupt kein Bezug zum FS erkennbar. Er hat die Page offensichtlich nur zum ablegen des Tools genutzt.

Hier mal der Link den er genannt hatte.


http://www.kline.demon.co.uk/autoasm.zip


Komischerweise habe ich es bei AVSIM auch nicht gefunden.

Auf jeden Fall bin ich beruhigt das Du bei einem Gebiet zusätzliche LWMs hast. Komischerweise hatte ich wiederrum beim Circle keine zusätzlichen LWMs. Ich denke das ist eine eindeutige Aussage das da etwas faul ist. Das Du es nicht bei TS_Demo hast könnte jetzt auch an einer anderen Version liegen.

Mit den Speichereinstellungen hatte ich auch schon rumgespielt, hat nichts gebracht hinsichtlich der Probleme.

Horst hat zwar nicht das LWM Problem aber er sagt ja selbst das Die Ergebnisse unterschiedlich sind wenn man andere Koordinaten angibt der Rest aber unverändert bleibt.

Zu deinem Satz
"Wenn das Eingabe .bmp so genau ist, frage ich mich, wieso so viele Strassen unverbunden bleiben?"

Ich denke mal da wird man den Search Radius hochsetzen müssen.



"Und dass die so krakelig aussehen, haengt wohl mit der 1:1-Umsetzung der Punktdichte zusammen?"

Denke ich auch. Denn das war bei mir immer dann der Fall wenn Die Information in der Bitmap dichter als der mögliche Vectorpointsabstand des FS war. Dann versucht er auch hier jeden Punkt umzusetzen. Erreichen tut er dieses dadurch das er den Vectorpoint wiederholt bzw. mal um einen Punkt nach rechts, links, oben oder unten ausweicht.


"Na ja, vielleicht laesst sich da mit verschiedenen Einstellungen oder Linientypen mehr herauskitzeln. Ist also nur eine vorlauefige Beobachtung"

Ich vermute mal fast nicht. In meiner Version gibt es keinen Steuerparameter der dieses zulässt.

Ev. ist das in Deiner oder Horst seiner Version anders.

Momentan sehe ich nur bei den Vectorpoints die Chance einen Bitmapmasstab zu wählen das die Pixel der Bitmap koordinatenmäßig gesehen einen größeren Abstand als die Vectorpoints des FS haben.

Ist natürlich auch nicht optimal.

Bei den LWMs keine Ahnung was da bei der Umwandlung in den ASM Code passiert.

Wahnsinn, habe gerade mit dem neuen LWMViewer herumgespielt. Toll jetzt sehe ich nicht nur die genau Abdeckung der einzelnen Meshdaten, sondern auch die Löcher. Ich hänge einmal ein Bild an.
Dies sollten Löcher im Mesh (Allegmane) sein. Sieht so aus wie beim Mauszeiger. Auch in der Umgebung relativ viele Stellen. Aber vielleicht interpretiere ich dies falsch. Meine Mesh- Kenntnisse sind noch zu gering.

Aber Jim Keir ein fähiger Mann, herzlichen Dank für seine Arbeit.

Das Fehlen von Lod 13 Area kann ich bestätigen. Ist mir auch aufgefallen, nur bei der Area daneben (westlich). Die Ursache dafür habe ich noch nicht gefunden, da es meiner Meinung mit der Erzeugung (also Ablauf, mit und ohne LWM, bzw Auto, Load, Save) zusammenhängt. Sehr selten auftritt. Sollte man beachten, vielleicht finden wir den Grund oder den Zusammenhang.

Zum Vergleich habe ich auf Seite 4 Ts_demo angehängt (test.jpg). Also muss ich da noch Fehler machen, da ich die Straßen gar nicht sehe. Ich denke auch, dass dieses TS_Demo Bitmap auch nicht geeignet ist.
Das TS1 Bitmap muss ich noch probieren.

Auch der Hinweis von Wright in der Anleitung, für Load, Save und anschließend wieder Read data, sollten wir beachten.
Ich für meinen Teil, muss diese Anleitung noch einmal Zeile für Zeile durchlesen und ausprobieren.

Verbindet man die Daten mit Höhendaten (in AA noch nicht möglich), muss jeder Anwender dieselben Daten haben (vielleicht deshalb auch Srtm, da sich dies jeder derzeit selbst erzeugen kann). Ansonsten kann man nur das geeignete Bitmap anhängen und der Anwender muss es selbst erzeugen. Wie bei AFCAD damals mit der Textdatei.

Joachim, unter Datei-Eigenschaften findest du wahrscheinlich auch bei dir die Information. Wie ich dir weiter oben beschrieben habe.
Bei FS2004 Geländedetails habe ich gestern zu einem alten Beitrag verlinkt. In diesem Beitrag erwähnst du ein Werkzeug: Toposcan von Bernhard. Kann ich dies im WWW finden, bzw. wo? Falls deine Antwort nicht für ein öffentliches Forum geeignet ist, würde ich um eine kurze Antwort per Mail bitten.

Da ich mich wieder in meine heimatliche Bergwelt zum Schifahren zurückziehe, ist dies mein letzter Beitrag. Internet und Computer bleiben, zum Wohle meiner Familie und mir, zu Hause.
Weiter testen werde ich erst wieder in der zweiten Februarwoche.

Ich würde aber bitten den Beitrag hier aufrecht zu erhalten. Nachdem wir uns auf einen sachlichen Austausch geeinigt haben, mischt sich auch keiner mehr ein, der sich nicht ernsthaft mit diesen Programmen beschäftigt. Und durchlesen von A-Z wird ihn so und so kein Neuer mehr.
Auch die Verlinkung zu neuen Werkzeugen und interessanten Beiträgen finde ich toll.

Ich denke, dies sind Werkzeuge, die mir noch viel Freude bereiten werden. Vielleicht auch wenn man sie verbindet und daraus ein tolles Tool macht. Wir sollten weitertesten und den richtigen Input bzw. Bitmap, für Jedermann erzeugbar, suchen. Und auch beachten, warum dies mit bglcomp derzeit noch nicht funktioniert. Bzw. ob sich hier Fehlerquellen ergeben können, für die Zukunft.

Horst

Da ich jetzt doch noch Zeit für einen kurzen Beitrag finde (große Familie = viel Gepäck), bevor ich meine „Kiste“ für eine Woche abdrehe.

Dient nur zur Fantasieanregung:

Strip kenne ich nicht. Aber mit AA sollte es möglich sein, auch Terrain zu erzeugen. Zumindest laut Anleitung. Ich füttere dieses Programm derzeit noch nicht mit eigenen Bitmaps.
Aber hänge hier ganz einfach ein jpg aus Höhendaten an (ein Knopfdruck). In diesem Format (jpg) ist dies nicht zu gebrauchen, aber ich kann es sonst nicht hier anhängen. Man kann aber aus anderen Daten, andere Formate erzeugen. Bzw. die Höhenschichten auch anders darstellen. Oder auch mit tmfdecompress raw Daten erzeugen.

Man kann diese Daten auch in farbigen Formaten darstellen. Laut Anleitung kann ich diesen Daten auch noch die Botanik richtig zuordnen.
Wenn ich diesen Colour-Index (derzeit denke ich nicht) richtig darstelle, habe ich die richtige Texture/Autogen auch noch am richtigen Platz.
Wenn ich dieses angehängte Bitmap auch noch mit realen Vegetationen-Bitmaps verbinde ( z.B Waldgrenzen, Weinberge), wird die Eingabe, das richtige Bitmap, sehr interessant.
Wenn ich über die terrain.cfg noch die richtigen Bitmaps zuordne, kann ich theoretisch auch noch verschiedene Texturen zuweisen (Vegetation sieht auf jeder Höhenstufe anders aus – bzw der Mensch greift hier sehr stark ein – siehe Waldbau - Kahlschlagflächen).

Ich bin ein sehr fantasievoller Mensch – verbinden wir vorhandene Daten auch für den Flusi.

Daher die Bitte: Füttern wir fähige Leute wie Jim Keir und Chris Wright mit unseren Ideen, die wir vorher überprüfen. Damit wir diese fähigen Programmierer nicht quälen. Damit sie Spaß auch an ihrer Arbeit haben.

Dies braucht jedoch Zeit.

Genug.

Horst

Horst das ist im Prinzip aber alles seit langem bekannt. Mesh wurde schon immer über RAW/BIN Dateien programmiert. Jedes Tool welches ev. komfortabel arbeitet muß letzendlich zu BGL Erzeugung den Weg über die SDK resample.exe gehen. Das ist bei Autoasm nicht anders.

Ich habe z.B alle meine Testmeshfiles und Landclassfiles in Adope Photoshop programmiert. Hier kannst Du auch aus einer Karte die Farbinformation auslesen und automatisch Landclass programmieren. Das habe ich schon im Sommer 2002 so realisiert.

Im Prinzip ist Autoasm für Mesh bzw. Landclass jetzt eine etwas komfortablere Möglichkeit. Wie gesagt geht alles mit einem Fotoprogramm. Du musst nur die Pixel der Kartenbitmap quasi in das LOD Raster des FS bringen so das dieses flächenmäßig alles passt.


Eine statistische LC Zuweisung abhängig von der Höhe hatte auch schon FS Landclass von B.Renk. Das Prog. gab es im Frühjahr 2002 schon.

Das Problem in unserem lieben Lande ist aber in der Regel die Verfügbarkeit von Daten die hier 100% geeignet wären. Wie so oft der Liebe Input. Super wäre morphologisches Kartenwerk. Das hatte ich schon mal vor langer Zeit geschrieben. Dieses wurde unter anderem auch in der Mobilfunkplanung genutzt.

Da konnte man sehen wo Wälder sind, welche Waldarten, Ackerbau, Sumpf, Wiesen, Städte mit jeweiliger Bevölkerungsdichte des Stadtteiles usw. Alles schön farblich abgesetzt.

Ich hatte damals versucht über TOP50 auszuwerten. Leider wird da zu oft die selbe Farbe verwendet. Orte/Städte immer schwarz. Die Straßen leider auch. Da kann man dann schlecht sagen hier ist Industriegebiet dort ist Wohngebiet usw.

Morphologisches Material bekommst Du nicht umsonst. Ist unbezahlbar.

Gut kann sein das man vieles auch über die verschiedensten Aufnahmetechniken von Satelitten rausziehen kann. Holger hat da ja ein paar gute Tipps gegeben. Setzt natürlich den Zugriff auf eine schnelle Datenverbindung vorraus.

Hallo zusammen!

Habe noch keine weiteren Tests mit Strip oder Autoasm gemacht.

Als Neuigkeit gibts zu vermelden, dass John Childs eine neue Version (3.50) von Blackart veroeffentlicht hat: http://www.terrainmap.com/

Wie ihr der Meldung entnehmen koennt, hat er meine Vergleichsbilder auf Avsim gefunden (ich hatte in diesem Thread ja auch ein paar gezeigt) und dabei festgestellt, dass eine der Interpolationsalgorithmen (LSQR) nicht sinnvollerweise auf die gesamte Datei, sondern nur die Loechers selbst angewendet werden sollte. Die neue Version tut das und ein kurzer Test von mir bestaetigt das auch - keine "verschwommenen" Ergebnisdaten mehr.

Cheers, Holger

Servus Holger und Joachim,

Die Zeit vergeht sehr rasch, ich hoffe trotzdem, dass ihr diesen Beitrag noch lest.

Joachim,
natürlich ist dies alles nicht neu. Und wie ich schon weiter oben geschrieben habe, versucht man seit Beginn von Computern Kartematerial (auch andere Pläne) zu digitalisieren.

Dein Satz:
„Du musst nur die Pixel der Kartenbitmap quasi in das LOD Raster des FS bringen so das dieses flächenmäßig alles passt.“
ist entscheidend.
Daher bin ich bei AA Tutorial Pkt 7 und 8 – reading and using bitmaps.

Vielleicht schaffe ich es diese Woche noch meine Gedanken etwas ausführlicher zu beschreiben.

Tausende Leute auf diesen Erdball versuchen auch Punkte, Linien und Polygone für GPS zu entwickeln und Kartenmaterial auch im privaten Bereich zu nutzen.

Daher nur kurz ein paar Links:

Eine von vielen guten Seiten, mit guten und kurzen Informationen (auch zu Werkzeugen):
http://www.digitalgrove.net/

Vergleich von kanadischem Datenmaterial:
http://members.shaw.ca/davepatton/mapcompare.html

deutscher Vergleich:
http://hometown.aol.de/mikeglade/TOP25BW.jpg
http://hometown.aol.de/mikeglade/GarminTop25.jpg
http://hometown.aol.de/mikeglade/GarminCS.jpg

Höhenlinien digitalisieren:
http://www.easytrace.com/work/englis...utorelief.html

ASCII – Höhenpunkte:
http://www.geocities.com/miroslavdressler/surgetut.htm

Vielleicht gibt es auch einmal eine Art POI (Points of Interest) Einbindung in den FS. Oder man kann so etwas entwickeln. Genauso wie bei GPS-Material oder anderen GIS-Material.
Damit meine ich nicht nur die Anordnung von Objekten entlang von Linien, sondern die Zuordnung von speziellen Gebäuden (z.B Wiener Stephansdom), anhand von Koordinaten. Man könnte eine Datenbank erstellen und Gebäude relativ einfach ergänzen.

Wie geschrieben, werde ich meine Ideen einmal zusammenfassen.

Wichtig wäre nur, dass dies jeder aus irgendeinem Material (Datenformate) machen kann. Damit hätte man sicher keine Probleme mit Lizenzen (man scannt die Daten ja nur) und relativ rasch eine realistische Landschaft im FS. Weltweit könnten Flusianer mit diesen Freewareprogrammen arbeiten und einfach Landschaften produzieren.
Und die Gierigen könnten es ja wieder auf CD zusammenfassen und verkaufen. Aber nur wenn sie den Autoren dieser Programme Geld geben (siehe Pete Dowson). Daher würde ich auch gerne anhand einer bgl erkennen, mit welchem Programm es erzeugt wurde.

Egal, fertig werde ich mit meinen Gedanken und deren Umsetzung nie sein, auch nicht beim FS10. Es ist auch sehr zeitaufwendig, wenn man beide Seiten - Material und Umsetzung im FS – verstehen will.

Derzeit habe ich 3 Fragen:

Holger
A)Ich habe hier
http://edcdaac.usgs.gov/glcc/tablambert_euras_eur.asp
ein img Datei schon vor etwas längerer Zeit geladen. Ich habe nur leider keine Ahnung wie ich diese Daten darstellen kann. Sind das HDF Daten?

B)Tmfdecompress funktioniert bei mir (XP) anscheinend auch nicht richtig. Mit –b, -l, -n usw. habe ich eigentlich immer dasselbe Ergebnis, und dies sieht nicht gut aus. Mache ich da etwas falsch oder gibt es eine neue Version? Bei mir funktioniert anscheinend die Bitmap-Routine nicht richtig.

Joachim
C) zu Toposcanner finde ich leider keine Informationen. Was das Programm eigentlich aus diesem Material auslesen konnte. Anscheinend wird es nicht mehr vertrieben (Lizenzgründe-Landvermessung?) Bzw. ob es jedes Datenformat kann.

Meine Download und Update Ordner ist schon sehr groß. Der muss diese Woche noch aufgearbeitet werden.
Priorität hat sicher AI-Floatplane und Ships und natürlich Glacier Bay National Park seit gestern (mit der Maule wahrscheinlich ein Genuss)
Holger, herzlichen Dank einstweilen dafür.

Horst

Zu B.

Funktioniert bei mir sehr gut. Mir reciht die nackte decompilierung aus. da ist alles drin was man benötigt. Alles andere ist meiner Meinung nach unwichtig. Bei nacktem Decompressvorgang kommt bei Landclass eine fertige Inf zum späteren Kompilieren raus. Weiterhin das RAW File. das gleiche gilt für mesh. Du musst nur ein Tool haben um die RAW Dateien zu bearbeiten bzw. auszulesen.

Dann könntest Du jedes Landclass oder Meshfile editieren.

Ich glaube deshalb hat es auch schon irgendwo Ärger gegeben. Wegen Lizenzen und so. Habe aber nur oberflächlich gelesen.

Zu D würde ich einfach mal Patrick ansprechen.

Du benötigts aber auf jeden Fall so etwas wie TOP50 neue Version mit digitalen Höhenmodell.

Nicht ganz billig der Spaß. z.B Bayern sind gleich zwei CD. Das wird so um die 100Euro liegen. Habe selbst auch nur Niedersachsen und Hessen mit Höhenmodell. Der Rest alles noch nur mit den üblichen Höhenlinien. Blackart scheint hier ja auch eine Unterstützung anzubieten. habe mir das aber noch nicht angeschaut.

Auto ASM habe ich in die Ecke gelegt. Komme trotz verschiedener Einstellungen und PCs immer zu selben Ergebnissen.

Außerdem ist es bei mir mit dem Code nicht performance freundlich. Da der FS schon genug belastet ist lasse ich die Finger davon.

Sollte ich den Code vom NAV System knacken was ich besitze werde ich wohl ein eigenes Tool machen.

Muß natürlich noch einiges lernen.

Ev. gibt es bis dahin ja schon was. Dann hat sich das erledigt.

Hallo zusammen!

Die Zeit vergeht tatsaechlich schnell; seit meinem letzten Post (Blackart 3.50 erhaeltlich) hat es 8 neue Versionen von Blackart gegeben! Scheint so aehnlich wie mit MicroDEM zu sein - vor jeder Benutzung erst mal auf der Webseite nachschauen, ob es bereits wieder eine neue Version gibt ;)

Horst, vielen Dank fuer die Sammlung der Links - als "Kartenfanatiker" (laut meiner Partnerin) finde ich solche Webresourcen immer sehr spannend.

----
"Vielleicht gibt es auch einmal eine Art POI (Points of Interest) Einbindung in den FS. Oder man kann so etwas entwickeln."

Gibts bereits fuer den FS, soviel ich weiss: http://www.abacuspub.com/catalog/s497.htm. Habe allerdings unterschiedliche Meinungen darueber gehoert - die Software laeuft wohl parallel zum FS und fuehrt oft zum Ruckeln beim fliegen.

----
"Ich habe hier [...] ein img Datei schon vor etwas längerer Zeit geladen. Ich habe nur leider keine Ahnung wie ich diese Daten darstellen kann. Sind das HDF Daten?"

Kannte diese Daten noch nicht aber laut Read-me (siehe unten) handelt es sich um 8-bit Rasterdateien. Sollte man also einfach als .raw Format mit Photoshop usw. laden koennen; die Datei fuer Eurasia hat 13000 Spalten und 12000 Zeilen.

"The data dimensions of the Lambert Azimuthal Equal Area projection for the Eurasia land cover characteristics data set optimized for Asia are 12,000 lines (rows) and 13,000 samples (columns) resulting in a data set size of approximately 156 megabytes for 8-bit (byte) images." http://edcdaac.usgs.gov/glcc/eadoc2_0.asp

Das groessere Problem duerfte hier die Projektion sein; da brauchst du wahrscheinlich ein Payware GIS um vom Lambert auf Lat/Long umzuprojektieren - falls du FS mit diesen Daten fuettern willst.

Uebrigens gibt es ein anderes, aehnliches Produkt hier:
http://www.gvm.jrc.it/glc2000/defaultGLC2000.htm. Dessen Vorteil ist, dass es sich bereits in der geographischen Projektion befindet. Jim Keir hat mich auf die Webseite aufmerksam gemacht und er bastelt bereits an einem neuen globalen Landclass-Datensatz fuer FS.

So ganz ohne Aenderungen werden die GLC2000 Daten aber auch nicht uebernommen werden koennen. Z.B. gibts nur eine Klasse fuer bebaute Gebiete und auch nur eine Klasse fuer Eis und Schnee. Fuer das gestern veroeffentlichte Glacier Bay N.P. Projekt habe ich mit den GLC2000 Daten experimentiert, sie dann aber doch nicht verwendet. Wie ihr wohl wisst, hat FS zwei Eis & Schnee Landklassen, #122 und #142. Die benutzen zwar dieselbe Textur, aber Klasse #122 wird nicht verblendet. Daher kann man Gletscher und Schneefelder im Inneren mit 122 deklarieren, muss aber an den Raendern immer eine Reihe von #142 anhaengen (das kann man auch in der default worldlc.bgl sehr gut sehen). Die Alternative, nur #142, sieht uebrigens auch nicht gut aus.

Da ich fuer das Glacier Bay Gebiet Landsat-Daten zur Verfuegung hatte, habe ich per GIS eine unueberwachte Klassifizierung der Kanaele 2, 4, und (4-3) durchgefuehrt, die 16 Ergebnisklassen auf 10 reduziert und denen dann den am besten passenden Landclass-Wert zugewiesen. Das Ergebnis ist natuerlich nicht perfekt aber sicher realitaetsnaeher als das Original.

Uebrigens wurden die Kuestenlinien vom Glacier Bay Projekt komplett mit "Strip" erstellt, inzwischen in "Slartibartfast" umbenannt (der ausserirdische Fjord-Designer vom "Hitchhikers Guide to the Galaxy"). Ihr koennt euch also im FS oder LWMViewer das Ergebnis mal kritisch betrachten.

Tmfdecompress (was ich selber noch nicht benutzt habe) ist nicht mehr frei erhaeltlich, da Jim damit moeglichen rechtlichen Schritten von Lizenzinhabern aus dem Weg gehen will. Er bitte auch darum, dass gegenwaertige Nutzer von Tmfdecompress dieses nicht weiter verteilen.

Ciao,
Holger

Na dann habe ich zu tmfdecompress doch richtig gelesen.

Übrigends Holger war Dir folgendes bekannt.

Man weis ja bei VTP2 Polys und Custom Fotosceneryzuweisung über LC252 und 253 schon recht lange das der FS hier vertikal gespiegelte Landclasstexturen liefert.

Was mir aber neu ist bzw. ich kann mich nie dran erinnern dieses jemals auch für normale Landclass gelesen zu haben das generell VTP2 Polys gekippte LC Texturen produiziert werden. Ehrlich gesagt ich habe nun so was über Ground2K gemacht und auch über SCASM Betaversionen. Mir ist es ehrlich gesagt nie aufgefallen. Sogar die Defaultpolys (Airport oder Parks stehen Kopf)

Fällt natürlich bei Wald und Rasen nicht auf. Bei VTP Polys die LCs mit Bebauung zuweisen passt natürlcih Autogen hin und vorne nicht mehr zur Textur.

Ich habe gedacht ich traue meinen Augen nicht. Anhand meiner Testtexturen konnte ich das jetzt sogar im FS2002 erkennen.

Wie gesagt bei Customtexturen findet man etliche Threads z.B AVSIM aber nie bei normalen LCs. Ob das noch niemanden aufgefallen ist. Mittlerweile gibt es ja sehr viele die Landclass über VTP2 zuweisen.

Hallo Joachim!

Das ist ja ein Ding! Mir war zwar schon oefters aufgefallen, dass die Bebauungs-Autogen eigentlich sehr schlecht zu den Texturen passen, obwohl MS eigens dafuer den Annotator entwickelt hat, aber auf die Idee mit der Spiegelung bin ich nicht gekommen. Ich werde mir das noch mal genauer anschauen und vielleicht auch mal im Avsim Scenery Design Forum nachfragen.

Uebrigens kann ich jetzt auch aus erster Hand bestaetigen, dass die "Weihnachtsgletscher" durch die "Mischung" von VTP2 Polys mit und ohne Nachttexturen entstehen. In einem der Ground2K4 Files vom Glacier Bay Projekt hatte ich neben den Gletschern auch ein Stadt-Poly (Juneau) zugefuegt und prompt leuchteten die Gletscher mit schoenster Dekoration - siehe Bild im Anhang. Habe das Stadtpoly entfernt, da das Ergebnis sowieso nicht so toll war und gleich war das Eis wieder schoen dunkel. Besten Dank nochmal fuer den Fund!!!

Cheers, Holger

Schönen Abend,

nur kurz:

Joachim
Nicht weglegen, Fehler aufzeigen und weiterhelfen. Autoren warten auf konstruktive Kritik und Meinungen. Mit dem Autor in Verbindung setzen.
Hier geht es nicht um Hacken, sondern die Suche nach Möglichkeiten für Jedermann (siehe SRTM (eine Basis auch für GPS-Karten), AFCAD)

a) Falls du Mapsource von Garmin meinst und img Files:
http://planeta.terra.com.br/informat...e_download.htm
http://karmin.sourceforge.net/
http://gps.chrisb.org/en/gps_mapper.htm
http://www.gpsinformation.net/gpsmapper/gpsmapper.htm
Zusammenfassung von Material:
http://kanadier.gps-info.de/d-map_source.htm

b) Topokarten (schon länger bekannt (ich glaube 2001):
http://home.wtal.de/noegs/top-export.htm

c) tmfdecompress:
Bitte kurzen Anhang (kleines jpg) von At2002/at2002.bgl
Übrigens noch einmal: ein gutes Freewaretool:
http://www.gadwin.com/printscreen/

Holger
a) zu meiner img-Datei
Den Link schon einige Male gelesen, und noch immer keine Ahnung wie ich es darstelle.
Vielleicht könntest du ein kleines Image runterladen und darstellen.

b) Dank deiner Anleitung bei Glacier endlich den Link zu Jim Keir Flusi-Seite gefunden:
http://www.jimkeir.co.uk/FlightSim/index.html
Küstenlinien gesehen.
AI will noch nicht richtig.
Ansonsten ein Genuss. Hatte alle Addons. Danke.

c) zu POI:
Ich meine nicht EZ-Landmark.

Sondern die Übernahme von Koordinaten und Einbindung in FS.
Keine Orientierung für bestimmte Objekte anhand von Linien (jedoch auch sinnvoll).
Z.B.: Mache eine Shell-Tankstelle und übernehme das Tankstellenetz aus andere Daten für ganz Österreich. (jede Tankstelle am richtigen Ort)
Nicht viele kleine bgl Dateien, sondern eine Datenbank und Erstellung einer bgl – siehe AI Traffic
Meine Gedanken muss ich näher erläutern.
Manchmal vergesse ich, dass der FS ein Spiel ist.

Andere Stellungnahmen muss ich erst nachvollziehen und überprüfen.

Horst

Hallo!

@ Horst

a) werd's mal im Hinterkopf behalten - versprechen kann ich aber nichts

b) bitte schoen! Lass mich wissen wenn's weiterhin Probleme mit den AI gibt

c) Aha - verstehe. Clevere Idee. Waere fuer die VFR auch gut geeignet, wenn man so z.B. Sendemasten einbinden koennte.


@ Joachim

Habe heute nachmittag deine Ergebnisse der Suche nach den beleuchteten Gletschern im Avsim Scenery Design Forum beschrieben - hoffe, dass ich das korrekt zusammengefasst habe: http://forums.avsim.net/dcboard.php?...id=18131&page=

Deutschland erwacht und ich gehe zu Bett ;-)

Cheers, Holger

Habe es gerade gelesen.

Danke

Stand heute morgen etwas unter Zeitdruck. Ich denke es ist ganz gut das ich eine Lösung für das Problem der leuchtenden Natur VTP2 Polys bieten kann. Denn mittlerweile berichten mehrere Designer von diesem Problem. Wenn man sieht das Du ihn im Prinzip jetzt bei dem Gletscher auch wieder hattest kann man erkennen das man sich den Bug sehr schnell einfangen kann.

Der Screenshot mit der Gletschergegend sieht (wenn man mal das Leuchten welches Du zwecks Demonstration des Bugs drin gelassen hast außen vor lässt) genial gut aus.

Weist Du etwas ob Jim das Tool Strip bzw. dessen Nachfolger offiziell veröffentlichen wird. Hier dürfte es keine Lizenzprobleme geben.
Reine Intereresse. Du erwähntest übrigends mal das es auch Küstenlinien beherschen wird oder bereits kann. Ist hier der Code performancefreundlicher. ( so das nur die benötigten Vectorpoints umgesetzt werden)

Ich habe übrigends eine Vermutung woher das eigentliche Problem der leuchtenden Nachtpolys rühren könnte. Denn es tritt ja wie gesagt nicht generell auf wenn VTP Polys mit LC Zuweisung von Texturen mit Nacht und ohne Nachttexturen vermischt werden.

Ob es allerdings eine effiziente Resourcen sparende Methode gibt um den Bug der vertikal gekippten Texturen bei LC Zuweisung über VTP2 Polys zu verhindern weis ich noch nicht. Schliesslich dürfen wir uns kein Speicherleck in Betracht der Auslagerungsdatei einfangen.

Wenn man aber bedenkt das fast alle User solche ADDON Scenerien betreiben (ev. ohne Wissen dieser Technik) und ihnen dieser Bug noch nicht aufgefallen ist, dürfte es nicht so tragisch sein.

Wenn ich Zeit gehabt habe wird ein Screenshot worum es geht angehangen sein. Dort wird man eine Landclasscenery eines Landclassfiles sehen mit Defaultbodentexturen wo die Texturnummer eingeblendet ist. Die Texturnummer ist ausgenordet und ist normal lesbar. Da wo sie auf dem Kopf steht wird eine Landclass nicht über ein Landclassfile sondern über ein VTP2 Poly zugewiesen.

Oben ist das VTP Landclasspoly eingebettet in eine Landclasscenery gleichen LC Types. Unten damit man es besser erkennt in einem normalen Landclassfile. Die Texturnummern sind direkt vorher in die Landclasstexturen von mir eingearbeitet worden.
Vorteil bei diesen VTP Polys ist übrigends das man theoretisch jede beliebige Form und Größe eines Ortes darstellen kann. Nachteil die Textur steht auf dem Kopf. Das ist zunächst mal nicht schlimm. Leider werden die Autogengebäude über ein zur Textur gehörendes eigenes Autogenfile zugewiesen. Dort werden quasi die Grundflächen der Häuser und Bäume definiert und positioniert. Dieses Autogenfile steht im VTP2 Fall leider nicht auf dem Kopf. Als Auswirkung davon stehen die Häuser und Bäume natürlich nicht mehr da wo sie hin gehören. Übrigends ein Problem welches auch bei FS Scene Texturen generell auftritt insofern man nicht eine Version besitzt die eigene Autogenfiles mitbringt. Bei den ersten Versionen gab es so was nicht. Kann sein das diese mittlerweile zum Lieferumfang gehören.

Diesen Bug habe ich neulich bei der Suche nach den leuchtenden VTP2 Nachtpolys entdeckt. Er gilt übrigends auch für den FS2002. (Damals kam die VTP2 Polytechnik aber noch selten zum Einsatz weil das SDK erst spät erschien) Für Fotoscenerien bei VTP2 Poly Zuweisung war der Bug schon länger bekannt. Für reine Landclass offensichtlich nicht. Bei Custom/Fotoscenery über VTP2 Polytechnik verwundert mich dieser Bug nicht da es nicht als offizielles Verfahren im SDK steht.

Bei reiner Landclasszuweisung bin ich überrascht da es ein offizielles Verfahren im FS2002 Terrain SDK ist. Auch der FS selbst hat dieses Problem bei seinen eigenen Airportpolys. Damit scheint es ein FS eigener Bug zu sein der nicht durch Designtools verursacht wird.

Da ich mir jetzt fast alle Hilfsmittel geschaffen habe um Landclass in alle Tiefen zu ergründen denke ich werde ich demnächst alle Bugs (Nachtpolys, CTD bei LC) aussortieren können. Auch ist jetzt eine Landclassdoku bis fast ins kleinste Detail möglich. Ein bischen fehlt mir noch. Im Prinzip könnte ich relativ schnell alle Steuertabellen des FS2004 aktuell für alle der sehr vielen möglichen Situationen erstellen. Also LC Nummer weist im Gebiet X die Texturserie A zu . Bei Meshsteigungen über Y Grad die Texturserie B. Bei Steigungen über Z Grad Texturserie C. Wird es mit Class Map =2 maskiert die Texturserie N usw. Dürfte mir jetzt alles schnell und effizient möglich sein.

Frage ist nur ob es noch Sinn macht. Aktuell denke ich würde es sehr viel Sinn für alle Designer machen. Nur das sind schon ein paar Stunden Arbeit. Wovor ich mich nicht scheue. Aber da gibt es eine Aussage in der aktuellen FXP Zeitschrift auf Seite 07 zum MyWorld Projekt von Burkhard Renk die mich zweifeln lässt.

"Beginnen wir bei den neuen Landklassen. Diese werden für die gesamte Welt nach neuesten Kartenmaterial und unter Verwendung von neuen Algorithmen, die die verfügbaren Daten noch besser umsetzen sollen nach den neuesten Vorgaben des FS2004 SDK erstellt......"



Nun weis ich nicht ob diese Aussage falsch gemacht wurde oder der Redakteur dieses ev. von Burkhard falsch interpretiert hat. Ev. ist mir etwas entgangen bezüglich SDKs.

Mir ist nämlich kein aktuelles SDK bekannt welches Neuigkeiten bezüglich Landclass des FS2002 bzw. gar dem FS2004 aussagt.

Nun ist es so das B.Renk offensichtlich einen sehr heissen Draht zu Microsoft haben muß. Denn er hatte damals auch schon mal eine Aussage zu dem späteren BGLCOMP.SDK gemacht. Da gab es das aber noch nicht. Entweder er hatte auch nur mal irgendwo was aufgefangen oder er ist Betatester und wird auch bei den kommenden SDKs im Vorfeld auf dem laufenden gehalten.

Jetzt ist nämlich für mich die Frage macht man sich die Arbeit wenn ev. schon nächsten Monat vieles über ein SDK aufgedeckt wird.

Da wäre die reine Fehlersuche sinnvoller.

Hi!
Auweia,daß mit dem Kopfstehen ist wirklich heftig!
Da gibt es tausende von Usern,die dieses irgendwo in einer Scenery haben und merken es nicht.
Ich hätte es wohl auch nie gemerkt:rolleyes:
Wirklich erstaunlich was Du Dir da wieder mal hast einfallen lassen,um den LC u.a. auf den Zahn zu fühlen.
Bei B.Renk's My World,ist davon auszugehen,daß er ein SDK bzw eine Art Beta SDK haben wird.
Er war ja auch der erste der mit MT2004 ein Addon für den neuen herausbringen konnte.
Mach aber bitte weiter,auch falls ein SDK kommen sollte.
So wie ich Dich einschätze,wird bei Deiner Version eh mehr information rüberkommen;)
Interessantes Thema,nur leider so versteckt hier im Forum.

@ Holger:Bekomme im März endlich DSL,dann will ich mal Deine Kunst bewnudern.Der Screen sieht ja wirklich wie Joachim schon schrieb:Genial gut aus.
Gruß::)

Nun ja.

Ich habe von einigen gehört die berichten aber auch im My World LC Projekt von Problemen die es auch schon im FS2002 Landclassfiles der Scenerykits gab. Auch im aktuellen Projekt soll es noch viele unpassende Texturen geben. Also vertrocknete usw. die man eher nach Amerika packen würde. Auch soll eigentlich nichts erkennbar sein was direkt für ein Arbeiten anhand neuester SDK Vorgaben spricht.

Auch in einem anderen Forum wurde von einem Crack zu dem Thema SDK berichtet das es noch kein neues Terrain SDK für den FS2004 gibt.

Also verpasst habe ich wohl nichts.

Dann wird bei den neuen Files bestimmt die Erkenntnis mit eingebracht worden sein das die LC Information auf dem LOD Raster und nicht dazwischen liegen sollte. Die Erkenntnis wurde langer in Foren diskutiert hat aber nichts mit einem SDK zu tun.

Ich vermute mal das es sich hier um eine Fehlinterpretation des Redakteurs handelt. Das mit dem Algorithem ist klar das wird sich auf die Wandlung des Kartenmaterials in das RAW File beziehen. Also das was hinterher über den resampler läuft um die BGL zu erzeugen.

Wie da das SDK ins Spiel gebracht wird keine Ahnung?

Aber ev. weis Burkhard wirklich mehr.

Die Problematik beim neuen das sich Landclass anders verhält und einiges verschluckt bzw. auch untergeht, siehe auch die Threads am Anfang als der FS2004 rauskam soll weiterhin bestehen. Wenn dann scheint ein ev. einigen bekanntes SDK welches die Allgemeinheit noch nicht besitzt hierfür auch keine Lösung zu bieten.

Naja, von genial darf man noch nicht sprechen. Aber es ist relativ schön.
Holgers und Jim Keirs Arbeit in Ehren, aber bei Holger steckt noch viel Handarbeit darin.
Falkland von Jim habe ich erst heute installiert.
Meinungen dazu sind schwer, da ich auch das Rohmaterial brauche. Bzw. mit AA vergleichen will. Aber ich werde meine Meinung hier schreiben.

@Joachim

Wäre ich ein MS FS Mitarbeiter und du ein Betatester, der mir deinen Beitrag in einer Mail senden würde, könnte ich dir eine eindeutige-zweideutige Antwort geben.
a)„Ihre Aufklärung ist interessant, wir werden dies überprüfen“
b)„Sie sollten sich keine Sorgen um diese Darstellung machen“
Je nach Antwort darfst du es interpretieren.
Ich denke, MS ist bei dieser Informationspolitik sehr strikt (siehe auch Lee Swordy)
Anhand von Updates kann man solche Sachen überprüfen. Nicht nur bei FS.
Daher abwarten und Anfragen von Designern beantworten, oder sich die Arbeit antun (natürlich wäre auch ich für mein Verständnis des FS interessiert, und sehr dankbar)

Diese Programme müssen Freeware sein (für Payware siehe Dowson), und wir sollten alle mithelfen. Und später die Daten tauschen (siehe PAI Projekt)

Ein Frage Joachim:
Kann man diese Texturzuweisungen nur anhand von Tabellen machen, oder ist es auch möglich diese Texturen-Informationen bei laufenden FS anzuzeigen? D.h : Was sehe ich jetzt bei meiner aktuellen Einstellung bzw. Situation.
Ich denke viele Forenbeiträge würden sich dadurch reduzieren, da man exakt sagen kann, was man sieht (Dateien und Datum). Ich habe dies weiter oben angedeutet bezüglich Diagnosetool.

@Holger

AI einstweilen im Griff.
Hättest aber auch in deiner Anleitung schreiben können:
Options/Settings/Traffic/General Aviation bitte unbedingt aktivieren, sonst sehen sie kein Fllugzeug :) (hat mich einige Zeit gekostet)
Manchmal stehe ich wirklich auf der Leitung.
Ansonsten liebe ich diese Kleinigkeiten. Es war wirklich eine Freude den Booten und Wasserflugzeugen zuzusehen. Mit deinen Anregungen werde ich sicher weiterbasteln.
An der schönen Donau fehlt ja noch Schiffverkehr :)
Danke.

Zu img:
Ich komme halt ständig mit den Dateiformaten und deren Darstellung durcheinander, und darf sehr viel dazu lesen. Wahrscheinlich mache ich den Fehler. Genauso bei raw-Daten.

Zu POI:
Datenbank für das selbe Objekt an vielen Orten, oder ein Objekt an einem Ort. Jemand gestaltet ein bestimmtes Objekt und alle können es relativ einfach einfügen.

Horst

Vielleicht folgende kurze Verlinkungen zu Landsat 7 für alle Mitlesenden:

Nähere Erläterungen bei John Child: http://www.terrainmap.com/
(schön brav von oben bis unten links alle Seiten anklicken und lesen – hier stehen sehr gute Informationen. Abgesehen von Blackart – einem tollen Freeware Tool)

Tutorial hier:
https://zulu.ssc.nasa.gov/mrsid/tuto...torial-V1.html

Qualität von Landsat Daten in Bezug zu Bewölkung kann man hier ansehen:

http://edc.usgs.gov/

auf Global Visualization Viewer drücken.
Anschließend in Karte zoomen – man erhält eine Karte mit neun Kacheln.
Sensor links oben auswählen
Eine Kachel anklicken und mit rechter Maustaste Optionen Auswahl
Metadata, Browse Image, und auch previous und next
Kurzinformationen links

z.B:
Landsat 7 ETM+ von WIEN rechts unten (sehr geografisch)

Jänner 2003 34% Clouds : http://glovis.usgs.gov/ImgViewer/sho...90026000300650
März 2003 0% Clouds:
http://glovis.usgs.gov/ImgViewer/sho...90026000308650
August 2002 24% Clouds:
http://glovis.usgs.gov/ImgViewer/sho...90026000224350

Nur zum Ansehen – Stück kostet 600 Dollar
__________________________________________________

Durch Hinweis bei Childs bin ich auch auf diese Seite gestoßen:

http://eol.jsc.nasa.gov/sseop/Clickmap/default.htm

Man bekommt hier umsonst Luftaufnahmen.
Ganz einfach in Kartenbereich klicken – hinzoomen – Database Result
ansehen und runterladen.

z.B Wien
http://eol.jsc.nasa.gov/scripts/sseo...0946143596.tsv
Flughafen Wien
http://eol.jsc.nasa.gov/scripts/sseo...=ISS002-E-7841

Mitunter schlechte Qualität der Fotos – man muss halt länger suchen. Man findet sicher auch zufällig gute Aufnahmen.

Kein Vergleich zu TerraServer USA (nur für USA):
http://terraserver.homeadvisor.msn.com/default.aspx
Programm zu TerraServer hier (Freeware):
http://jdmcox.com/

oder z.B D-Sat 6 für Deutschland.

Horst
(Ich hoffe die Links funktioniern)

Hallo!

Noch schnell ein paar "Aufarbeitungen" vor der Schreibtischarbeit...

@ Joachim
"Weist Du etwas ob Jim das Tool Strip bzw. dessen Nachfolger offiziell veröffentlichen wird. Hier dürfte es keine Lizenzprobleme geben.
Reine Intereresse. Du erwähntest übrigends mal das es auch Küstenlinien beherschen wird oder bereits kann. Ist hier der Code performancefreundlicher. ( so das nur die benötigten Vectorpoints umgesetzt werden)"

Jim schickt mir alle paar Tage eine neue Version, d.h. er arbeitet also weiter daran und der Funktionsumfang waechst an. Wann und wie veroeffentlicht wird hat er mir noch nicht gesagt, aber ich werds euch natuerlich wissen lassen (und, wie gesagt, er freut sich sicher auch ueber andere Beta-Tester).

Ja, die Kuestenlinien des Glacier Bay Projektes wurden mit "Slartibartfast" erzeugt. Man kann MinSmooth und MaxSmooth einstellen, die sowohl fuer LWM als auch die VTP Kuestenlinien die Generalisierung bestimmen. Das ist sehr sinnvoll, denn bei einem wenig detaillierten Eingabemesh kommt sonst eine etwas eckige Kueste heraus.

Der Kuestenlinien-Suchalgorithmus ist zwar sehr schnell aber doch recht komplex; hier ein Zitat von Jim:
"Each Area (capital A) has 1,024 Cells (or is it the other way round - never can remember); each one of them is expanded to 288x288 pixels, smoothed, clipped to 256x256 and only then scanned for land/water transitions which is fairly intensive in itself, possibly requiring several passes to check for outlying islands. Each pixel tested involves 8 sub-tests to work out which direction to go in next so, for a single Area and depending on the actual mesh, that's something like 50,000,000 operations *plus* polygon smoothing."

Allerdings ist der Kuestenlinien-Algorithmus noch nicht ganz ausgereift, wie man beim anschauen meiner "s_Glacier Bay VTP.bgl" Datei gut feststellen kann. Da gibt es Ueberschneidungen und sogar ein paar Verdrehungen. Auf der anderen Seite gefallen mir die (ungewollten) Unterbrechungen sehr gut, da in der Natur es ja auch nicht ueberall Straende gibt.


Zu deiner Landclass-Arbeit:

Ich habe so meine Zweifel bzgl einer Landclass/Scenery SDK fuer FS9 und wuerde daher auch dafuer stimmen, dass du dein Wissen zusammenfasst und unter die Leute bringst, natuerlich in einem dir passenden Zeitrahmen und Umfang.

Hier ist ein Zitat von Richard (Ludowise) bezueglich der gespiegelten Polys:
"
Yes, all VTP2 polys are vertically flipped... it has to do with the VTP2 being orientated to the upper-left of the texture... but the terrain "engine's" orientation for textures is the lower left.
"

---

@ Schubi
Danke fuer das Lob! Das mit dem DSL kann sich schnell in ein "Ladefest" verwandeln - Vorsicht, Suchtgefahr! ;-)

---

@ Horst
"Naja, von genial darf man noch nicht sprechen. Aber es ist relativ schön.
Holgers und Jim Keirs Arbeit in Ehren, aber bei Holger steckt noch viel Handarbeit darin"

Hmmm... Vielleicht moechtest du beim naechsten Projekt 2.000km Kuestenlinien per Hand digitalisieren oder 30.000 LOD13-Zellen mit Ground2K4 oder EZ-Landclass deklarieren??? ;-)

Klar, die Ground2K4-"Zugaben" haben Zeit gekostet, aber das Kernstueck sind die Kuestenlinien und die Landclass-Dateien und das ist soweit automatisiert, wie es derzeit geht. Ich wuerde diesen Projektteil, der ja nicht meine Arbeit war, durchaus als genial und innovativ bezeichnen.

Danke fuer die neuesten Links!

"Nur zum Ansehen – Stück kostet 600 Dollar"

Hatte doch bereits erwaehnt, dass man sich tausende von diesen Landsat-Datensaetzen kostenlos herunterladen kann: http://glcf.umiacs.umd.edu/index.shtml Nur braucht man halt die Software, um die (geokodierten) Rohdaten FS-nutzbar zu machen.

Mit der Demo-Version von Global Mapper http://www.globalmapper.com/ kann man die TM Daten direkt laden und zu lat/long WGS84 umsetzen, nur klappt der Export nicht. Allerdings koennte man das Ergebnis in Teilen als Screenshots speichern und dann per Photoshop o.ae. zusammensetzen. Und schon hat man ein 100x100km Hintergrundbild fuer die Szenerie-Arbeit. Das geht wahrscheinlich schneller als das entzerren der Weltraumbilder, die auf John's Webseite verlinkt sind.

Cheers, Holger

Zu Horst:

"Ein Frage Joachim:
Kann man diese Texturzuweisungen nur anhand von Tabellen machen"

Die Tabellen sollen dem Designer dazu dienen eine Erkenntniss zu haben wenn er z.B Landclassnummer 103 setzt was ihn dann für eine Texturserie in Europa oder z.B Asien erwartet. Auch was er zur Ansicht bekommt wenn das Mesh bestimmte Steigungen annimmt. Denn bekanntlich reagiert ja Landclass auf Mesh. Weiterhin finden weitere Texturveränderungen statt wenn jetzt besagte Mask Class Map Polys drüber gelegt werden wie z.B bei den Airports. Dann hat nicht jede Landclass alle Jahreszeiten oder wie Holger gesagt hat keine Verblendung.

Solche Informationen bzw. wie Landclass und Verblendung usw. genau funktioniert das wollte ich dokumentieren. Auch ev. wie solche Bugs wie CTD oder leuchtende Nachtpolys entstehen wenn es denn beweisbar ist.
Wenn nicht wird es eine Vermutung geben.

"
, oder ist es auch möglich diese Texturen-Informationen bei laufenden FS anzuzeigen? D.h : Was sehe ich jetzt bei meiner aktuellen Einstellung bzw. Situation.
Ich denke viele Forenbeiträge würden sich dadurch reduzieren, da man exakt sagen kann, was man sieht (Dateien und Datum). Ich habe dies weiter oben angedeutet bezüglich Diagnosetool".

Das was Du willst das habe ich für mich bereits (zum Teil) geschaffen. Denn daraus werde ich meine Informationen zum Teil beziehen. Nur das sind fast 1GB Daten. Die kann ich mit meinen 56K Modem unmöglich irgendwo hinladen. Wollte ich auch erst mal nicht bevor die Dokumentation steht.

Welche Landclass gerade aktiv ist bzw. welches File kann ich auch nicht direkt auslesen. Geht natürlich auch indirekt über den tmf Viewer. Wobei man hier natürlich nur über logisches denken erst mal rausbekommen muß welches Landclassfile gerade aktiv ist.

Mir ist auch keine Möglichkeit bekannt z.B über FSUIPC oder ähnlichem auszulesen welche LC Datei gerade aktiv ist. Ev. ist das auch nicht möglich. Habe mich zumindest damit nicht beschäftigt. Ja der FS ich könnte mich 24 Stunden damit beschäftigen.

Zu Holger

Hier ist ein Zitat von Richard (Ludowise) bezueglich der gespiegelten Polys:
"
Yes, all VTP2 polys are vertically flipped... it has to do with the VTP2 being orientated to the upper-left of the texture... but the terrain "engine's" orientation for textures is the lower left.
"


Ja habe ich gelesen. Wie gesagt auf AVSIM habe ich bei normalen LCs dazu nichts gefunden. Ich vermute mal das er ev. auch überrascht war oder eben auch nicht.

Nur die Aussage finden ich etwas zu pauschal. Denn wo steht in einem SDK geschrieben das eine Textur bzw. die Terrainengine Ihren Bezug unten links hat. Mir ist da nichts bekannt. Klar die Polys haben Ihren Bezug oben links. Kommen wir zur Terrainengine. Wo hat Mesh seinen Bezug "oben links". Wo hat Landclass seinen Bezug "oben links". Komisch schaue ich mir eine Textur an bevor sie ins DXT1 Format konvertiert wird. Wo hat sie in einem Fotoprogramm Ihren Bezug "oben links" Konvertiere ich sie in DXT1 wos ist Ihr Bezug hat er sich geändert? Nein "oben links"

Wo hat das Autogen welches ja irgendwo in der TerrainEngine intergriert ist seinen Bezug "Oben links" Komisch die Terrain Engine hat bei Autogen den Bezug "oben links" und bei den VTP2 Polys ebenso "oben links".

Alles "oben links". Komisch und ausgerechnet bei Landclass unter VTP2 soll es anders sein. Nein also ganz ehrlich ich denke da kann man sagen das muß ein Bug sein. Absicht also so dass man sagen könnte der bezug ist hier einfach anders gewählt kann man nicht gelten lassen.

Ich denke wenn dann hätte Microsoft da im Terrain SDK drauf hingewiesen. Schliesslich erwähnen sie die LC Zuweisung bei VTP2 offiziell. Warum sollten sie hier diese Möglichkeit erwähnen wenn sie wissen das es bei Bebauung in die Hose geht. Wenn da eine Absicht hinter steckt dann hätten sie bei den Autogenfootprints ja auch eine Unterscheidung machen können zwischen VTP2 und Terrain Engine.

@Holger
Verzeih, ich habe dies etwas leichtfertig dargestellt.

Diesen Denkansatz der Umsetzung von beiden Produkten finde ich genial (das Wort mag ich jedoch nicht), jedoch das derzeitige Ergebnis noch nicht ausgereift, sondern ausbaufähig.
Ich denke, ich habe dies bereits oft genug erwähnt, und bin sehr zuversichtlich (auch bei Straßen und anderen)

Wenn ich fähig dazu bin, werde ich mich sicher bei Jim Keir melden. Bei AA bin ich anscheinend der Einzige (ich finde nirgends Beiträge dazu – mit Chris Wright habe ich nicht Kontakt). Vielleicht bin ich als Tester nicht geeignet, da ich immer gleich nach Lösungen -Denkfehlern suche, bevor ich den Autor frage.

Dein Satz:
„Allerdings ist der Kuestenlinien-Algorithmus noch nicht ganz ausgereift, wie man beim anschauen meiner "s_Glacier Bay VTP.bgl" Datei gut feststellen kann. Da gibt es Ueberschneidungen und sogar ein paar Verdrehungen. Auf der anderen Seite gefallen mir die (ungewollten) Unterbrechungen sehr gut, da in der Natur es ja auch nicht ueberall Straende gibt.“

Vielleicht darf ich ein jpg anhängen (Hoffe ich stelle dies richtig dar, was ich im FS sehe).

Ich stimme dir völlig zu, diese Unterbrechungen wären sehr schön, nur in die richtige Richtung (bzw. bei steilen Mesh).
War bereits ein Punkt meiner Meinung zu dem Projekt.

Zu meinen Links:
Danke, habe den Freewarelink nicht noch einmal angeführt, bzw. vergessen hinzuweisen. Ich finde nur, auf dieser Seite ist es relativ einfach die Unterschiede darzustellen, bzw. die letzten Bilder (Datum) anzusehen (Küstenlinien ändern sich jedoch nicht schnell - zumindest für FS).
Die Fotos sind sicher nicht geeignet für die Umsetzung im FS (vielleicht findet jemand ein interessantes Bild). Wollte nur darauf hinweisen, dass es außer anderen Seiten im WWW, vielleicht auch gute Sachen gibt. Man darf sicher auch unter Highlights nachsehen und über Kioto nachdenken. Es gibt auch viele andere Probleme auf diesen Globus, außer FS.

@Joachim

Dein Satz
„Welche Landclass gerade aktiv ist bzw. welches File kann ich auch nicht direkt auslesen.“

Ich wollte dich noch einmal hinweisen, ob du bei deiner Arbeit hier eventuell Möglichkeiten siehst. Da ich bei vielen deiner Antworten auf Beiträge gemerkt habe, dass der Anwender nicht richtig aussagen kann, was er sieht.
Vielleicht finden wir hier Möglichkeiten. Hat aber sicher keine Priorität.

Wir transportieren solange Vermutungen, bis es eine SDK gibt, und decken später Fehler der SDK auf bis der FS 10 erscheint. Nur die Gemeinschaft schafft diese „Probleme“ zu lösen.

Horst

Wenn ich Möglichkeiten sehe werde ich das bekannt geben. Momentan sehe ich da aber keine große Chance. Wenn wir ehrlich sind hat der FS momentan ja offensichtlich selbst Problem zu entscheiden was er denn nun anzeigen möchte oder soll. Siehe auch vertauschte Area16N Flattenpriorität. Das ganze Thema was du für wünschenswert hälst, welches aus meiner Sicht natürlich allen bei der Fehlersuche helfen würde ist mit Sicherheit auch nicht so einfach zu realisieren. Als Beispiel Area16N Flatten. Als ich diesen Bug entdeckt hatte habe ich zu Demonstrationszwecken in die Doku (die damals zu dem Flackerproblem des FS2002 auf meiner Homepage lag) ein Tesfile veröffentlich welches drei überlappende Area16N Flattenpolys enthielt alle mit unterschiedlichen Höhen. Hier konnte man den Bug genau erkennen. Speziell wenn man in der Scenerybiblothek die Priorität der Polys vertautschte. Fakt ist aber auch alle drei waren gleichzeitig aktiv.

Es würde uns also nichts nutzen wenn wird den Speicher auslesen könnten und hier erkennen würden die Dateien X bis Y sind geladen.

Nein wir müssten eine punktuelle Auswertung machen. Also was befindet sich exakt unter dem Refpoint des Flugzeuges. Nun ist es aber so das ich bei den VFR Airfields Vol 1 für den FS2004 unter anderem insofern mitgearbeitet habe um hier nach Möglichkeiten zu suchen einen möglichst geringen Autogenverlust im Bereich um die Scenerien zu erreichen. Quasi das Optimum herauszuholen.

Dabei mußte ich aber feststellen das es nicht immer der Refpoint des Flugzeuges allein ist der hier als Steuerbasis für eine Anzeige von Scenerydefinitionen dient.

Es sind auch die verschiedenen Sichtbedingungen. Daher dürfte das ganze Thema nicht einfach sein. Die vernünftigste Eingriffstelle wäre daher eigentlich bei der Information die zur Grafikkarte geht bzw. kurz davor. Jetzt müßte man rausfinden aus welchen Sceneryinformation sich diese Grafikinformation aufbaut.

Das dürfte nicht ganz einfach sein und würde meine Kenntnisse übersteigen. Ich denke dazu müßte man genaueste Kenntnisse der Programmierung des FS haben. Nur den Quellcode des FS wird uns bestimmt keiner in die Hand drücken.

Ev. helfen natürlich bereits weniger Informationen.

Zum Thema SDK gebe ich Dir recht. Zum einen waren schon sehr oft Fehler drin enthalten. Zum anderen hat es zum Thema Landclass schon im FS2002 so gut wie keine Informationen gegeben von daher sehe ich es fast so wie es Holger geschildert hat. Es wird vermutlich auch beim FS2004 nicht viel kommen. Deshalb interessiert mich ja auch gerade dieser Satz den ich oben aus der FlightXpress zitiert habe.

Bisher war es wie gesagt dürftig was im FS2002 SDK Stand. Danach hätte man allenfalls Grundtabellen erstellen können. (die übrigends für den FS2004 zum Teil nicht mehr gelten würden).

Diese ganzen Sonderformen wie bei verschiedenen Steigung wurden bisher immer unterschlagen in den Informationen.

Joachim, ich bin halt derzeit leider nur ein Ideenlieferant.
Ich kann mit eurem Wissen nicht mithalten und muss ständig nachlesen, wenn ich manche Zusammenhänge nicht verstehe, die ihr erklärt. Daher bin ich hier sehr zeitaufwendig und langsam unterwegs und bedanke mich für die Mühe der Beantwortung meiner Fragen.

Vielleicht bringen meine Aussagen und Links, euch und andere Mitlesende auf Gedanken, deren Potential ich noch nicht erkenne bzw. falsch interpretiere. Irgendwann werde ich aufholen, und meine Gedanken darstellen. Es ist bereits zuviel Kommerz in dieser Szene.

z.B die Idee, die keiner überprüfen muss:
Warum nimmt man nicht ein Orthofoto, legt z.B Vektordaten von Strassen darüber, bzw hat welche, die genau passen.
Füttert mit diesem Layerbitmap (also nur die Strassen) AA. Anschließend generiert man automatisch entlang der Linien Häuser.
Die Strassen werden wieder mit Exclude-Befehl gelöscht und man hat vielleicht eine Stadt mit Fotoszenerie und Autogen am richtigen Platz (mir gefällt das nur für einen Stadt)
Rasch und einfach, ohne viel Arbeit.
Ob dies so funktioniert – keine Ahnung. Ich will nur nichts händisch machen bzw. Linien und.Polygone „malen“.

Auch diese Anleitung muss ich noch durchdenken bzw. aufarbeiten:
http://www.ucalgary.ca/~clarko/garmi...ial/index.html

Daher suche ich nach dem richtigen Input.
(natürlich auch Holgers und Jims Weg)

Vielleicht auf dieser Seite unter Geobasisdaten
http://www.bev.gv.at/
(für Mitlesende: gute und kurze Beschreibungen und Informationen für Österreichs Geodaten)

Mir schwebt vor aus Datenmaterial, das eigentlich viele Leute haben, ein Bitmap zu machen, wie unter den Punkten digitales Landschaftsmodell (Verkehr, Siedlung, Gewässer) und digitales Geländehöhenmodell (Höhenlinien).
Der Preis-Link funktioniert bei mir nicht, aber sicher nicht bezahlbar.

Ich möchte diese Daten von vielleicht vorhandenen Produkten auch nicht hacken, sondern eine Möglichkeit suchen, wie dies jeder einfach in dieser Art (eben nach Layern getrennt) darstellen kann.

Vielleicht find ich eine halbwegs legale Methode, um mir selbst ein schönes Österreich zu erstellen – erstelle eine Anleitung – und andere dürfen dies für ihr Land machen.
Und wir teilen unsere Freude mit anderen, so wie Holger es macht.

Ich will ganz einfach nicht hunderte Euros an automatisierten Szenerien, mesh, landclass, autogen ausgeben, nur damit ich ein paar Länder abdecke und der Rest der Welt schlecht aussieht. Dann wird das Hobby zu teuer.
Und mein FS soll ja auch ein kleiner Earth-Explorer sein.

Horst

Zu Holger:

"Warum nimmt man nicht ein Orthofoto, legt z.B Vektordaten von Strassen darüber, bzw hat welche, die genau passen.
Füttert mit diesem Layerbitmap (also nur die Strassen) AA. Anschließend generiert man automatisch entlang der Linien Häuser.
Die Strassen werden wieder mit Exclude-Befehl gelöscht und man hat vielleicht eine Stadt mit Fotoszenerie und Autogen am richtigen Platz (mir gefällt das nur für einen Stadt)
Rasch und einfach, ohne viel Arbeit.
Ob dies so funktioniert – keine Ahnung. Ich will nur nichts händisch machen bzw. Linien und.Polygone „malen“."

Ich auch nicht.


Problem ist woher bekommt man kostengünstig ein großes Orthofoto von Deutschland. Nirgends. Die paar Städte von Deutschland in D-Sat kann man vergessen. Real Germany basiert auf Orthofotos. Wir kennen die lückenhafte Abdeckung Deutschlands. Also ist Orthofoto nicht bezahlbar und nicht ausreichend abgedeckt. Überlagern reiner Vectordaten auf ein Orthofoto ist so nicht möglich. Wüsste nicht mit welchem Tool. Klar wenn ich mir z.B die Vectordaten aus meinem NAV System nehme und zwar als Screenshot aus dem Kartenplaner dann kann ich das überlagern.

Im Prinzip kann ich auch aus TOP50 das Straßennetz abfiltern über Masken. So habe ich nur noch das Straßennetz. Nachteil das abgefilterte ist nicht immer 1 Pixel breit so wie es Autoasm gerne hätte. Auch die Eckpunkte sind nicht optimal. Hier stellt Auto ASM auch gewisse Ansprüche bei Kreuzungen von Linien. Gut bekommt man irgendwie in den Griff. Nur dann bliebe noch der Code mit den vielen Vectorpoints bei Autoasm.

Gut müssten wir ev. mal dem Author schreiben ob er da was machen kann.

Ev. ist der Nachfolger von Strip irgendwann das Maß der Dinge.

Mir persönlich würde natürlich am ehesten ein Tool passen welches die vectorisierten und komprimierten NAV Daten der gängigen z.B Navigon Fahrzeugnavigationsdaten direkt ausliest also ohne über ein Grafik zu arbeiten. Quasi ein reiner Konverter der umrechnet.

Dazu müsste man wissen wie das ganze codiert ist.

Denn diese Daten reichen aus sie sind perfekt. Und sie haben die wesentlichen Informationen bereits ohne Überflüssige Punkte intergriert.

Übrigends anhand des NAV Materials (ev. der Screenshots) wollte ich mal probieren Landclass automatisch zu programmieren. Ich habe das damals anhand TOP50 Screenshots schon erfogreich für größere Projekte Mit Corel und Adope Photoshop durchprobiert.

Bei TOP 50 war aber das Problem das zuviele Informationen die selbe Farbe hatten. Z.B Straßen und Bebauung. Bei den Navigon Daten ist das besser.

Sogar Industriegebiete sind hier farblich abgesetzt. Das ist schön für Landclass.

Nur verschieden Waldarten, Agrarflächen (Wiese,Feld) Stadt oder Wohngebiet das ist leider nicht auswertbar.

Da muß man dann manuell nachbessern. Nur anhand welchen Informationen?

Selbst bei D Sat ist das bei den Satelittenfotos nicht so einfach erkennbar.

Man könnte die Satelittenfotos zwecks Hilfe zumindest als Objekt deckungsgleich als Hilsmittel überlagern.

Mal sehen irgendwann komme ich dazu. Nur ich vermute ich werde das selbe Problem haben wie Rainer. Es muß vermutlich entzerrt werden.

Hi!
Es wäre ein Traum,LC's anhand von Navigationsdaten(KFZ) zu Automatisieren.
Weiss denn wirklich keiner wie diese Systeme codiert sind?
Falls das jamals klappen sollte,hätten wir die beste Landclsszuordnung
die man haben kann!

Mal was ganz anderes:
Ich bin gerade dabei Süd Niedersachsen mit G2K zu erstellen.
Nach einigen vorab Tests steht nun für mich fest:Es muß alles an Straasen,Flüßen etc. exludiert werden.
Nur so kann ich möglichst genau Arbeiten.
Da diese Fläche für mein vorhaben recht groß ist,suche ich nach einer Automatisierung dieser Files,die excludiert werden sollen.
Es ist eine Schweine Arbeit;)jede einzeilne Cell in G2k anzuklicken und dann zu bestätigen.
Da ich mich nicht iritieren lassen will,habe ich eine Wald Textur über das gesamte Gebiet gelegt.
Nun kann mich zum beäugeln der div. Abschnitte keine Default LC ablenken(da alles Wald ist).

Ganz zum Schluß von diesem Project,will ich LC's zuordnen.
Macht das überhaupt Sinn mit G2K?
Formgebung der LC's ist ja mit G2K wunderbar zu realisieren,ansonsten wird es eine recht langwierige Angelegenheit,mit sehr vielen Überlappungen.
Gibt es denn schon irgendwo LC Editoren für den 04er?
SCC,oder FS Landclass waren ja ganz unangeneheme Zeitgenossen zur LC Produktion.
Dann doch lieber G2K :rolleyes:
Oder Joachim bastelt ein Tool;)

Wer weiss,wo die Scenery Entwicklung hingeht...........
LC oder Photo mit Autogen???
Ich denke letzteres wird sich zumindest in kleineren Gebieten durchsetzen.(siehe ISD-VFR Milano)
Doch was ist mit dem Rest der Welt?
Mann/Frau braucht weiterhin Landclasses,nur mit was am besten erstellen??
Gruß::)

Hallo Schubi:

Suedniedersachsen? Ist da zufaellig auch meine Geburtsstadt Hameln mit drin? ;-)

Bzgl. Excludieren wuerde ich dir eine von zwei Moeglichkeiten empfehlen.

1. DefArea 2.0, von Christian Fumey (Autor von G2K4); das enthaelt zwei .exe Files; mit Excl8.exe kannst du beliebige Layer in LOD8-Zellen excludieren und mit DefArea.exe im FS ueber einzelne Linien fliegen und die somit aufgenommenen LOD13-Zellen als Exclude-File erstellen lassen. Mit anderen Worten, Excl8.exe ist fuer die Grobarbeit und DefArea.exe fuers Detail.

2. Mit LWMViewer von Jim Keir die LOD5 FS Rohdaten (VTP und LWM)decodieren, im Texteditor die gewuenschten LOD8 oder LOD13 Sektionen entfernen und dann mit BGLC.exe wieder kompilieren. Dieser Ansatz erfordert zusaetzliches Wissen ueber den Aufbau der .asm Dateien, ist aber nicht so schwierig.

Die erste Moeglichkeit ist die technisch saubere, weil sie nicht mit den Originaldaten rumfummelt und die Excludes schoen aussen vor bleiben.

Die zweite Moeglichkeit ist die optisch bessere (und moeglicherweise auch Framerate-freundlichere), da sie die Flattens der default Seen, Strassen, Eisenbahnlinien und Baeche aus dem Weg schafft und ganz ohne Excludes auskommt.

Die Strassen, Eisenbahnen und Fluesse von meinen Rocky Mountains Ground2K4 Files habe ich mit der DefArea Methode excludiert. Gerade gestern habe ich aber diese Excludes durch editierte Defaultdaten ersetzt und der Unterschied ist doch gewaltig. Vorher war an vielen Stellen im Mesh Terrassen zu erkennen, die den Verlauf der default-Strassen usw. aufzeigten. Jetzt ist alles genau so, wie es sein sollte.

Fuer die flacheren Gebiete von NS reicht wahrscheinlich die DefArea Methode aber fuers Weserbergland koennte die LWMViewer-Methode Vorteilhaft sein.

Jedenfalls ist es kein Problem, mit DefArea anzufangen und dann hinterher zu entscheiden, ob du nicht doch lieber die zweite Methode anwenden willst.

---

Landclass-editieren ist ziemlich langwierig. Fuer das Glacier Bay Projekt habe ich Satellitendaten klassifiziert, aber (abgesehen von den technischen Anforderungen) im stark bebauten/fragmentierten Europa wuerde ein aehnliches Verfahren sicher schwierig sein, da dort sehr viele verschiedene Klassen erzeugt werden wuerden.

Eine einfache Moeglichkeit, LC Dateien schnell zu fuellen, ist mit EZ-Landclass, das ja als EXCEL-Makro arbeitet. So koenntest du in Ground2K4 z.B. die besonderen LC, wie Ortschaften und Staedte, "punktgenau" deklarieren, dann die .raw Datei in EZ-Landclass importieren und die offenen Flaechen mit einem mehr oder weniger zufaelligem Muster aus Agrarland und Wald fuellen.

Cheers, Holger

Hallo Holger,

Hameln... :) So schön an der Weser gelegen. :D

Sorry Holger, werde mich auch noch bei Dir melden. Habe momentan mit meiner OWL2003-Fertigstellung zu kämpfen.

Excludieren von größeren Bereichen geht natürlich auch komplett ohne Ground2k. Excludiere mal in Ground2k nur eine einzige kleine Zelle (oder auch 2) und schaue Dir an, welches Format die dazugehörige und von Ground2k erzeugte asm-Datei hat... wer jetzt 1 und 1 zusammenzählen kann hat blitzschnell einen kleinen Algorithmus, der dies automatisch löst... (und dies dann auch auf den Layern, die man benötigt).

Schubi, kannst ja mal was rüberwachsen lassen, wenn Du was von Deiner Szenerie "testfähig" hast. Bin sehr interessiert, zumal ja Göttingen und das Weserbergland nicht weit weg von meinem Ostwestfalen sind...

Automatismus von Landclass-Zuweisungen... da wäre ich auch sehr interessiert dran... wobei ich mir keine Landklassen im herkömmlichen Sinne, sondern - da viel genauer - VTP-Polygone vorstelle.

Ciao,
Rainer.

Schönen Abend,

Das Konvertieren ist nicht unbedingt das Problem. Dies darf ich auf meinem PC sicher. Und dann?
Ich habe nichts davon, ich darf es nur illegal anbieten. Ich besitze aber nicht alle Daten.
Pech, ich werde keine schöne Welt erhalten.
Je genauer man zu den Landvermessungsdaten kommt, desto strikter der Handel mit diesen Daten.
Weder Fugawi, OziExplorer usw. darf dies weiterverarbeiten aus Lizenzgründen.
1:1 Konvertierung optimal, aber nur Vorsicht – alle Daten haben kleine Fehler. Der Nachweis für den Datenanbieter relativ einfach.

@Joachim

- Klar wenn ich mir z.B die Vectordaten aus meinem NAV System nehme und zwar als Screenshot aus dem Kartenplaner dann kann ich das überlagern.

Habe ich gemeint.

- Nur dann bliebe noch der Code mit den vielen Vectorpoints bei Autoasm.

Ist kein Problem und muss sein, je genauer du es darstellen willst Habe ich weiter oben geschrieben.

- Bei TOP 50 war aber das Problem das zuviele Informationen die selbe Farbe hatten. Z.B Straßen und Bebauung. Bei den Navigon Daten ist das besser.

Bei Top 50 oder 25 finde ich derzeit keinen sinnvollen Weg, zu viele Informationen die ich nicht einfach und rasch trennen kann.
Die Layerstruktur bei anderen Daten ist interessant. Habe ich verlinkt.
Holgers und Jims Weg über Satellit ebenfalls.

- Nur verschieden Waldarten, Agrarflächen (Wiese,Feld) Stadt oder Wohngebiet das ist leider nicht auswertbar.

Dies geht nur über kleinsten Raum (mit gescannten Karten, teilweise Internetkarten – kleinflächig und umständlich) und ist großflächig noch nicht erfasst. Aber vielleicht gibt es hier auch Möglichkeiten über Satellit.

@Holger, Schubi

bitte lasst Möglichkeit 2 derzeit aus bzw. verbreitet sie nicht. Es gibt auch Autoren die dies mit Installationsprogrammen ganz einfach ersetzen. Oder man deckt das ganze Gebiet ab.
Ich hoffe noch immer, dass bald eine Möglichkeit dafür von MS veröffentlicht wird. Sonst gibt es ein Chaos.
Außer cfs2conv2.

__________________________________________________ ___________________

Nur falls jemand zufällig vor einem Image Web Server sitzt und die Enterprise Edition lizenziert ist (und keine Ahnung hat was er damit anstellen kann)
Bei Jim Keir melden als Tester.
Dies runterladen:
ecwp://www.earthetc.com/Images/geodetic/world/Landsat742.ecw
inptut size: 2113.21GB or 2.06TB
Output size: 26.4GB
http://www.earthetc.com/ecwearth/asp...rld/landsat742
auf about klicken
für “kleinere” Bereiche
http://www.earthetc.com/imagery_list...LOCATION_ID=17
Anschließend mit Strip testen.
Was es noch alles gibt hier: http://www.earthetc.com

Horst

Hi!
Vielen Dank für die vielen Tips,diese müssen jetzt erstmal verdaut,verstanden und verarbeitet werden.
EZ Landclass? Wohl ein Editor?Wo findet man den?
@Holger:Hameln ist leider nicht mehr mit drinn:rolleyes:
Mein Bereich den ich umsetzen will hat eine Durchschnittliche größe von ca.40-50 Km.
Das sollte für den Anfang auch erstmal reichen.
Aber es ist durchaus möglich in Zukunft,Richtung Hameln weiter zu machen.
@Rainer:Hauptsache ich kappiere was Du meinst mit 1+1?
Bin ja noch ein völliger Rookie im Desighnen:rolleyes:
Sobald ich was fertig habe lass ich es Euch wissen.
Erwartet aber nicht zuviel davon:lol:
Kann aber dauern(Familie,bin Musiker und t.w.Schichtarbeit).
Da muß man sich die Zeit schon gut einteilen.
Gruß::)

z.B
http://www.simviation.com/fs2004utilities1.htm

Horst

Sorry

Zunächst mal hätte ich oben "zu Horst" schreiben müssen und nicht "zu Holger".

Horst Deine Links sind sehr interesant. Leider wenn es um Datenmaterial geht welches man nützen könnte dann klappen bei mir immer die Augen zu denn das hat sich für mich dann mit Modem erledigt.

Ich habe leider auch das Problem das ich zu weit weg von der Vermittlungsstelle liege. DSL ist da nicht möglich. Allenfalls halbe Datenrate könnte ev. klappen. Von daher kommt für mich nur das in Frage was man normal halbwegs kostengünstig kaufen kann.


"Nur dann bliebe noch der Code mit den vielen Vectorpoints bei Autoasm".

""Ist kein Problem und muss sein, je genauer du es darstellen willst Habe ich weiter oben geschrieben"".


Sehe ich nicht ganz so. Bei engen Radien z.B Autobahnauffahrten OK gebe ich Dir recht. Aber nicht wenn hier eine Autobahn mehrere Kilometer fast gerade aus läuft. Gerade bei Autobahnen kann auf extrem viele Vectorpoints verzichtet werden. Auch bei den normalen Straßen ist extrem viel einzusparen. Meiner Meinung nach überwiegt bei weiten der Anteil dessen wo man auf Vectorpoints verzichten kann gegenüber dem Teil wo man sie für Rundungen benötigt.

Von daher sehe ich das anders.

Siehe auch was Holger schrieb. Löschen von Informationen aus Defaultfiles. Hat den Vorteil das nicht nur das Mesh nicht durch die excludierten Defaultstraßen bzw. die Flüsse versaut wird sondern auch die Performance besser wird.


Ich gebe Dir recht man wandert da auf dünnem Eis. Es ist gefährlich wenn mehrere Designer gleiches vorhaben. Zumindest muß es gut dokumentiert sein und jeder muß in Bezug dessen zu einer Interessengemeinschaft bereit sein damit man ev. dann hier die Änderungen unter eine Hut bringt.

Ich vermute leider nicht das uns ein SDK dort eine andere Lösung bietet.

Vielleicht haben wir Glück.

@ Joachim

mein letzter Link: uneingeschränkter Download kostet ca. 50.000 Dollar. Aber vielleicht sitzt jemand vor diesen Geräten bzw. hat Zugang.
Aber dies sind Daten die Holger verlinkt hat. Nur in Mosaik zusammengefügt.

Bei AA:
Jeder Punkt ist zu vermeiden. Gebe ich dir völlig Recht.
Aber bei genauer Darstellung gibt es sehr wenige Geraden.
Und etwas zu Laden und dann zu excludieren ist auch nicht sinnvoll. Genauso wie hunderte kleine bgl-Dateien.

@ Holger

Ich habe leider heute keine Zeit gefunden meine Ideen bezüglich der Küstenlinien darzustellen.
Wenn man diese Linien absichtlich unterbrechen könnte, wäre dies für mich wirklich sehr toll.
Ich hoffe, ich darf dies darstellen.
Es ist keine Kritik, sondern meine Überzeugung, dass diese Programme der Weg für Automatismen sind.

Horst

"Jeder Punkt ist zu vermeiden. Gebe ich dir völlig Recht.
Aber bei genauer Darstellung gibt es sehr wenige Geraden".

Gut drücke ich meine Meinung anders aus. Meiner Meinung nach tut diese Genauigkeit nicht not.

Werde wenn ich dazu komme mal mit Autoasm ein paar typische Straßen aus unserer Gegend machen. Werde es in eine BGL kompilieren. Anschließend werde ich diesen Code bereinigen ev. ein Pedant der Straßen erzeugen der verschoben mit einer anderen Textur liegt. Du wirst dann im Prinzip zwei verschiedene Straßennetze sehen die der Realität entsprechen. Ich denke dann wirst Du sehen das im FS es genau genug mit weniger Points ist. Das was ich bei Autoasm an Fehlern gesehen habe was passiert wenn deine Ausangsgrafik zu klein ist also dann wenn das Tool in die Bedrullie kommt alle Ponis unterzubringen dürfte dann sogar zu optischen Verschlechterungen führen.

Am besten wenn wir/ich Zeit habe tauschen wir uns mal mit Bitmaps aus.

Klar ich habe bei Autoasm ein ungelöstes LWM Problem.

Aber bei VTP2 stelle ich mir vor dürftest Du die selbe Problematik haben.

Joachim, du kannst mir gerne etwas Konkretes schicken und ich überprüfe dies. Anschließend können wir unsere Bitten und Fragen an Chris Wright richten.

Auch das Angebot an Jim und Holger für Strip. Wenn ich etwas ausprobieren soll, bitte nur sagen. Brauch aber dann wahrscheinlich eine kurze Anleitung.

Ich mache dies normalerweise sehr sorgfältig.

Übrigens Joachim noch ein Hinweis:
http://rst.gsfc.nasa.gov/Front/tofc.html
Eine sehr gute Seite über Satellitentechnik der NASA. Mit sehr vielen kleinen Beispielbildern. Ich lese hier sehr oft nach. Auf dieser Seite kann man Stunden verbringen.

Horst