Board index FlightGear Development Canvas

777 EFB: initial feedback

Canvas is FlightGear's new fully scriptable 2D drawing system that will allow you to easily create new instruments, HUDs and even GUI dialogs and custom GUI widgets, without having to write C++ code and without having to rebuild FlightGear.

Re: 777 EFB: initial feedback

Postby Hooray » Sun Jun 22, 2014 12:53 pm

and we could also more easily review/improve and patch things by committing directly, without being bothered by fgdata being possibly "broken".
Post your gitorious handle here so that we can set you up with commit access - otherwise, Hyde can also commit there directly on your behalf.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: 777 EFB: initial feedback

Postby Johan G » Sun Jun 22, 2014 2:50 pm

I-NEMO wrote in Sun Jun 22, 2014 12:26 am: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.
...
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'.
Of course, that's just my opinion.
...
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.
...
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.


It should be possible to add relatively complete charts procedurally. Terrain features and obstacles might be a problem though I guess. I think neither is needed on high altitude instrument charts though. The alternative is to provide tools or procedures to allow the user to rasterize PDF charts (in most parts of the world it will not be possible to legally distribute rasterized versions due to copyright).

You can find ICAO Annex 4, Aeronautical Charts, Eleventh edition, July 2009 (2.5 MB PDF) at the Swiss "Bundesamt für Zivilluftfahrt BAZL" (similar in function to the US FAA) web site.


Please respect the terms of use (Google translated). I do not want the single good free (and legal) resource gone:
The Annexes may not be printed due to copyright restrictions. The ICAO provides on its website (see link in the right column) venal Print and digital subscriptions to.

The publication of the following documents is illustrative, for their accuracy and completeness of the authorities take no responsibility.


The publication starts with textual specifications followed by sample cart symbols (do note that they only is a guidance; line widths etc can be varied). Regarding the symbols, Michat probably has a large svg set of the symbols used by FAA (and therefore in public domain). With some adaptation they would be suitable for procedural generation of chart symbols.

See also the topic which svg symbols are needed?.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5529
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: 777 EFB: initial feedback

Postby Hooray » Sun Jun 22, 2014 2:59 pm

I am a bit torn here - like you said, we can create 100% of the charts procedurally, including charts for TPs (terminal procedures like SIDs/DPs, STARs and IAPs) - the main issue is lack of data. And even if we get our hands on a relatively recent AIRAC cycle, the FG side of things (navdb) will not match that data. And in FG, we don't currently have the corresponding TP data. Converting/rendering existing charts (even PDFs from airnav.com) should be straightforward, but the FG world would use a different set of navaids and FIXES. So, we'd be better off looking at how X-Plane handles this challenge, given that they also used to use DAFIF(T) originally.

In general, I'd probably favor procedural creation if we can get the data - and short of that, I'd use the approach discussed a while ago: Subject: A project to create a source of free geo-referenced instrume


Such charts would be centrally created, along with VRT (XML) files for geo-referencing them, so that the corresponding charts could be requested at run-time and downloaded on demand (or cached).
We could probably use a simple form of OCR to extract navaid info from such charts to obtain relevant navaids for the given sector - it's just our navdb design that is kind of inflexible at the moment, but we could certain enrich/augment existing data using such updated data for navaids and fixes (or procedures)
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: 777 EFB: initial feedback

Postby Johan G » Sun Jun 22, 2014 3:32 pm

Johan G wrote in Sun Jun 22, 2014 2:50 pm:The alternative is to provide tools or procedures to allow the user to rasterize PDF charts (in most parts of the world it will not be possible to legally distribute rasterized versions due to copyright).

Hooray wrote in Sun Jun 22, 2014 2:59 pm:Converting/rendering existing charts (even PDFs from airnav.com) should be straightforward, but the FG world would use a different set of navaids and FIXES.

Indeed.

