@Rolf:

naja... so groß ist mein Ostwestfalen-Gebiet ja nicht. Da geht dies relativ zügig. Die damals händische Anpassung der Landklassen-Kacheln im FS2002 auf Grundlage der Scenery-Germany-LC selbst hat viel länger gedauert. Darum hab' ich dies auch dieses Mal gar nicht mehr versucht und dies nur entsprechend in der Anleitung erwähnt. Zumal ich ja für eine neue Version schon die andere Technik in der Hinterhand habe...

Klar habe ich mir Eure Airports sehr genau angeschaut. Und wie gut ich die finde hab' ich auch an jeder Straßenecke weitergesagt... Ist Christoph und Dir doch ganz sicher nicht verborgen geblieben.

Wegen den harten Kanten hast Du natürlich einen Einwand gebracht, den ich mir auch entgegengestellt hatte. Wenn ich mich aber auf meinen letzten Realflug richtig entsinne... da gab es auch absolut harte Kanten. Wälder fangen nun mal z.B. - da hat die Landschaftsreform der Kommunen zugeschlagen - mit einer harten Kante an.

Ich denke, eine einhundert-Prozent-Lösung werden wir in diesem Spiel (es ist ja immer noch eine Freizeitbeschäftigung, der eine bekommt dafür vielleicht zusätzlich ein Taschengeld, der andere eher nicht-materielle Dinge) sowieso niemals erreichen. Mein Ansporn an dieser Technik war einfach mal, die Möglichkeiten in dieser Richtung auszuloten.

Was auf jeden Fall fehlt sind passende europäische Strukturen, gerade für Bebauung. Was uns Microsoft da übrigläßt mit nicht-amerikanischer Rechteckstruktur ist nicht sonderlich gut geeignet. Aber besser als gar nichts.

@Schubi:

Überlappungen? Nööö... da gibt es Tricks. ;) Du mußt ja nicht alles in eine bgl packen. Ist sowieso nötig, weil ja - wie Jobia doch glaube ich herausgefunden hat - ansonsten die "leuchtenden" Wälder in der Dämmerung entstehen, also falsche Untergrundtexturen bei Beleuchtung gewählt werden.

Ciao,
Rainer.

HI Rainer!
OHHH-Brett vor meiner Birne:rolleyes:
Klar doch,mehrere BGL's zb. Wälder unter sich etc.!
Habe gerade das neue Autobahndreieck mit dem derzeitigen Namen: Dametahl,in Zukunft wohl Friedland/Göttingen erstellt.
Ab hier wird es möglich sein von Göttingen(A7)nach Halle zu kommen(A81)
Die Kommunen streiten sich heftigst über einen Namen:lol:

Was für ein Frickelkram in G2K,doch ich wollte es ja nicht anders;)

Mit den harten Kanten sieht das bei Ortschaften nicht ganz so prall aus,aber immer noch besser als eine ungenaue Form über den klassischen weg.
Gruß::)

Naja,
Eigentlich haben wir uns auf einen sachgerechten Austausch geeinigt.
Vermutungen sollten vermieden werden, wenn man keine Ahnung hat.

Ich möchte bitten Holgers Meinung auf Seite 2 (Beitrag 2 und 3) noch einmal zu lesen.

Man darf im gesamten Beitrag manchmal zweimal lesen.

Man kann auch einen neuen Beitrag eröffnen:
z.B „Meine Vermutungen zu Scenery Design – die Zukunft“
und seine Meinung hinschreiben.
z.B : Mit Automatismus für mich nicht realisierbar.

Ich würde darum bitten. Mir persönlich wird es zu unübersichtlich, und es macht auch keinen Spaß, aufgrund der Wortmenge, diese Vermutungen zu lesen, und Informationen zu überlesen.
________________________________________________

@ Joachim
Das Foto Top sollte nur zeigen, dass es relativ sinnlos und langweilig ist, Linien zu zeichnen, die es bereits gibt.
Ja, wir brauchen ein Bitmap.
1:1 ist Datendiebstahl, und geht nur über hacken von bestimmten Datenmaterial (jeder braucht das gleiche Material oder macht es selbst)
Hat irgendjemand schon einen Ground2k – Designer angezeigt, da er ein Copyright verletzt hat?
__________________________________________________

