Re: [Flightgear-devel] World Scenery 1.0.1
On jeudi 30 octobre 2008, Ralf Gerlich wrote: > Hello everybody! > > The World Custom Scenery Project is proud to finally present the > long-awaited bugfix release V1.0.1 of the World Scenery. > > The scenery can currently be downloaded at > http://mapserver.flightgear.org/Scenery > > We suggest that mirror provides fetch the release from there. > > Be sure to also download the shared models collection from > http://scenemodels.flightgear.org/download/SharedModels.tgz and unpack > the archive in your FGROOT folder. > > Outline of this mail: > - Contents of the scenery > - Acknowledgements > - Base data > - Airport data proposal > > Contents of the scenery > --- > > In addition to the bugfix the release contains some very fine bits of > custom scenery work, namely > > - 6 Caribbean islands plus Helgoland (John Holden, Christian Schmitt) > > - Revised ParisV2 scenario from > http://helijah.free.fr/flightgear/scenery/ParisV2/ParisV2.htm > (cleanup and import by Jon Stockill) > > - Taxiway signs at 6 airfields: KSFO, KBWI, KLVK, KRHV, TFFF, TJSJ > > - Major progress in crowding the Scenery with 3D models - by Alexis > Bory, Gijs de Rooy, Alex Park, Christian Schmitt, Hugo Devon , Paolo > Savini just to name a few of the many involved contributors; > > Acknowledgements > > > The scenery was built on a quad-processor machine in San Diego with > access provided to us by John Graham of Telascience. > > Jon Stockill and Martin Spott maintain the static scenery objects > database at http://scenemodels.flightgear.org/ and provided the > adjustments of the elevations in the objects DB. > > Curt Olson provided us with valuable hints as a long-time scenery > builder and TerraGear development. > > Special thanks go to John Holden and Christian Schmitt, who by their > work on manual digitizing of Landsat imagery in the Caribbeans and at > Helgoland have helped us pushing the envelope of custom scenery in the > official scenery release. We sincerely hope that by this newfound > experience more people will go this way of improving the data in the > landcover database. > > Base data > - > > The scenery was generated with terragear-cs, the Custom Scenery version > of TerraGear, available at http://mapserver.flightgear.org/git. > > Except for the obvious cases listed above the following base data was used: > > - landcover and line data: VMAP0, as available on > http://mapserver.flightgear.org/ > > - airport data (apt.dat): as included in FlightGear Release 1.0 > > - elevation data: SRTM v2 3arcsec and 30arcsec data > > - static objects: current status of the FlightGear Static Scenery > Database (http://scenemodels.flightgear.org/) as of > 29th of October 2008 > > As apt.dat is distributed with the base package instead of the scenery > itself we were unable to use up-to-date airport data. This scenery > release is intended to serve as official scenery for the current > FlightGear release and therefore its contents must be synchronized with > the contents of the released base package. > > Airport data proposal > - > > As an additional feature the release therefore contains airport data in > an "Airports"-directory, based on a proposal of the Custom Scenery > Project on decoupling airport data from the base package. > > The Custom-Scenery-Team is convinced that airport data related to the > geometry of the scenery has its place in the scenery instead of the base > package. Besides the easily updated static objects airports currently > are the main scenery feature that is and should be in constant flux due > to updates by users. > > Currently, the release-cycle of the base-package dictates the possible > update cycle of airport data in the official scenery. This is a pity and > ought to be changed. > > The proposal targeted a scheme which allows users to only download the > airport data required for their desired area, while at the same time > allowing easy access to the data with either the airport-ID or a > position as key. > > Currently the apt.dat makes up nearly 5MB compressed, containing lots of > data which is actually only needed by genapts, but not by FlightGear > itself. With the v850 format of apt.dat - which we will hopefully be > able to support in the future - this amount of "superfluous" data will > increase. > > We therefore think that simply distributing apt.dat.gz together with > each scenery tile might not be feasible anymore. > > Each 10x10-degree-tile contains only information about the airports > contained in this tile, consisting of at most three XML-files per > airport: .twr.xml, .threshold.xml, .parking.xml > > The .twr.xml-File contains the position(s) of the tower(s) > associated with the airport in a PropertyList, presumably to be used for > tower view positioning. > > The .threshold.xml-File contains the threshold positions of > runways associated with the airport - two per runway - with heading and > di
[Flightgear-devel] World Scenery 1.0.1
Hello everybody! The World Custom Scenery Project is proud to finally present the long-awaited bugfix release V1.0.1 of the World Scenery. The scenery can currently be downloaded at http://mapserver.flightgear.org/Scenery We suggest that mirror provides fetch the release from there. Be sure to also download the shared models collection from http://scenemodels.flightgear.org/download/SharedModels.tgz and unpack the archive in your FGROOT folder. Outline of this mail: - Contents of the scenery - Acknowledgements - Base data - Airport data proposal Contents of the scenery --- In addition to the bugfix the release contains some very fine bits of custom scenery work, namely - 6 Caribbean islands plus Helgoland (John Holden, Christian Schmitt) - Revised ParisV2 scenario from http://helijah.free.fr/flightgear/scenery/ParisV2/ParisV2.htm (cleanup and import by Jon Stockill) - Taxiway signs at 6 airfields: KSFO, KBWI, KLVK, KRHV, TFFF, TJSJ - Major progress in crowding the Scenery with 3D models - by Alexis Bory, Gijs de Rooy, Alex Park, Christian Schmitt, Hugo Devon , Paolo Savini just to name a few of the many involved contributors; Acknowledgements The scenery was built on a quad-processor machine in San Diego with access provided to us by John Graham of Telascience. Jon Stockill and Martin Spott maintain the static scenery objects database at http://scenemodels.flightgear.org/ and provided the adjustments of the elevations in the objects DB. Curt Olson provided us with valuable hints as a long-time scenery builder and TerraGear development. Special thanks go to John Holden and Christian Schmitt, who by their work on manual digitizing of Landsat imagery in the Caribbeans and at Helgoland have helped us pushing the envelope of custom scenery in the official scenery release. We sincerely hope that by this newfound experience more people will go this way of improving the data in the landcover database. Base data - The scenery was generated with terragear-cs, the Custom Scenery version of TerraGear, available at http://mapserver.flightgear.org/git. Except for the obvious cases listed above the following base data was used: - landcover and line data: VMAP0, as available on http://mapserver.flightgear.org/ - airport data (apt.dat): as included in FlightGear Release 1.0 - elevation data: SRTM v2 3arcsec and 30arcsec data - static objects: current status of the FlightGear Static Scenery Database (http://scenemodels.flightgear.org/) as of 29th of October 2008 As apt.dat is distributed with the base package instead of the scenery itself we were unable to use up-to-date airport data. This scenery release is intended to serve as official scenery for the current FlightGear release and therefore its contents must be synchronized with the contents of the released base package. Airport data proposal - As an additional feature the release therefore contains airport data in an "Airports"-directory, based on a proposal of the Custom Scenery Project on decoupling airport data from the base package. The Custom-Scenery-Team is convinced that airport data related to the geometry of the scenery has its place in the scenery instead of the base package. Besides the easily updated static objects airports currently are the main scenery feature that is and should be in constant flux due to updates by users. Currently, the release-cycle of the base-package dictates the possible update cycle of airport data in the official scenery. This is a pity and ought to be changed. The proposal targeted a scheme which allows users to only download the airport data required for their desired area, while at the same time allowing easy access to the data with either the airport-ID or a position as key. Currently the apt.dat makes up nearly 5MB compressed, containing lots of data which is actually only needed by genapts, but not by FlightGear itself. With the v850 format of apt.dat - which we will hopefully be able to support in the future - this amount of "superfluous" data will increase. We therefore think that simply distributing apt.dat.gz together with each scenery tile might not be feasible anymore. Each 10x10-degree-tile contains only information about the airports contained in this tile, consisting of at most three XML-files per airport: .twr.xml, .threshold.xml, .parking.xml The .twr.xml-File contains the position(s) of the tower(s) associated with the airport in a PropertyList, presumably to be used for tower view positioning. The .threshold.xml-File contains the threshold positions of runways associated with the airport - two per runway - with heading and displacement information, again in a PropertyList. The .parking.xml-File contains the AI-network for the airport in the well-known format. These files are found in a three-level directory structure (poor man's index). The files for KSFO are for example found in