I find this being a very good (and tricky) point:
Hooray wrote in Sun Jun 22, 2014 2:59 pm:...we can create 100% of the charts procedurally, including charts for TPs (terminal procedures like SIDs/DPs, STARs and IAPs) - the main issue is lack of data... And in FG, we don't currently have the corresponding TP data.


An alternative to rasterizing PDF:s would of course be to improve Brisa's map generation tools so that they produce Annex 4 compliant maps (where applicable) using the data used in the scenery, like landclasses and object positions/elevations (for obstacles) as well as navigation aid and airport data. The maps could then be as if real, be using the same data as is used in-sim and (no less important) be fully distributable.

A database with procedures like suggested might be a good idea (but a lot of work). And it is indeed a good idea to have a look at how X-Plane handles the challenge (maybe there is even a possibility to team up like as with the other data).
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5529
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: 777 EFB: initial feedback

Postby Hooray » Sun Jun 22, 2014 3:40 pm

At least for the US, there's a ton of data freely available that can be extracted from such charts procedurally using a bit of scripting and OCR or regex. The corresponding data could be put into a database and updated regularly, according to the AIRAC cycle. But something like that should really be a central web service - in FG, we now have the means to easily download data via HTTP, and make web service requests. In other words, we could populate some kind of central navdb with our existing data, update the whole thing with the kind of data provided by the scripted discussed at Subject: A project to create a source of free geo-referenced instrume.

At that point, we would have a web service that could run a cron job to regularly update the whole thing - maybe in combination with some kind of wiki-like front-end to allow contributors to update/edit and maintain entries for different countries and navaids, as well as procedures.

The navdb would then be md5-hashed and fetched on demand, so that the navcache can be updated/rebuilt accordingly.


Subject: Why does Flightgear use X-Plane airport data?

Hooray wrote:I am not sure if I agree: There are so many advantages when reusing the X-Plane data and their format, they have a HUGE community of contributors - which FG simply doesn't have.

On the other hand, some web-based frontend to allow people to easily contribute and maintain airport/navdb data, would be great to have in my opinion:
Pretty much like a "GIS Wiki", possibly based on PSQL or even git - so that people could go to a website, open an airport/navaid and file merge requests, review entries and help maintain all the data there.

The new scenemodels submission process is actually a very good example here.

Something like this could be very useful, not just for airports (runways, taxiways, aprons etc), but also for navaids and terminal procedures (SIDs/STARs and IAPs).

And I guess we could even get the X-Plane community to contribute to something like this.
The whole work flow could be moved to a website, so that it would be easier contribute.

Using git as the backend (i.e. plain text files) would have the advantage, that we'd also get a revision history automatically.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: 777 EFB: initial feedback

Postby I-NEMO » Sun Jun 22, 2014 3:41 pm

Hallo,

