Canvas Tile Element

From FlightGear wiki
Revision as of 12:28, 14 June 2020 by Hooray (talk | contribs) (→‎Intro)
Jump to navigation Jump to search
This article is a stub. You can help the wiki by expanding it.

Intro

tiled web maps are obviously great for many reasons, but people without a broadband internet connection may still want to use a different tool, or even an offline solution in general. And like I said, there is the issue of mismatching data - FlightGear has never been particularly good at this, but there is now an increasing tendency to rely on "online functionality", i.e. there is a growing assumption that people do have an internet connection, and that they're online while using FlightGear - depending on whom you ask, that is not just controversial, but increasingly problematic.


Apart from that, there is the issue that some of our really long-term contributor are in fact behind GSM-style connections, as well as a growing number of hard-coded online assumptions that have hit the project repeatedly - remember the METAR URL issue ?

Bottom line, it's not a good idea for the project to rely so much on infrastructure and make connectivity assumptions, FlightGear must remain usable in offline mode.

Atlas/Map can help the project to remain/become self-sufficient (again).

We've previously seen how this reliance on online infrastructure can hit the project really hard and affect the project for years to come (mapserver).[1]

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).[2]

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.[3]

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.[4]

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.[5]

Idea

1rightarrow.png See Atlas for the main article about this subject.

Atlas map view of the San Francisco bay area

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.

Integrating Atlas

atlas isn't "obsolete" - it just works "as is". What it provides ? A moving map, and in fact an accurate moving map - because it contains its own terrain processing routines that "parse" FlightGear scenery/terrain to render moving map charts interactively, and it does so in a different process (out of the FlightGear main loop), so can easily use other cores.

These days, it may admittedly seem redundant and even irrelevant thanks to options like Phi and/or Azure. But the truth is, atlas remains relevant, because it processes actual FlightGear terrain files to create those charts, but also because it's an "offline" application, you don't need a high bandwidth internet connection - it will even work without an internet connection.

As a matter of fact, the right thing to do would be absorb atlas/map into simgear and use it in-sim to dynamically create charts "on demand", which would then include "up to date" airport charts (think runways, taxiways, frequencies etc) - but that would also mean updating atlas, because it's still from the early pre-OSG days, i.e. is using legacy OpenGL[6]

References

References