Ground Radar plugin 1.5 beta 4

[Juha Holopainen]

Main changes from beta 3:

• If no approach paths have been specified for an airport, generic paths will be auto-generated to all runways (on runway extended centerline, 3 degree slope, terminating at airport elevation + 50ft over the runway threshold)
• For runways where the most often used approach is an offset one, a setting (Airport_Runway_Approach) is available to make the TTT lists and safety nets use that approach path to find aircraft on approach.

 

Edited July 22, 2022 by Juha Holopainen

[Jonas Kuster (1158939)]

Is it intentional that maps from other than the defined airport in the ASR are displayed in the APP window as well? As these maps have another than the active airport defined, I cannot deactivate them via the functions menu either.

[Jonas Kuster (1158939)]

When using the plugin function to reload airport settings (such as runway ends or buffers), deletions in the settings file (and therefore a return to the default values) are not considered for the drawings of the airport data. Only added or changed values are taken into consideration. To get a correct drawing of the airport data after deleting some values, the ASR file needs to be reloaded.

[Juha Holopainen]

On 13/04/2022 at 19:12, Jonas Kuster said:

Is it intentional that maps from other than the defined airport in the ASR are displayed in the APP window as well? As these maps have another than the active airport defined, I cannot deactivate them via the functions menu either.

At the moment yes. If not limited by ASRDATA and/or SCREEN-SPECIFIC lines, the map information will be displayed on every radar screen instance. As it's a relatively recent change that drawing a lot of maps on the APP window is an intended possibility performance-wise, the issue of conflicting maps hasn't yet been addressed. Whether it'll be done by simply filtering based on AIRPORT lines or an additional keyword such as AIRPORT-SPECIFIC to make it possible to separate the visibility in the maps list from the visibility on the radar screen, I'm not sure yet.

On 14/04/2022 at 01:22, Jonas Kuster said:

When using the plugin function to reload airport settings (such as runway ends or buffers), deletions in the settings file (and therefore a return to the default values) are not considered for the drawings of the airport data. Only added or changed values are taken into consideration. To get a correct drawing of the airport data after deleting some values, the ASR file needs to be reloaded.

I'll keep this in mind but depending on how much would need to be changed to make it work, the solution may end up being a complete fix, a fix to update the data in the currently open ASR only, or just a "this happens - deal with it" - note in the developer documentation.

[Jonas Kuster (1158939)]

12 hours ago, Juha Holopainen said:

At the moment yes. If not limited by ASRDATA and/or SCREEN-SPECIFIC lines, the map information will be displayed on every radar screen instance. As it's a relatively recent change that drawing a lot of maps on the APP window is an intended possibility performance-wise, the issue of conflicting maps hasn't yet been addressed. Whether it'll be done by simply filtering based on AIRPORT lines or an additional keyword such as AIRPORT-SPECIFIC to make it possible to separate the visibility in the maps list from the visibility on the radar screen, I'm not sure yet.

My concern is not really the number of maps, but that some of them cannot be activated or deactivated, just because the menu does not include them. I expected the AIRPORT parameter to do this, but it seems it's (only) a filter for the maps list in the menu. So might it also be an option to just skip the AIRPORT parameter? Because then all maps would be available in the menu.

I did some tests with ASRDATA, but I fear I don't understand exactly how it is intended to be used. Does ASRDATA be set in every map like AIRPORT? Is the ItemList a free name to be given, and can the same be used by multiple maps? Or is it rather like the map name? If you can just help me there with a basic example, this might help.

[Juha Holopainen]

Currently the one and only purpose of the AIRPORT line in a map is to provide the ability to filter the map away from the map list when it's not needed there - when you do not need to toggle its state from any other screen than the one for that airport. If that's not the case, the AIRPORT line must not be used.

Regarding ASRDATA, this is the TSW2 background map definition for EFHK:

MAP:TSW2_backgnd:2
FOLDER:EFHK
ACTIVE:1
ASRDATA:EFHK
SCTFILEDATA:REGIONS\EFHK(GND)
SCTFILEDATA:GEO\EFHK(GND)
ASRDATA:EFHK(OLD)
SCTFILEDATA:REGIONS\EFHK(GND)(2010)
SCTFILEDATA:GEO\EFHK(GND)(2010)

