13,212
edits
Navdata cache: Difference between revisions
Jump to navigation
Jump to search
Reordering some sections; More details on some known issues and how to solve them; Non-camel case headings
(Reordering some sections; More details on some known issues and how to solve them; Non-camel case headings) |
|||
| Line 7: | Line 7: | ||
== Background == | == Background == | ||
[[File:Navcache.png|thumb|Screen shot showing several navcache (SQLite) files in $FG_HOME for various fgfs versions]] | |||
We need a lot of data ''available'' at startup for position init. Parsing it from apt.dat and nav.dat is 'slow', but has been optimised over the years. (Parsing 20MB of text data each launch is still kind of crazy, though) Collecting it from many XML files would also be slow, but there's a general point that we should be decoupling ''availability'' from ''loading''. | We need a lot of data ''available'' at startup for position init. Parsing it from apt.dat and nav.dat is 'slow', but has been optimised over the years. (Parsing 20MB of text data each launch is still kind of crazy, though) Collecting it from many XML files would also be slow, but there's a general point that we should be decoupling ''availability'' from ''loading''. | ||
== Cache initialization == | == Cache initialization == | ||
| Line 40: | Line 40: | ||
The cache is stored in <code>[[$FG_HOME]]/navdata.cache</code>, and is rebuilt if the timestamps on any of the data files change (<code>apt.dat<code></code></code>, <code>nav.data</code>, <code>fix.dat</code> and so on). When the cache needs to be rebuilt, startup will take a bit longer than before, but when the cache is valid, startup is ''much'' faster, especially for debug builds - because all the usual parsing/processing will be skipped, and the corresponding data will be read from the binary cache instead. | The cache is stored in <code>[[$FG_HOME]]/navdata.cache</code>, and is rebuilt if the timestamps on any of the data files change (<code>apt.dat<code></code></code>, <code>nav.data</code>, <code>fix.dat</code> and so on). When the cache needs to be rebuilt, startup will take a bit longer than before, but when the cache is valid, startup is ''much'' faster, especially for debug builds - because all the usual parsing/processing will be skipped, and the corresponding data will be read from the binary cache instead. | ||
== Known issues == | |||
{{Note| See also these bug reports: | |||
== Known | |||
{{Note| | |||
* {{Issue|1166}} | * {{Issue|1166}} | ||
* {{Issue|894}} | * {{Issue|894}} | ||
| Line 84: | Line 47: | ||
* {{Issue|1774}} | * {{Issue|1774}} | ||
}} | }} | ||
The SQLite-based navcache seems to have a tendency to get corrupted during segfaults/crashes, especially on Windows, but more recently also on OSX: | |||
=== Read only database === | |||
The SQLite-based navcache seems to have a tendency to get corrupted causing FlightGear to not start and give for example the following error messages: | |||
* <code>Sqlite error : attempt to write a readonly database received from DELETE FROM groundnet_edge</code> | |||
* <code>Sqlite error : attempt to write a readonly database</code> | |||
The easiest way around these errors is to delete the navcache and let FlightGear automatically rebuild it the next startup. Depending on the amount of scenery available to FlightGear on your computer it may take some minutes. | |||
=== Corruption due to crashes === | |||
The navcache also seems to get corrupted during segfaults/crashes, especially on Windows, but more recently also on OSX: | |||
{{FGCquote | {{FGCquote | ||
| Line 115: | Line 88: | ||
}} | }} | ||
== Upcoming | == Upcoming developments == | ||
There's future work to move even more data into the cache — for example parking positions — which will further help performance for FMS / map systems since we | There's future work to move even more data into the cache — for example parking positions — which will further help performance for FMS / map systems since we | ||
won't need to parse lots of XML data repeatedly. | won't need to parse lots of XML data repeatedly. | ||
| Line 215: | Line 187: | ||
}} | }} | ||
== FGPositioned == | |||
{{FGCquote | |||
|it will become a base for the following: | |||
* FGAirport | |||
* FGRunway | |||
* FGFix | |||
* FGNavRecord | |||
* ATCData | |||
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/20111781/ | |||
|title=<nowiki>[Flightgear-devel] FGPositioned refactoring</nowiki> | |||
|author=<nowiki>James Turner</nowiki> | |||
|date=<nowiki>2008-08-16</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|I've been carrying on with my experiments with my FGPositioned idea, and I now have several of my original steps done: | |||
* Fix, NavRecord, Airport and Runway all inherit the base class | |||
* they all live on the heap, where previously Runway and Fix were stack based, and hence rather heavy to work with<br/> | |||
* since the liftetime is now (generally) long, I can use a persistent spatial index (currently not Matthias', but it's an easy, internal change) | |||
* I can query all of the above in a unified fashion, and add more types easily (Jon Stockhill has obstacle data I can add in) | |||
* I've written a bunch of test cases, all of which pass identically on the mainline and with my changes applied | |||
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/20257459/ | |||
|title=<nowiki>[Flightgear-devel] FGPositioned update</nowiki> | |||
|author=<nowiki>James Turner</nowiki> | |||
|date=<nowiki>2008-09-06</nowiki> | |||
}} | |||
}} | |||
{{FGCquote | |||
|it's also the starting point for working on improving the airways code and creating a standard FGFlightPlan class - an airway or flightplan is essentially built out of FGPositioned objects, tagged with some extra data. | |||
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/20111781/ | |||
|title=<nowiki>[Flightgear-devel] FGPositioned refactoring</nowiki> | |||
|author=<nowiki>James Turner</nowiki> | |||
|date=<nowiki>2008-08-16</nowiki> | |||
}} | |||
}} | |||
[[Category:Core development projects]] | [[Category:Core development projects]] | ||