Canvas MapStructure layers

This article is a stub. You can help the wiki by expanding it.

• 

  A simple MapStructure layer called DEMO that renders a circle of NDB symbols (SVGs) in the vicinity of the aircraft using geo.nas and its helpers like geo.aircraft_position() and the apply_course_distance(course, dist) method as per [1]. See Canvas Radar to learn more.

• 

  MapStructure WXR (weather) layer created by omega95's using a web service API to fetch live online imagery

Canvas-based VSD prototype (Vertical Situation Display) developed by Omega95

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)

Note  These MapStructure layers are currently to be found in $FG_ROOT/Nasal/canvas/map - these are conventional Nasal files, but they are bound to existing data structures at run-time and become classes that can be procedurally instantiated and customized. Depending on the phase of the current release cycle, the links shown below may be outdated and more recent additions are to be found in the Canvas-hackers team clone only. There are several incomplete/missing layers, if you'd like to work on any of those, please get in touch via the forum first.

The main feat of the NavDisplay framework, and even MapStructure, is not so much its design (sorry, P. ) - which isn't particularly "standard" or even elegant - the main accomplishment is its loose coupling, i.e. the decoupled nature of these modules makes it possible for people -who are interested in very different aircraft, avionics and use-cases, to still collaborate effectively, simply because things are so flexible. So these two "frameworks" are primarily collaboration enablers, because people that would normally not collaborate can all of a sudden easily work on a common code-base pretty easily.

People doing modern MFD-style avionics or any kind of mapping/charting displays should really have no reason NOT to use these frameworks - if something is missing, extending the framework is simple enough, and it means that your work is going to be used -and even maintained- by a number of contributors who have a track record doing similar stuff.

Obviously, there are quite a few other examples of great avionics developed in Nasal/Canvas, particularly the Avidyne Entegra R9 - but as long as those are non-generic and use-case specific (e.g. single aircraft), it is unlikely that fellow contributors will step up to help maintain such modules over time unfortunately. And re-implementing existing instruments on top of NavDisplay/MapStructure is a win/win for all parties involved, because there's less aircraft-specific code involved at some point.

The whole MVC separation established by the ND/MS frameworks allows people to collaborate despite possibly working with very different aircraft and instruments/avionics, which even includes people who don't do any aircraft/instrument development at all, but "merely" GUI dialogs like an instructor console for example.