Wenn meine Links keiner liest, bitte schreiben, stelle ich den Service ein. (sind nur Auszüge aus meinem GIS Favoritenordner)

z.B Luftbilder:
über Doug Cox und Terraserver nachdenken, und ganz Bayern runterladen, hier:
http://www.geodaten.bayern.de/bayernviewer/index2.html.

Tolle Bilder findet man auch hier:
http://www.spaceimaging.com/
http://www.spotimage.fr/html/_167_.php

z.B Wasserspezialisten:
2 Beispiele:
a)Ein kommerzielles Produkt, bei dem man sehr viele Linien, Polygone und Punkte sieht. Oder?
http://www.garmin.com/cartography/bathymetric/
Hier gibt es auch einen MapViewer, wo man alle Produkt ansehen kann.
b) z.B Kostenlos
http://chartmaker.ncd.noaa.gov/mcd/enc/download.htm

Horst

Horst,

ich gehe davon aus, dass Du entweder mich, Rolf oder Schubi gemeint haben mußt, wahrscheinlich aber mich.

Ich entschuldige mich hiermit in aller Form für meinen unqualifizierten Beitrag aus der Designerpraxis, der der letzte in diesem Thread gewesen sein wird. Und auch gleich für diesen hier mit, falls ich meinem Avatar wieder zu ähnlich geworden bin.

*kopfschüttelnd*

Ciao,
Rainer.

@Rainer
Verzeih, ich wollte wirklich niemanden beleidigen. Also bitte ich um Entschuldigung, falls ich die falschen Worte gewählt habe.
Ich verliere nur die Übersicht.

z.B:
Zu genau, oder geht das?

Land:
http://www.spotimage.fr/automne_modu...idobre_800.jpg
http://www.spaceimaging.com/gallery/...03/top10_2.htm

Stadt:
http://www.spotimage.fr/automne_modu...ulouse_800.jpg
http://www.spaceimaging.com/gallery/...03/top10_7.htm

Flächenwidmung Wien:
http://service.wien.gv.at/flaechenwidmung/
Wienübersicht – 2 x Reinzoomen
Sieht so aus wie mein Anhang.

Horst

@Horst:

Kein Problem. (es gab also doch noch einen Beitrag...) * aber hoffentlich der Übersichtlichkeit halber kurz genug * ;)

Ciao,
Rainer.

Zu den VTP Polys Rainer. Meiner Meinung nach wirken sei auch etwas zu aufgesetzt. Ich weis nicht ob Du es mitbekommen hast. Aber bei meiner Fehlersuche wegen der leuchtenden Nachtpolys ist mir aufgefallen das der FS2002/2004 nicht nur bei Custom Foto Scenery den Bug hat das die Texturen vertikal gekippt sind. Nein er hat ihn generell bei VTP2 Polys. Das bedeutet bei VTP2 Polys wird Autogen immer falsch positioniert.

Bei Custom Fotoscenery kennen wir die Tricks. Bei Landclass sehe ich das schwieriger. Schlieslich müssen sie seitenrichtig für globales Landclass vorliegen. Auf der anderen Seite gekippt für VTP2 Landclasspolys. Nicht ganz einfach. Da muß man erst mal testen was geht ohne das man sich gleich wieder ein Speicherleck einfängt.

Übrigends anhand meiner Testfiles habe ich im FS2004 wieder eine Ungereimtheit entdeckt. Mal sehen ob das im FS2002 auch der Fall ist.
Sollte das im FS2002 funktionieren dann wäre das nicht gut für den FS2004. Denn dann ist mit der Brauchbarkeit von halbwegs genauer Positionierung im FS2004 nicht weit her.

Horst noch mal ein Beitrag zum Thema Bitmap Auswertung. War Offline vorgeschrieben. Ev. würde ich ihn jetzt abändern aber ich denke so kommt die Problematik eindeutig rüber die ich sehe. Meine Meinung bezogen aus der Praxis auch bei Landclass.

Mal etwas weg von der Theorie zur Praxis. Nehmen wir mal an man wollte für ein Bundesland wie Bayern das Straßennetz mit Autoasm realisieren.

Nur mal angenommen wir wollen sehr genau arbeiten (wie Du das zuvor in der Diskussion favorisiert hast) so das Kurvenradien von Straßen perfekt abgebildet werden. Wir müssten demnach in der Auswertebitmap anhand der Autoasm arbeitet mindestens jeden im FS möglichen Vectorpoint verfügbar haben. Eher noch mehr.

