Board index FlightGear Development Canvas

How to display Airport Chart?

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.

How to display Airport Chart?

Postby Hyde » Tue Oct 22, 2013 1:55 pm

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
 
Posts: 724
Joined: Fri Aug 12, 2011 2:09 pm
Location: Peachtree city, GA
Callsign: N407DS
Version: GIT
OS: Fedora 25

Re: How to display Airport Chart?

Postby Hooray » Tue Oct 22, 2013 2:14 pm

Hi Hyde,

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_ ... d_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 ... 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:

Image

It is fairly straightforward to "extract" the logic to show the airport map in some form of dialog or instrument.

At the moment, the framework is still fairly basic, but it's documented at: http://wiki.flightgear.org/Canvas_Map_API

So if all you want is a dialog, you can use it as is - if you want the map to be shown on some form of cockpit-MFD, we need to make some (fairly trivial) changes - but I can walk you through them, I was hoping to clean up the messy map.nas file at some point anyhow, so why not now :D

Maybe you could briefly list your requirements, so that we can discuss the required changes, and so that I can post some code for showing the map.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: How to display Airport Chart?

Postby Gijs » Tue Oct 22, 2013 2:57 pm

Hi Hyde,

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.

Cheers,
Gijs
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9544
Joined: Tue Jul 03, 2007 3:55 pm
Location: Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: How to display Airport Chart?

Postby Hooray » Tue Oct 22, 2013 3:15 pm

I've asked Philosopher to help review the map.nas stuff to get rid of all the messy code and placeholders and implement the required hooks to also support instruments and additional map types.

@Gijs: Can we have a look at your ND implementation (assuming that it is using Nasal and the canvas system, and NOT the hardcoded display) ?

I'm asking because that will need to be generalized, too - preferably, by me having a look at your code, and then talking with Philosopher about integrating it with the map.nas framework, so that the functionality can be easily used in dialogs and instruments, but also customized as much as needed.

So if you should already have an ND implementation that would be good to know, because it's clearly overlapping with the map.nas roadmap, but also with Zakalawe's original plans of re-implementing the hardcoded map display, something which we recently talked about:

Subject: Adding a canvas to the route manager dialog (split)

zakalawe wrote:I'll be looking at adapting the MapWidget now, which will probably involve symbol / icon support in the Canvas map, since that's a recurring feature of all these displays.


Subject: Using a canvas map in the GUI

zakalawe wrote:I did some experimental work on converting the map dialog last night - I need to have some discussions with Tom about symbol instancing, since the vector symbols I'm doing for waypoints, VORs and so on should ideally be shared. I'll let Tom speak about his ideas for that.

Hooray, I have the impression you're also working on the mapwidget / map dialog - but it's all unfinished code? I'd like to avoid repeating effort, so if you're already working on it I can instead give you some help? So far I didn't see how to handle the route-path in the Canvas map, since it requires a path with both ends mapped by geo-coord.

From your screenshot, I'd say some symbol LOD is needed too - the taixways and tower symbols are already meaningless at that zoom-level.


zakalawe wrote:I would be absolutely delighted by a 100% Nasal driven replacement for the 2D panel and HUD systems - as you say, no C++ is needed!

What I've mentioned before is that I think there's some elements, especially in the HUD, that might benefit from native (C++) canvas elements to avoid creating hundreds of property nodes to describe them to the Canvas - especially for tick marks on ladders. But of course that's an optimisation, and the first step is to try pure Nasal.

And those items are things I could work on, but I would be delighted for someone else to work on them - indeed I've suggested it as a first project to several people on IRC, but I don't know if any of them contacted Tom as I suggested. My only concern would be that they talk to me so we can ensure the replacement system is 100% compatible with the existing HUD / panel loading code (which is C++) - that part should be trivial and doesn't matter until we have at least a proof of concept.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: How to display Airport Chart?

Postby Gijs » Tue Oct 22, 2013 3:22 pm

I've been in contact with James about this, so don't worry, it won't conflict with his plans. The dialog will eventually use the same map. Anyhow, the ND is more than just a map, but for the map part I make use of the map API.

The ND is in a messy proof-of-concept state at the moment and needs some more cleaning before anyone should dare to look at it. It's a collection of ideas, trials etc. to see what works and what doesn't. I'm currently in the quarterly exam period, so time is scarce, but I hope to have something more or less usable after FSweekend.
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9544
Joined: Tue Jul 03, 2007 3:55 pm
Location: Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: How to display Airport Chart?

