Canvas Maps

Canvas - the FlightGear 2D drawing API
Canvas - Main Page Canvas News - for the latest developments Shiva Alternatives - ongoing work for Core Profile support Canvas FAQs - frequently asked questions Canvas - Getting started Canvas Development (core) Canvas Troubleshooting (core) Canvas Sandbox (core) PUI2Canvas (PUI/XML Parser) Canvas GUI Canvas Widgets Canvas Maps Canvas Snippets
RFC
Canvas Instancing Howto:New Canvas Execution Model Canvas SVG Canvas Popout Windows Canvas Scenery Overlays
Frameworks
Canvas Map API (soon deprecated!) Canvas MapStructure Canvas MapStructure Layers MapStructure Snippets Canvas Radar Canvas Animation Framework (WIP) Canvas Plotting Framework (WIP) Canvas MFD Framework Canvas ND Framework Canvas PFD Framework Canvas MCDU Framework Canvas EFB Framework Canvas Wrappers Canvas Glass Cockpit Efforts
Tutorials
Howto: Canvas Troubleshooting Howto:Adding a canvas to a GUI dialog (PUI!) Howto:Creating a Canvas GUI dialog file (New) Howto:Dynamic Liveries via Canvas (new) Howto:Creating a Canvas GUI Widget Howto:Add a 2D canvas instrument to your aircraft Howto:Parsing 2D Instruments using the Canvas Howto:Creating fullscreen Canvas applications Howto:Use SVG inside a Canvas Howto:Extend the Canvas SVG module Howto:Serializing a Canvas to SVG Howto:Canvas applications as Nasal submodules Howto:Using raster images and nested canvases Canvas HUD Howto:Project 3D to 2D coordinates on desktop canvas
Reference
Canvas Element Group Image Map Path Text Canvas Nasal API MessageBox Layout System Canvas GUI API Canvas draw library Event Handling
Related
Canvas Properties Unifying the 2D rendering backend via canvas Howto:Use a Camera View in an Instrument Howto:Extending Canvas to support rendering 3D models Howto:Extending Canvas to support MathGL
To be ported
Navigation display Map FGCanvas Canvas Nasal/JavaScript Subset
Deprecated by Canvas
Complex Glass Cockpit Avionics
(click on headings to toggle)

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 (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:

• 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

Vector data

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)
• 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