In any case, no matter what format is finally used, should the precise definition of the file format(s) accepted be appended to the updated manual we were just discussing. As long as these files are used by several systems, of which not all are so strictly respecting standards, files shared with other users might just not be exactly standard. In case of doubt, a precise definition is the only way for a user to check if the files he got from a possibly unknown source can be used to his full advantage. (It just took me quite some time to find out about some mystery garbage characters in my airfield details files which caused them to fail.)
Martin --- Am 21.12.2010 um 19:40 schrieb Tobias Bieniek: > Might be an option. The problem is that we need to scan for that format > in every airspace name and that obviously takes time and it doesn't > matter if the frequency is in there or not, it will be slightly slower. > If it was an accepted standard that wouldn't be such a big disadvantage > but implementing a scan for every possible format takes a lot of time at > loading and I am not quite sure if this is a good idea. It might be > worth it to see how the other countries are doing it... if there is a > certain number of different files with a similar format I think we could > consider implementing that. > > Turbo ------------------------------------------------------------------------------ Forrester recently released a report on the Return on Investment (ROI) of Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even within 7 months. Over 3 million businesses have gone Google with Google Apps: an online email calendar, and document program that's accessible from your browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew _______________________________________________ Xcsoar-user mailing list Xcsoar-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcsoar-user