Postby Hooray » Tue Oct 22, 2013 3:34 pm

Just to clarify: Are you using the Canvas/Nasal for the ND or are you using the hardcoded NavDisplay: http://wiki.flightgear.org/Navigation_display ?

I'm asking because any Canvas/Nasal code should obviously be reviewed and generalized, to make it aircraft-agnostic, and usable for different purposes - i.e. use in instruments, but also dialogs.

The dialog will eventually use the same map. Anyhow, the ND is more than just a map, but for the map part I make use of the map API.

what "map API" are you referring to here ?

The ND is in a messy proof-of-concept state at the moment and needs some more cleaning before anyone should dare to look at it. It's a collection of ideas, trials etc. to see what works and what doesn't. I'm currently in the quarterly exam period, so time is scarce, but I hope to have something more or less usable after FSweekend.


Please don't worry about your code being in a messy state - my original plans for map.nas were also hugely different, and I didn't mean for it to remain such a mess neither - I just put it together after I realized that people started doing copy/paste programming by adapting Tom's canvas examples, rather than generalizing the concept for different purposes and needs, to have a single backend, which is how we arrived at the placeholder-mess that map.nas has become meanwhile.

But I am hoping to team up with Philosopher and identify all requirements and fix up map.nas accordingly, so that it can serve as the common backend for any and all aircraft instruments and dialogs that have 2D charting requirements - including the NavDisplay and Map dialog.

I've been in contact with James about this, so don't worry, it won't conflict with his plans.

which is great, but admittedly a surprise to me - see the last PM that I quoted above - that's not even from a week ago, and I wasn't made aware of any related work by you back then, instead I was given the "go ahead" to take over from there, without knowing about your effort here ... :?

And this has happened more than once already, despite the fact that all parties involved are fairly active contributors and should know better ...
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: How to display Airport Chart?

Postby Hyde » Tue Oct 22, 2013 4:11 pm

Thanks Hooray, Gijs for your quick reply as usual.
I just wanted to fix the issue #1229.
I think I'd be better to wait for a while to be standardized.
Hyde
 
Posts: 724
Joined: Fri Aug 12, 2011 2:09 pm
Location: Peachtree city, GA
Callsign: N407DS
Version: GIT
OS: Fedora 25

Re: How to display Airport Chart?

Postby zakalawe » Tue Oct 22, 2013 4:51 pm

Gijs' experiment is looking pretty good already - I was able to give him some help with it on IRC. It certainly means we can deprecate the C++ NavDisplay code going forwards. Ideally we might want some alternative spatial queries (to address a sorting problem which also affects the C++ versions), again we discussed this and I can add them relatively easily.

Above Hooray quoted some PM comments from me (and some rather outdated comments of mine from somewhere else), just to clarify, I wasn't aware of Gijs' work at that point. I don't think there's a communication problem, just that it's much faster to work on a concrete implementation than trying to create a perfect, generalised, agnostic, does-everything design.

Hyde, I believe Gijs' work on the PFD and EICAS are already in Git - you could adapt the 777 to use them already, and it would improve some features (or simplify the 3D models, and cut down on the textures). Certainly if I get any time to work on the NG (unlikely before 3.0) that's what I will be using.
zakalawe
 
Posts: 1259
Joined: Sat Jul 19, 2008 5:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: How to display Airport Chart?

Postby Hooray » Tue Oct 22, 2013 5:33 pm

Thanks for clarifying, and sorry for probably sounding a bit surprised (aka PITA) - but even if you learned about it after our PM exchange, it might have been a good idea to let me know that there's something in the works - rather than staying silent, especially given that your final words to me were basically along the lines of "sure, go ahead" - obviously, I'm just as happy about people contributing to this part as you are, so please don't get me wrong here - but yes, we do have a communication issue once several people start to work on -possibly- conflicting approaches, which is (if you remember) exactly what happened when the three of us (Stuart, you and myself) started working on the airport selection dialog at the same time, where all of us seemed eager to move on rather quickly, only to see the whole thing being abandoned rather soon, along with a pretty long-winded and tedious review process eventually. That's, by the way, where the quotes came from - so it's not totally out-of-context or "outdated", this took all place fairly recently in FG-terms actually.

