Hi Ralf
I've come back to this post because there is a lot in here that I don't
fully nderstand and for my efforts to be of any use to anyone I think I need
to understand it a bit better.
From: Ralf Gerlich <[EMAIL PROTECTED]>
Hi,
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.
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
.....except perhaps for placing predefined objects - wells, transformer
stations, etc. - automatically, which is a totally different issue).
Furthermore, we want the database to provide a logical view on the data.
This means that the object attributes in the database should actually tell
us more about a primitive than its material or - in case of lines and
points - its width/size. This way we can change the material assignments
based on logical information (instead of presentation information) in case
we're making progress in terms of the standard material database.
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?
Maybe one day we'll have a terrain engine in FlightGear which can grok the
primitives directly (maybe including dynamic level-of-detail and thereby
allowing more accurate base data). In that case, the modifications in the
database will still be of use, while the direct tile modifications will be
lost.
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;
My local airport r/way 16x approach passes over a hilltop suburb at 1200ft
AGL then 0.5NM later is over the harbour. To the right of the approach is a
200-300ft deep man-made gorge for the main motorway
http://denemaxwell.blogspot.com/2006/01/nzwn-r16.html
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.
So, we have - as we think ;-) - good reasons for our decision and we regret
that this means that many current modifications cannot be integrated.
However, we hope to eventually get all of you into the boat with
appropriate tools, etc.
And yes, I'm still working on the tutorial and the tools ;-)
Martin Spott schrieb:
Frederic usually
makes sure that FGSD runs on Windows, there is QGIS on Windows which
makes a nice viewer, there is uDIG which runs on Windows as well (as
it's written with Java/Eclipse), GRASS is available on Windows (although
this might be a tricky part ....).
Well, GRASS on Windows is entirely possible, although with some usability
problems and it needs some tricks for compilation. However, I think that
most of the usability problems can be circumvented by using a combination
of QGIS/GRASS, which seems to be a good idea anyway, regardless of
operating system. In that case, QGIS is more than a nice viewer ;-) and
provides nice replacements for the problematic GRASS modules. Haven't yet
tried it on Windows, though.
Regarding the extraction of polygon data from .btg.gz: The main effort in
creating custom scenery in any form is digitising the shapes, so something
like that might actually be useful.
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?
..... If a node is connected to exactly two boundaries, it can be removed,
joining the two boundaries to one.
The result would actually be an appropriate input for GRASS, as GRASS uses
planar partitions for topology. One would only have to relabel the data in
GRASS by the logical data and possibly introduce additional boundaries
where the distinction by material does not match the logical distinction. A
bit of manual cleanup might be required as well (non-matching vertices on
tile borders).
Regarding line data I currently have no idea how to solve that.
This way we could at least save some part of the work done directly on the
tiles. Maybe someone wants to give it a try.
Best regards,
Ralf
Regards
Dene
_________________________________________________________________
On the road to retirement? Check out MSN Life Events for advice on how to
get there! http://lifeevents.msn.com/category.aspx?cid=Retirement
-------------------------------------------------------
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