Gehen wir aber von der absoluten Superhintergrundbitmap aus. Ideal vorbereitet, entzerrt jeder Vectorpoint ist umgesetzt. Es ist so wenig Information wie möglich vorhanden also keine Punkte die ev. zwischen Vectorpoints liegen. Gehen wir nur mal davon aus das ein Bundesland wie Bayern in einem LOD5 Quadrant also dem was der kleinsten Definitionsgröße bei einem Landclassfile entspricht umgesetzt ist. Das schwankt je nach Größe und Form des Bundeslandes etwas. Im Mittel ist diese Annahme für den Informationsinhalt von Bayern aber gerechtfertigt.

Der Landclass Scenerypack Germany war bei Burkhard Renk übrigends in 17 solcher LOD5 Quadranten definiert. Es hat damals natürlich mehr als Deutschland abgedeckt. Auch Teile Hollands, Österreich, Dänemark usw. waren dabei. In Quadranten kann man halt nicht genau die Grenzen definieren.

Nun bleiben wir bei obigem Beispiel für Bayern. Dann wären in diesem File 65536 x 65536 mögliche Vectorpoints als Information enthalten. Was natürlich einer Hintergrundbitmap von eben 65536 x 65536 Pixeln entspricht. Würden wir radikal alles was für Deutschland nicht benötigt wird weglassen, blieben wir immer noch bei einer Information die mindestens 6 LOD5 Quadranten entspricht. Das würde z.B einer Bitmap von 131072 x 196608 Pixeln entsprechen.

So günstig kommen wir aber eh nicht weg. Denn eine Bitmap ist nun mal eckig und wenn wir in einem Rutsch arbeiten wollen müssen wir alles überflüssige auch mitschleppen. Ich gehe jetzt aber trotzdem mal von dem günstigen Fall aus.

Nun Chris Wright hat zumindest bis 10000 x 10000 Pixeln sein Autoasm getestet. Davon ab das er als höchste Bildschirmauflösung 1280 x 1024 unterstützt dürfte es dann schon optisch nicht so einfach sein das alles vernünftig zu nutzen. Das wird eine ganz schöne Scrollerei wenn man das betrachten will. Gut hier sehe ich jetzt erst mal nicht die Begrenzung. Ich sehe sie schon vorher wenn ich mir oben nur diesen einen LOD Quadranten für Bayern anschaue. Nämlich vorher beim Fotoprogramm bzw. dem PC selbst.

Also mein Corel Photopaint lässt egal welche Farbtiefe ich wähle (8Bit wäre für Autoasm ausreichend) nicht mehr als 30000 x 30000 Pixel zu. Das wären 7.200.000.000 Bit oder eben 900.000.000 Byte ohne Header. Damit haben wir aber noch nicht mal ein Viertel der Fläche eines LOD5 Quadranten abgedeckt. Aber auch so sind das schon weit über 800MB Speicher die für diese eine Bitmap benötigt werden.

Adope Photoshop macht bei mir übrigends ebenfalls bei 30000 x 30000 Pixeln dicht.

Nun wollte man ja überlagern, das heist es kommt noch eine zweite Information dazu.

Ehrlich gesagt ich habe es nicht gewagt so eine Monster Bitmap zu erstellen. Jeder der schon mal ein DIN A4 Foto mit viel zu hoher Auflösung eingescannt hat und dieses Bildchen hinterher aus drucken wollte, weis wie so was in der Regel endet. Speziell wenn dann die Auslagerungsdatei in Anspruch genommen werden muß.

Bei einem Pentium3 700MHZ mit zugegebener Maßen nur 128 MB konnte ich diesen aber sehr schnell mit einer weitaus kleineren Bitmap zum Schwitzen bringen. Ein paar Aktionen und er wurde schon bedächtig langsam weil jetzt auch die Festplatte mitgenutzt wurde. Auf der Festplatte waren auch nur noch 370MB als Auslagerungsdatei übrig. Irgendwann kam dann die Fehlermeldung das auf den Arbeitsvolumen nicht ausreichend Platz zur Verfügung steht.

Selbst wenn ich meine Basisbitmap so reduziere das nur jeder 4 Vectorpoint zur Anwendung kommen kann wären das immer noch 16381 x 16384 Pixel.

