Why the trouble !? - by Chris Metzler
> 2) Are you recommending "GRASS, FWTools (gdal, OpenEV), QGIS, etc." as
> better/different tools to edit existing scenery or justa new format?
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:
- 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
- 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.