Hi Martin,
thanks for explaining.
Am 19.12.2010 um 17:37 schrieb Martin Gregorie:
> Those of us with lists of non-gliding airfields and other landable
> places keep them in a separate list thats configured as Turnpoints 2.
I am very much in favour of this method. It is much closer to actually knowing
what info is actually available, as opposed to trusting in the fact that
everything's going to be in there somehow, which I consider kind of
'unaeronautical'. Fortunately, XCSoar allows to load two separate files. One
more would not do any harm, though.
Loading a new airfields file with every local TP list makes me feel very
uncomfortable, as it requires me to dump my verified airfields data and rely on
supposedly unsafe information of unknown origin.
> This isn't so surprising when you consider that the file format is
> merely the Cambridge Instruments (CAI) turnpoint file.
Yes, I know, and this is most probably so that readily available data can be
used as easy as possible.
I see, however, the shortcomings of this format. On soaringweb.org they use a
format that is organized in kind of named fields or columns if you want to call
them so. Here's a sample. It is not required that every field is occupied,
though as the structure is known, even a blank field does not create a mess,
and if a turn point does not have a frequency, well, then it just hasn't.
Still, the format can be used for all kind of points, landable or not, and this
would not be yet another format.
There is only one thing I would like to add, as it is very important for the
maintenance of a WP data base: Each data set should have the date of it's most
recent update with it.
> ***** Question for XCSoar developers: what is the maximum size that
> ***** XCSoar will accept for the 7th field (the description)?
Yepp. I'd also be very much interested to know.
> Given that XCSoar needs two additional pieces of data:
> - the home field
> - up to a screenful of displayable information about airfields
The need for a home field could be eliminated by detecting the take off
location, as discussed a few days ago, and as far as I have learned, it is but
an 'H' in the attribute flag anyway. The screenful of additional info does IMO
not justify another file and it's maintenance.
> the decision was taken to put that in a separate 'airfields' file rather
> than taking the turnpoint list differ from the well known CAI turnpoint
> format. This makes sense when you realise that many countries (and the
> Soaring Server) distribute turnpoints in this format. Do we really want
> yet another turnpoint file format that must be maintained and
> distributed? I don't think so.
I do not want to talk anyone into creating yet another format. The CAI format
could be kept as is and EG be enhanced, so that the published turnpoint files
could be used as before, but for airfields or landable places data could be
appended. This would open the opportunity to maintain all these data with the
same tool. Editing and checking the status of airfield files in today's format
is a pain, and matching it with field and turnpoint files is a pain too.
> There's an alternative way of going about it that some of us are
> investigating. That is to develop a list of mandatory and optional
> fields that can be used to describe airfields and to gather a set of
> airfield descriptions that fit this format. This airfield database can
> be held in almost any convenient format (an SQL database, an XML file or
> a CSV file are the obvious ones). Then all you need is a program for
> maintaining the airfield database and another program that can generate
> loadable file(s) for XCSoar, LK8000, Cambridge, SeeYou....
> in short, a converter program for any instrument or program that needs
> the access the airfields database.
Yes, that would have the charm of allowing to use sorting and filtering by
several properties.
A spreadsheet format was meant to be an example, any format that can be treated
with a suitable tool would be just fine.
> IMO a spreadsheet isn't suitable as the master file because:
>
> - different spreadsheet programs have incompatible file formats.
> There are even incompatibilities between different Excel versions.
Yes, that's so true. I would not use a proprietary format such as .xls anyway.
Still, the data we want to store has such a low complexity that it should not
be any issue with incompatibilities, I think. Special national characters in TP
names are a much greater challenge.
> - A spreadsheet isn't good at validating this type of date, for instance
> to make sure a turnpoint isn't entered twice by mistake or to validate
> turnpoint attributes.
Validation is indeed an issue, and I agree a database format might be better,
and it would allow running scripts on the data, too. Recently, we made a tool
for running a competition, which was based on a database, though the input and
output file was a spread sheet. That worked very well, as it supplied the best
of both worlds, and made the date easily accessible and distributable.
> Note that, as the data needed to describe a turnpoint is a subset of
> that needed for an airfield, this database can also be used to maintain
> turnpoints by adding a field that says whether an item represents an
> airfield or a turnpoint.
Agree, that's my point. No need to use different formats for the both of them.
We already have the attribute flag in the WP file, though for an airfield, the
CAI format just lacks the required space. Maybe, one could kind of expand the
rightmost field (usually full name of the point) to have kind of subfields used
to display airfield data, if the point is an airfield, or maybe just add
fields? This would be a situation, where a spread sheet format might shine, as
it would allow sorting the sets by attribute and export to TP, outlanding and
airfield files relatively easy.
All there had to be was XCSoar recognizing an enhanced version of the CAI
format with longer lines.
Martin
------------------------------------------------------------------------------
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
_______________________________________________
Xcsoar-user mailing list
Xcsoar-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xcsoar-user
