Canvas EFB framework

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

Note: While this article is based on considerable community feedback, there's nobody working on this currently.
So if you'd like to help in one way or another, please get in touch or just help improve the article in the meantime!
Useful Skills:
PropertyList XML File, Property Tree, Nasal scripting, Canvas, CanvasMFD, Canvas Development, 777, 787


People:

Mentors: Hyde [3] This is a link to the FlightGear forum., Hooray (get in touch to learn more)
It's possible that this article hasn't been updated in a while, so to catch up with the latest developments, you are advised not to start working on anything directly related to this without first coordinating your ideas with fellow FlightGear contributors using the FlightGear developers mailing list or the FlightGear forums. See also the talk page.


Canvas EFB Framework
Omega95-efb-787.jpeg
Started in 06/2014
Description EFB Framework
Contributor(s) I-NEMO, Hyde, Hooray
Status discussion (777-200ER/prototype)
Folders

https://sourceforge.net/p/flightgear/flightgear/ci/next/tree/src/Canvas

https://sourceforge.net/p/flightgear/simgear/ci/next/tree/simgear/canvas
Topic branches:
fgdata (main repository, master branch; https://gitorious.org/fg/toms-fgdata?p=fg:toms-fgdata.git;a=shortlog;h=refs/heads/canvas-gui-demo)
Subforum https://forum.flightgear.org/viewforum.php?f=71



Canvas & PDF

1rightarrow.png See Canvas Development#PDF for the main article about this subject.

Cquote1.png Looking at the Boeing 777 EFB (which is driven by a Jeppesen Application based on Windows), they use PDF files (in hi-res) for Navigation Charts (and for Aerodromes too, I presume) in order to avoid any zooming problem.

I'd assume that a hi-res .pdf file would be the best easy solution, at the moment (it will take some time to define an acceptable standard for procedural charts, I presume): is Canvas capable of displaying a .pdf file?


— I-NEMO (Sun Jun 22). Re: 777 EFB: initial feedback.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png as I mentioned previously, Canvas cannot currently deal with PDF files directly - even though OSG does have support for doing this kind of thing, but we would need to add a few dependencies, i.e. a PDF rendering library like "poppler" that would render a PDF to an osg::Image. At that point, it could be dealt with like a conventional canvas image, and could even be retrieved via HTTP. Extending Canvas accordingly could actually be useful, because it would even allow us to render other PDFs inside dialogs - such as for example the manual itself, i.e. as part of some kind of integrated "help" system. The question is if TheTom can be convinced that this is a worthwhile goal or not. But it's clearly something for post 3.2


Based on Tom's previous comments, he doesn't really favor procecural chart generation either, but would prefer having some kind of "web service" from which charts etc could be fetched.

Not sure if you'd really want to come up with a corresponding "standard" from scratch, it should be easier to support the real thing, i.e. ARINC 424 / AIXM.

Traditionally, there are "CAD" tools for designing terminal procedures, i.e. tools like ArcGIS: http://webhelp.esri.com/arcgisdesktop/9 ... l_Solution

Also see this related discussion on the XP forum: http://forums.x-plane.org/?showtopic=46676


— Hooray (Sun Jun 22). Re: 777 EFB: initial feedback.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png More recently, another idea is to add dedicated PDF support to the core Canvas system, so that arbitrary PDF files can be rendered onto a Canvas: [4] This is a link to the FlightGear forum.
— Hooray (Sep 27th, 2015). Canvas MFD framework vs. EFB functionality.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png It might be also possible to decrease the quality of any PDFs a little to drop the sie. It would be good to have everything self contained, for easy reference. Was the procedure to carry these on the shuttle for quick lookups? Hmmm, I'm now wondering about a canvas PDF viewer This is a link to the FlightGear forum.!
— bugman (Sep 18th, 2015). Re: Space Shuttle.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png See: Canvas Development#PDFIt may make sense to revisit this idea, supporting a subset of PDF would not be too difficult, but it would be better to really use a PDF library and OSG's built-in suport for rendering a PDF to a texture, which could the be easily turned into a new Canvas Element, as per the example at: Canvas Development#Adding a new ElementThe coding part is relatively straightforward (basically copy&paste), but getting the dependencies/cmake magic right for all supported FG platforms would probably require a bit of work.
— Hooray (Sep 21st, 2015). Re: 777 EFB: initial feedback.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png I checked the OSG source tree and examples there, the C++ code is directly dealing with an osg::Image and the cpp file is just 100 lines, so it seems fairly compact: Adapting our CanvasImage code to also support PDF files should be fairly straightforward and not even take very long - so we can revisit this post 3.2 and I can also post some patches to get this started.
— Hooray (Jul 8th, 2014). Canvas Element for rendering PDFs ? (split).
(powered by Instant-Cquotes)
Cquote2.png

Motivation

Cquote1.png I've noticed that a number of aircraft start having some kind of an "Electronic Flight Bag" (EFB), like the 787-8. They allow to view check lists, manuals, flight plan, airport charts, IAPs, SIDs and STARs etc. This is quite a nice development, at least for modern aircraft.
— Jens Thoms Toerring (Sep 26th, 2015). [Flightgear-devel] Electronic Flight Bag.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png The problem I see is that, at the moment, each aircraft has its own implementation, so a lot of work is done repeatedly.
— Jens Thoms Toerring (Sep 26th, 2015). [Flightgear-devel] Electronic Flight Bag.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Thus I have been wondering a bit if it would make sense to develop a kind of framework for electronic flight bags.
— Jens Thoms Toerring (Sep 26th, 2015). [Flightgear-devel] Electronic Flight Bag.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png SIDS, STARs, and approaches are free for the US (where they're in the Public Domain, like most government-produced material). For Canada, they're not *libre* (free-as-in-speech), but you can get them *gratuit* (free-as-in-beer) from FltPlan.com.
— David Megginson (Sep 26th, 2015). Re: [Flightgear-devel] Electronic Flight Bag.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png I *think* what Jens is describing is just a global _framework_ to store these kinds of documents which then each plane would use, so that you don't have to copy files into every aircraft directory separately - it'd then still be up to the user to acquire the _content_ in a legal way and put it there. Without myself being much into airliner operation, to me this sounds a very useful idea. I think the best path forward is to get in touch with a few airliner maintainers who have used this kind of thing already, talk to them about a good interface/standard and then go ahead and do it - once it runs for 2-3 demo cases, others are going to adopt it.
— Renk, Thorsten (Sep 27th, 2015). Re: [Flightgear-devel] Electronic Flight Bag.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png at least a big part of it is about having a central location where EFBs built into the aircrafts can find data that all of them need. That are not SIDs or STARs as XML files (or whatever format would be used by the route manager) , but the corresponding approach plates, airport charts etc., i.e. stuff that you want to present to the user as graphics. Of course, there could bne more to such a framework in supporting functionalities shared by all EFBs.
— Jens Thoms Toerring (Sep 27th, 2015). Re: [Flightgear-devel] Electronic Flight Bag.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png the whole EFB idea has also been discussed previously, with a focus on using Canvas and Nasal - analogous to how Richard's MFD framework is just a front-end on top of Canvas/Nasal. Obviously, this approach (it not using Phi), has the limitation that it can only display stuff inside the fgfs main window.But we do have code/prototypes doing EFB handling using Nasal & Canvas
— Hooray (Sep 27th, 2015). Canvas MFD framework vs. EFB functionality.
(powered by Instant-Cquotes)
Cquote2.png


Background

Cquote1.png I'm trying to change 777's indicators to canvas system now. Could someone lecture me how to display Airport Chart - Aircraft/Instruments/Textures/od_groundradar.rgb - on EFB? Or is there any other equivalent method?
— Hyde (Tue Oct 22). How to display Airport Chart?.
Cquote2.png
Cquote1.png Feel free to work on the EFB (don't have that in the 744), but please don't waste any time on the rest of the displays. I already have PFD and ND for the 744 and am making them as generic as possible. They will end up in Instruments/ so we can re-use them on other aircraft.
— Gijs (Tue Oct 22). Re: How to display Airport Chart?.
Cquote2.png
Cquote1.png I'm quite busy with modeling a new EFB and other stuff.
Cquote2.png
Cquote1.png we are working on the new EFB, which is coming out nicely, we presume.
Cquote2.png
Cquote1.png I'm currently developing a new EFB for the 777 Seattle; even if I'm inspiring to Omega95's job made for the 787 Dreamliner (which, BTW, I'm not able to load onto FG 3.0!...a mystery!), I'm working on it since more than a month (everyday, several hours), the task is a long one. I do hope to be able to have a "rude" version of the new EFB (with some simplifications and enhancements, looking to Boeing's 777 EFB Manuals) to submit to my partners in about ten days (I'm totally a newbie on nasal! [Ouch! ]...but I'm trying to learn). Then, we will go through our internal testing and improvement. Then, again, the new EFB will be released 'as-is', so the FG Pilots might play with it and report back to us what's wrong, and what might be improved.
Cquote2.png
Cquote1.png we may not even need to run external EFB software, because our integrated scripting system in combination with the Canvas 2D rendering system may provide all the hooks required to render such geo-referenced imagery directly inside FlightGear with very little work needed - we even have http bindings to load images on the fly.
Cquote2.png
Cquote1.png we should have most building blocks required for this in place, maybe some things are not yet exposed to scripting space currently (but still available in C++) - but being able to run this directly inside FG would be kinda useful obviously, especially because of recent work in this area, especially the tiled map support, HTTP bindings, SGPath exposure (disk access). And being able to directly geo-align raster images has been previously discussed, too
Cquote2.png
Cquote1.png Right now the script basically just a creates .PNG and a .VRT for a given plate, suitable for loading directly into something like QGIS If you run the script for the entire set of plates (eg. "multithread.sh .") using the -s option you'll get a statistics file which has all of the lon/lat extents for each plate in it (which is how I made the spreadsheet I linked here)
Cquote2.png
Cquote1.png extending our 2D rendering API (Canvas) to provide a mechanism to geo-align such images would be kinda useful for a variety of purposes, we already have a "map" element that can automatically geo-reference lat/lon pairs without any manual work involved - and we also have support for a raster image element.
Cquote2.png
Cquote1.png all we have to do to display such charts within FlightGear is to load the chart image and apply the matrix created by the script. In the case of VRT files, it should be enough to just read the GeoTransform tag and set it as matrix on the Image element inside the canvas (with the parent element set up to have a coordinate system matching the current position and range). Some central server for collecting such free and geo-referenced charts would surely be useful and probably does not require too much space and bandwith. These charts would not only be useful for FlightGear, but also for real aviation applications, like EFBs. I think I saw this or a similar script somewhere inside the sources of Avare?
Cquote2.png
Cquote1.png having just a web service that maintains and provides those charts would be straightforward and should not require any work on the Canvas side of things, also it avoids redundant work, because charts would remain identical normally, i.e. would only need to be created once. Not sure what the geo-coding question was all about ..
Cquote2.png



777-200ER EFB [1] This is a link to the FlightGear forum.
777-200 EFB AIRPORT SEARCH, see [2] This is a link to the FlightGear forum.

The 777 EFB

Cquote1.png As I wrote several times, I finally decided to put hands on the EFB (Reason: No one ever took care of developing an EFB for the 777; a 'working' EFB, though) with two (2) main goals in mind:

1) to do something to compensate for the lacking of an EFB inside the Seattle.
2) to actually try (I repeat it: 'try') to learn some first essentials of nasal.

