Currently AeroData downloading is very strict by cycle date. This should be made more flexible, best explained by example. Current cycle 201903 ends today, March 27, and the new 201904 cycle starts tomorrow March 28. New cycles always start on Thursday. At 07:00Z today, the new 201904 cycle is not yet available on EasyVFR. Experience with EVFR3 is that the new cycle only becomes available on the first valid date. From a practical viewpoint, this is too late for planning a trip starting that Thursday. The new cycle data is fixed and available about a week earlier and Jepp and ForeFlight make new cycle data available for download about a week beforehand which reduces the workload for a flight planned around the cycle cutover date.
I can think of some options, but can't estimate the effort so here are a couple possibilities that would improve the situation:
1) Make the new cycle data available for download as soon as possible, or at least by the weekend before cycle change, with EasyVFR using the currently valid data transparently, and automatically switch to using the new data on Thursday. This is similar to competitor products.
2) Make new cycle data available for download by the weekend before cycle change, and let the user decide when to download the new cycle up to the activation date. If not done by activation date, then proceed as currently done.
The difference between 1) and 2) is that for 1) EasyVFR needs to keep 2 cycles of data and switch at the cutover date. For 2), the user decides when to download the new data, which is then used by EasyVFR immediately avoiding the need to manage 2 cycles of data. Clearly, one doesn't want to fly with wrong data, but if planning a flight on a Thursday cutover with no intention to fly during the days before it, the updating activity could be taken care of in advance rather than adding a time-consuming activity on the day of flight.
This has been subject of discussion since day 1 of PocketFMS ( now almost 15 years ago! ). Its not an easy subject, more and more data is coming in last-minute just before a new AIRAC cycle starts. Other "manufacturers" put these changes in the second new cycle, sine the new cycle was already prepared by them earlier.
Our data maintenance team already needs all hands on deck to get every change in at each new cycle, and releasing a new cycle one or two weeks upfront would not do any good to data quality. I realize this is a typical problem of the way how we proces AeroData; a lot of human error checking is done that just requires time. Releasing a new cycle the day before the start of a new AIRAC cycle is in my opinion still the option with the least drawbacks.
