Hi Syd, I agree with you that the state of affairs regarding scenery is currently awkward, to say the least. As Martin has said, we are working on improving this.
Martin's and my work are currently concentrated on making more and different datasources accessible for scenery creation. Martin is doing a pretty good job in aggregating a huge set of datasources in the common landcover database (see http://mapserver.flightgear.org/ for a quick look at the data already available) in cooperation with the OSGeo foundation. We also want to make use of freely available raster data, such as Landsat ETM+, for automatic classification of landcover and conversion to vector data which can then be used to replace the low-accuracy VMAP0 data at least partially both in terms of space and content (e.g. we won't be able to extract streets from 28.5m- resp. 14.25m-resolution Landsat bands). You can see some results of my first experiments in the landsat_* layers at the above-mentioned mapserver URL and a bit more detailed look at the process at http://custom-scenery.org/Satellite-Image.304.0.html As far as my interpretation of the communication goes, OSGeo will support this effort as well due to the common interest in freely available geodata. We are already provided with computing power and storage space. So this is really a huge project and we will try to lower the barrier of participation in this effort gradually and as our free time allows it. After all it will be necessary to provide training data to the classifier and as each Landsat image may have different lighting and contrast properties, this training must be done for each individual Landsat tile. For a little training in the form of a view exemplary polygons specifying e.g. some regions of forest, town, urban area, water, etc. for each landsat tile, automatic classification will provide us with pretty detailed and accurate landcover data for about 40000 sqkm per tile! We have a timeline for many of our endeavours, and it ends at end of May 2007, as we want to have it ready for LinuxTag in Berlin. BTW: There was a long list of suggestions for static objects to be built for Berlin on the organisation list. Maybe we should post that to the Wiki for people outside the organisation committee to participate. If LinuxTag is jumping to a different location in Germany every year, this would get us to have most bigger German cities properly populated within a few years ;-) So as we have explained several times in previous mails, our approach is to view the input data in an abstract way as geographical information, not as merely a network of triangles as output by TerraGear. We have also laid out our reasons for this and the cooperation and interest of OSGeo should show that our reasons are not flawed. That said, our time is limited - as everybody else's. Which is also why the site that Martin described as "the most apparent description of such work" is also heavily lacking behind the current development. Also any contribution, e.g., by providing a current basic tutorial on compiling TerraGear and building scenery with it, is very welcome. A general explanation of the TerraGear scenery-building process, specifically focusing on the setup of the working directory, the different stages and also adressing the attribution of material types would be of good use. If there is noone wanting to do that or having enough time or knowledge, well, then you'll have to wait 'til someone else (like me) comes around to doing it. I know that there is a TerraGear-building tutorial on the Wiki somewhere, so if this doesn't work for some reason, help improving it. Finally, TerraGear can properly grok all kinds of Shapefiles for vector input and Martin will provide you with shapefile equivalents of VMAP0-vector data for your region of interest, if you ask nicely. Shapefiles can be edited with probably any GIS toolset that is out there. The most prolific on the OSS side are Quantum GIS (have a look at http://www.qgis.org/ or check your distribution's package directory) as well as GRASS, whereas the latter requires a steeper learning curve and is more an analyst's tool than suitable for editing vector data. So if you want to edit scenery, go for it. The tools are there. They may be a bit awkward to use currently, but as I said: We're working on it and we're happy for any support we get. And if you want to nudge triangles in the btg.gz, you shouldn't hope for support from our side. ;-) The relevant code for reading and writing btg-files is in the SimGear source in simgear/io/sg_binobj.hxx, simgear/io/sg_binobj.cxx and simgear/io/decode_binobj.cxx even contains a simple example on using these classes and methods. With a little time and commitment it should be no problem to figure out how to transform this into AC3D and back. But make sure to not only dump single triangles back to btg, but also establish triangle strips or fans again, for loading and display efficiency. ;-) Cheers, Ralf ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
