Canvas EFB framework: Difference between revisions

Jump to navigation Jump to search
m
no edit summary
mNo edit summary
Line 305: Line 305:
   }}
   }}
}}
}}
{{FGCquote
  |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). <br/>
<br/>
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]] <br/>
<br/>
[[File:Airport-selection-dialog.png|250px]]<br/>
<br/>
As you can probably tell, these kinds of layers would be very useful for any  kind of EFB related application.<br/>
<br/>
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 http://airnav.com] without having to download/convert/ship any imagery. The code required to pull this off would be very compact in comparison.
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=213084#p213084
    |title=<nowiki>Re: 777 EFB: initial feedback</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Sat Jun 21</nowiki>
  }}
}}
=== Page Handling ===
=== Page Handling ===
{{cquote
{{cquote
Line 425: Line 407:
   }}
   }}
}}
}}
{{FGCquote
  |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). <br/>
<br/>
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]] <br/>
<br/>
[[File:Airport-selection-dialog.png|250px]]<br/>
<br/>
As you can probably tell, these kinds of layers would be very useful for any  kind of EFB related application.<br/>
<br/>
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 http://airnav.com] without having to download/convert/ship any imagery. The code required to pull this off would be very compact in comparison.
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=213084#p213084
    |title=<nowiki>Re: 777 EFB: initial feedback</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Sat Jun 21</nowiki>
  }}
}}
{{FGCquote
  |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.<br/>
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.<br/>
In a word: Charts have to be real.<br/>
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.<br/>
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'''.
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=213115#p213115
    |title=<nowiki>Re: 777 EFB: initial feedback</nowiki>
    |author=<nowiki>I-NEMO</nowiki>
    |date=<nowiki>Sun Jun 22</nowiki>
  }}
}}
{{FGCquote
  |Please, check a couple of real KSFO charts:<br/>
<br/>
(source: airnav.com)<br/>
[https://www.dropbox.com/s/jjm53laqwbqkfnf/00375AD.pdf https://www.dropbox.com/s/jjm53laqwbqkfnf/00375AD.pdf]<br/>
(source: the Web, I presume it's originated by Jeppesen)<br/>
[https://www.dropbox.com/s/sqswo7fk64r3v9p/RR-CPAIR-KSFO-Airport-Diagram.jpg https://www.dropbox.com/s/sqswo7fk64r3v9p/RR-CPAIR-KSFO-Airport-Diagram.jpg]<br/>
<br/>
I do presume that this kind of Charts too might be procedurally rendered using Canvas and styling (texturing and canvas objects' overlay).<br/>
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.<br/>
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.<br/>
I would go for real charts (available on the Web), rather than producing again thousands of 'partial' charts.<br/>
I wish that someone else interested in this issue might share his opinion on this.
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=213115#p213115
    |title=<nowiki>Re: 777 EFB: initial feedback</nowiki>
    |author=<nowiki>I-NEMO</nowiki>
    |date=<nowiki>Sun Jun 22</nowiki>
  }}
}}


== Design ==
== Design ==

Navigation menu