Canvas tile element
| IMPORTANT: Some, and possibly most, of the features/ideas discussed below are likely to be affected, and possibly even deprecated, by the ongoing work on Integrating CompositeViewer Suppport and Compositor via a dedicated Canvas View element to render orthographic views to a Canvas. Please see: Post_FlightGear_2020.2_LTS_changes#Canvas for further information
You are advised not to start working on anything directly related to this without first discussing/coordinating your ideas with other FlightGear contributors using the FlightGear developers mailing list. talk page. |
|
Drawing an entire image via setPixel calls from Nasal will also be slow [...] I would suggest, it might be better to make these special image layers which are computed by C++ code, so they can be updated efficiently. — James Turner (2018-12-02 11:16:35). [Flightgear-devel] Feature request: Canvas dynamic image from Nasal.
(powered by Instant-Cquotes) |
|
|
|
Once you get to the extra features (of modern avionics), like FIS-B weather or TIS-B traffic info over ADS-B, or TAWS  (terrain alerting), we're probably in way over our heads trying to emulate even the simplest general-aviation IFR GPS.— David Megginson (Jul 3rd, 2017). [Flightgear-devel] RFD: FlightGear and the changing state of air navigation .
(powered by Instant-Cquotes) |
|
|
|
A moving map is a different beast. It would make sense to implement that as a scene graph in its own right with its own pager. That would require a change in current fg architecture to use a CompositeViewer instead of a single Viewer, but we're contemplating that anyway.
— Tim Moore (2008-08-04 09:43:37). [Flightgear-devel] Cockpit displays (rendering, modelling).
(powered by Instant-Cquotes) |
|
|
|
I'd really like to use the Atlas generated maps as a layer in the browser map. Is anybody out there looking for an adventure and is able to modify the Atlas map generator to generate maps on-the-fly? |
|
| This article is a stub. You can help the wiki by expanding it. |
Some contributors have been experimenting with atlas based moving map displays (with pre-rendered Atlas images), but with nasal code.[1] [2]
The nice thing about Atlas is that it uses the current FlightGear scenery for generating it's maps. If we get better scenery, Atlast produces better maps.[3]
This issue of not being able to render maps to a sub window is coming back to bite us every time. If it's not stuff like this then it's moving map/GPS/ND type instruments. [4]
James originally implemented the a moving navigational Map as a custom PUI widget - it's *not* an Atlas-replacement, or an MPMap replacement, i.e. not intended to also display terrain elevation [5]
An Atlas- style renderer as another layer is possible, it'd also let people builda 'map' dialog box with navaids and airways overlaid, like the map UIs in MSFS / X-Plane / Fly. [6]
In order to feed imagery from tools like Atlas or moving maps in general from a network server, you'd want to look at protocols like WMS and the servers which already have been developed for this purpose.[7]
the Atlas project already has a GetMap application, linked with CURL to to do the http requests... written by Fred back in 2004 [8]
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).
It isn't too far-fetched to suggest that sooner or later the project's increasing tendency to add functionality with a focus on people being online, will leave some people out of the loop.
Absorbing atlas back into the project can help the project to become self-sufficient again.
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).[10]
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.[11]
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.[12]
Discussion
Also, relying on external data hasn't always served the project too well - many data sources have disappeared over time, and that even applies to web services
an "offline" layer would be better, in the sense that it will also work for people without having to be online, i.e. it is procedurally created via Nasal/Canvas, and isn't just downloading/displaying external data that may sooner or later get out of date, or become unavailable altogether.
and the fact remains, over the years, many FG related web services and web pages have disappeared on us - thus, adding self-contained functionality that can be used without requiring on external services and without requiring an internet connection, is definitely desirable - as a matter of fact, the FG project has faced more than one crisis due to its reliance an external services for critical infrastructure.
Right now, we are in witnessing another iteration of this, as more and more functionality is added in a manner that basically hard-codes the assumptions that fgfs users always are online, and that it's okay for FG to access web services - this is problematic for a variety of reasons, such as security. The other issue is, FlightGear is getting less and less self-contained that way, because features like Phi or the FG1000 depend on external data sources, that may seize working - even if the underlying web service/API does not go out of business, even just a change in the underlying API/service will cripple older fgfs binaries - so that it's no longer in the hands of the project to determine if a certain binary/set of features is going to work 5 years from now or not. All of which is to say, you certainly didn't "waste" any time here - because your addon will remain available and accessible, and useful, even 5+ years from now - when many current web services (or users) may have "expired" (or moved on...)
Even as we're speaking, there's another discussion taking place on the devel list, about exactly this topic: integration of Navigraph charts and navdb in flight gear. This increasing reliance on external APIs and services means that fgfs binaries shipped now, may no longer be functional in the future - and as a matter of fact, we may be integrating proprietary/commercial services that way, or at least services that may one day become proprietary/commercial
The FG1000 has come a long way already, but I think it is particularly important to also keep the offline use-case in mind (like Thorsten repeatedly mentioned on the devel list and the forum), i.e. offline is equivalent to people behind a low-bandwidth connection, and here relying on TerraSync, package managers, catalog systems and online chart services/web APIs is rather problematic, and it will cripple such fgfs versions for people downloading them years from now, because there are too many hard-coded assumptions about external services that may no longer be available.
Besides, depending on external web-services makes future fgfs releases much less self-contained obviously, just like Thorsten stated originally (imagine downloading fgfs 2018.1 5 years from now - these features won't work at all).
That being said, unless I am missing something (e.g. because there is an explicit exception granting us the corresponding rights), the way we (that is, Phi/fgfs) is making access to their API, also seems very likely to be a violation of their terms of use. Given the legal turmoil surrounding fgmembers, the Honda jet and other controversial developments, I find it a little surprising that we're seeing such features added without clarifying whether a corresponding exemption exists or not (as in, linking to it, and adding it to the commit logs).
Primarily, it's a matter of agreeing that there's a problem and that people need to find a solution, to help determine what's viable - heck, some folks even suggested adding ads to the FlightGear installer/about box to "thank" companies who are sponsoring FlightGear in one way or another. But again, that's been a recurring topic - to some it's acceptable to run google ads on the website, others would rather accept paypal donations, or run crowd funding campaigns.
Either way, the more the FlightGear project is depending on 3rd party services that it itself cannot provide, it will need to figure out how to "scale" (or not ...)
All that being said, I am myself not a huge fan of the increasing reliance on external web services, I consider it hugely problematic, because FlightGear as a project tends to rely on 3rd party resources/services that are no longer under its control. I don't know if you are familiar with the "mapserver debacle", but that was a rather disturbing incident at the time, and it threw back the project considerably, with tons of discussions (for details, refer to the archives).
Thus, I am not overly interested in seeing more web services "embedded" into FlightGear, because I've seen how FlightGear ends up being crippled by such additions, the very instant they disappear (or even just "update"). Some folks have been downloading rather old/outdated FG versions for that reason - since these days, you can no longer assume that a binary/installer downloaded last week will continue to work next month, because we're adding more and more "online functionality". ThorstenR and others also have been sharing their concerns about the whole "being expected to be online" dilemma.
Then again, the osgEarth patches (which still work), do make the same assumption and do fetch the corresponding imagery on demand - which goes to show it can be done, if people care about such functionality.
As others said elsewhere over the years: for the project, the safest option at this point for our charting needs, is taking the atlas/map source code and modernizing that to turn it into a GIS/WMTS plugin - at that point, we can process our own scenery/terrain and create charts, obviously that doesn't fix the photo scenery issue though
Speaking in general, this would be a rather worthwhile direction for the project to take, because we're seeing an increasing reliance on external services/web APIs, so that fgfs versions in the future may use hard-coded dependencies for certain internal functionality - in other words, you may no longer be able to run a 2022.1 binary in 3+ years from now, due to this circumstance. That also applies already to fgfs instances running on computers that don't have any internet connectivity.
Using the aforementioned approach would make fgfs more self-contained again, and optionally address this external dependency, while also fixing the issue of most charts/maps not really matching fgfs scenery/terrain at all, whereas procedurally generated maps would obviously always be in sync with fgfs scenery. [13]
About setPixel()
Drawing an entire image via setPixel calls from Nasal (for terrain / wxr radar overlays by any chance?) will also be slow, in which case, it might be better to make these special image layers which are computed by C++ code, so they can be updated efficiently.[14]
Obviously, it's a valid use-case, i.e. creating a ‘scanned’ terrain radar, WXR or similar overlays on Canvas, no argument there, where defining a raster via paths is pretty heavyweight for frequent updating.
[15]
For features like:
- Inverse synthetic-aperture radar
- Synthetic-aperture radar
- Ground radar
- Ground radar for moving objects
But once we got capability for modifying canvas images real-time or through some other method like fragment shader, it will be usable for many things, for example wxr radar etc etc.[16]
Originally, radar altimeter was a big CPU hit, because it does a ‘scanned’ set of 3D ground intersections (over a range of angles in two axes) at the full FDM rate (120Hz), and this becomes significant number of triangle intersections.[17]
This kind of feature would be the prerequisite to get a working TERRain mode on the 737 MAP display.[18]
Status
07/2020
| Note This can already be done by treating the tile as a 3D model and rendering an orthogonal projection of the tile(s), and using the patch from Howto:Extending Canvas to support rendering 3D models |
RFC (idea/feature request frequently discussed on the devel list and forum)
To be fair though, depending on the progress in the scenery department (adopting Virtual Planet Builder), the atlas based approach may become obsolete sooner or later: World Scenery 3.0 roadmap
Background
FlightGear uses very outdated navigational data - whereas online sources (chart providers) use different data.
To solve this, we 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 web 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.[19]
| Note Porting Map.cxx into a dedicated ReaderWriter plugin for OSG by merging it with the existing STG/BTG ReaderWriter machinery in SimGear, we still end up with a mechanism that runs outside the main loop for loading/rendering, even if we're going through Canvas::Image or a subclass of it, because osg::Image objects are loaded by a worker thread. |
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.
Integrating Atlas
| Note Also note that, while atlas may seem huge/complex and archaic, all that is needed is porting Map.cxx - which is really just 600 lines of self-contained C++ code, because it's a standalone executable - and it deals with all the parsing/scenery processing using atlas APIs, so given that it's designed to run in a separate process, it could also easily run outside the fgfs main loop, i.e. as part of an OSG ReaderWriter plugin, at which point it would become trivial to also support BTG files at the canvas/image level, because the plugin would process the BTG files using Map.cxx: https://sourceforge.net/p/atlas/hgcode/ci/default/tree/src/Map.cxx
This would also mean that Phi could use an atlas/map based back-end for the creation of maps based on actual FlightGear scenery, as per Torsten's original idea.[20] |
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[21]
Pointers
- https://sourceforge.net/p/atlas/hgcode/ci/default/tree/src/Map.cxx
- https://sourceforge.net/p/atlas/hgcode/ci/default/tree/src/Tiles.cxx
- https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/canvas/elements/CanvasImage.cxx
- https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/scene/tgdb/ReaderWriterSTG.cxx
- https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/scene/tgdb/SGReaderWriterBTG.cxx
- Fgelev
- Canvas Image