Für RLUND unsichtbare Runway

[schubi]

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
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ß:

[JOBIA]

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.

[Horst LOWW]

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

[Horst LOWW]

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)

[BC_Holger]

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

[JOBIA]

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.

[Horst LOWW]

@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

[JOBIA]

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.

[Horst LOWW]

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

[JOBIA]

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.