it's much faster to work on a concrete implementation than trying to create a perfect, generalised, agnostic, does-everything design.


I share your concerns regarding "perfectionist" approaches and I'm also being wary regarding "design astronauts" - but obviously I'm familiar with the original framework/ideas, and would have loved to be made aware of any related efforts.

As I mentioned previously, I am not at all emotionally attached to any code (especially not any prototype/hacking) - feel free to throw it aware once you have something better.

I fully realize and agree that the design was a quick hack, but it was just intended to prevent us from seeing more and more "copy & paste" canvas uses without anybody spending time to look at things from a distance - which is something that's been all too common in Nasal-space since mfranz left the project, but which can also be seen in hardcoded examples like the NavDisplay/Map or earlier od_gauge-based instruments: little to no code reuse/sharing, meaning that conceptually identical features end up being re-implemented unnecessarily and without being compatible with eachother.

Finally, we are in a situation to solve such issues generically - and if somebody is volunteering to handle the generalization aspect (moi), that someone should be made aware of ongoing efforts - especially given that I specifically asked about it. Again, I don't expect anybody else to come up with an agnostic design, but being aware of it, I can at least help obviously, and reduce the amount of time required to fix things later on.

While map.nas in its current form is an ugly monster-hack, it is a single file that is straightforward to fix, i.e. a single place - which would no longer apply if we had dozens of more-or-less self-contained canvas uses for different purposes, all with their own code bases ...

So yeah, whenever an active and involved contributor is getting the impression that he may have wasted his time despite communicating extensively (and with the right people), we are doing something wrong - regardless whether we may agree technically or not, we cannot afford having people who're getting the impression that their time spent contributing may have been wasted because of such issues.

That is not to say that I wouldn't appreciate the work that's going on - in fact, I'm offering any help you/Gijs may need with this, regardless if it means integrating/porting things to use the original map.nas framework, or abandoning the whole thing altogether. I just want to make sure that we are actually collaborating efficiently - and obviously, that does require being aware of what people are working on in the first place, and not just learning about it by coincidence after having started related work.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: How to display Airport Chart?

Postby Philosopher » Tue Oct 22, 2013 7:30 pm

(Since this has turned into a project management discussion.)

I will offer to help restructure code and such. My primary goal would be to clean up class structure, do MVC (I think I understand what that means...), etc. once we agree what module we want to develop. I'll have to take a look at Gijs' design, but map.nas looks like an easy target for me to clean up. I also need to figure out where bootstrapping fits in, because if anything it would be higher priority for me, and it might even help with dependency management here.
Philosopher
 
Posts: 1593
Joined: Sun Aug 12, 2012 7:29 pm

Re: How to display Airport Chart?

Postby Hooray » Tue Oct 22, 2013 7:43 pm

map.nas itself is about 60-70% placeholders only, so it's fairly easy to "clean up" actually - but some of the ideas/concepts should probably be preserved until the original goal has been accomplished - and in the meantime, I suggest to wait for Gijs code - so that we can have a look. I'll offer to explain any missing bits regarding map.nas, and fill in any gaps documentation-wise, but also features-wise, to help provide what's needed to generalize the current Nasal/Canvas ND code and make it reusable in an agnostic fashion.

@Gijs: so if there's anything that needs explaining, just let me/us know and I'll provide the required assistance - however, even if you don't intend to touch/use the map.nas stuff, I'd still like to have a look at your code - no matter how messy you consider it for now, it's unlikely to be any more messy than the map.nas stuff :D
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: How to display Airport Chart?

Postby zakalawe » Tue Oct 22, 2013 10:18 pm

Hooray, apologies for not mentioning Gijs' work - it really didn't seem necessary to me, since it was shown to me very much in passing on IRC, and as a prototype / evaluation of what is possible. I even mentioned to Gijs that I'd discussed the matter with you recently, so I'm not sure what else is needed? If you produce an updated map.nas at some point in the future, then that's the time to see about modifying any existing code or prototypes (whatever they be) to use it. The more hacking and experimentation people do in the interim, just adds to the pool of examples and implementations you can base a general design on.

Anyway hopefully doesn't Gijs feels his contributions or time are wasted, that would indeed be unfortunate.
zakalawe
 
