llauner
commented
2 months ago Hi Sorry for the late reply, I think I've lost notifications, I need to look into that... It's not intentional, it grew with time :) Different frequency than the one define in AF is not intentional I'm not 100% about the temporary airspace: some might be permanent, and some might be temporary and need to be removed...
You're more than welcome to address all of the listed issues. Maybe in a stepwise approach where the first PR would be resolving the AN and frequency issues, and then the rest ?
reskume
We are currently manually adjusting the french airspace file before it is imported into OpenAIP. One reason is that some AY values have diverged, e.g. AVR and another one is that the names that are used on the AN definition don't seem to follow a certain format, especially for restricted airspaces. One can find all different types of syntaxes like
Is this intentional or did this just grew with time? At least from my perspective, it would be beneficial to have a default syntax for all those name. We will rewrite that into "AN LF-R123A NAME OF AIRSPACE" whenever possible. In addition to that, we will also remove all frequency strings from the name and make sure that there is a dedicated AF field and if possible to "guess" from the name, also an AG field. We also found that there are tons for airspace names that have a different frequency defined than the one used in the AF tag. Is this also intentional? On top of that, there are several airspaces that have names with activation periods which may have been added to add more context - but those airspaces, e.g."AN RMZ Le Havre Du 30/03/2017 au 08/11/2017" actually should be removed from the file if those activation periods are correct... I suppose this RMZ is now permanent and only the name did not receive an update?
Overall, there is a lot of metadata in the AN name which will be outdated and lead to misleading information when it is not kept in sync with other values, eg. frequency field AF. Also, the phone numbers pose a big maintenance burden and given the fact that the frequencies already have diverged a lot, wouldn't it be better to remove them from the file?
To not do that over and over again, I can create a PR that will at least resolve the AN issue and the frequency issue. Let me know if I should address other issues too.