Live WXRadar MapStructure Layer Development

[omega95]

Nevermind, I found that it wasn't working properly because I forgot to flip the y axes. I usually consider +y as up but found that it was actually down in the canvas system. That fixed it!

Anyway, now that I got the instrument to work almost exactly as I want it to (unfortunately, the WX Radar layer is only available in North America - I have to use satellite weather imagery (a little less realistic) for the rest of the world) - I can start porting it into a MapStructure layer. Hopefully, this should be smooth.

[Hooray]

you could probably set up your lcontroller/searchCmd in a way that it uses geo.nas APIs to selectively use different APIs for different locations (lat/lon), so that different web services are used depending on the current position of the aircraft - such a scheme should be simple to implement - you would just use a helper class that encapsulates the location check and which contains a corresponding URL building routine. That way, you could also experiment with different schemes easily. Depending on how sophisticated you want to get, you could also let the searchCmd() method return a vector of tiled maps for a grid, e.g. 3x3 numbered from 0..8 so that you can fetch images more selectively and only transform previously fetched images if possible, which should allow you to save some bandwidth and have a more responsive layer, because less image data would be fetched over time.

I am sure that Tom can help clarify if/when native caching support via SQLite may become available - but once that is the case, we could even "pre-fetch" images

[omega95]

that it uses geo.nas APIs to selectively use different APIs for different locations (lat/lon)

Why would we need to do that? The WXR instrument shows data returned from the Weather Radar placed on the nose cone of the aircraft - and should also show radar images right in front of the aircraft.

Btw, I'm still going to use geo.nas for the coord class and to help make the math easier - not sure why I didn't do this earlier.

so that different web services are used depending on the current position of the aircraft

Do you mean radar/satellite imagegy based on availability? We could do that with a simple closest airport ID check (check first/ first 2 letters of ICAO)

you could also let the searchCmd() method return a vector of tiled maps for a grid, e.g. 3x3 numbered from 0..8 so that you can fetch images more selectively and only transform previously fetched images if possible

Ahh, I found that the data on wunderground's wundermap updates quite often. Considering that with a FREE developer API key, one can make 500 requests per day (10/min limit - so it'd be a mess if we get 9 images at a time). There are 1440 minutes in a day which means the API will let us make a request every 2.88 (say 3) minutes. This is actually pretty good - the weather radar shows more up-to-date data and it's cool to watch the storm system moving slowly on the WXR. Ofcourse, pilots will not be flying 24 hours a day, but a lot do fly 16+ hour flights on Flightgear (usually a scheduled VA flight) and especially considering that this instrument is targeted at glass cockpits which are used on medium/long range aircraft - so I wanted to make that possible. This will also leave some margin for testing - as I used up a lot more that my 10-min quota for testing that they sent me a warning, lol.

I am sure that Tom can help clarify if/when native caching support via SQLite may become available - but once that is the case, we could even "pre-fetch" images

But if we "pre-fetch" images, how can we stay up to date? The weather keeps changing and even google (especially google ) can't make a proper prediction.

EDIT - Just saw that git just finished pulling the canvas-hackers repository. Will go through the wiki section on creating new layers and do so after a short nap.

[Hooray]

I just mentioned the possibility of supporting different web services because you said that availability would be limited - likewise, pre-fetching obviously does have the shortcomings you mention, but people need to be all the time on-line to use such instruments - which could be a no-brainer for MP/VA flights or people using osgEarth - but otherwise, I do know a number of people who have fairly limited bandwidth, and who cannot be expected to remain on line for several hours just for certain instruments/maps to be functional. Either way, we may want to provide some dialog for layer specific settings. Overall, these recent developments provide some pretty cool features - but people may not be aware of the fact that being online is a requirement and that bandwidth may be consumed. The same method you've used here could also be used to support GIS formats to implement heightmaps/terrain views, i.e. using GeoTIFF images for example. And obviously doing so would be less resource-hungry than computing these heightmaps at run-time - but like I said, we cannot necessarily expect that everybody is on line, and we should work out some subset of features that continues to work in offline mode - otherwise, FG may soon become a pure online-experience given additions like osgEarth and avionics that are driven by online imagery/APIs.

Like I mentioned elsewhere, MapStructure itself is sufficiently modular to even natively use NaviGraph data without being restricted by FlightGear's outdated NavDB - and it wouldn't even be difficult to support such a mode - and like I mentioned in one of those "FGAIS" threads, a MapStructure traffic layer processing RL traffic could even instantiate traffic via the AI system fairly easily, even without going through MP - but we're obviously at a crossroads here, because we are now approaching a situation where we can easily re-implement existing functionality in a fairly flexible generic fashion, as long as we can make the assumption that people will have sufficient online bandwidth. Thus, I would definitely keep the offline use-case in mind and at least name such layers accordingly to make such dependencies obvious.