Name	Type (object/position)	Description	Status	management	drawing/styling	styling flags	drivers	Notes
ALT-profile	...	route manager/flightplan	Done	ALT-profile	ALT.symbol	...	local only	required to phase out map.nas
APS	Moving	Airplane Symbol	Done	APS	APS.symbol	...	all (main/AI/MP)	caching/styling ? needs listeners to respond to map events (ref-lat/ref-lon, heading, center etc)
APT	Stationary	Airports (ND)	Done	APT	APT.symbol	line_width ...	all (main/AI/MP)	caching/styling ? ticket #1320 Done [2]basically done, but some optimizations are being considered (mostly via the positioned APIs)
ILS	Stationary	ILS/LOCALIZER	Not done	ILS	ILS.symbol	line_width ...	all (main/AI/MP)	caching/styling ? should probably be split: LOC and ILS ?
AWY	Stationary	Airways (LO/HI) [3]	Not done	AWY	AWY.symbol	...	all (main/AI/MP)	also see James' comments at Map
DATA	Stationary	info labels for all layers	Not done	DATA	DATA.symbol	...	all (main/AI/MP)	also see Map and [4]
ESRI/SHP	Stationary	ESRI shapefiles (shp), e.g. for borders/coastlines etc [5]	Not done	SHP	ESRI.symbol	...	all (main/AI/MP)	prototype using a shp2svg script[6]. Either expose shapelib/OGR via cppbind or add a new CanvasElement for shapefile processing
FIX	Stationary	fixes		FIX	FIX.symbol	line_width ...	all (main/AI/MP)	caching/styling ?
FLT	Moving (continuous!)	Flight Path/History (main aircraft-only!)		FLT	FLT.symbol	...	main-only !	All API calls should be moved into aircraftpos.controller, so that we can encapsulate this and use timer-based sampling for AI traffic. caching/styling ?
GRID	Stationary	lat/lon grid		GRID	GRID	...	all (main/AI/MP)	draws a lat/lon grid with tic marks
NDB	Stationary	NDB stations	Done	NDB	FIX.symbol (draws a SVG)	line_width ...	all (main/AI/MP)	caching/styling ?
PARKING	Stationary	parking/helipads	Done	PARKING	PARKING.symbol	...	all	required to phase out map.nas
POI	Stationary	Points of Interest	Not done	POI	POI.symbol	...	all (main/AI/MP)	alreadyexposed via Nasal/NavCache
RTE	Stationary	Routing (legs, flightplan API)		RTE	RTE.symbol	...	main-only !	the route layer needs to use listeners to receive "onChange" notifications from the route manager, or it may take a few seconds until the route shows up ticket #1326 caching/styling ?
RWY	Stationary	runways	Done	RWY	RWY.symbol	...	all	required to phase out map.nas
OSM	Stationary	tiled map overlay via http (mapserver/OSM)		OSM	n/a	...	all (main/AI/MP)	performance depends on bandwidth, files cached persistently in $FG_HOME
OpenAIP	Stationary	tiled airspace overlay via http (openAIP)		OpenAIP	n/a	...	all (main/AI/MP)	Currently uses a Slippy Map raster image. Would be better handled with vector data, if available
VFRChart	Stationary	tiled sectional / VFR charting overlay via http (vfrmap)		VFRChart	n/a	...	all (main/AI/MP)	Currently uses a Slippy Map raster image of sectionals, only available for US and Germany.
TAXI	Stationary	taxiways	Done	TAXI	TAXI.symbol	...	all	required to phase out map.nas
TWR	Stationary	Tower position	Done	TWR	TWR.symbol	...	all	required to phase out map.nas
TERR	Stationary	Terrain heightmap (G1000-style)	Not done	TERR	TERR.symbol	...	main-only (tile-manager restriction)	use the terrain presampler to compose a heightmap using raster images. Will also be needed for modern Garmin-series avionics like the Garmin GNS530, as per[7]. Also see Omega95's pre-Canvas work at [8] and [9]. In 07/2014, omega95 started porting some of his VSD/heightmap work to use Canvas: http://forum.flightgear.org/viewtopic.php?f=71&t=23593&p=214920#p214906 http://forum.flightgear.org/viewtopic.php?f=71&t=21509&p=214897#p214826 http://forum.flightgear.org/viewtopic.php?f=71&t=23592&p=214943#p214925 http://forum.flightgear.org/viewtopic.php?f=71&t=23622
TFC	Moving	Traffic (AI/MP)	Done	TFC	TFC.symbol	...	all (main/AI/MP)	caching/styling ? needs listener to receive notifications once enabling/disabling AI/MP, needs optimizations (e.g. draw vs. just update)
TGT	Moving	ATC-Targets (AI/MP)		TGT	TGT.symbol	...	all (main/AI/MP)	caching/styling ?
TUT	Stationary	Tutorial targets		TUT	TUT.symbol	line_width ...	main-only !	also show models?
TWR	Stationary	towers	Not done	TWR-profile	TWR.symbol	...	all	required to phase out map.nas
VOR	Stationary	VOR stations		VOR	VOR.symbol	* line_width	all (main/AI/MP)	navaid layers need to register autopilot/navradio listeners in their controller, because the ND highlights certain stations based on selected frequency/OBS settings - caching/styling ?
WPT	Stationary	Waypoints (flightplan API)		WPT	WPT.symbol	...	main-only !	bug fixed [10], caching/styling ? navdisplay.mfd still contains a few stubs from the original code - they should be replaced once we respond to RM events in RTE/WPT
WXR	Moving	Weather (LW/AW only!)		WXR	WXR.symbol (draws a PNG)	...	all (main/AI/MP)	needs to use listeners to receive notifications on enabling/disabling AW, and any settings related to it, caching/styling?
WXR_live	Moving	Live Weather Only		WXR_live	WXR_live.symbol (draws a web-generated PNG)	...	all (main/AI/MP)	User is required to have a subscription (key) to the wunderground API. Also, switch source image to satellite if outside North American or Europe. Ported from - http://forum.flightgear.org/viewtopic.php?f=71&t=23753#p216316 (by omega95)

Live Weather Imagery

Do note that the weather data FlightGear uses is not as detailed that it will match those plots. Reading FlightGear's weather systems directly (as our, so far crude, WXR layer in the ND does) will give a more accurate view of what you will encounter. It'll certainly proof to be a lot more flexible once we'll implement various features and failures (I've planned to revisit it later this month). Not saying you should not try to use this API (it does look very nice), but it's not more realistic per se — Gijs (Sat Aug 09). Re: Displaying Remote Images (from URL/API) on canvas/MapStr. (powered by Instant-Cquotes)

