OpenAir extended format: use AY indication for colouring with AC UNCLASSIFIED

[llauner]

XCSoar version: 7.41

What should XCSoar do differently, what functionality should be added?

Currently the airspace colour is based on the Airspace Class: AC
Following the Extended OpenAir format parsing #1152 the colouring should be based on the airspace type (AY) when AC is set to UNCLASSIFIED.

For exemple, this Airspace is declared as

And is displayed using the "Unknown" color:

It should be displayed using the "Prohibited" color.

What are you trying to do, what is the use case for the suggestion?

Fully implement the OpenAir extended format so that the AY type indication is taken into account in the airspace colour

[ubx]

Is there an 'official' description of the OpenAir extended format ? Or do we have to agree with this implementation?

[llauner]

Is there an 'official' description of the OpenAir extended format ? Or do we have to agree with this implementation?

This is the "official" documentation:
http://www.winpilot.com/UsersGuide/UserAirspace.asp

[ubx]

Is there an 'official' description of the OpenAir extended format ? Or do we have to agree with this implementation?

This is the "official" documentation: http://www.winpilot.com/UsersGuide/UserAirspace.asp

I'm familiar with this document, but it doesn't provide much information about the extended format (Extensions suggested by the Naviter Company?). To implement the OpenAir extended format, we need to understand its specifications.

[kobedegeest]

The AY and extended format is introduced by openAIP i belief. Info can be found here https://www.openaip.net/docs.

And i agree that looking at the type can be useful (even if AC field is given). Example a "restriced airspace" all have class R in the AC field but can mean different things RMZ or TMZ, ... I also find marking for example "CTR" differently useful.

[llauner]

And i agree that looking at the type can be useful (even if AC field is given). Example a "restriced airspace" all have class R in the AC field but can mean different things RMZ or TMZ, ... I also find marking for example "CTR" differently useful.

@kobedegeest
Well, that's the point, they shouldn't have R in the AC field, as airspace class is A,B,C,D,E,F,G only and airspace type can be R
http://www.winpilot.com/UsersGuide/UserAirspace.asp
And it's confirmed here:

the AC tag is exclusively used to specify the airspace ICAO class

And also here in the openaip-openair-parser:

A required tag that specifies the airspace type, e.g. "TMA", "CTR" or "TMZ". Unlike in the original format, the AC tag must now only be used to specify the airspace ICAO class. If airspace has no type, i.e. is only ICAO class, the AY should be set to UNCLASSIFIED. The AY tag must be placed directly after the AC tag.