— I-NEMO (Mon Jun 02). Re: 777 EFB status & plans  ?.
Cquote2.png
Cquote1.png this Seattle EFB is just a 'rude' one: with this term, I mean (as a word's pun) 'unpolite'. I'm perfectly aware that the coding is horrible, clumsy, repetitive, silly and very, very far from what it should be.
My first aim was simply to have a somehow 'working' EFB inside the Seattle's Cockpit.

My second aim was to use EFB.nas as a starting playground for a newbie as I am on 'nasal'.
— I-NEMO (Mon Jun 02). Re: 777 EFB status & plans  ?.
Cquote2.png
Cquote1.png I do not pretend that current 777's EFB.nas is a piece of nice software; but - to my initial purpose - it works. Not completely, not nicely, not properly...but it's a starting point. At least, it works...
— I-NEMO (Mon Jun 02). Re: 777 EFB status & plans  ?.
Cquote2.png
Cquote1.png the EFB manual is made by Jeppesen for Boeing, and a particular ('vertical') approach must be considered by the casual developer (myself, in this case). Many functions devised by Jeppesen for Boeing are not easily simulated in FG; so - for the moment - I decided to skip them, and I concentrate on what I considered nice and/or useful (again, it's of course a matter of opinion).
[Note: anything 'vertical' is not portable, which works on the contrary on 'horizontal' perspective]
— I-NEMO (Mon Jun 02). Re: 777 EFB status & plans  ?.
Cquote2.png
Cquote1.png As I said above, my aim was to give the Seattle's Pilot the feeling of a 777's EFB.
I doubt that an Airbus might have been developed using the same Boeing's EFB. The reason is easy: the two aircraft were 'thought' differently by the actual engineers, and both Boeing and Airbus would have - not only possibly used different graphics - but also different software behavior.
Certainly, if Jeppesen was the EFB contractor both for Boeing and Airbus, Jeppesen's engineers undoubtedly used the 'standard' core of one of their EFB; but then, almost immediately they 'adapted' the EFB functionality so that Boeing and Airbus expectations could be respectively satisfied. At the end, we have two differently behaving tools (they do obviously interface to their respective FMC and instrumentation, which - again - works differently). Not to mention further applications added for newer versions, stemmed again in time by Boeing and Airbus.
— I-NEMO (Mon Jun 02). Re: 777 EFB status & plans  ?.
Cquote2.png
Cquote1.png I found Omega95's EFB from the 787 Dreamliner; I've studied it, 'thinking' that it could be considered as a good starting point (I somehow considered that 'that' piece of nasal was already considered as Standard and/or portable by the FG's community. And - again in my opinion - I considered that some of the logic behind Omega95's nice piece of software should have been adapted to the current Seattle Status; and I've tried, with my bad knowledge of nasal, to make something...functional. (it was Hyde's brilliant suggestion to use hashes for the airport data; but, I want to take those lines out of efb.nas, so to have a sort of easily accessible sort of DB
— I-NEMO (Mon Jun 02). Re: 777 EFB status & plans  ?.
Cquote2.png
Cquote1.png Nevertheless, I do agree with you, Hooray; I will gladly follow any working suggestion, and appreciate any real help in fixing the EFB; but, please, do consider that:

We want to have a Boeing 777 EFB (The device is already obsolete; real pilots now use other fancy devices on board).
  • It must be easy for a developer to actually use such an help.
  • It should be a quick and daily help, because - on my side, and being just two or three people - we want to achieve a FINAL release, passing of course through a WIP;
  • The expert should have a lot of patience with me, because on nasal I'm a dumb kid; I can learn easily, though, if you take care in fully Communicating (see above) the issues consistently and with the outmost care for details.
    My aim is to make a decent piece of software, which of course might be reused by someone else in the future; but my primary aim is the Boeing 777 Seattle, portable or not portable.

— I-NEMO (Mon Jun 02). Re: 777 EFB status & plans  ?.
Cquote2.png
Cquote1.png I like the fact that the code is using hashes to configure some things at the top of the file, but otherwise, it's still fairly non-generic and not very flexible at the moment. And structurally it is certainly overlapping with existing code, such as the Avidyne Entegra, or even just the GPSMap196 - especially the page handling and mode switching stuff is not yet sufficiently generic. There's a reason that we've been discussing a generic Canvas-based EFB framework, which should ideally use a common "MFD" framework
— Hooray (Sun Jun 01). 777 EFB status & plans  ?.
Cquote2.png
Cquote1.png Functionality-wise there seem to be a lot of corner cases handled already by the efb.nas file: https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/777/Nasal/efb.nas But especially event handling and mode switching is extremely explicit and non-generic at the moment, a problem that the original GPSMap196 code also had - the whole thing could probably be reduced by about 60% if we could work out a way to find common goals And the whole point is flexibility and generic code, so that things like the ND, PFD or EFB use the same back-end for implementing MFDs, and the same back-end for event handling, including page- and mode management.
— Hooray (Sun Jun 01). 777 EFB status & plans  ?.
Cquote2.png
Cquote1.png The basic recipe to make this sufficiently generic is basically what we did with Gijs' original ND code:
  • supporting multiple independent instances/instruments
  • supporting different aircraft
  • extracting useful code and generalizing it
  • integrating the whole thing with existing instruments (ND, PFD, EICAS)

— Hooray (Sun Jun 01). 777 EFB status & plans  ?.
Cquote2.png

777 Canvas EFB Roadmap

Cquote1.png I don't think you need to start from scratch at all, I would instead incrementally "modernize" some portions of your code, and prioritize updating those portions that you consider too inflexible/fragile at the moment, such as page handling for example.
— Hooray (Tue Jun 03). Re: 777 EFB status & plans  ?.
Cquote2.png
Cquote1.png Current development ('modernisation' phase) of the Boeing 777 Seattle's EFB is going on nicely; the code is shorter, more readable and cleaner.

I have not finished it, yet (I'd say that it's almost 50% done).


— I-NEMO (Sat Jun 21). Re: 777 EFB: initial feedback.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png At the moment I have a single Canvas group (i.e., EFB_group), with 5 children: the text-matrix (16 left lines, 16 right lines), a Title line , an Helper line and the Display.

The Display element is then textured with all the various pages' textures, called by the page-handler (see here below).
Currently, I'm using the .jpg textures which I had previously generated through Photoshop; in the future they might be replaced by .svg files, depending from actual interactive use of some graphical objects (a few EFB pages do need interaction with graphical parts). Besides - if i'm not wrong - I've read somewhere on the FGWiki that gradients are not handled by the SVG parser...and I do like to use some gradients effects (antialiasing and such) to achieve a sort of realism on the displays.


— I-NEMO (Sat Jun 21). Re: 777 EFB: initial feedback.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png that's the current status of the new 777 Seattle's EFB: it's still far from being perfect, but - as a newbie - I'm quite satisfied for the moment: I need to finish the first version fairly soon, because my to-do-list is long (I have to re-model all the aircraft fuselage [original model has wrong measures, sigh!], produce better gears and flight-control surfaces model & animations in Blender, and then to produce a new Paint-Kit in Photoshop; then all 3D models optimizations...and so forth; of course, we also have to take care of CDU, which will interface with the EFB. So, the job is still very, very long...
— I-NEMO (Sat Jun 21). Re: 777 EFB: initial feedback.
(powered by Instant-Cquotes)
Cquote2.png

Page Handling

Cquote1.png Page Handling Parser: what would be your advice? Could you give me some working examples - consistent with my actual EFB framework - to be tested inside my code?
I would test them, study them and come back with deeper questions and so forth.
— I-NEMO (Tue Jun 03). Re: 777 EFB status & plans  ?.
Cquote2.png
Cquote1.png I'd like to get a crystal-clear example about integrating a Canvas screen for a given page (remember I'm an old-school man, I like to be detailed; even if a concept is new to me, I first want to proper understand the Philosophy behind a certain solution, then I would study the logic, and then the syntax): how to create the instance, how to define properties like size, content, interactions and so forth.
— I-NEMO (Tue Jun 03). Re: 777 EFB status & plans  ?.
Cquote2.png
Cquote1.png I presume I could elaborate and reproduce it all along my current code, and get back to you with problems and results, so to solve issues, refine the coding, and to get it work...
— I-NEMO (Tue Jun 03). Re: 777 EFB status & plans  ?.
Cquote2.png
Cquote1.png I really suggest to take a quick look at F-JJTH GPSMap196 - it's still a stub, much less functional than your work, but at least the code is compact that way. Understanding classes/OOP would be helpful though, but that will greatly simplify all your other work either way. So it would be worthwhile to read up a bit on OO and maybe work through 2-3 tutorials, or even just play with classes in the Nasal console. Let me know if you have any questions - better use the wiki for OO question, so that we can directly update the corresponding articles.
— Hooray (Tue Jun 03). Re: 777 EFB status & plans  ?.
Cquote2.png
Cquote1.png Random thought: you know the view.nas code, the view managers? They have init, start, update, stop methods, which I think could be really helpful for pages as well. (Plus a register method to add a view-handler-aka-page
— Philosopher (Sat Jun 21). Re: 777 EFB: initial feedback.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png pretty much the "proper" way to do this can be seen in the Avidyne Entegra R9 code - but even a simple workaround like the one used in the updated GPSMap196 code should do for starters, and would at least be more flexible than the current method, while also being straightforward to update/extend or revamp at some point.


Regarding init/start/update/stop methods, those would be straightforward to have/add, currently the code is just structured such that this is all handled by the page manager. I kind of introduced that assumption a while ago to get rid of all the explicit polling and settimer/maketimer weirdness, because there was some discussion about having one timer/callback per "page", which was a bit concerning :D

gitorious/fg/canvas-hackers-fgdata/b6f4c80e2ac439db6f72c291a66ca3010f91e21d/Aircraft/Instruments-3d/GPSmap196/mfd.nas

Technically, I was really just using those experiments to come up with something more flexible in XML space (where we could trivially support such code blocks/tags), which I am hoping to extend over time, assuming that people would be willing to adopt such a system: Framework-centric aircraft-agnostic avionics development post on the forum This is a link to the FlightGear forum.


— Hooray (Sat Jun 21). Re: 777 EFB: initial feedback.
(powered by Instant-Cquotes)
Cquote2.png

Text Handling

Cquote1.png the Text object matrix is made by about 20 lines of text (to be consistent with some added applications, like the Descent Rate calculator, I had to add some more lines with different horizontal, vertical position on the screen, and different Font Size).
The piece of .xml code (EFB_display_lines.xml) which handles a given line of text (taken from Omega95' software) is quite large; so, I splitted the .xml related to all the text lines from the main EFB xml.
Still, I do not like it at all: is there a better solution for that?...the ideal would be to have just one piece of code to display a line, and a bunch of, say, 15 variables for all the various text properties (positions, alignment, font, font size, character size, and so forth); can nasal pass these variables to .xml withour addressing each time a setprop call? Or, even better: can we avoid .xml coding for the text matrix, and handle it from within nasal?
— I-NEMO (Tue Jun 03). Re: 777 EFB status & plans  ?.
Cquote2.png
Cquote1.png Regarding your current way of text handling, yes, there is a much better way using Canvas - you are still using the old method that people used to use when canvas was not around, it is now deprecated. Like you say, the whole XML/setprop mess can be avoided these days by using Canvas. TheTom's CDU framework is using the new method
— Hooray (Tue Jun 03). Re: 777 EFB status & plans  ?.
Cquote2.png

Procedural Charts

rgb files are conventional images, like jpg/png - so they are so called "raster images" (unlike SVGs, which are "vector images"). So to display raster images, you can use the tutorial at: http://wiki.flightgear.org/Howto:Using_raster_images_and_nested_canvases This assumes that you have previously created the corresponding charts as image files, a technique that omega95 and redneck have been using for a while.

For starters, you can use the Nasal console to play around with it: http://wiki.flightgear.org/Nasal_Console

Now, to add an EFB dialog to the 777, you could use the old dialogs and embed a canvas region, see the tutorial at: http://wiki.flightgear.org/Howto:Adding_a_canvas_to_a_GUI_dialog

If you want to display vector images (SVG) or custom-drawn maps, you'll want to use OpenVG paths

To display a procedurally-created airport chart (without adding a precreated raster image for each airport), you'll probably want to use the technique used by the airport selection dialog

Cquote1.png
  1. You can basically transform any group, i.e. by changing its scale/ratio, rotation etc - animations would be implemented by changing color/size/rotation through a timer for example, maketimer() should be used for those, ideally all through an Animation class that serves as a wrapper for all animation needs.
  2. The visual outcome of a procedurally created chart can be 100% customized, it's just a Nasal file that draws all those lines - colors, line width, labels etc (you name it) can be completely customized. You'd probably want to look at $FG_ROOT/Nasal/canvas/map/*.draw files for the handling of PARKING.draw, RUNWAYS.draw and TAXIWAYS.draw - those are standard Nasal functions that render to a group. However, this should really just serve as an example for the time being, because those files are going to be updated and ported to MapStructure during the upcoming release cycle (post 3.2), and people wanting to draw such diagrams should really be using Philosopher's MapStructure framework.
  3. Regarding airnav.com: there's no account needed, those charts can be directly accessed and downloaded, they're using standard ICAO codes to look up the corresponding PDF files.

— Hooray (Sat Jun 21). Re: 777 EFB: initial feedback.
(powered by Instant-Cquotes)
Cquote2.png


Cquote1.png I don't like the idea at the moment: I've seen some tests you proposed in the developmnet of the 'Airport Location' dialog: looking at Boeing manuals we want to stick to real charts, hi-res, full of details for the pilot; we just want to display a crisp nice .jpg, or .png, or svg, file on the screen (Boeing 777's EFB has a fixed ratio of 1.412371 proportion between width and height); a nice possibility, though, would be to superimpose some symbols over those charts, in time)
— I-NEMO (Tue Jun 03). Re: 777 EFB status & plans  ?.
Cquote2.png
Cquote1.png Procedural charts are not needed - PDFs converted to PNGs should work just fine. Displaying symbol overlays is straightforward to do using Canvas, and those could even be moving and animated symbols using the MapStructure framework
— Hooray (Tue Jun 03). Re: 777 EFB status & plans  ?.
Cquote2.png


Cquote1.png The current EFB code is heavily focused on rendering raster images, which can be retained obviously, but in FG, we have additional means to render airport information that is 100% in sync with the FG side of things (navdb).


For instance, we are going to "port" the airport-selection dialog to move rendering of airports/runways/taxiways/parking spots into dedicated MapStructure layers that can be properly styled and customized: Canvas_MapStructure#Porting_the_airports.xml_dialog

Airport-selection-dialog.png

As you can probably tell, these kinds of layers would be very useful for any kind of EFB related application.

As long as the underlying design for a "page"-based MFD framework is sufficiently generic, we can easily replace/augment raster images and procedurally created charts - we could even use the built-in support for fetching via HTTP to download images on-line. In fact, we could then even extend Canvas to directly support rendering PDFs (OSG supports this out-of-the-box), this would make many steps unnecessary, because we could directly access http://airnav.com without having to download/convert/ship any imagery. The code required to pull this off would be very compact in comparison.


— Hooray (Sat Jun 21). Re: 777 EFB: initial feedback.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Regarding the Chart issue: those Charts are not what I have in mind; basically, they lack of Lat and Long datas...and detailed graphics and infos.

At the time, Brisa did a very nice job with that Java application; but the actual result it's not what we're looking for: the Chart standard - for example - should include STAR/SID/IAP Charts, which have a lot of info and details used and/or usable by FG Pilots and ATC.
In a word: Charts have to be real.
The fact that FG may not get into the AIRAC update's cycles, is not that important at the moment...the main issue here is that FG data should be consistent with the real world data; if it reflects 2007 data or 2014 it's not really important, I think. The point is that if we want to simulate the real world, we have to take into account real world data.
Again: it's just a matter of setting up a sort of standard. But it should be based on reality, not on our simulation. Otherwise, we'll all fly inside a nice indian reserve.


— I-NEMO (Sun Jun 22). Re: 777 EFB: initial feedback.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png Please, check a couple of real KSFO charts:


(source: airnav.com)
https://www.dropbox.com/s/jjm53laqwbqkfnf/00375AD.pdf
(source: the Web, I presume it's originated by Jeppesen)
https://www.dropbox.com/s/sqswo7fk64r3v9p/RR-CPAIR-KSFO-Airport-Diagram.jpg

I do presume that this kind of Charts too might be procedurally rendered using Canvas and styling (texturing and canvas objects' overlay).
As I said earlier, the lack of a generally accepted standard in FG (at the moment) will take our Seattle's Team to devise a possible solution; we'll of course try to take into account avionics general rules and so forth.
Anyway I'll discuss with Hyde what would be a fair starting point...an EFB (any EFB) plays with Charts; and there are thousands of charts that a Pilot may need in his flight planning.
I would go for real charts (available on the Web), rather than producing again thousands of 'partial' charts.
I wish that someone else interested in this issue might share his opinion on this.


— I-NEMO (Sun Jun 22). Re: 777 EFB: initial feedback.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png It should be possible to procedurally render charts like these using Canvas and some custom styling:

Airport_Diagram_Generator
Adg-KSFO-0.png Adg-KSFO-1.png


— Hooray (Sat Jun 21). Re: 777 EFB: initial feedback.
(powered by Instant-Cquotes)
Cquote2.png


Also see