Canvas tile element
| This article is a stub. You can help the wiki by expanding it. |
Problem
Thanks to the Canvas system, we now have an increasing number of MFDs/avionics that use so called "slippy" maps - there remains the obvious issue that such a "slippy map" will usually be based on very different geo data than FlightGear's terrain (i.e. mismatching data).[1]
FlightGear uses relatively old data pulled at the time from X-Plane (IIRC). This data is not updated regularly because this could cause conflicts with the (also relatively old) scenery.[2]
More and more Airports that have different airport data on the FG Map & Route Manager. Route Manager data seems to agree with other map sources like Sky Vector. Does FG Map get updated from independent sources like Sky Vector & others.[3]
Status
Background
FlightGear uses very outdated navigational data - whereas online sources (chart providers) use different data.
To solve this, you need to use the same underlying data source.
The most straightforward option would be to procedurally render our own charts using the map/atlas tools, and use those internally, without relying on 3rd party sources, and online services:
Motivation
There is the long-standing idea to use FlightGear itself to render a map to a texture, e.g. based on the atlas/map source code (GPL compatible), quoting TorstenD:
- What I have in mind for the map is to render the map tiles (small 256x256px fragments of a map) from flightgear scenery data on the fly when the user requests them from within the map application. Thats how openstreetmaps works and I like the idea of reusing proven concepts. There is no need at all - in fact, it's not even desireable - to do that in the main loop. Running a standalone application (or call it process if you like) creating and serving the tiles will add no load to the FlightGear process, no matter how complex the map is.[4]
Idea
|
|
Given that we do have existing code to render such maps, and that the Canvas system does have support for loading raster images (sc::Image), this would be the most straightforward option to ensure that there is no mismatch between a moving map and a corresponding radar display, because it'd be using the same underlying terrain/vector data.
References
| References |