Wenn Chris schreibt er hat Bitmaps über 10000 x 10000 Pixel getestet dann werden das keine 15000 x 15000 gewesen sein sonst hätte er das auch geschrieben. Ich denke er war knapp über 10000. Wenn ich mich recht erinnere wird in der Ground2K Doc der Anwender z.B darauf hingewiesen das große Bitmaps problematisch sein können.

Wird nur jeder vierte Vectorpoint in der Basisbitmap umgesetzt so haben wir eine Lücke von 3 Vectorpoints welches einer Distanz ca. 14,3m entspricht, die wir rein theoretisch (siehe unten) nicht abdecken.

Es könnte sein das man bei ungüstig verlaufender Linie in der Basisbitmap dieses später im FS als Sprünge in einer geraden Straße erkennen könnte.
So etwas hatte ich bei meinen Versuchen entdeckt.
Eigentlich wieder ein Grund warum das verwendete Tool generell nur Points umsetzen sollte wenn bei aufeinander folgenden Punkten definitiv eine Richtungsänderung erkennbar ist.

Autoasm bietet hier immerhin die Möglichkeit solche Effekte zu mindern (daher ein paar Sätze weiter oben theoretisch). Nur wenn die Bitmap nur jeden vierten Vectorpoint enthält kommen wir von Deiner gewünschten Genauigkeit weg.

Ev. habe ich Dich falsch verstanden oder Du hast es anders gemeint aber ich sehe es nicht so das man hier eben schnell mal was in ein paar Minuten vorbereitet. Erstens da man kaum die Möglichkeiten für so monströse Bitmaps hat (es sei denn man arbeitet ungenauer). Oder man bietet Autoasm viele kleine Bitmaps an welches natürlich mehr Vorarbeit bedeutet wenn noch die Entzerrung dazu kommt insofern man überhaupt vernünftige Möglichkeiten dafür hat.

Als ich damals mal Versuche mit automatischer Erstellung von Landclass gemacht habe (anhand Hintergrundkartenmaterial damals TOP50) mußte ich die auszuwertenden Bereiche auch drastisch verkleinern damit die automatische Auswertung nahezu alles an möglichen Informationen umsetzen konnte.

Da konnte man nicht auch mal eben ein komplettes Landclassfile mit abdecken

Dazu muß man bedenken, das ein Landclass RAW / BIN File im Prinzip nur schlappe 65536Bytes bei 256 x 256 er Definition bzw. 66049Byte bei 257 x 257er Definition hat.
Nur wenn man als Basis eine topografische Karte oder eben auch grafisch dargestellte Vektordaten hat müssen dieses ein vielfaches von dem sein um hier ein halbwegs vernünftiges Ergebnis zu erhalten. Zumindest ist das meine persönliche Erfahrung anhand meiner Versuche.


Wie gesagt mit anderen Material welches schon so eine Art Landclass vorgibt (worauf Du verlinkt hast) kann man bestimmt größere Flächen auf einmal machen.


Wie gesagt beim Straßensystem mit Deiner favorisierten Genauigkeit sehe ich keine Chance auf ein schnelle Lösung die sich auch in der Praxis umsetzen lässt. Zumindest nicht mit Tools die Bitmaps auswerten. So wie ich Holger verstanden habe wertet Strip bzw. dessen Nachfolger Slatibart oder wie es heist im wesentlichen eigentlich auch Bildmaterial aus.

Chancen alle diese Probleme einer grafischen Auswertung zu umgehen sehe ich wie gesagt nur bei Konvertierungstools ähnlich E00 Konverter der nur mathematisch umrechnet. Den könnte man dann über Nacht rechen lassen. Also ein Weg an solchen Tools wie Autoasm vorbei. Wenn man sich natürlich Navigationsdaten anschaut so kommen diese auch auf ca. 500 MB für Deutschland (je nachdem was noch alles enthalten ist) Der ASM Code den man vor dem kompilieren erstellen muß ist auch nicht ohne. Ich denke selbst hier könnte es Probleme geben für Deutschland alles in einem Rutsch abzufertigen.

Bei einem Konverter wenn das optimal sein soll hat man dann das Problem woher die hochgenauen Rohdaten, sind sie überhaupt frei verfügbar, was kosten sie, und wie sind sie verschlüsselt. (Aber das Thema hattest Du ja selbst schon erwähnt.)