Hence the problem, when you have AC UNCLASSIFIED (because it's not A...G), and AY R, it shows up (=is represented in the UI) as unclassified when it should show up as Restricted.

[ubx]

The OpenAIP documantation says:

AY: Specifies the type of the airspace, e.g. "CTR". In the extended format, the AC tag is exclusively used to specify the airspace ICAO class. The AY tag is required and must be placed directly after the AC tag.

A search for AC tags following AY tags in some commonly used airspace files (xcsoar-data-content) shows:

• 2023_07_Airspace_Germany2023.txt has total AC with following AY 295, without AY 45
• SFVS-FSVV_CH-Airspace23_eDABS_APR2.txt has total AC with following AY 295, without AY 45
• france.txt has total AC with following AY 1288, without AY 0
• australia_class_all_23_11_30.txt has total AC with following AY 0, without AY 1877

The questions are:

• How to distinguish between the OpenAir and OpenAir extended format?
• If we implemented a fully OpenAir extended parser, what to do with records not following the above specs?

[llauner]

Well, I guess this as to be "flexible" at least in a first approach, and allow that some AC will not have AY, and in other cases there will be an AY after the AC...I know it's easy to say, but a pain to implement...

[lordfolken]

The way I understand this, is that the format can be chosen per record.

Both formats agree on the basic airspace classes. As long as its one of a-f, you check for the presence of AY.

[ubx]

Can we agree on the following:
if AC has an ICAO airspace class and is followed by AY, then we have an extended record, with AY representing the airspace class?

[lordfolken]

if AC has an ICAO airspace class and is followed by AY, then we have an extended record, with AY representing the airspace class?

if any of these values appear in AC:
extendedFormatClasses: ['A', 'B', 'C', 'D', 'E', 'F', 'G', 'UNCLASSIFIED'],

Then we check for presence of AY.

[lordfolken]

Basically this list needs to be extended, with the possible values.
OpenAIP lists them in the headers of their files

* This OpenAIR file does contain non-standard AY values. The following list shows all AY types that may be used within this file:
* UNCLASSIFIED, RESTRICTED, DANGER, PROHIBITED, CTR, TMZ, RMZ, TMA, TRA, TSA, FIR, UIR, ADIZ, ATZ, MATZ, AWY, MTR, ALERT, WARNING, PROTECTED, HTZ, GLIDING_SECTOR, TRP, TIZ, TIA, MTA, CTA, ACC_SECTOR, AERIAL_SPORTING_RECREATIONAL, OVERFLIGHT_RESTRICTION, MRT, TFR, VFR_SECTOR

here:

XCSoar/src/Airspace/AirspaceParser.cpp

Lines 77 to 80 in 010af8a

	static constexpr AirspaceClassStringCouple airspace_tnp_type_strings[] = {
	{ "C", CTR },
	{ "CTA", CTR },
	{ "CTR", CTR },

Then the parsing needs to be adapted to parse the logic of following up on AY.

XCSoar/src/Airspace/AirspaceParser.cpp

Lines 658 to 663 in 010af8a

	case 'Y':
	case 'y':
	if (input.SkipWhitespace())
	temp_area.astype = string_converter.Convert(input.c_str());
	break;

And extend the rendering defaults for the Airspaces:

XCSoar/src/Renderer/AirspaceRendererSettings.cpp

Lines 39 to 64 in 010af8a

	#ifdef HAVE_HATCHED_BRUSH
	classes[OTHER].brush = 2;
	classes[CLASSA].brush = 3;
	classes[CLASSB].brush = 3;
	classes[CLASSC].brush = 3;
	classes[CLASSD].brush = 3;
	classes[CTR].brush = 3;
	classes[WAVE].brush = 2;
	classes[AATASK].brush = 3;
	classes[CLASSE].brush = 3;
	classes[CLASSF].brush = 3;
	classes[RMZ].brush = 3;
	#endif
	classes[OTHER].SetColors(RGB8_CYAN);
	classes[DANGER].SetColors(RGB8_MAGENTA.Darken());
	classes[MATZ].SetColors(RGB8_MAGENTA.Darken());
	classes[CLASSC].SetColors(RGB8_MAGENTA.Darken());
	classes[CLASSD].SetColors(RGB8_BLUE);
	classes[CTR].SetColors(RGB8_MAGENTA.Darken());
	classes[WAVE].SetColors(RGB8_YELLOW.Darken());
	classes[AATASK].SetColors(HasColors() ? RGB8_YELLOW : RGB8_MAGENTA);
	classes[CLASSE].SetColors(RGB8_GREEN.Darken());
	classes[CLASSF].SetColors(RGB8_GREEN.Darken());
	classes[RMZ].SetColors(RGB8_MAGENTA.Darken());
	}

[ubx]

UNCLASSIFIED
Why? It is nowhere specified, just an invention of the parser.

[llauner]

UNCLASSIFIED
Why? It is nowhere specified, just an invention of the parser.

Well, it looks like UNCLASSIFIED is widely used now.
Which makes sense when the ICAO class for a given airspace is not A,B,C,D,E,F,G

As indicated above, it's also listed:

OpenAIP lists them in the headers of their files

[reskume]

This does not help directly with solving this issue but I wanted to shed some insights on this "extended format" that we use with openAIP. Actually, this was proposed by Naviter, as already mentioned in one comment above. We just picked up the idea and use it as another export/import format for openAIP and extended it with one tag, the "AI" tag. Reason behind this was that we didn't want to loose metadata that is already present in the system when exporting to openAIR, e.g. using only AC instead of AC+AY. Also, the system may also includes multiple frequencies for each airspace and we are now able to at least dump the "primary" one including the ground station callsign with using AF+AG tags.
The AF/AG and AC/AY combination can be found in various country airspace files (e.g. Switzerland, Austria (although Austrocontrol leaves the AY blank if not defined) ...). The only thing that openaAIP "added", besides extending the AY types with the internal types we use, was the AI tag so that we are able to track changes to different versions of a country file if necessary. Personally I consider the AI tag to be a very useful addition because it helps a lot with doing automated diffs and imports in our system. Unfortunately, it's not really used anywhere although we provide the OpenAIR Fixer Tool that can add this line to every openAIR file. I guess it's because the format is specifically consumer oriented.

[ubx]

You can try it out