Re: [Flightgear-devel] Custom Scenery generation

[Ralf G. <rge...@kn...>]

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