PS: you should only have to fetch/pull after adding the canvas-hackers repo as a "remote"

[omega95]

So far, I've just been adding the WXR layer to the ND canvas group but I'm trying to make it into a map-structure layer now.

I created a new WXR_live.lcontroller and WXR_live.symbol and added WXR_live to the navdisplay.styles file -

Code: Select all

{ name:'WXR_live', isMapStructure:1, update_on:[ {rate_hz: 0.1}, 'toggle_range','toggle_weather','toggle_display_mode'],
            predicate: func(nd, layer) {
               var visible=nd.get_switch('toggle_weather') and nd.get_switch('toggle_display_mode') != "PLAN";
               layer.group.setVisible(visible);
               if (visible) {
                  layer.update();
               }
            },
            'z-index': -4,
         },

But, when I try to start up an aircraft using this style, I get this -

Code: Select all

Nasal runtime error: MapStructure SymbolLayer.get(): unknown type 'WXR_live'
  at /home/narendran/fgfs/canvas-hackers-fgdata/Nasal/canvas/MapStructure.nas, line 27
  called from: /home/narendran/fgfs/canvas-hackers-fgdata/Nasal/canvas/MapStructure.nas, line 763
  called from: /home/narendran/fgfs/canvas-hackers-fgdata/Nasal/canvas/MapStructure.nas, line 775
  called from: /home/narendran/fgfs/canvas-hackers-fgdata/Nasal/canvas/api.nas, line 470
  called from: /home/narendran/fgfs/canvas-hackers-fgdata/Nasal/canvas/map/navdisplay.mfd, line 342
  called from: /home/narendran/fgfs/canvas-hackers-fgdata/Aircraft/777/Models/Instruments/ND/ND.nas, line 72
  called from: /home/narendran/fgfs/canvas-hackers-fgdata/Nasal/globals.nas, line 119


Do I have to make a reference to the layer anywhere? The code for the lcontroller and symbol are in the canvas-hackers WXR_live branch.

Thanks!

[Philosopher]

Change the constant at the top of .lcontroller from 'WXR' to 'WXR_live'

[omega95]

Aha! thank you - I thought I did that, but it was with my own fgdata copy and forgot to copy it to the canvas-hackers directory. Cheers!

EDIT -
Hmm, I don't get any errors anymore but the layer doesn't seem to be working. (Excuse me, this is my first MSLayer ) I know that it's not initializing either because it's supposed to set some props into the instrumentation/wxr property tree.

Also, I've made another commit where I moved the api_key.xml file to the Nasal/canvas directory with my key (for development/testing only) and loaded it from there. How exactly would I go about debugging this?

EDIT 2 -
Nevermind, I forgot to switch my --fg-root= path to the canvas-hackers-fgdata directory. I'm I have a barrage of errors - time to look at them one by one.

I was wondering what the below line is used for -

Code: Select all

layer.searcher._equals = func(l,r) l.equals(r);

I get an error saying this:

Code: Select all

Nasal runtime error: No such member: equals
  at /home/narendran/fgfs/canvas-hackers-fgdata/Nasal/canvas/map/WXR_live.lcontroller, line 22


Also, I still get a layer but I can't seem to get it to be affected by the range - even though the expression used by setSize uses the range.

Also, it seems to be way off proportion, but I think we should take this an error at a time.

http://postimg.org/image/f88cyq27j/5230b6d7/

[Philosopher]

