Canvas Maps: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(33 intermediate revisions by 3 users not shown)
Line 2: Line 2:


== Status: The Map/NavDisplay backend ==
== Status: The Map/NavDisplay backend ==
* '''TheTom''': "Seems like the map and groundradar/map are good examples to use for improving the API and implementing new features. I'm currently working on passing all the needed events to the property tree and improving the API. But also the NasalPositioned needs to be extended to eg. also expose taxiways, aprons and parking positions (it's already possible to get the names of the parking positions but not their positions)."
* '''TheTom''': " [[ATC-FS]] is definitely an interesting application which can benefit from the Canvas very much. Maybe we can do some ATC programs which look like the real ones... "
* '''Hooray''': "The map dialog is certainly one of the more complex (and more interesting) dialogs, but it will definitely be a valuable lesson to see how the Canvas/GUI layer works, and if it still needs enhancements. And yes, since fairly recently, the navdb data is fully exposed to Nasal (also thanks to James, who did all this as part of his work on [[Nasal scripting language#Positioned Object Queries|NasalPositioned.cxx]])"
* '''Hooray''': " It would be great to have 2-3 "real" applications, so that the canvas/map API becomes more powerful."
* '''TheTom''': "Porting the map dialog should be possible as soon as the input handling is finished and I know if all needed information is available to Nasal (eg. Airport/Nav data)" {{Pending}}
* '''TheTom''': "vertical projection seems not too complicated as its basically just calculating segment lenghts on a sphere, or maybe just direct distance calculations. I think the error in comparison to the real sphere can be neglected while using typical distances (eg. at a distance of 300 miles the error is about 2.8 miles, which is ~0.9%)." {{Pending}} (see [[Canvas Maps]])
 
== Background ==
One of the most common 2D drawing needs in a flight simulator is related to charting and mapping of geographic coordinates (latitude,longitude,altitude) to screen coordinates (x,y). This is a shared requirement for navigational displays, MFDs and also GUI charts/maps. That's the reason why the Canvas system supports a dedicated mapping mode which automatically converts geographic coordinates (lat/lon/alt) to screen coordinates using two different mapping modes (horizontal/vertical).
 
This makes it extremely simple to create new fully interactive navigational displays and mapping dialogs.
 
There's now a first proof of concept available which replicates part of the built-in, hard-coded, [[Map]] dialog:
 
[[File:Demonstration of using the Canvas inside a GUI dialog..png|thumb|none|600px|Simple Map of KSFO]]
 
Using the Canvas system, it has now become trivial to create new map layers of symbols with geographic positions which are transparently mapped to screen coordinates by the canvas system automatically.
 
