Jump to content

Navigraph 1409 update seems to have corrupted all the route definitions.


Recommended Posts

Hi,

Todays Navigraph 1409 update seems to have corrupted all the route definitions. Although they appear to complete the bulk validation checks on the entire list this is definitely not the case in practice. When one selects all 5100 (or so) routes and then executes the check function, they all seem to pass. Their background changes from yellow to white and they acquire a green tick mark.

At this point one can now close down the routes database window and then quit the application. However,

when restarting the application and re-opening the routes database window, all of the routes are once again unchecked and have orange text on a yellow background thus signalling an out of date error.

Selecting a number of routes at random I find that in the fourth field with the heading 'Database' is also Orange on a Yellow background. This field always contains the value NG1409. Right clicking on the same route and then choosing validate triggers no activity. Editing the route and then performing validation mostly yields the error message "®ROUTE152 FLIGHT NOT APPLICABLE TO IFPS". This is the most common error but not the only one. Other errors seen regularly are: "ROUTE165 THE DCT SEGMENT <snip>... IS TOO LONG ... <snip>" and "PROF204 <snip> ... FORBIDDEN ROUTE <snip> ..."

In each case, after validating the route and closing the editor window, the Route Database list now has the route with a green check mark and black text on a white background. IMHO given we now know that at least one error has occurred during the validation cycle, this latter state cannot possibly be the correct display setting.

Notwithstanding the above mentioned repeatable error, I suspect another underlying error exists that may well require the combined effort of personnel from the PFPX team and the Navigraph team to resolve.

Link to comment
Share on other sites

Hello Bruce,

I agree that once checked the database routes should remain cleared.

However don't confuse an AIRAC update check with Validation. The first simply checks for any breaks in your routes following changes in the airway structure whereas the latter requires individual route submission through CFMU and can require route and or altitude amendments.

The ROUTE152 FLIGHT NOT APPLICABLE TO IFPS indicates that validation is been tried out of the EuroControl zone.

As for the DCT segment too long you'd need to address the route IF you wish to validate them.

Certainly not a Navigraph issue.

Link to comment
Share on other sites

I have the same issue, Checked as normal and all got the 'green tick'. No if I go back into the route database all routes are 'outdated' there are no current routes.

Don't think that has a big knock on with planning though?

PS: Good one on you hours on VATSIM Stephen :excellenttext_s:

Link to comment
Share on other sites

Hi Stephen,

I guess I was as clear as mud in detailing my thoughts.

What I in fact have done is highlight 3 different observations in a single rather wishy washy descriptive story.

To clarify:

1. Characteristic behaviour of the check procedure normally performed at implementation of each AIRAC update has changed on data set AIRAC 1409.

2, I also stated that the characteristic behaviour of the Validation process had also changed, and that I was getting failures on every route I checked.

3. Based on the observation noted in 2, I asserted that I believed it an error to subsequently flag a route as checked if it fails validation.

Hopefully, it is now clear that these three items are related but not all are necessarily dependant consequences of failures of the others, In particular,

1 is independent of 2 and 3.

Now, as for point 2, I must admit that I am indeed in error. I have discovered that I was a little negligent with my testing of the validation. During a second round of these tests I paid more attention to the detail of the error messages delivered. With just a small amount of thought I realised I have been pretty dumb indeed. If I put an acceptable cruise altitude which would match the requirements of a high/low airway then validation is likely to be successful.

Since I have discovered this bit of stupidity I now realise that my assertion in 3 is also off target. It is evident to me now that the check flag only signals that all the way points can be found in the current database. They are not invalid just because a pilot does not satisfy the altitude constraints when planning a flight.

Now, after all of this self deprecation I can clearly confirm that I have nevertheless tracked the exact condition which causes the problem defined in 1.

I can also state that this problem will not be seen tomorrow.

The problem noted is induced by an erroneous logic test in the application. Code equivalent to the following semantics is in operation:

IF date(TODAY) <= CYCLE_START_DATE then

mark_route(Route_ID, OUT_OF_DATE)

ENDIF

The code should in fact be:

IF date(TODAY) < CYCLE_START_DATE then

mark_route(Route_ID, OUT_OF_DATE)

ENDIF

This can be proved by experimentation by anybody with the courage to do a little bit of experimentation.

In directory C:\Users\Public\Documents\PFPX Data\NavData (Normal case for Win 7 users) a file named navdata.nav exists. This is a text file where the first part is readable text, the balance has been encoded to presumably protect the data.

This is the clear text.

PFPX NAVDATA
NG1409
2014/08/21
2014/09/17
NAVIGRAPH
The meaning of these rows should be obvious to all readers.
The condition reported can be triggered by changing the first date (2014/08/21 in this case) to the current machine date.
Starting PFPX and following the process mentioned in the earlier postings will show the error condition as reported.

This is a trivial fix and clearly this fault will only affect those who are on the ball and update their AIRAC on the day of release.

Link to comment
Share on other sites

The change in 'check' behaviour appeared to come about in v1.15 where the activation time also moved to 0800Z on the AIRAC date ( however the actual time this occurs in PFPX is currently 0900Z)

Link to comment
Share on other sites

Hi,

i think it has been mentionned before but to avoid problems with the update date and time it is better to change your computer one day ahead, to apply the new AIRAC and after you come back to the actual date on your computer. if you update today (on the 22nd) it should be OK. We have to keep in mind that some of us would have a day difference with Europe.

Regards,

JP

Link to comment
Share on other sites

Hello JP,

In changing the PC date it created issues for me previously when returning to the current date where, the date stamps on files throw a spanner in the works.

The problem needs addressing as per Bruce's post.

Link to comment
Share on other sites

Hello Stephen,

For me it is the only answer and it works perfectly (so far).

Anyway,I suppose it is the same problem that we all have from one computer to another with behaviours so different from one setup to the other.

Regards,

JP

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy & Terms of Use