How about in .init you register and start a timer to update the layer regularly (that's what the lcontroller is for ):

Code: Select all

me.timer = maketimer(me.update_interval, me.layer, me.layer.update);
me.timer.start();


And also I would suggest to use systime() instead of prop://sim/time/elapsed-/sec (because it's basically server time you're worried about, not sim time, and systime/maketimer use the local time).

The problem right now, I believe, is that your draw isn't being called on .init (you say to wait about 240 - -210 = 30 sec) and then you have to fly 2NM or more to update the layers, which you might not be doing. I would suggest to change it to -241 sec or higher to ensure it is immediately updated, then 240 seconds go by until it is updated again. But it's looking good, thanks for contributing here!

[omega95]

How about in .init you register and start a timer to update the layer regularly (that's what the lcontroller is for ):

But why would I need to do that if I already specified a refresh rate in the navdisplay.styles file? Shouldn't it update on it's own?

then you have to fly 2NM or more to update the layers,

Where did I do that? On the non-mapstructure canvas WXR overlay I made (http://s17.postimg.org/a86ecb2we/fgfs_screen_005.jpg), it works fine using the times (but I can switch to systime if it helps - that's not a critical issue, is it?)

What I don't understand is the error regarding the equals members.

[Hooray]

What I don't understand is the error regarding the equals members.

these are all covered in the MapStructure article - we've been diligently adding such information to the article over time, just look for _equals and you should find find an explanation there - we're hoping to make such discussions unnecessary this way: http://wiki.flightgear.org/Canvas_MapSt ... Controller

There's a fairly large note explaining things. And documentation is there for a reason, so that people can look at it

The main thing to keep in mind here is that many MapStructure layers deal with positioned objects, i.e. objects that have lat/lon/altitude - internally, the system uses a "diff" (delta) method to compare the current result set against the previous result set to tell how many new/removed items are there - so that things can be selectived updated (added/removed), i.e. to only partially redraw/update things for the sake of efficiency. In this particular case, using this method may be over-engineered, because you're basically just having an overlay and are using it as a background. But to work around the error message, you can just provide that a callback that always returns false - please refer to the wiki for details.

Besides, given your own experiences now - both of you (omega95 & artix) are obviously invited to help improve those docs - but obviously that only makes sense if you've actually looked at them ...

But even if you should prefer the forum, it makes sense to copy our responses there, so that others can refer to them in the future - because -as you're currently proving- people don't tend to search the forum to look at previous discussions.

[omega95]

just look for _equals and you should find find an explanation there - we're hoping to make such discussions unnecessary this way: http://wiki.flightgear.org/Canvas_MapSt ... Controller

Oh wow, I was reading the article earlier today and I could almost swear I didn't see that - must have just missed it. Thanks anyway.

[Hooray]

No problem, admittedly, it's become a fairly massive article - but it does help to use CTRL+F to search the whole thing ...
Besides, regarding a custom _equals() method for you, you could fairly easily use the URL itself - i.e. if current URL == previous_URL, the image would be identical obviously, and would not need to be re-fetched/redrawn - as it should already contain things like resolution, position etc as GET-encoded parameters.

For the equality check to work, you'd just store the filePath in your result and assemble it there (i.e. move all the redundant code out of the symbol file) via something like me.url = ...
and your equality check would then simply look at the me.URL field and use that equality checking.

Currently, your init/draw methods are fairly identical, so that should help remove redundant code, because you'd only have to pass the URL itself via the result vector, and all the other stuff would be kept in the lcontroller/searchCmd location

The URL would only ever be modified if it has changed obviously - and the translation/transform stuff would be separately handled regardless.

And like I said previously, I'd suggest to move URL building into a helper function (2-3 lines), so that you can more easily support alternate schemes.

also, I'd consider addning a procedural configuration dialog for things like API keys etc - which could be autosaved via the userarchive attribute, i.e. more intutive ...

PS: Philosopher: We shouldn't have to be using DotSym here as the parent class, maybe we need something like an Overlay class (which could also help generalize the compass rose and the grid layer) ?

[TheTom]

And like I said previously, I'd suggest to move URL building into a helper function (2-3 lines), so that you can more easily support alternate schemes.

Don't forget about string.compileTemplate: https://gitorious.org/fg/fgdata/source/ ... g.nas#L244

[Hooray]

right, thanks for pointing this out - I actually did remember this - but didn't want to intimidate anyone
However, the external interface is obviously simple enough and should work well for these purposes.

Regarding the WXR_live branch, here a few more comments:

• inheriting from MultiSymbolLayer probably isn't required if you don't intend to create a tiled map with multiple images arranged in a grid
• for things like position access (properties) the driver hash method should be used to encapsulate such accesses, so that the layer keeps working if a different position source is used (e.g. AI traffic) - which may seem weird at first, but is awesome for prototyping and regression testing, and it helps to keep the code pretty generic, too
• like I said, all those fields don't need to be passed from the lcontroller to the symbol file - it should suffice to generate the URL and just pass it, and then use that for equality checking
• the draw routine really only needs to know one thing: the kind of drawable and related parameters, but the details should be normally set up in the lcontroller file - you'll see that once this encapsulation is in place, you could easily use the exact same code to even support tiled maps in a N x N grid
• some variables seem to be lacking the var keyword (filePath)

[wlbragg]

I'm not sure this is worth mentioning but, if you need to lighten the load on weather underground you might consider National Weather Radar for North America also. I know a little bit about the direct radar links and how to read them.