Closed reskume closed 1 year ago
llauner
commented
1 year ago @reskume I can maybe have a look at that and see if a certain part of it can be added automatically like I did for the radio frequency. Do you have a link to the documentation for the AY tag ?
reskume
commented
1 year ago @llauner, yes sure! Link to "official" docs here: http://winpilot.com/usersguide/userairspace.asp . You can find the proposed additional fields in the section "Additional OpenAir fields (differences from original)" in the bottom part of the page.
In general, as far as I understand, when using the additional AY field, the AC field is used to only have ICAO class values (including SUA). AY will carry the actual type of the airspace, e.g. "RMZ", "TMZ" or "CTR".
llauner
commented
1 year ago @reskume Ok so if I understand correctly: AC should only contain: A,B,C,D,E,F,G + SUA What is the list of SUA ?
AY should contain any other acronym already used for AC that is not listed above In the case where current AC information has to be moved to AY, should the AC tag disappear ?
Regards
reskume
commented
1 year ago I guess "SUA" (Special Use Airspace) doesn't appear in the original OpenAIR format. Within the OpenAIP GeoJSON format, we are using SUA and UNCLASSIFIED as additional ICAO classes but both classes are actually very similar. I suppose we could also drop "SUA" in favor of "UNCLASSIFIED" because both are used if there is no dedicated ICAO class for "special" airspaces like:
In the case where current AC information has to be moved to AY, should the AC tag disappear ?
I would always preserve the AC tag as it is the standard one. If an AC value like "CTR" can be moved to the AY tag, the assigned ICAO class for this airspace has to be set on the AC tag. And that's where a lot of work has to be done to get to the point where the file reflects the reality as described in the AIP. That's because this particular information "which ICAO class is assigned to this airspace with type 'CTR'" is simply missing in the OpenAIR files . As interim solution, it seems reasonable to use 'UNCLASSIFIED' as AC value when moving AC value to AY. Those 'UNCLASSIFIED' values can be updated over time to reflect the actual definition in the AIP. In the above scenario, this would be like:
Moving AC value to AY field
Move AC value to the AY field whenever actual types like "CTR" or "TMA" are used. Use "UNCLASSIFIED" as AC value as interim solution.
Before:
** CTR AGEN LA GARENNE (14 APR 2005) **
AC CTR
AN CTR Agen 121.3
AH 2000FT MSL
AL GND
AF 121.300
DP ...After:
** CTR AGEN LA GARENNE (14 APR 2005) **
AC UNCLASSIFIED * this field can be updated over time
AY CTR
AN CTR Agen 121.3
AH 2000FT MSL
AL GND
AF 121.300
DP ...AC value is already ICAO class
In this case, I would simply leave as is.
Before:
** CTR VILLACOUBLAY (13/11/2014) **
AC D
AN CTR Villacoublay 128,95
AH 2000FT MSL
AL GND
DP ...After:
** CTR VILLACOUBLAY (13/11/2014) **
AC D
AN CTR Villacoublay 128,95
AH 2000FT MSL
AL GND
DP ...Although this change will add a big benefit, it will break a lot of clients if they don't implement parsing the additional AY tag. If probably a good idea to have a v2 version of the file that has this new additional AY tag. The actual v1 version should also be kept as-is for backwards compatibility. Any thoughts on this?
llauner
commented
1 year ago @reskume Thanks for the clarification You're right, it may be a breaking change. I don't want to maintain 2 versions of the file. I'll test how XCSoar, SeeYou, SeeYou navigator reacts to the change. I can even already write the code to implement the change, and then depending on how "most famous" navigation software react I'll get in touch with the editors and see what we do from there...
reskume
commented
1 year ago Yeah, I can understand that. Maintaining one file is already enough work. It seems that the best way of moving forward is to simply ask the guys over at XCSoar, SeeYou et.al. if they would welcome this change and if they do, just switch to the AC/AY usage.
Personally I hope that this will be the case as it would make so much sense and adds real benefit. Seen from an OpenAIP standpoint it would also make sense to add another "ID" field to each airspace definition. This way "diffs" and exports/imports would be easier too. But that's a new ticket :)
reskume
commented
1 year ago I'm converting the file right now. From looking at the file, it may be beneficial to remove the frequency value from the name. This is redundant with the AF/AG tag anyway. Should I strip the frequencies from the AN value and create an AF/AG field if applicable?
llauner
commented
1 year ago Keep the frequency in the name as I don’t think the AF tag is taken into account for display in XCSoar, SeeYou … Thanks.
On Thu 27 Apr 2023 at 14:43, Stephan Besser @.***> wrote:
I'm converting the file right now. From looking at the file, it may be beneficial to remove the frequency value from the name. This is redundant with the AF/AG tag anyway. Should I strip the frequencies from the AN value and create an AF/AG field if applicable?
— Reply to this email directly, view it on GitHub https://github.com/planeur-net/airspace/issues/16#issuecomment-1525631585, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH2QQDILQWVZQ3TQRJTFPETXDJSYNANCNFSM6AAAAAAQWPYY4I . You are receiving this because you were mentioned.Message ID: @.***>
--
Ludovic Launer @.***
reskume
commented
1 year ago I converted file. Please re-validate and ensure correctness. Assumptions made:
Parachute zones are mapped as AC UNCLASSIFIED and AY AERIAL_SPORTING_RECREATIONAL:
** 208 Para FRETOY LE CHATEAU**
AC UNCLASSIFIED
AY AERIAL_SPORTING_RECREATIONAL
AN Para Fretois le Chateau
AH FL135
AL GND
V X=49:40:00 N 002:58:00 E
DC 1CTRs are assumed to be ICAO class D unless otherwise specified:
** CTR AGEN LA GARENNE (14 APR 2005) **
AC D
AY CTR
AN CTR Agen 121.3
AH 2000FT MSL
AL GND
AF 121.300
DP 44:16:44 N 000:28:29 E
DP 44:13:48 N 000:45:33 E
V X=44:10:29 N 000:35:26 E
DB 44:13:48 N 000:45:33 E,44:02:56 N 000:39:07 E
DP 44:02:56 N 000:39:07 E
DP 44:05:39 N 000:31:05 E
DP 44:08:31 N 000:24:40 E
V X=44:10:29 N 000:35:26 E
DB 44:08:31 N 000:24:40 E,44:16:44 N 000:28:29 E
DP 44:16:44 N 000:28:29 ELTAs have two different mappings depending on the used ICAO class:
If AC E, the type is set to GLIDING_SECOR:
** LTA PYRENEES + AWY A29, B31 (14 APR 2005) **
** LTA Pyrennees Secteur Ouest **
AC E
AY GLIDING_SECTOR
AN LTA Pyrenees1 FL195 Max
AH FL195
AL FL115
DP 43:04:34 N 001:20:32 W
DP 43:17:33 N 001:22:41 W
DP 43:22:05 N 001:23:06 W
...If any other class is used, the type is set to CTA:
** (16/02/2016) LTA FRANCE partie 3 Alpes 2 Vercors
AC D
AY CTA
AN LTA FRANCE partie 3 Alpes 2 Vercors
AH FL 195
AL FL 125
DP 45:00:00 N 005:19:42 E
DP 45:00:00 N 005:31:16 E
DP 45:02:49 N 005:37:54 E
...Please find the file attached.
llauner
commented
1 year ago Thanks ! I'll look into it
Regards Ludovic
Ludovic Launer @.***
On Thu, 27 Apr 2023 at 15:32, Stephan Besser @.***> wrote:
I converted file. Please re-validate and ensure correctness. Assumptions made: Parachute zones
Parachute zones are mapped as AC UNCLASSIFIED and AY AERIAL_SPORTING_RECREATIONAL:
208 Para FRETOY LE CHATEAU AC UNCLASSIFIED AY AERIAL_SPORTING_RECREATIONAL AN Para Fretois le Chateau AH FL135 AL GND V X=49:40:00 N 002:58:00 E DC 1
CTR
CTRs are assumed to be ICAO class D unless otherwise specified:
CTR AGEN LA GARENNE (14 APR 2005) AC D AY CTR AN CTR Agen 121.3 AH 2000FT MSL AL GND AF 121.300 DP 44:16:44 N 000:28:29 E DP 44:13:48 N 000:45:33 E V X=44:10:29 N 000:35:26 E DB 44:13:48 N 000:45:33 E,44:02:56 N 000:39:07 E DP 44:02:56 N 000:39:07 E DP 44:05:39 N 000:31:05 E DP 44:08:31 N 000:24:40 E V X=44:10:29 N 000:35:26 E DB 44:08:31 N 000:24:40 E,44:16:44 N 000:28:29 E DP 44:16:44 N 000:28:29 E
LTA
LTAs have two different mappings depending on the used ICAO class:
If AC E, the type is set to GLIDING_SECOR:
LTA PYRENEES + AWY A29, B31 (14 APR 2005) LTA Pyrennees Secteur Ouest AC E AY GLIDING_SECTOR AN LTA Pyrenees1 FL195 Max AH FL195 AL FL115 DP 43:04:34 N 001:20:32 W DP 43:17:33 N 001:22:41 W DP 43:22:05 N 001:23:06 W ...
If any other class is used, the type is set to CTA:
** (16/02/2016) LTA FRANCE partie 3 Alpes 2 Vercors AC D AY CTA AN LTA FRANCE partie 3 Alpes 2 Vercors AH FL 195 AL FL 125 DP 45:00:00 N 005:19:42 E DP 45:00:00 N 005:31:16 E DP 45:02:49 N 005:37:54 E ...
Please find the file attached.
france_convert.txt https://github.com/planeur-net/airspace/files/11344071/france_convert.txt
— Reply to this email directly, view it on GitHub https://github.com/planeur-net/airspace/issues/16#issuecomment-1525703942, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH2QQDKHXS2UXPEJPPHRJ5DXDJYQBANCNFSM6AAAAAAQWPYY4I . You are receiving this because you were mentioned.Message ID: @.***>
llauner
commented
1 year ago New format now in use
llauner
commented
1 year ago Hi We are now using the extended format for the file..
Thanks Ludovic
Ludovic Launer @.***
On Thu, 27 Apr 2023 at 16:10, Ludovic Launer @.***> wrote:
Thanks ! I'll look into it
Regards Ludovic
Ludovic Launer @.***
On Thu, 27 Apr 2023 at 15:32, Stephan Besser @.***> wrote:
I converted file. Please re-validate and ensure correctness. Assumptions made: Parachute zones
Parachute zones are mapped as AC UNCLASSIFIED and AY AERIAL_SPORTING_RECREATIONAL:
208 Para FRETOY LE CHATEAU AC UNCLASSIFIED AY AERIAL_SPORTING_RECREATIONAL AN Para Fretois le Chateau AH FL135 AL GND V X=49:40:00 N 002:58:00 E DC 1
CTR
CTRs are assumed to be ICAO class D unless otherwise specified:
CTR AGEN LA GARENNE (14 APR 2005) AC D AY CTR AN CTR Agen 121.3 AH 2000FT MSL AL GND AF 121.300 DP 44:16:44 N 000:28:29 E DP 44:13:48 N 000:45:33 E V X=44:10:29 N 000:35:26 E DB 44:13:48 N 000:45:33 E,44:02:56 N 000:39:07 E DP 44:02:56 N 000:39:07 E DP 44:05:39 N 000:31:05 E DP 44:08:31 N 000:24:40 E V X=44:10:29 N 000:35:26 E DB 44:08:31 N 000:24:40 E,44:16:44 N 000:28:29 E DP 44:16:44 N 000:28:29 E
LTA
LTAs have two different mappings depending on the used ICAO class:
If AC E, the type is set to GLIDING_SECOR:
LTA PYRENEES + AWY A29, B31 (14 APR 2005) LTA Pyrennees Secteur Ouest AC E AY GLIDING_SECTOR AN LTA Pyrenees1 FL195 Max AH FL195 AL FL115 DP 43:04:34 N 001:20:32 W DP 43:17:33 N 001:22:41 W DP 43:22:05 N 001:23:06 W ...
If any other class is used, the type is set to CTA:
** (16/02/2016) LTA FRANCE partie 3 Alpes 2 Vercors AC D AY CTA AN LTA FRANCE partie 3 Alpes 2 Vercors AH FL 195 AL FL 125 DP 45:00:00 N 005:19:42 E DP 45:00:00 N 005:31:16 E DP 45:02:49 N 005:37:54 E ...
Please find the file attached.
france_convert.txt https://github.com/planeur-net/airspace/files/11344071/france_convert.txt
— Reply to this email directly, view it on GitHub https://github.com/planeur-net/airspace/issues/16#issuecomment-1525703942, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH2QQDKHXS2UXPEJPPHRJ5DXDJYQBANCNFSM6AAAAAAQWPYY4I . You are receiving this because you were mentioned.Message ID: @.***>
lordfolken
commented
1 year ago Xcsoar supports AF since a while. AY support was released two days ago in 7.29.
As proposed in the "official" OpenAIR docs by Naviter, each airspace definition block may have a AY tag that contains the type of the airspace. Currently, airspaces are only categorized by the AC tag which mixes up the ICAO class with actual types like RMZ, TMZ, CTR etc pp.
It's a lot of work to implement this since all information has to be re-visited and class/type set accordingly. On the other hand, this would be are really huge benefit as no information about the airspace is lost. Especially for system like OpenAIP where type and class can be defined, exports into openAIR format simply loose a lot of contextual information at this point. Re-importing such an openAIR file that does not have the AY field will inevitable lead to imports that lack information.
This could be done in small steps and not as a 100% complete change - even small continuous changes that add this information would be very very beneficial. I can adjust the OpenAIP OpenAIR-Parser to accept this token and also validate against a set of allowed types.
Additionally, moving forward in this direction may encourage other openair-airspace contributors to add this token. I can encourage every contributor that sends airspace files to openaip to start adding this type of information.