Erst danach kann man sich über ein Tool Gedanken machen. Oder aber man geht den beschwerlichen Weg über Autoasm und kleinere Hintergrundbitmaps. Oder aber den ganz beschwerlichen über Ground2K.

Wenn das alles so leicht wäre, dann hätten wir bestimmt schon ein europäisches ADDON Straßennetz im FS. Der nackte BGL Code den wir benötigen ist schließlich schon seit Anfang Herbst 2002 bekannt.

Wie gesagt es wird wenn man Glück hat immer ein paar Leute geben die ev. Zugriff auf solche Spezialdaten und deren Code haben. Ähnlich hat es das ja bei anderen ADDONs schon gegeben.

@Rainer
Ich dachte, Holger hat dich überzeugt?
Und hoffe, es war nicht dein letzter Beitrag. Wir sollten nur versuchen, nicht in andere Bereiche uns zu entfernen (die wir derzeit verstehen), da der Thread so und so kompliziert zu lesen ist.
Die Vergangenheit kennen wir:
http://www.avsim.com/pages/0500/terr...rrascene.shtml
http://library.avsim.net/search.php?...Root&Go=Search
Die Gegenwart hast du mit deiner tollen Arbeit gezeigt (Danke nochmals)
Die Zukunft, und Automatismen wollen wir suchen – mit Fantasie, und die Autoren unterstützen.
Dies soll der Inhalt des Thread sein.
Ohne die Worte „das geht nicht“, sondern mit der Frage „wie könnte es gehen?“.

@Joachim
Viel Stoff, brauche ich sicher länger, und lese ich sicher noch einmal. Deine Hochrechnung ???? (muss ich überprüfen, da ich darin derzeit kein Problem sehe, für deinen Bereich) (am Rand: Vielleicht kann ich deshalb ein 500 MB img (global forest density) nicht darstellen – war die Frage an Holger).

Los Angeles Beispiel: 800x 600 Pixel genügt dies?
Ich denke nicht, kann man vielleicht noch genauer machen – die Grenze kenne ich nicht.

Zu gescannter TOPO habe ich geschrieben. Komplizierter Vorgang Daten zu filtern (vorher zeichnet man sie auf ein Blatt (ohne PC) - jetzt will man sie trennen - wurde und wird gemacht, durch professionelle Software – daher Topo Foto)
Umgekehrter Vorgang für GPS ebenfalls – siehe Ground2k.
Die Daten gibt es auf vielen Rechnern, nur die Möglichkeit nicht, sie halbwegs legal in den FS zu importieren (bei Freeware sehe ich kein Problem)
http://gpsinformation.net/#tutorial

TS Demo:
Daten von GPS Material (siehe TerraScene-Bitmap) und andere Darstellung bei Print Funktionen – bei GPS Material?
d.h andere Darstellungsversuche. So kann man dies derzeit im FS nicht darstellen. (siehe Holger und Dali)
Wenn ich dies nicht kann, anderer Algorithmus für Straßen (?) – Suche nach Vorschlägen für Chris Wright.

Meine Ideen zu Points – und vor allem zu POI - schreibe ich sicher noch.

Zu EOO:
Daten findest du hier zum experimentieren (hast du sicher keine Freude damit, aber kein großer Download):
http://data.geocomm.com/catalog/GM/datalist.html
Registrieren und runterladen (kostenlos).
Zum Lesen braucht man keine schnelle Verbindung, runterladen können es Freunde (siehe SRTM).
EOO Konverter ? - derzeit keine Ahnung.

Ich will keine Daten (die sind sehr teuer) stehlen (du sicher auch nicht) – auch kein Payware-Hersteller hoffentlich?(oder soll ich das Datenmaterial nachweisen?), es gibt genügend Bastler (siehe Anzahl der Downloads von Holgers Angebot - wollen sie nur Bilder ansehen?), die keine Ahnung haben, was sie mit ihren Daten bzw. Internetdaten anstellen können.

Falls ich Fragen unbeantwortet lasse (wie geschrieben deine Aussagen muss ich durchdenken), später nachfragen. Bilder sind kein Problem und erklären manchmal mehr als tausend Worte.
Wenn Bedarf und legal (wegen Veröffentlichung), hänge ich sie an.

Horst