Posts: 1259
Joined: Sat Jul 19, 2008 5:48 pm
Location: Edinburgh, Scotland
Callsign: G-ZKLW
Version: next
OS: Mac

Re: How to display Airport Chart?

Postby Hooray » Fri Nov 01, 2013 11:02 am

Okay, Gijs has just committed his code, here's the relevant Nasal bits: https://gitorious.org/fg/fgdata/source/ ... /ND/ND.nas

For generalization, we'll need to remove any use-specific stuff, including listeners, timers, getprop() calls and other hardcoded constraints - those would be better done through function objects/predicates - otherwise, it should be fairly straightforward to move this incrementally to $FG_ROOT/Nasal/canvas/map and use a true MVC approach. Will be getting in touch with Philosopher. If anybody else is interested in working out the requirements/details, please get in touch - or just leave a message here. If there's sufficient interest, we can just as well discuss everything right here.

For styling purposes, it might be better not to draw things procedurally, but instead allow functors or SVG file names to be specified.

@Gijs: Not sure if you have any plans (or time) to further work on this in the coming weeks - but if you do, here's some preliminary feedback to help/simplify our integration work, take it with a grain of salt, depending on feedback from TheTom/Philosopher and Zakalawe. These are some of the changes that I would be making, let me know if you agree/disagree:
  • all your draw* callbacks look similar enough to what's currently used in the MVC stubs, so if you could change the signature accordingly, that would help a lot
  • basically, don't rely on global variables - such as canvas groups, instead pass the group to be rendered to, as an argument to the draw callback
  • instead of having var draw_fix = func (lat, lon, name) you'd use var draw_fix = func (group, lat, lon, name)[/b]
  • you will find that this will also make it much easier to have multiple instances of your instruments, without awkward global state
  • we can then simply add your draw implementations as *.draw files and extending the MVC framework accordingly
  • that will then make it trivial to also show separate/independent dialogs using your exact same code - as in having 10 different NDs, all with different settings, working properly :D
  • signature-wise, I would wrap anything that is specific to the type of symbol in a hash
  • styling: I would use a defaulted argument to check if the "built-in" image is to be drawn, or if a string/filename is provided, or a custom func (nil being default)
  • the range argument is probably what the original "lod" argument was supposed to do - so we can unify that, too ?
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Re: How to display Airport Chart?

Postby Gijs » Fri Nov 01, 2013 11:10 am

I quickly commited what I have to make sure we can use it at FSweekend ;-) My main concern so far was to get the basic functions working and see how it all can be done in canvas. I'll have a look with James tomorrow, to discuss the plan. After my last exam next Tuesday, I'll spend some more time turning this collection of ideas and approaches into something more usable.
Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Gijs
Moderator
 
Posts: 9544
Joined: Tue Jul 03, 2007 3:55 pm
Location: Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: How to display Airport Chart?

Postby Hooray » Fri Nov 01, 2013 12:23 pm

Even without having had a chance to run/test the code, things are looking pretty good actually, I think we can definitely use it, it will save us tons of time and help us reimplement the Map dialog, we could even show a "route" widget in the route manager dialog now - all based on your code! :D

Regarding the canvas/segfault you mentioned in your comments, Tom can probably clarify what's happening: https://gitorious.org/fg/fgdata/source/ ... D.nas#L359

@Zakalawe/TheTom: From an optimization point of view, having to call the .removeAllChildren(); method in each draw routine is probably not strictly necessary, given the sophisticated spatial queries that are now supported by NasalPositioned: if we could look up canvas groups/elements by a key (say VOR/FIX/DME identifier), we could only remove those that are actually out of range - I think the property tree code could be easily modified accordingly, and the NasalPositioned APIs could then be told to return the corresponding subset of "new" geographic positions, instead of having to redundant work.

Overall, we can work with the assumption that the aircraft is usually moving, so permanently updating its center/origin coordinates to selectively prune entries that are no longer in range should be more efficient than doing the whole thing in scripting space.

So there are probably some features that can be used to identify missing/useful extensions, not necessarily as dedicated canvas::elements, but rather as extensions to existing elements - once we have a more final version, we can do some profiling to find the low-hanging fruits.
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: 12707
Joined: Tue Mar 25, 2008 9:40 am
Pronouns: THOU

Next

Return to Canvas

Who is online

Users browsing this forum: No registered users and 3 guests