Re: [Flightgear-devel] apt.dat.gz and TerraSync
On 23 Sep 2013, at 13:58, Tomash Brechko tomash.brec...@gmail.com wrote: I use fgdata from git repo and so have a fresh copy of apt.dat.gz. I noted that apt data is actually ahead of what is fetched with TerraSync: some airports (at least UHPB, UIAE, UIUB, UIIB, but likely much more) present in apt.dat.gz (and thus shown in Atlas) but not in the scenery (fgfs --airports=UHPB starts in the woods, etc.). I also suspect that as of now TerraSync repo hasn't been updated yet. I wonder if there's a dev version of TerraSync SVN that is updated more frequently than once per release, and is in sync with dev fgdata? TerraSync is supposed to in-sync with fgdata I think, but hopefully Martin will respond with more details. On a side note, recently I put together Perl script ( https://github.com/kroki/fg-navaid , still work in progress) to query internal navdata cache (SQLite database) for various info. Front page has examples of currently available information outputs. Mention it as an easier way than digging through .dat.gz. I would greatly prefer you NOT do this, because the internal format of the cache (eg, the fact it's a SQL DB) is deliberately opaque. There are no guarantees made about the format of the file, the SQL scheme or anything. There is a version field of course, and I'm not planning or expecting any changes, but I really don't want to be tied to the current scheme if we discover problems or want to add something else in the future. Kind regards, James -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat.gz and TerraSync
Hi, 2013/9/23 James Turner zakal...@mac.com I would greatly prefer you NOT do this, because the internal format of the cache (eg, the fact it's a SQL DB) is deliberately opaque. Sure I'm aware of this, and please feel free to change the internals at any moment without notice (as a last resort I can add an option to the script to create its own DB based on navdata - just don't see the reason for this at the moment). Moreover I view the script as a temporal stub until the information is available somewhere inside FG, my current knowledge of FG internals is insufficient to implement it there myself, and having it dirty way is better than nothing. Related to this, it would be nice if the function to query magvar for arbitrary location would have a Nasal binding (or magvar field in the output of geodinfo() or airportinfo(), but this is less efficient if one needs only magvar (and less flexible in the case of airportinfo(), though in most cases you need to know declination exactly there)). This will allow reporting magnetic runway headings in the Airport dialog which I presume is implemented in Nasal. -- Tomash Brechko -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat.gz and TerraSync
2013/9/23 James Turner zakal...@mac.com I think you should investigate the magvar() function: Great, just what I need! As ever, the problem here is we have no way to auto-document what's exposed to Nasal. Could it be some special format comments in the C++ code and an extraction script to update http://wiki.flightgear.org/List_of_Nasal_extension_functions ? Wouldn't recommend Doxygen though, I think something grep-able would be enough. Thanks for magvar() pointer, will look throught the code to see what other goodies might be hiding :). -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat.gz and TerraSync
On 23 Sep 2013, at 15:19, Tomash Brechko tomash.brec...@gmail.com wrote: Sure I'm aware of this, and please feel free to change the internals at any moment without notice (as a last resort I can add an option to the script to create its own DB based on navdata - just don't see the reason for this at the moment). Moreover I view the script as a temporal stub until the information is available somewhere inside FG, my current knowledge of FG internals is insufficient to implement it there myself, and having it dirty way is better than nothing. Well, if you need the information *inside* FlightGear, you can ask for an accessor to be added …. But, yes, if you're happy with the risk of it all changing, indeed it's easy to extract information. Related to this, it would be nice if the function to query magvar for arbitrary location would have a Nasal binding (or magvar field in the output of geodinfo() or airportinfo(), but this is less efficient if one needs only magvar (and less flexible in the case of airportinfo(), though in most cases you need to know declination exactly there)). This will allow reporting magnetic runway headings in the Airport dialog which I presume is implemented in Nasal. I think you should investigate the magvar() function: var x = magvar(); # at present aircraft pos var y = magvar(lon, lat); # guess what this does …. var z = magvar( some object retrieved from airportinfo() / navinfo() / one of the other DB query functions ) As ever, the problem here is we have no way to auto-document what's exposed to Nasal. In general reading NasalSys.cxx / NasalPositioned.cxx is a good hint, though. At this point I've exposed every piece of data that anyone has requested, I think - there's no backlog of non-exposed data (but, if I have, adding accessors is easy and low-risk) Kind regards, James -- LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99! 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151iu=/4140/ostg.clktrk___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