That's one map containing both the 2010 and the current layout. To display only the relevant layout, in the ASR file used for the current layout there's the following line:

PLUGIN:Ground Radar plugin:HideMapData:EFHK(OLD)

This instructs the plugin to skip drawing all map lines tagged "EFHK(OLD)". By default all maps start out "untagged", hence unaffected by any HideMapData or ShowMapData commands in the ASR file. If the ASR file contains no instructions on what to do with ASRDATA lines, the plugin disregards them (in this case it would draw both the 2010 and current layout on top of each other).

The ASRDATA line in the map provides a list of tags for all following lines until the next ASRDATA line or the end of the map. The tag names can be freely decided (but not to contain the comma or colon characters, as they would mess up reading the line) and used across as many maps as necessary.

For this specific map, the result would be the same if the ASR file contained "PLUGIN:Ground Radar plugin:ShowMapData:EFHK" instead as there are only the two options. If the map had three or more - for example an ASRDATA:EFHK(REALLYOLD) section as well, instructing the plugin to hide EFHK(OLD) or to show only EFHK would no longer be the same thing. Which command to use in the ASR file depends on how the maps have been set up. Sometimes it makes a difference, sometimes it doesn't matter. This can get fairly complicated to set up, in most cases setting a map SCREEN-SPECIFIC is the simplest way to limit its visibility unless it has ACTIVE lines or you want control over specific parts of a map as above.

In the above setup, as the code reads the map, it displays everything until it gets to ASRDATA:EFHK(OLD) and skips all following lines until another ASRDATA line comes up and then re-evaluates whether to draw or skip the next lines. In this case the map ends before any new ASRDATA lines are found so nothing further is drawn.

[Jonas Kuster (1158939)]

Thank you for this detailed explanation. I got it now.

 

Came accross another issue today where the warning "TWY TYPE" was displayed although the aircraft in question fullfil the restriction requirements.

The definition in the Maps file is the following:

COORDTYPE:TWYTYPE:NONE
RESTRICTION:MAXWINGSPAN:34.3
N046.54.40.519:E007.30.06.886
N046.54.45.413:E007.30.00.732
N046.54.47.645:E007.30.02.509
N046.54.48.326:E007.30.04.352
N046.54.41.802:E007.30.10.984

The aircraft in question was a B350, according the json file with the following data:

{"ICAO":"B350","Description":"L2T","WTC":"M","WTG":"G","RECAT-EU":"F","Wingspan":17.7,"Length":14.2,"Height":4.4,"MTOW":6800,"Use":"B","IATA":"BET","Manufacturer":"BEECH","Model":"300 (B300) Super King Air 350"},

So, the wingspan limitation in the polygon defined shouldn't be a problem. Still the warning "TWY TYPE" is displayed for B350. Any idea?

[Juha Holopainen]

I'd need a bit more information. First make sure the alert is raised due to that specific map (->deactivate all other maps, see if alert is still active). Then I'd need to see the entire definition for that map.

[Jonas Kuster (1158939)]

Whatever you need. I've specifically removed the map in question from the definition file, then no alarm was shown anymore.

This are the current files I use:

GRplugin_LSAS settings.zip

[Juha Holopainen]

You have "RESTRICTION:MAXWEIGHT:5700" specified earlier in that map. The B350 has a MTOW of 6800, so the alert is working as expected. If the weight restriction is not valid for that area, it needs to be adjusted using a new restriction line - for example "RESTRICTION:MAXWEIGHT:999999" effectively disables the weight restriction.

Quote

If a map contains more than one AREATYPE and/or TWYTYPE polygon, the previously set restrictions in the same map will be used for the polygons unless overridden by new restriction lines with the same Types.

[Jonas Kuster (1158939)]

My bad, sorry. Thanks for pointing this out. I'll rearrange the limitations then and put the taxiway with the weight restriction at last place. If I understand correctly, this will also have the desired effect.

Edited May 3, 2022 by Jonas Kuster

[Juha Holopainen]

Yes, either keep the current order but add a new maxweight 999999 restriction after the polygon restricted to 5700kg to cancel that restriction for the following polygons, or put the weight restricted polygon to the last place. The end result will be the same in both cases.