that's interesting: I dont' know if the jlmcgraw's database covers the whole world or not, but those Chart's visual outcome is more than acceptable...(even if I'd prefer an higher resolution, for proper zooming on some details)

In the meantime, I had already got in touch with Brisa, asking if it would be possible to further develop his Application.
I'll keep you posted on that...

Regards,

I-NEMO
I-NEMO
 
Posts: 102
Joined: Thu Sep 29, 2011 2:09 am
Location: Italy
Callsign: I-NEMO
Version: 2017.2.1
OS: Windows 7 64 bit

Re: 777 EFB: initial feedback

Postby Hooray » Sun Jun 22, 2014 3:54 pm

I-NEMO wrote in Sun Jun 22, 2014 3:41 pm:.(even if I'd prefer an higher resolution, for proper zooming on some details)


keep in mind that procedurally-created charts using SVG/OpenVG primitives would be fine for _any_ resolution, because they would be vector images, not raster images.
The main limitations we have on the FG side of things is rendering terrain/ocean - thus, we'd need to use ESRI shapefiles for that at some point.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: 777 EFB: initial feedback

Postby I-NEMO » Sun Jun 22, 2014 4:16 pm

Hooray,

you're right; that's the old debate about vector and raster images' fans. Both of them do have their respective 'thumbs up & down'.
BTW: the jlmcgraw's Charts were raster, or am I wrong?...that's the case where I would prefer higher resolutions...
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?

Regards,

I-NEMO
I-NEMO
 
Posts: 102
Joined: Thu Sep 29, 2011 2:09 am
Location: Italy
Callsign: I-NEMO
Version: 2017.2.1
OS: Windows 7 64 bit

Re: 777 EFB: initial feedback

Postby Hooray » Sun Jun 22, 2014 4:28 pm

Nope, 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
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: 777 EFB: initial feedback

Postby Johan G » Sun Jun 22, 2014 6:17 pm

Very interesting links. Thanks for sharing.

I note that one would have to buy the ARINC 424 specification and that AIXM seems to be a free download. At the other hand ARINC 424 is used on the flying side, while AIXM seems to be used on the ATS side.

I am not that surprised to see an ESRI product here as they probably have near monopoly on cartography through ArcMap. :| That said it is probably very effective after styling and configuration.
Low-level flying — It's all fun and games till someone looses an engine. (Paraphrased from a YouTube video)
Improving the Dassault Mirage F1 (Wiki, Forum, GitLab. Work in slow progress)
Johan G
Moderator
 
Posts: 5529
Joined: Fri Aug 06, 2010 5:33 pm
Location: Sweden
Callsign: SE-JG
IRC name: Johan_G
Version: 3.0.0
OS: Windows 7, 32 bit

Re: 777 EFB: initial feedback

Postby I-NEMO » Sun Jun 22, 2014 6:29 pm

Hooray,

thanks for the info: at the moment, my idea is to use Charts 'as-they-are', no need for too many elements to be handled from Canvas (nor, to learn another piece of software!...and then process all the various data and charts).
Procedurally generated Charts requires work, a long work; the final result would be always be less valuable than a real Chart, especially because it's - probably - already available.
Here's my very basic startup proposal for Charts:

    1. - decide (all together) which source for Charts to use; the source should have Charts for all the world, otherwise it would be partial, and people wishing to integrate the missing Charts would have to deal with possibly different standards;
    2. - try to take FG to use real world data (why on earth should we use WPs that do not correspond to real world WPs?). I'm aware that this is a major change, - and that it will take a LOT of time - but I would avoid the feeling to be able to fly in an 'indian reserve', so to speak, and with 'FG personalized' charts.
    3. - ensure that the charts (all of them, Aerodrome and Navigation Charts) do have geo-spatial data ( scales on the vertical and horizontal Chart's side) with North orientation;
    4. - probably/eventually setup a transformation tool (nasal?) to be addressed from within the FG application (usually, an EFB), for different geo-spatial scales, so to quickly be able to get the Charts with the same geo-spatial data;
    5. - try to get .pdf handling/rendering into Canvas (a simple .pdf viewer like that offered by google, or sort of, might be quick-and-easy- to setup), so to have a decent resolution and smooth details; should this not been possible, we go for .jpg, but hi-res .jpg (from the Charts source!)
    6. - setup a bunch of useful objects to be overlayed to the Charts (Michat's library, for instance);
    7. - organize the Charts into a FG Database, by ICAO, hosted on an FG server.
Of course it needs to be discussed/modified/developed, but keeping in mind that we need to be simple and effective.

It would be good, I presume, to SetUp a Chart Team...and certainly another Topic !

Regards,
I-NEMO
I-NEMO
 
Posts: 102
Joined: Thu Sep 29, 2011 2:09 am
Location: Italy
Callsign: I-NEMO
Version: 2017.2.1
OS: Windows 7 64 bit

Re: 777 EFB: initial feedback

Postby Hooray » Sun Jun 22, 2014 6:42 pm

Like I said already several times previously: Opening/displaying existing charts should be fairly straightforward - the real challenge is ensuring that the FG navaid/WPT data is in sync with those charts - which either means to procedurally create charts, or to come up with a source and keep it sync according to AIRAC cycles. And while the US/FAA provide fairly good coverage, including free charts, which could be used to procedurally extract such info from most charts, this doesn't apply to most other countries. It may be much easier to simple go with external sources like NaviGraph, even if that means paying for the data, or using a slightly outdated version.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: 777 EFB: initial feedback

Postby I-NEMO » Mon Jun 23, 2014 2:53 am

Hallo Hooray,

agreed.
I would say the the 'sync' issue is of topmost importance; I still think that 'real' charts are better than procedural ones; unfortunately, as you said, at the moment that possible 'sync' would be available for US region only...and I assume that - eventually - it would be a rather long process.
So, I'll wait to read other's opinions and suggestions, while trying to devise with Hyde a working startpoint for the 777's EFB (Chart Section).

Thanks,
I-NEMO
I-NEMO
 
Posts: 102
Joined: Thu Sep 29, 2011 2:09 am
Location: Italy
Callsign: I-NEMO
Version: 2017.2.1
OS: Windows 7 64 bit

Re: 777 EFB: initial feedback

Postby Hooray » Mon Jun 23, 2014 12:43 pm

Well, we've been talking about the lack of current navdata in FG recently. On the MapStructure side of things we really only need to encapsulate any NasalPositioned calls, to support arbitrary data - including even fetched (XML), or manually entered navaids/fixes. Such data could then be centrally served or based on NaviGraph. So we wouldn't have to touch any of the existing NavDB stuff to work around its limitations.

So I am thinking about moving all NasalPositioned queries in MapStructure into a "driver" hash, but maybe more in line with the aircraftpos.controller stuff that Philosopher developed, just specific to some kind of "NavaidSource".

That would allow us to easily work around such limitations, so that I-NEMO, Hyde, Gijs etc can easily use the latest data on their EFB/ND. The other motivation here is that I experimented with interactive layers, i.e. where objects could be visually placed on a map-these could be scenery objects, but also navaids. And once we move such assumptions out of the lcontroller files, we can trivially support other cool use-cases, not just GUI-based editing, but even simulated radio navigation or other "learning" tools:

Image Image

Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Hooray
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Hooray
 
Posts: 11354
Joined: Tue Mar 25, 2008 8:40 am

Re: 777 EFB: initial feedback

Postby I-NEMO » Tue Jun 24, 2014 1:01 am

Hooray,

sorry to bother you...back on nasal coding.
I'm actually dealing with 3d-buttons on the EFB; currently I have a long list of buttons-objects in an .xml file, which are associated with the property 'keypress'.
Then, in the main efb.nas, I parse the actual 3d-buttons' pressing by that 'keypress' property with a conditional loop (keypress != "").
The whole stuff, using your words, is a "smell-code" :| .
I have read on the Garmin196 Topic about 'event-listener', and I would ask you to clarify the issue.
First question: How to associate an 'event-listener' to an .ac object? Is this possible?
Could you suggest an existing example with 3d-objects and/or propose a code to be used as a guideline?

My aim is to completely eliminate the long list in the .xml file, if possible; and to try to handle the 24 3d-buttons (not canvas objects, but .ac objects) from nasal only.
Second question: can the 'event-listener' be turned on and off, and/or just select specific 3d-buttons to listen to (sometimes, I just need to parse two buttons)?

Sorry for asking, but the FgWiki is not really clear for a beginner...

Thanks for your patience,

I-NEMO
I-NEMO
 
Posts: 102
Joined: Thu Sep 29, 2011 2:09 am
Location: Italy
Callsign: I-NEMO
Version: 2017.2.1
OS: Windows 7 64 bit

PreviousNext

Return to Canvas

Who is online

Users browsing this forum: No registered users and 0 guests