Canvas MapStructure layers
|This article is a stub. You can help the wiki by|
| The FlightGear forum has a
subforum related to: Canvas
|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 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) ||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 |
|ESRI/SHP||Stationary||ESRI shapefiles (shp), e.g. for borders/coastlines etc ||Not done||SHP||ESRI.symbol||...||all (main/AI/MP)||prototype using a shp2svg script. 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. Also see Omega95's pre-Canvas work at  and .
In 07/2014, omega95 started porting some of his VSD/heightmap work to use Canvas:
|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 , 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).
— 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)
|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.