Canvas MapStructure layers

From FlightGear wiki
(Redirected from Canvas MapStructure Layers)
Jump to navigation Jump to search
This article is a stub. You can help the wiki by expanding it.

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

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 Done ALT-profile ALT.symbol ... local only required to phase out map.nas
APS Moving Airplane Symbol Done 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 Done APT APT.symbol line_width ... all (main/AI/MP) caching/styling ? ticket #1320 Done Done [2]basically done, but some optimizations are being considered (mostly via the positioned APIs)
ILS Stationary ILS/LOCALIZER Not done 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 Not done AWY AWY.symbol ... all (main/AI/MP) also see James' comments at Map
DATA Stationary info labels for all layers Not done 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 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 80}% completed FIX FIX.symbol line_width ... all (main/AI/MP) caching/styling ?
FLT Moving (continuous!) Flight Path/History (main aircraft-only!) 60}% completed 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 20}% completed GRID GRID ... all (main/AI/MP) draws a lat/lon grid with tic marks
NDB Stationary NDB stations Done Done NDB FIX.symbol (draws a SVG) line_width ... all (main/AI/MP) caching/styling ?
PARKING Stationary parking/helipads Done Done PARKING PARKING.symbol ... all required to phase out map.nas
POI Stationary Points of Interest Not done Not done POI POI.symbol ... all (main/AI/MP) alreadyexposed via Nasal/NavCache
RTE Stationary Routing (legs, flightplan API) 70}% completed 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 Done RWY RWY.symbol ... all required to phase out map.nas
OSM Stationary tiled map overlay via http (mapserver/OSM) 90}% completed 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) 90}% completed 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) 90}% completed 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 Done TAXI TAXI.symbol ... all required to phase out map.nas
TWR Stationary Tower position Done Done TWR TWR.symbol ... all required to phase out map.nas
TERR Stationary Terrain heightmap (G1000-style) Not done 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:

TFC Moving Traffic (AI/MP) Done 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) 20}% completed TGT TGT.symbol ... all (main/AI/MP) caching/styling ?
TUT Stationary Tutorial targets 80}% completed TUT TUT.symbol line_width ... main-only ! also show models?
TWR Stationary towers Not done Not done TWR-profile TWR.symbol ... all required to phase out map.nas
VOR Stationary VOR stations 80}% completed 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) 80}% completed 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!) 80}% completed 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 60}% completed 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 - (by omega95)

Live Weather Imagery

Cquote1.png 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

Cquote1.png 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.

Cquote1.png 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.

Vertical Layers

Note  Also see

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.

Cquote1.png 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)