Feature Requests / Proposals / Ideas: Difference between revisions

Jump to navigation Jump to search
m
it is siMgear not siNgear ...
m (it is siMgear not siNgear ...)
Line 133: Line 133:
* add support to metar code, to run update on demand (i.e. when user requests an update)
* add support to metar code, to run update on demand (i.e. when user requests an update)
* the replay system is very nice, but it is not very convenient to use: improve usability
* the replay system is very nice, but it is not very convenient to use: improve usability
* add texture paging support to singear/flighgear
* add texture paging support to simgear/flighgear
* allow the navdb to be reloaded at runtime, possibly differentiating between airports,navaids,fixes etc. - so that changes can take effect without having to restart FG
* allow the navdb to be reloaded at runtime, possibly differentiating between airports,navaids,fixes etc. - so that changes can take effect without having to restart FG
* implement support for dynamically augmented/replaced airport/navaid/fix data, this is something that has been repeatedly discussed on the devel list: Robin Peel's database is not necessarily accurate in every aspect, and we may eventually want to use additional information-that is currently not yet available in Peel's database and that may possibly never make it into his database, due to its focus on X-Plane. Thus, the suggested approach was to simply use an additional FG specific dataset, that could optionally augment or replace existing information. In particular we are talking of inaccurate airport and navaid data, but also of smaller airports that simply don't bear any relevance for the X-Plane database. So, the idea was to provide a facility that could enrich the current format for certain places. Most likely we could simply maintain a set of separate XML files for airports and navaids from the Peel database that should be overridden or augmented with custom data (based on the coordinates,ID etc). Depending on a runtime property variable, FlightGear could then optionally honor such data or not. Basically, we can only win, as we are still maintaining compatibility with the Peel database, but could nevertheless begin to add additional data-without requiring any changes to the Peel database or even its format, and whenever this should causing any trouble we could simply disable the feature.
* implement support for dynamically augmented/replaced airport/navaid/fix data, this is something that has been repeatedly discussed on the devel list: Robin Peel's database is not necessarily accurate in every aspect, and we may eventually want to use additional information-that is currently not yet available in Peel's database and that may possibly never make it into his database, due to its focus on X-Plane. Thus, the suggested approach was to simply use an additional FG specific dataset, that could optionally augment or replace existing information. In particular we are talking of inaccurate airport and navaid data, but also of smaller airports that simply don't bear any relevance for the X-Plane database. So, the idea was to provide a facility that could enrich the current format for certain places. Most likely we could simply maintain a set of separate XML files for airports and navaids from the Peel database that should be overridden or augmented with custom data (based on the coordinates,ID etc). Depending on a runtime property variable, FlightGear could then optionally honor such data or not. Basically, we can only win, as we are still maintaining compatibility with the Peel database, but could nevertheless begin to add additional data-without requiring any changes to the Peel database or even its format, and whenever this should causing any trouble we could simply disable the feature.
2,561

edits

Navigation menu