To illustrate just how powerful this new feature is, take a look at the following foreach loop which places all the parking positions in the shown map dialog (for the full code, see this [https://gitorious.org/~tomprogs/fg/toms-fgdata/commit/9a40c82bc06c33fb59b95188ea000d69e760b75a commit]).
<syntaxhighlight lang="php">
193  foreach(var park; me._apt.parking())
194  {
195 var icon_park = me.grp_apt.createChild("text");
196 icon_park.setDrawMode(9);
197 icon_park.setText(park.name);
198 icon_park.setFont("LiberationFonts/LiberationMono-Bold.ttf");
199 icon_park.setGeoPosition(park.lat, park.lon);
200 icon_park.setSize(15, 1.3);
201  }
</syntaxhighlight>
 
As can be seen in line 199, the canvas system directly uses geographic coordinates, so there's no explicit conversion to screen coordinates or other projection handling required. In other words: what you get from the Nasal DB, can be directly used here.
 
This feature is based on the ARINC661 standard, which handles this very elegantly: the A661 CDS (display) is really just sent geographic positions of objects, associated image information and it will automatically turn this into a horizontal or vertical map using the proper projection mode.
 
Basically, this means that users of the mfd/canvas module only ever need to know a handful of things (position, symbol, mapping mode) and they can get started right away.
And the really nice thing is that this abstraction wrapper can be reused for all related things: navdisplay, wxradar, tcas, fixes, airports etc.
 
Thus, the Nasal code to handle these display modes can be really short and elegant, especially compared to all the C++ code that we have currently for the same purpose!


== Shared Requirements (MFDs and GUI maps) ==
== Shared Requirements (MFDs and GUI maps) ==
Line 89: Line 56:
Overall, I feel that would be better implemeneted as a separate mode (implemented in C++)?
Overall, I feel that would be better implemeneted as a separate mode (implemented in C++)?
I think it would be better to use the same elevation data that is used for rendering, so that you don't have to create and provide the same data two times. Rendering an orthographic view would come for free if we implement support for multiple cameras. If we don't want to do it with rendering we can use a cached list of terrain intersections. I have seen such an implementation in one of the aircrafts in the forum (I think it was the 787).
I think it would be better to use the same elevation data that is used for rendering, so that you don't have to create and provide the same data two times. Rendering an orthographic view would come for free if we implement support for multiple cameras. If we don't want to do it with rendering we can use a cached list of terrain intersections. I have seen such an implementation in one of the aircrafts in the forum (I think it was the 787).
Yes, that's true - that's been discussed previously, but there was talk about using a dedicated scene graph for such moving map displays on the devel list.
Yes, that's true - that's been discussed previously, but there was talk about using a dedicated scene graph for such moving map displays on the devel list, see [[CompositeViewer Support]].
 
== Canvas Groups/Layers {{Done}} ==
The layer/grouping feature we talked about will definitely be useful once the canvas is being used for such displays, because these "layers" can usually be toggled individually - so group sorting to disable hierarchies of drawable nodes, sounds like the way to go.
 
Fortunately, with the canvas system, it will be possible to reuse the same code for GUI dialog widgets AND instruments, so there will be less duplicate code.
The only thing that's required for different aircraft or different dialogs is exposing some form of "style" helper, so that symbols/colors/fonts can be customized for different needs and instruments.
 
If that could be made to work, people could easily instantiate a new MFD gauge (or dialog!) and just customize it according to their needs, which will be great.
 
== Planned Features ==
Future extensions will probably include support for:


* using SVG files instead of manually coded geometry
Also see: [[Howto:Use a Camera View in an Instrument]]
* stylable elements (font size, color etc)
* showing AI/MP traffic
* show navaids and fixes
* showing ILS symbols (depending on scale)
* showing route manager routing
* weather radar
* compass roses
* map center / off center mode


Basically, the main features supported by existing NDs will be supported by the new map system (i.e. APP/VOR/MAP/PLN), while ensuring that it is still kept generic enough so that the same backend code can not only be used for cockpit gauges, but also for GUI widgets, i.e. custom charting/mapping widgets.
Related:
* http://forum.flightgear.org/viewtopic.php?f=4&t=15722&p=154788&hilit=synthetic#p153941
* http://forum.flightgear.org/viewtopic.php?f=71&t=17105&p=163120&hilit=synthetic#p163119
* http://forum.flightgear.org/viewtopic.php?f=71&p=164340#p163475


All of these will be implemented as "layers" (canvas groups) which can be dynamically toggled using properties. These layers will be internally converted to "canvas groups", so that they can be efficiently sorted.
== Vector data ==
{{Main article|Canvas Tile Element}}


Looking at the [[Map]] dialog docs, James was planning to add a bunch of other features which are not currently supported by the map widget, but which would probably be worth keeping in mind for the canvas system as such, for example:
Looking at the [[Map]] dialog docs, James was planning to add a bunch of other features which are not currently supported by the map widget, but which would probably be worth keeping in mind for the canvas system as such, for example:
Line 121: Line 73:
Also, he mentions "national borders & coastlines rendering" under planned improvements.
Also, he mentions "national borders & coastlines rendering" under planned improvements.


That would probably be best accomplished by rendering vector data from shapefiles (esri), OSG already has support for ESRI using the ESRIShape plugin: http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.2/src/osgPlugins/shp/ESRIShape.cpp
That would probably be best accomplished by rendering vector data from shapefiles (esri), OSG already has support for ESRI using the ESRIShape plugin: http://svn.openscenegraph.org/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.2/src/osgPlugins/shp/ESRIShape.cpp


Yeah, it seems like osgGIS is really focused too much on OSG. But instead of using shapelib for ESRI support I'd rather use gdal or ogr which is already used in TerraGear and is not limited to a single format. But I think this is something to consider later. For a first version of the map it should be enough to expose the data that is already available in the core.
Yeah, it seems like osgGIS is really focused too much on OSG. But instead of using shapelib for ESRI support I'd rather use gdal or ogr which is already used in TerraGear and is not limited to a single format. But I think this is something to consider later. For a first version of the map it should be enough to expose the data that is already available in the core.
== Misc ==
This is copied from various articles that have become obsolete now and which are considered for deletion - so none of this is currently planned, it's just kept here to help us assess whether all the required building blocks are in place, or if we should look into adding other building blocks.
=== Geo-referencing ===
* ability to load maps/charts in standard formats, i.e. as ESRI shapefile layers (There are some plugins for OSG to deal with ESRI/GIS data [http://osggis.org/wiki/index.php?title=Main_Page])
* access to terrain via terrain API to query terrain properties
* access to airspace via airspace API to query surrounding airspace
* access to navigation databases (airports, navaids, waypoints, airways)
* render to texture

Revision as of 14:42, 2 July 2020


Status: The Map/NavDisplay backend

  • TheTom: " ATC-FS is definitely an interesting application which can benefit from the Canvas very much. Maybe we can do some ATC programs which look like the real ones... "
  • Hooray: " It would be great to have 2-3 "real" applications, so that the canvas/map API becomes more powerful."
  • TheTom: "vertical projection seems not too complicated as its basically just calculating segment lenghts on a sphere, or maybe just direct distance calculations. I think the error in comparison to the real sphere can be neglected while using typical distances (eg. at a distance of 300 miles the error is about 2.8 miles, which is ~0.9%)." Pending Pending (see Canvas Maps)

Shared Requirements (MFDs and GUI maps)

It would make sense to introduce another wrapper here, something like "mfd.nas" which transparently handles the low level details and which uses canvas.nas as its workhorse.

Like you say, the API requirements for canvas and the mfd module will become clearer once existing dialogs and gauges are getting ported. I would however be careful not to put too much special stuff into the generic canvas module.

We need to keep in mind that once the hard coded Map dialog is getting ported, there will be lots of overlapping functionality with similar "displays", like the NavDisplay, agradar, wxradar - all of these are basically about mapping a geo-position to 2D screen space (horizontal currently).

The Canvas system's mapping mode loosely follows the ideas from ARINC 661. The current hard coded NavDisplay is really an ARINC 661 display - it takes a list of symbols, a list of items and combines then using a projection to create a final display. The only additional code is to deal with special things that can't easily be described by a simply symbol, especially the flight-plan/route path.


The Map widget will be special in that it will be a shared component that can be used for both, GUI dialogs, as well as MFD-style avionics. The idea is to create a generic system that can be easily parametrized and customized as required, so that it can be used by people to create all sorts of mapping/charting displays in FlighGear, either as conventional MFD gauges, or as GUI dialogs (for example ATC radar screens).

A display like the current navdisplay could be rendered as an instrument, but also as a GUI widget. In any case, there would be a fixed set of "inputs" and "outputs", i.e. the "interface" of the system.

In FlightGear, this would usually mean that there are input and output properties. For cockpit instruments, these would be mapped to hot spots, i.e. clickable panel actions.

So, what could be done is adding a new Nasal class to make these relationships explicit: input properties and output properties. When a canvas system is being loaded as an instrument, these "generic" properties would be mapped to instrument-specific properties. And when it is loaded as a GUI widget, these could be exposed as GUI hooks, i.e. mapped to checkboxes, buttons etc.

In its simplest form, developers would use different hashes or vectors to specify the properties supported for input/output, in each different mode:

  • Instrument mode
  • HUD mode
  • GUI (widget) mode
  • scenery mode

There could be other more specific modes, for MFDs (or CDUs).

For example, let's consider the MFD example, i.e. the map dialog, which has a single "control property" (input) to select if the runways shall be rendered or not. The GUI widget would simply map this property to a checkbox, while the cockpit panel would map it to a cockpit hotspot to show/hide this layer.

Obviously, it would be important to support multiple instances, so that an aircraft may have multiple MFDs, CDUs - and so that the cockpit settings don't override the settings in the canvas-driven map dialog, but that can be accomplished by using different canvases. At some point it might make sense to see how this can be optimized, so that a single canvas may be partially shared, ie. by having cascades of canvases (like we talked about), so that there are no redundant canvases being drawn. Basically, something like a shared canvas instance, which is evaluated for each instance of the instrument/widget, i.e. drawn multiple times per frame for the control properties of each canvas system (PFD, ND, EICAS).

That would make it possible to share multiple instances, with different settings, while sharing most of the rendering logic and data, i.e. a single canvas RTT context could be largely shared. That may be a worthwhile thing to support, because it would help improve the performance for complex glass cockpits, with many identical instruments (layers/groups) - which may still have different "modes" selected, so that they require their own rendering pass, while sharings lots of data/GL state otherwise.

That being said, I would consider changing the canvas class such that it is possible to link properties to certain usage modes/scenarios. That would make it possible for people to easily use the same code for different purposes.

Overall, I feel that the design would evolve automatically once we actually try to port the map dialog to become a generic canvas module, usable for both, cockpit instruments - but also as a GUI widget. In other words: how would the design ideally look, if we could create generic canvas systems for such purposes?

That shouldn't involve any C++ changes - just creating abstract interface classes for people to use - so that their subclasses automatically satisfy everything that's needed.

And it would actually make sense to support the same thing for GUI widgets, too - i.e. allow them to be rendered as part of fully functioning cockpit instruments, that may seem like over-engineering now - but all modern airliners use A661 meanwhile, and they all support "real GUIs" as part of the MFD/CDU - i.e. control boxes, dialog boxes, check boxes, buttons etc. So it would be great to support the FG canvas widget here, too - we could get it for free like this.

Moving Maps

Basically, a moving map terrain view would require support for accessing the FG tile manager, so that a orthographic view of the scenery can be rendered. It might be easier to use OSG's GeoTIFF support instead and require people to add GeoTIFF images for the region of interest? Overall, I feel that would be better implemeneted as a separate mode (implemented in C++)? I think it would be better to use the same elevation data that is used for rendering, so that you don't have to create and provide the same data two times. Rendering an orthographic view would come for free if we implement support for multiple cameras. If we don't want to do it with rendering we can use a cached list of terrain intersections. I have seen such an implementation in one of the aircrafts in the forum (I think it was the 787). Yes, that's true - that's been discussed previously, but there was talk about using a dedicated scene graph for such moving map displays on the devel list, see CompositeViewer Support.

Also see: Howto:Use a Camera View in an Instrument

Related:

Vector data

1rightarrow.png See Canvas Tile Element for the main article about this subject.

Looking at the Map dialog docs, James was planning to add a bunch of other features which are not currently supported by the map widget, but which would probably be worth keeping in mind for the canvas system as such, for example:

  • "use terrain height intersections to compute a EGPWS / G1000-style terrain clearance overlay"

Also, he mentions "national borders & coastlines rendering" under planned improvements.

That would probably be best accomplished by rendering vector data from shapefiles (esri), OSG already has support for ESRI using the ESRIShape plugin: http://svn.openscenegraph.org/osg/OpenSceneGraph/tags/OpenSceneGraph-2.8.2/src/osgPlugins/shp/ESRIShape.cpp

Yeah, it seems like osgGIS is really focused too much on OSG. But instead of using shapelib for ESRI support I'd rather use gdal or ogr which is already used in TerraGear and is not limited to a single format. But I think this is something to consider later. For a first version of the map it should be enough to expose the data that is already available in the core.

Misc

This is copied from various articles that have become obsolete now and which are considered for deletion - so none of this is currently planned, it's just kept here to help us assess whether all the required building blocks are in place, or if we should look into adding other building blocks.

Geo-referencing

  • ability to load maps/charts in standard formats, i.e. as ESRI shapefile layers (There are some plugins for OSG to deal with ESRI/GIS data [1])
  • access to terrain via terrain API to query terrain properties
  • access to airspace via airspace API to query surrounding airspace
  • access to navigation databases (airports, navaids, waypoints, airways)
  • render to texture