Hi Ralf
Hi,
dene maxwell wrote:
> it's not just layout that is important, there have been instances where
> people have wanted uni-directional runways... this could just as equally
> apply to taxiways (I haven't come across any examples of this YET!)...
> defining taxi-ways as unirdirection or bidirectional could cater for
> specifically styled runway signs (if indeed this was the case in RL)...
> taking it a step further... apron markings could be layered over this.
With
> the proprietry APT format this would be hard to implement...a more
generic
> "tree" structure would be more extensible (I think this has been
mentioned
> before as an advantage)
As it seems, the X-Plane authors are not keen to go away from the
apt.dat format, so if FlightGear would go away from bidirectional
compatibility with apt.dat, this would result in a clear split of the
databases and in ceasing the up to now fruitful exchange of data between
FlightGear and X-Plane. Keep this in mind when assessing the advantages
of a new, totally different format.
I have made this point before, IMHO it is preferrable that we both (FG &
Xplane) stay with the same format if only for the reason that the more
people that are working on getting airport layouts correct the better both
the end results are going to be no matter how we process the data in each
application. My flights (pardon the pun) of fancy are only a way of sharing
some ideas on where the furture will lead us. They are certainly not a
proposal we go our(FGFS) own way independantly.
The more discussion and more ideas that are proposed then any final choice
can only be more informed (even the most ridiculous idea might have some
merit even if to discount it).
Thomas Förster wrote:
>>Example case: I've seen taxi lights standing besides the asphalt and on
the
>>other hand others buried within the taxiway concrete. Just specifying
that
>>there is taxiway lighting is not enough in my opinion.
...and that's why that is to change in the new apt.dat-format. They have
both polygonal pavement sections, but also polyline sections, by which
rows of lights, markings, etc., can be placed accurately.
Which brings us to the point where we have to draw our borderlights,
etc., ourselves _in addition_ to the pavement, where in the past we
"simply" placed a rectangle and activated lighting.
However, given proper tools - which is what TaxiDraw is going for - we
can make the tool support the user, by, e.g., automatically placing
lines of borderlights around any new pavement polygon and allow the user
to edit them or remove them as they wish.
as mentioned, "a certain amount of logic" can be enforced at a data
structure level or at a tool level, I believe it should be done at the tool
level at this stage of the discussion as it leaves the data structure more
open and able to cater for unforseen developments. Whether or not the APT
data format is most suitable now is largely irrelevant...without a universal
agreement that it should be discarded and a clean start should be made it is
the legacy format and the 850 proposal is a definite step forward... who
knows what ingenious changes are possible in the apt format to accomodate
some of the "flights of fancy" that have been expressed.
Cheers,
Ralf
regards
:-D ene
_________________________________________________________________
Find the coolest online games @ http://xtramsn.co.nz/gaming
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
