Recommended reading
For getting started, you should have a look at the 
tutorial material at the GRASS homepage. We specifically recommend the 
GRASS GIS Tutorial provided by GDF Hannover, which is available both in English and in German, and "GRASS in a Nutshell", which was written for a workshop on the Open Source Geospatial '05 Conference and will give a nice insight into the workings and features of GRASS in general.
For more info on generating scenery, have a look at David Megginson's and Curt Olson's scenery generation tutorials.
Coordinate Systems and Map Projection
For digitising any map projection and coordinate system can be used that fits your base-material, such as raster-maps, satellite photos, etc. However, when it comes to generating scenery, the vector data needs to be reprojected to a latitude-longitude coordinate system using the WGS84 ellipsoid and datum.
In general, reprojecting vector data is much easier and faster than reprojecting raster data, as in case of raster data, each pixel of the raster image needs to be reprojected and interpolated, while in case of vector data reprojection of the vector vertices - which are much less numerous - is sufficient. Also a badly chosen resolution in the target coordinate system can notably reduce the accuracy, while vector data has no specific resolution and typically only loses accuracy due to deviations in floating point operations. However, the loss of accuracy due to floating point operations is much smaller than that due to bad choice of resolution.
GRASS, GDAL and OGR (which is part of GDAL) support reprojection of both vector and raster data.
In GRASS, the v.proj command can be used for projection of vector maps.
To reproject a shapefile lakes.shp in the current directory into latitude-longitude with the WGS84 ellipsoid and datum using OGR, writing the result to the pre-existing directory ./wgs84, use the following command:
ogr2ogr -t_srs WGS84 ./wgs84 . lakes
Note that this requires information about the original projection in the file lakes.prj in Well-Known Text (WKT) format, which is available when the shapefile was exported from GRASS.
Selecting an attribution system
When selecting an attribute model for your data, you should try to express what the feature represents, not how it is represented in FlightGear. The representation concept in FlightGear may change or in the future there may be additional materials which could fit some types of features better, and by attributing the "what"-way, not the "how"-way, you can save yourself the effort of reassessing your whole dataset when such a change occurs.
In the categorisation currently used for the South Germany custom scenery, we have a category each for townships, cities and industrial areas. While townships are represented by the material Town, cities and industrial areas are currently both represented by material Urban, as there is no material for industrial areas yet (at least, I didn't find one). As soon as we find a material for industrial areas, we simply change the mapping at one point instead of having to reassign the attributes for all industrial areas.
But why do we separate industrial areas from city areas in the first place? Because there is a significant difference in the look of these areas as from above and because our map material provides for such a differentiation.
Currently we are working on a common classification system for the terrain database, which both must be compatible with the classification system of the worldwide base data (VMAP0, GSHHS, etc.) as well as sensible regarding the differentiation possible from typical raster maps.
Using shape-decode and GRASS
The current CVS version of TerraGear contains a shape-decode tool, which can handle shapefiles containing point, line and polygon data.
The tool reads the vector features from the shapefile one by one, converting each of them to polygons in case of point or line data, and writes the resulting polygons to the specified TerraGear working directory.
Thomas Förster has also added the possibility for specifying the width of lines in a column of the DBF file. Use the --line-width-column option for specifying which column to use.
To make polygons with material Lake from the shapefile lakes.shp and write the result to the directory workdir/Lakes, splitting up long lines into segments of a maximum length of 400m, use the following command line:
shape-decode --max-segment 400 lakes.shp workdir/Lakes Lake
If no material name is given as last argument, the name is taken from a column in the DBF-file associated with the shapefile. While there is a standard setting, you are encouraged the specify the column number with the --area-column option.
In our generation process we make a shapefile of its own for each of the area types, specifying the area type on the command-line instead of in the DBF.
Use v.out.ogr to export your data from GRASS. Note that you can only include either points or lines or polygons in a single shapefile, but no combinations of these types are possible.
When exporting polygons make sure that you use the -c option to v.out.ogr. Otherwise holes are not cut out but filled.
Suppose you have a GRASS vector theme named landcover with an associated attribute table containing a column type specifying the type of landcover on the respective vector feature. To extract all features with a type of "Lake" into a shapefile lakes.shp in your current directory, use the following commands from within GRASS:
v.extract input=landcover output=lakes type=area where="type='Lake'"
v.out.ogr -c input=lakes type=area dsn=. olayer=lakes