Regarding the LW/AW system, it's true that it can try to model things based on METAR, but that isn't an "exact" science, like Thorsten keeps pointing out, there's a lot of interpretation/guesswork involved - what /might/ work though is enriching the system, and its heuristics, using additional data, such as those images - i.e. by fetching them via HTTP and post-processing them to get WXR info for certain coordinates - but that is something that isn't currently done, and while we can fetch images via Canvas or Nasal fairly easily, we cannot easily post-process them currently - that would require some image processing support (think OpenCV), or integration with the effects/shader framework - to affect Nasal-space placement heuristics etc. Unlike HTML5 Canvas, there's no such a thing as getPixel() etc available in FG's Canvas AFAIK for pixel manipulation in a setPixel/getImageData fashion(?) Probably, this is something that we don't want to do in Nasal space - it would be more efficient to really use either shaders or at least OpenCL bindings to accomplish the same in a more generic fashion. — Hooray (Sat Aug 09). Re: Displaying Remote Images (from URL/API) on canvas/MapStr. (powered by Instant-Cquotes)

the existing WXR layer uses the AW system - which puts all "storm" info into the property tree, for details see the WXR layer, which should tell you where to look for the kind of info that AW provides (use the property browser) - overall, this is obviously fairly unlikely to be as detailed/accurate as live imagery fetched online - the other issue may be related to the tiling system used by AW, i.e. I don't know if it even tries to create/render storms far away - I am afraid only Thorsten can answer that reliably. — Hooray (Sun Aug 10). Re: Displaying Remote Images (from URL/API) on canvas/MapStr. (powered by Instant-Cquotes)

Vertical Layers

Note  Also see http://forum.flightgear.org/viewtopic.php?f=71&t=23593

Omega95 played with this a while ago: Howto:Implement a Vertical Situation Display in Nasal

Not important right now, but the design should be prepared to support both types of maps - it is foreseeable, that will have vertical maps, i.e. altitude/terrain graphs, such as a VSD or an approach profile (instructor station), also a VNAV map would benefit from having a straightforward way to show a vertical map, especially from a performance standpoint (i.e. having all those geodinfo calls!), basically:

• layer dimensions (x/y)
• geo-referencing a position, i.e. mapping the origin to geographic coordinates (lat/lon)
• transparently mapping altitude/coordinates to proper screen coordinates.
• i.e. say, the route manager has 5 waypoints with altitude constraints
• the total route is 50 nm - the X axis is 400 pixels wide, so 10nm => 80 pixels on the X axis
• well, roughly - if our first waypoint is 10 nm ahead, it needs to be drawn at 80px, and the aircraft symbol needs to be drawn at X:0
• vertically, the altitude differences between all waypoints are between 2000ft and 14000ft, i.e. 12000 ft
• so the Y axis (200 pixels) needs to be split into segments, where 1200 ft corresponding 20 pixels
• waypoints would then be mapped to this coordinate system
• this is just for prototyping, it would obviously need to support a range knob, too - i.e. directly transform as required (Tom once mentioned that he would add hardcoded support for this at some point, so before we spend any significant time on this, get in touch with him first)
• from a design point of view, the "driver" (model) for the view could be shared between all VSD instances, i.e. should be more efficient in cases where one VSD shows a greater range than the other, because the same data could be reused/plotted, and possibly even the whole canvas group for the terrain data, i.e. as a texture map.

these are the main steps to port your work to become a MapStructure layer extend api.nas to allow "vertical" maps to be added, these would be just canvas groups for now, because we don't have support for hard-coded projections currently i.e. change the .addLayer() method to add a mandatory mode/projection argument (defaulted to "horizontal") support a *.symbol field that also defaults to "horizontal", but which can be overridden by vertical layers add a new MapStructure layer that renders a polygon, the lcontroller file would then simply return a set of lat/lon/alt vertices investigate if/how to reuse lcontroller files (WPT/RTE) Overall, this shouldn't be very difficult, and it would allow omega95's work to be reused in other places, including other aircraft and GUI dialogs. At the same time, this would mean that we'd support independent instances and styling, too. — Hooray (Sun Jul 20). Canvas Vertical Maps vs. MapStructure VSD layer. (powered by Instant-Cquotes)