Roberto Inzerillo wrote:
> > I don't know if I was successful, but when discussing the upcoming
> > apt.datformat to include a much more flexible taxiway spec, I also
> > lobbied to have an airport boundary also included. If this
> > boundary was fixed and never changed, then a user could change
> > anything inside that boundary
[...]
> I have to say I don't think having fixed airport boundaries is _the_
> definitive solution to the problem.
Sir, I have to object ;-)
Defining fixed boundaries around airfields is a bad idea in the long
term. To my understanding FlightGear still focuses on methods that are
laid out in a forseighted manner and fixed boundaries is definitely not
a part of this collection. While claiming this I have three reasons in
mind:
1.) Airport boundaries change. I'm subscribed to the monthly update of
the "Jeppesen Bottlang Airfield Manual" and from reading almost
every page in these updates I remember that I've seen changing
boundaries from time to time.
2.) Maybe one day we'll see a modification maybe not only to the
Scenery format itself but also to the process of Scenery creation.
If you start adding 'proprietary' geometries into the terrain then
you are likely to waste this work one day because you'll probably
be unable to reverse-engineer the information on which your
detailed airport layout was based.
3.) It's very likely that people not only want to create a detailed
arrangement of their local airfield entourage but of other places
of intersting geography as well. This would mean scattering fixed
boundaries around numerous places around the world - something that
definitely will get us into trouble over the time.
Therefore I'd like to remind us of some insight that Fred Bouvier
posted about one and a half year ago on the fgsd-devel list - and which
almost coincindenced with the start of my Landcover Database project:
> Instead, I will implement higher level primitives, in the same vein as
> current curve embedding. The primitives I am thinking of are :
>
> - flatten the area in a closed curve,
> - embed curves,
> - assign material to area of a closed curve,
> - draw road or steam along an open curve,
> - project a map fragment on the terrain to produce photo-scenery,
> - etc...
If we're going to define accurate layout of a region by respective
primitives like contour lines for detailed description of changes in
elevation, then we'll be able to re-use this data whatever way of
representing terrain will be used with FlightGear in the future.
Frederic has already shown in FGSD that it's feasible to modify the
triangle schema of FlightGear Scenery according to countour lines which
are defined by the user. If this 'apparatus' would be incorporated into
the respective TerraGear tools, then everybody would be able to create
one or more contour files (i.e. Shapefiles) for the area of his
interest and build the Scenery accordingly.
Just for fun: This image is made from a Shapefile which contains
elevation contour lines in steps of 10 m around EDDK:
http://foxtrot.mgras.net/bitmap/FGFS/EDDK_contour.png
.... and the Shapefile is made from SRTM elevation data. The contents
of such Shapefiles could be stored and distributed via the same
Landcover DB as well and everybody would profit from it.
Cheers,
Martin.
--
Unix _IS_ user friendly - it's just selective about who its friends are !
--------------------------------------------------------------------------
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
