Hi,
dene maxwell schrieb:
Dene, I'm very sorry that we won't be able to integrate your current
work directly. The main problem here is that the database stores
primitives in order to allow easier modifications of larger scale.
What sort of primitives are you referring to? I think you might mean
shape primitives such as squares, triangles, circles and elipses.
I'm referring to the primitives I'm used to from scenery digitizing with
GRASS, i.e. points, lines and polygons, all planar and 2D (lat/lon).
Sorry for jumping the "primitives"-bandwagon ;-)
It might be technically possible to extract polygon primitives from
the .btg.gz files (see at the end of this mail), but for line data
we're practically lost (as practice shows, point data is actually of
no use, .....
3-D point data surely is the essential to reference objects into the
real world. even a circle wth no beginning and no end is referenced with
a single point at its centre and inclination and node of accesnsion
properties to reference it to the other axis's
Heh, another expressiveness slip on my side. The VMAP0 data which is
currently used for scenery generation contains the location of some
objects as points. This is also the case, e.g., for "small" objects such
as smaller towns. This makes sense for a map database such as VMAP0,
which was created for small map resolutions, but it does not really make
sense for a scenery.
Curt currently creates rectangles from some of these "town" points with
a sidelength of 1km IIRC. However, we have now digitized more than 100
scenery tiles and never needed points for terrain representation. As you
mention further down in your mail, the positions of static objects such
as towers, etc., are managed elsewhere.
Of course, we could use point data for representing the positions of
windmills, water towers, etc., which would then automagically produce
appropriate entries for static objects in the scenery. However, I was
talking about extracting data from the terrain part (.btg.gz) and in
that part I see no use for trying to extract such "town" points. Even
more so I see no algorithmic way to do that.
We can, however, extract the polygons from there so the only manual
interaction needed for converting "old" fgsd scenery customisations to a
database-compatible format would be providing the proper attributes for
the extracted polygons and some cleanup. No redigitalisation of the
polygons necessary.
I think there are two types of objects involved here. The 3-d models
such as radio masts, houses etc. and shape primitives. These are current
held separately is this not the intention moving forward?
There is a database for the static objects at
http://fgfsdb.stockill.org/ and we aim at creating a database for the
other part, the terrain data.
And, as Martin already said, we're not getting in trouble if, e.g.,
new elevation data can be used for the scenery, or similar.
The present scenery data is very "averaged". This is fine for deserts
and the such. It can be very disappointing when the actual scenery is
more severe. eg;
You may want to have a look at the screenshots from our recently
published route description through the Alps:
http://www.custom-scenery.org/From_Friedrichs.269.0.html
The data there seems quite accurate compared to actual photos of the
region. Of course, there's always room for improvement.
I don't know the parameters Curt is using for generating his fitted
elevation data, but our scenery uses a maximum elevation error of 40m
and a maximum of 1000 nodes per tile (which are the standard settings of
terrafit.py)
Alot of these scenery changes are made using 1 inch:1 mile terrestial
survey maps. Is this level of detail going to be incorporated into the
new DB.
Terrestrial survey maps? I take it you are talking about elevation
contour lines you edited in? There are plans to keep those in the DB as
well, in a special contour lines layer.
Extracting elevation data from the btg.gz files should be possible.
After all, each of the triangle points in a tile actually has an
elevation. One could interpolate these to create a raster for the whole
tile and then extract contour lines from that. Maybe someone else has a
better idea here.
The data in the current scenery is nothing more than a non-minimal
planar partitioning of the original data. Let a boundary be a polyline
connected to a node on each side. In the beginning each vertex is a
node and each edge is a two-point boundary. A boundary can be removed
if both faces it participates in have the same material.....
Correct me if I'm wrong but a boundary may also define a change in
terrain gradient?
Yes, it may. However, we separate the land coverage data (forest, city
area, water, etc.) from the elevation information. The idea of the
described algorithm is to extract the land coverage data. As I said
above, extracting customised elevation data should be possible as well,
but with a different method.
Perhaps an additional attempt for clarification: The basic idea is that
the terrain database will mainly contain 2D land coverage data in the
form of line data (e.g., for roads and streams) and polygon data (e.g.,
for cities, lakes, forests, etc.). These define a 2D map of the world.
On the other side, an elevation model is generated from raster data -
currently SRTM2 3-arcsec rasters are used - and possibly refined
elevation contours, which may be kept in the database as well.
The 2D map is then draped over that elevation model, finally becoming
the terrain part of the scenery (the .btg.gz files)
Static objects come from Jon Stockill's object database.
All this already takes place when Curt is generating the standard
scenery, except that up to now the 2D landcover data was not coming from
the terrain database and we have no refined elevation data to feed in
(TerraGear doesn't even have a tool for that yet).
I hope these answers help you understand the concept better.
Best regards,
Ralf
-------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
