dene maxwell wrote:
>>From: Paul Surgeon <[EMAIL PROTECTED]>
>>On Tuesday 10 January 2006 09:14, [EMAIL PROTECTED] wrote:
>>>
>>> A recent (within the last week?) discussion in the fgsd-devel mailing
>>> list
>>> was about this. The goal is for fgsd to be able to output data in a
>>> format
>>> that can then be incorporated into the scenery database (in addition to
>>> being able to output .btg files as at present).
>>>
>>> In the absence of this, free GIS interfaces are an option, I suppose --
>>> they exist for Windows just as they do for Linux etc.
>>
>>
>> All of the Open Source GIS apps that I am aware of are ported and
>> distributed
>> in ready to run binary packages for Windows users.
>> Examples : GRASS, FWTools (gdal, OpenEV), QGIS, etc.
>>
>> Most of the users of open source GIS applications are Windows users who
>> don't
>> understand how to configure or build software so it only makes sense to
>> provide them with ready to run applications
>
>
> OK, now i'm really confused;
Did you check the archives? There's been a *lot* of threads about
this topic. I know it might take a while to sort through it all to
get the answers you want; but then again, it takes other people a
while to explain it again, too.
> 1) Is FG scenery format going to change from .btg/.stg format to something
> else?
No, it isn't.
> 2) Are you recommending "GRASS, FWTools (gdal, OpenEV), QGIS, etc." as
> better/different tools to edit existing scenery or justa new format?
Neither, really.
The terrain used in FlightGear -- that is, the polygons that make up
the surface you're flying over, their vertices' locations and altitudes,
as well as the terrain types ("materials") associated with the polygons
(i.e. the fact that this polygon is forest, that polygon is ocean, and
so forth) -- is created by a program called TerraGear. TerraGear makes
the .btg files. To make the polys in the .btg files, TerraGear needs
data telling it what the ground elevation is, and what the landcover
is at different locations (whether it's forest or grass or farmland or
urban or whatever). There are publicly-available datasets with this
information. TerraGear reads that data, comes up with the polys
and their altitudes and materials, and makes the tile .btg files with
that information.
But the input data isn't perfect, for a variety of reasons. So the
result is that most people can look at the simulated terrain in an
area they know well and see that it isn't quite right. Up to this
point, if you wanted to do something about that, the only route
really available to you is the route that you took: using Fred's
FlightGear Scenery Designer to manually manipulate the polys in a
.btg file, adjusting terrain heights and poly materials (landcover)
to tweak the terrain into a form that the user thinks is correct.
Another option, however, is to feed TerraGear better input data to
start with. If TerraGear is given better input data, it will generate
better output .btg files. For instance, as higher resolution ground
elevation data has become available, we've switched to feeding that
to TerraGear, resulting in more realistic terrain shapes (not looking
as "smoothed out" as it once did). But even with better input datasets,
an area of interest to a user isn't going to look quite right -- it
may get better, but it'll never be perfect. It'll probably never
be as good as the user could get by manually adjusting the terrain
towards "reality."
But what about this possibility: make those input datasets editable.
In other words, instead of editing the tiles (like you did with fgsd),
you edit the datasets which are input to TerraGear, so that when
TerraGear runs, it outputs a tile that looks like you want.
This has the advantage that when Curt has rebuilt all the terrain
again (containing the effects of the latest improvements to the
TerraGear code), you don't have to make the choice between:
1. keeping your old tile (which won't include those enhancements
to TerraGear, and may not match up well on the boundaries with new
tiles), or
2. dumping your old tile, getting the new tile from the new terrain
build, and then editing it in fgsd all over again to get the changes
you made back.
By editing the datasets that are input to TerraGear, you don't have
to make this choice. Your changes went into the input data, so they're
there when the scenery is built, and will be there automatically in
every scenery build after that. Furthermore, there's no worries about
distributing your tile to other people; it'll be in the official
downloadable scenery right after the terrain rolls out of Curt's
latest TerraGear build.
The World Scenery database they're talking about is intended to keep
the datasets that will be input to TerraGear; and what we're discussing
is how one would go about making changes to those input datasets, in
order to improve the quality of the data for a particular area, so that
the .btg files that come out of TerraGear for that area will look better.
One way that you might go about doing it, for instance, is in a
fashion similar to what you're familiar with: you'd start up fgsd
and edit your terrain manually, like you did. But when it's time
to output the results, instead of (or perhaps "in addition to" --
that's up to Fred) getting a .btg file out, you'd get some other
file, which would contain changes to the input datasets in the
Terrain/LandCover database. You'd then send those off to Ralf/Martin/
whoever, your changes would get incorporated into the database,
the data in the database would get used in the next scenery build,
and presto!, your changes are now in the official scenery that
everyone downloads. For this to work, fgsd has to know how to
output the information about the tile in a way that can be
incorporated into the database; Fred and Martin have been discussing
this over on fgsd-devel.
Another way you could do it would be by interacting with the data
through some graphical GIS front-end -- a GUI-based program that's
designed to load geographical information out of databases, present
it to you in some informative way, and (depending on the program)
allow you to manipulate it. For instance, you might pick a certain
area to look at, and pull out of the database a map showing elevation
contours. Then, you might use tools in the application to make
changes to the path of those elevation contours; and when done,
save your changes back to the database. Bingo: you've just changed
how the terrain that comes out of TerraGear will look. When people
talk about QGIS, GRASS, etc., this is what they're talking about.
It's a route you might take for making changes to TerraGear's input
datasets as they're kept in the database.
Hopefully this makes things more clear; and hopefully others will
chime in on things they think I didn't do a good job of explaining.
-c
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
