Different sector?

[GHD]

Can someone explain this message please?

 

[gadgets]

It's telling you that the lat/lon specified in the traffic or text file for the noted airport(s) is sufficiently different from the lat/lon specified for the same airport(s) in AirportList.dat (i.e, stock or add-on airport position) that two different sectors are involved. As noted, the position from the traffic/text file is used.

This could be a result of the same ICOA code having been used for two different airports or, perhaps, an error in positioning an add-on airport. Or, it may simply be the result of a minor positioning difference of an airport located very close to a sector boundary. In the last instance, the effect would be that a short-haul flight in one case might become a long-haul flight in the other or vice versa, with the consequent difference in performance. (Short-haul flights, i.e., those that originate in a sector adjacent to the destination airport, are governed by the MSFS flight-engine end-to-end, while long-haul flights are governed by the sector transition times in the traffic file until the next-to-last sector is reached.

Hope this explanation doesn't create more confusion than the message.

Don

 

[GHD]

It's telling you that the lat/lon specified in the traffic or text file for the noted airport(s) is sufficiently different from the lat/lon specified for the same airport(s) in AirportList.dat (i.e, stock or add-on airport position)

Hmm, the difference between the airport reference points of the stock and my airfield is 148.715841 metres. In fact, I think it is the difference between the FS9 position and the FSX position.

I don't think this is "sufficiently different".

 

[bobbyjack]

So Don, we are all used to adding airport information manually because that's how TTools worked. I suppose most people using AIFP add new ,or airports with a different location, manually also. And I assume then that the airport dat. list is updated that way. I got out of the habbit of entring airports manually because I used to use Aisort to make FPs. With Aisort, any time you added an airport, or changed it in any way(even added parking) you had to do an "Airport Dump" from the "Traffic Tool Box" in FSX. This is why I always use the "Collect Airports" function in AIFP. And never use your default airport list. That way AIFP uses what I have in the sim for airport information. The new airoprt dat. reflects what is really in the sim.

More an observation than an answer or a question.

Bob

 

[gadgets]

Hmm, the difference between the airport reference points of the stock and my airfield is 148.715841 metres. In fact, I think it is the difference between the FS9 position and the FSX position.

I don't think this is "sufficiently different".

George, I agree that this seems trivial. (One or the other must be very close to a sector boundary.) However, to MSFS, it's significant since it places the airport in a different sector which can cause operational differences as I noted last night. As you can see, I like to err on the side of too much information.

How do you suggest I handle positional discrepancies?

This is why I always use the "Collect Airports" function in AIFP. And never use your default airport list. That way AIFP uses what I have in the sim for airport information. The new airport dat. reflects what is really in the sim.

Bob, the default airport list is the result of "collect airports" run on FS9 and FSX stock airports. Where there's a discrepancy other than ICAO code, I keep the FSX info (which could explain George's experience). Whether you run "collect airports" after adding a new/editing an existing airport or enter the data using the Airport Editor, the result saved in AirportList.dat is the same (so long as you enter the same data).

I can easily suppress this message. If I do, which position do I use? If from the file, I'm creating a sector crossing table taking the AI to a sector different from where MSFS "thinks" the airport is located - which may or may not have a significant influence on how the AI will be routed. If from AirportList.dat, the sector-transition table will take the AI to a different location (sector) than specified in the flight plan.

I could apply a distance test, but the long-haul/short-haul issue I highlighted last night remains.

I'm not sure what the sim does if an AI arrives at the last sector in the sctor transition table and finds that the destination airport isn't there. I suspect it doesn't even check, i.e., that it transitions to "flight" mode anyway and goes to wherever the sim's data says the airport is. If that is the case, then a compromise would be that I only issue the "different sector" message when the two sets of information place the airports in non-adjacent sectors. This could still give rise to a previously-short-haul flight being treated as long-haul but that's unlikely to be noticed unless someone is carefully monitoring Traffic Toolbox Explorer or some other traffic analysis program.

George, are you happy with non-adjacent sector notification? That means the difference must be measured in miles (how many depends on latitude) before the warning would be issued.

Don

 

[GHD]

George, are you happy with non-adjacent sector notification? That means the difference must be measured in miles (how many depends on latitude) before the warning would be issued.

I think it is meaningless since the intended airport reference point is in the traffic bgl (or if not, it can be referenced from the ICAO).

 

[gadgets]

the intended airport reference point is in the traffic bgl

I agree. And that's what AIFP uses.

(or if not, it can be referenced from the ICAO).

Well, not quite. It's not that AIFP doesn't have an airport position; it's that it has two (which is what the message is telling you). The position for the ICAO code specified in the stock or add-on airport data (and saved in AirportList.dat) is different from that specified in the traffic, or aircraft text, file - sufficiently different that the airports lie in different AI sectors.

AIFP allows you to suppress warning messages. While this message is not currently supressable, I can easily make it so. That coupled with the "non-adjacent sector" proposal I made below should fully address the problem.

Don

 

[bobbyjack]

Bob, the default airport list is the result of "collect airports" run on FS9 and FSX stock airports. Where there's a discrepancy other than ICAO code, I keep the FSX info (which could explain George's experience). Whether you run "collect airports" after adding a new/editing an existing airport or enter the data using the Airport Editor, the result saved in AirportList.dat is the same (so long as you enter the same data).

I undrstand. I use the collect airports function because if I can do the same thing with a few mouse clicks as opposed to typing, well, I'm very slow and prone to mistakes.

Bob

 

[gadgets]

I've taken another look at the matter. The issue is that the airport in the traffic/flight plan file is in a different location from that recorded in AIFP. Minor discrepancies shouldn't be made the concern of users - whether or not a different sector is involved. But, in the case of a large difference, the user probably wants to know.

So, I've made two changes:

• the message is now classified as a warning and is suppressed by the Options / Suppress Warnings menu item, and
• the message is now only issued if the difference is >10 nm.

Since this change has no bearing on AI operation, I'll wait for a little while to see if there are any more bug-fixes required before maiing it available.

Don

 

[GHD]

The problem is it comes up twice. Firstly when on selects the flightplans and again when compiling, it'a a right mess, especially when the dialogs are on top of each other:

 

[gadgets]

Let me see what I can do about getting rid of the second set of messages. It won't be a trivial change, however, since it requires some method of tracking what came in with the file and what is the result of editing.

You can get rid of all those "may not be in FSX" warnings by accepting AIFP's offer to add the missing airports to AirportList.dat.

Don

 

[GHD]

You can get rid of all those "may not be in FSX" warnings by accepting AIFP's offer to add the missing airports to AirportList.dat.

But I don't use AirportList.dat.

 

[gadgets]

But I don't use AirportList.dat.

As explained in Section 3 of the user manual, the data used in the traffic file compiled by AIFP for any airport AIFP isn't "complaining" about comes from AirportList.dat.

The only time AIFP sources airport data from the loaded traffic/flight plan files is:

• when an airport is not in AirportList.dat, or
• when the positional data from the traffic/FP files disagrees with that in airportList.dat by more than 10 nm (after the next update) or, currently, falls in another AI sector)

If neither situation is true, AIFP overwrites whatever data came from the traffic.FP files with the data from AirportList.dat.

Like I said, the way to suppress most of those warnings is to allow AIFP to update AirportList.dat.

Dn

 

[gadgets]

Let me see what I can do about getting rid of the second set of messages.

Sorry, doing so requires major redesign.

As noted earlier, you can suppress these messages entirely by selecting Suppress Warnings in the Options menu or by adding the airports to AirportList.dat.

Don