answered KGOO formerly O17 overlaid create elevation error

[Bsuslin]

It appears the Orbx NorCal scenery designates Grass Valley -Nevada County by its former FAA designation as “O17” instead of the current ICAO of KGOO.  Navigraph data and FSAD use the ICAO nomenclature and consequence appears to stack the two airports creating an elevation error.

[Nick Cooper]

Hello,

welcome to the forums.

This has nothing to do with Orbx.

It is an unintended consequence of updating the navigation data.

 

The P3D airport database has not been updated since it was first published as FSX

and in fact even then was way out of date.

A good example is EGTH, Hatfield Aerodrome in England, which had been closed and redeveloped

in the late 1990's and yet is still now to be found in P3D v4.5.

EGTH has been reassigned to Old Warden.

The Orbx Old Warden changes the menu to Old Warden form Hatfield Aerodrome which is possible

because the ICAO code remains the same and the name can be changed.

 

Your problem is slightly different, in that the airfield is still there but its ICAO has been changed.

It is not possible to remove or change  ICAO codes in P3D unless the core files are modified, which some

of these navigation data programs actually do.

 

The navigation data products then introduce a problem when they add data for the same airport but under a new ICAO code.

Normally, P3D would see both and any exclude would prevent more than one version from showing.

Because it does not recognise the new ICAO code or the files relating to it, nothing is excluded and two versions

are seen in the same place.

 

A very extreme case was reported here some time ago, where a customer had done the same as you and then visited

an airport in South America which was also new in the real world.

He came to these forums because he had some Orbx products, complaining that he had gone there, only to find no airport at

all and what were we going to do about it.

The answer was that his navigation data had cleverly added the new airport data but as it was not in the P3D database and

no one had created an addon airport model, there was indeed nothing there except the navigation data.

 

[medx421]

There are a growing number of these as the years fall off the calendar.  GOO is in my backyard, so I know about that one.  Boulder City 61B vs. BVU is one that is completely wrecked on my machine now.  Well until Orbx releases theirs ;-)  I think there's one west of JAC too.

[medx421]

18 hours ago, Nick Cooper said:

Hello,

welcome to the forums.

This has nothing to do with Orbx.

It is an unintended consequence of updating the navigation data.

 

The P3D airport database has not been updated since it was first published as FSX

and in fact even then was way out of date.

A good example is EGTH, Hatfield Aerodrome in England, which had been closed and redeveloped

in the late 1990's and yet is still now to be found in P3D v4.5.

EGTH has been reassigned to Old Warden.

The Orbx Old Warden changes the menu to Old Warden form Hatfield Aerodrome which is possible

because the ICAO code remains the same and the name can be changed.

 

Your problem is slightly different, in that the airfield is still there but its ICAO has been changed.

It is not possible to remove or change  ICAO codes in P3D unless the core files are modified, which some

of these navigation data programs actually do.

 

The navigation data products then introduce a problem when they add data for the same airport but under a new ICAO code.

Normally, P3D would see both and any exclude would prevent more than one version from showing.

Because it does not recognise the new ICAO code or the files relating to it, nothing is excluded and two versions

are seen in the same place.

 

A very extreme case was reported here some time ago, where a customer had done the same as you and then visited

an airport in South America which was also new in the real world.

He came to these forums because he had some Orbx products, complaining that he had gone there, only to find no airport at

all and what were we going to do about it.

The answer was that his navigation data had cleverly added the new airport data but as it was not in the P3D database and

no one had created an addon airport model, there was indeed nothing there except the navigation data.

 

 

As GOO, BVU, and the airport west of JAC are covered by Orbx regions, and Orbx has done updates to those fields based on being included in a region, couldn't those ICAO's be updated by Orbx?

[Nick Cooper]

Hello,

please read my post again.

[medx421]

8 hours ago, Nick Cooper said:

Hello,

please read my post again.

 

I have, and I understand what it says.  I guess the better question is; for the airports that are upgraded in the regions, are they completely redone, or do they omly provide enhancements over the default?  If they are redone, then are there exclusions built in?  Take Boulder City.  The new, and navdata updated ICAO is BVU, however examining the SCA scenery folder, there are several scenery files for the old ICAO; 61B.

[Nick Cooper]

Hello,

they are if you like, makeovers.

 

Once again, it is not possible to change an airport's ICAO code in FSX or P3D

without changing default airport files.

As I explained above, changing default airport files can have unintended consequences

and so Orbx do not do it.

 

For example, if you create KGOO, it cannot exclude O17 because it can only

create an exclude for KGOO.

An exclude for KGOO will not exclude O17.

Similarly, navigation data for KGOO cannot override O17 because it

cannot see the O17 data, so you see both.

 

It is all in my original reply.

[medx421]

Okay.  You win.  Thanks for elaborating beyond your initial reply.

[Bsuslin]

...”It is not possible to remove or change  ICAO codes in P3D unless the core files are modified, which some

of these navigation data programs actually do.

 

The navigation data products then introduce a problem when they add data for the same airport but under a new ICAO code.”

 

 

But then the end user who has purchased a  nav data product that updates the core files is disadvantaged because ORBX uses 20yr old legacy data which compromises the users intent to modernize and increase the utility of the sim.  I don’t buy the notion that the problem is caused by nav data update.  Rather it appears that the scenery vendor should share some responsibility to have their product work with fundamental updates to nav data.  At least they could include a tool component that enables the end user to edit the ICAO file to comport with their installed nav data.  

[Bsuslin]

I emphasize I’m not referring to the foundation core nav data.  I understand your explanation why ORBX doesn’t include ICAO designation changes and exemplified by your explanation and my initial query.  

 

Now l am curious whether you can address the issue with replacement  navdata  products and how ORBX scenery functions in that environment?

[Nick Cooper]

It is my turn to give up.

[Bsuslin]

“Hairballs in stomach, veterinary!”  Re:  All Creatures Great and Small

 

 

[Nick Cooper]

The topic contains all the answers to your questions sometimes more than once.

Asking the question again will not change the nature of the simulator nor will it

elicit a different answer.

[Bsuslin]

It seems to me you gave a stock answer to my initial question and then a posed variation by eluding to a nav data replacement.  That’s what I referenced and don’t see an answer.  If you’re not authorized to speak to my specific question or can’t offer a remedy you should say so forthrightly.  Can the condescension.

[Nick Cooper]

You have a very full answer at post 2 which is only "stock" because it is the only accurate answer.

Here are the main points once again:

.

1. it is not possible to change the ICAO code of an airport in FSX or P3D because these are "hard coded" into the default airport files.

2. It is possible to rewrite the default airport files, which is what some of the navigation data programs do.

This however can introduce problems of its own, as illustrated in the very full answer at post 2.

 

 I now ask if you do in fact have any software that changes the airport ICAO code.

I had thought that FSAD which I take it is FSAERODATA:FIRST GLOBAL AERONAUTICAL DATABASE FOR PREPAR3D/FSX was in fact in use.

 

If so, Orbx addon airports function in the same way as do default airports.

 

 

[Bsuslin]

Yes, I have fs aerodata installed.

[medx421]

I use the freeware Aero.Sors product.  Not as comprehensive as FS Aerodata, but does update the ICAO's amongst other things.

[medx421]

On 12/11/2019 at 11:59 AM, Nick Cooper said:

You have a very full answer at post 2 which is only "stock" because it is the only accurate answer.

Here are the main points once again:

.

1. it is not possible to change the ICAO code of an airport in FSX or P3D because these are "hard coded" into the default airport files.

2. It is possible to rewrite the default airport files, which is what some of the navigation data programs do.

This however can introduce problems of its own, as illustrated in the very full answer at post 2.

 

 I now ask if you do in fact have any software that changes the airport ICAO code.

I had thought that FSAD which I take it is FSAERODATA:FIRST GLOBAL AERONAUTICAL DATABASE FOR PREPAR3D/FSX was in fact in use.

 

If so, Orbx addon airports function in the same way as do default airports.

 

 

 

O17/KGOO Before:

 

 

KGOO with all references to O17 removed:

 

 

No trace of O17:

 

This was the end product of good collaboration with the original poster of this topic.  These are issues that ORBX can fix and it takes less than 5 minutes to do so.  Now the topic can be marked Answered/Resolved.

[Nick Cooper]

Well done.

I wrote in my first explanation

 

Quote

It is not possible to remove or change  ICAO codes in P3D unless the core files are modified

 

I have to assume that you modified Scenery\0102\scenery\APX15180.bgl

with the very useful Airport Inspector and Editor.

This is a core file and Orbx do not do modify the core airport files.

If you did this some other way, please share it for the benefit of your fellow customers.

[medx421]

26 minutes ago, Nick Cooper said:

Well done.

I wrote in my first explanation

 

 

I have to assume that you modified Scenery\0102\scenery\APX15180.bgl

with the very useful Airport Inspector and Editor.

This is a core file and Orbx do not do modify the core airport files.

If you did this some other way, please share it for the benefit of your fellow customers.

 

The only thing that touched Scenery\0102\scenery\APX15180.bgl was the navdata programs that updated the airport ICAO which caused this mismatch between the non-updated Orbx files in the first place.

 

The solution lays within updating the Orbx files to reflect the current ICAO.  Like you said a different ICAO cannot exclude or overlay another.  Since the core scenery ICAO's were updated by the navdata programs, the only possibility became to update the Orbx ones in conflict.

 

I will consider writing a tutorial on how to do this for the benefit of the community, but again, it does involve modifying, or rather making offending Orbx files current.  In the meantime, I am happy to assist other members, and company developers.

 

On a side note, I realize words on paper or screen do not have the benefit of carrying tone.  That said, I felt, like the original poster a sense of feeling dismissed.  It's frustrating for the end user to have to make these changes.  I have had a few support issues, as much as I try to resolve things on my own, and I often feel like my issues are minimized and dismissed in these forums.  The answers are out there, and they are out there by much smarter people than I, such as the developers here.  I want to be a help to the community, and will be, but understand, these fixes aren't in everyone's capability, and at some point, Orbx will need to take the reigns and be a leader in progressing that which is outdated.

 

[Nick Cooper]

Hello,

sometimes, if one is reading something that one does not agree with, it can appear that one's own opinion is being dismissed.

The solution is there, it is just that Orbx do not do it, as made very clear at the outset.

 

Quote

It is not possible to remove or change  ICAO codes in P3D unless the core files are modified

 

As I understand it, you have used the Airport Inspector and Editor to first amend the P3D file Scenery\0102\scenery\APX15180.bgl

to remove the O17 identifier and replace it with KGOO.

Did you then amend the Orbx airport or remove its files altogether or added your own version or have you just left the default?

It looks like you amended the Orbx version.

 

Orbx does not modify the core airport files, so if this airport were to be released with the KGOO identifier, the result would be the same

as it presently is with the core file modified to KGOO and the airport remaining as O17.

 

It strikes me that it might be possible using the xml method to replace Scenery\0102\scenery\APX15180.bgl without touching the core

file but I don't know of any plans for Orbx to go through the hundreds of airports in the regions, find the ones that are either no longer there,

the ones that have new identifiers and even the airports that were not there when the products were released.

I think that the solutions to these problems will have to remain local to those customers who want to apply them unless or until the P3D

developers decide to update their database.  

 

[medx421]

35 minutes ago, Nick Cooper said:

Hello,

sometimes, if one is reading something that one does not agree with, it can appear that one's own opinion is being dismissed.

The solution is there, it is just that Orbx do not do it, as made very clear at the outset.

 

 

As I understand it, you have used the Airport Inspector and Editor to first amend the P3D file Scenery\0102\scenery\APX15180.bgl

to remove the O17 identifier and then replace it with KGOO.

Did you then amend the Orbx airport or remove its files altogether or added your own version or have you just left the default?

It looks like you amended the Orbx version.

 

Orbx does not modify the core airport files, so if this airport were to be released with the KGOO identifier, the result would be the same

as it presently is with the core file modified to KGOO and the airport remaining as O17.

 

It strikes me that it might be possible using the xml method to replace Scenery\0102\scenery\APX15180.bgl but I don't know of any plans 

for Orbx to go through the hundreds of airports in the regions, find the ones that are either no longer there, the ones that have new identifiers

and even the airports that were not there when the products were released.

I think that the solutions to these problems will have to remain local to those customers who want to apply them unless or until the P3D

developers decide to update their database.  

 

 

This is going to carry the weight of what would be a tutorial.  It's just not going to have screenshots and cleanliness.

 

First off, again, I did not touch the Scenery\0102\scenery\APX15180.bgl file.  What did touch that file was the navdata update program, be it in my case Aero.Sors, or in the other case FS Aerodata.  Those programs modify the core files to bring the ICAO's, runway numbers, taxiways, etc. current.  

 

If I were to use the program Little Nav Map for example, and typed in O17 for Nevada County, it would show me that the files it is referencing for O17 were ADEX_FTX_NCA_O17.bgl and ADE_FTX_NCA_O17_elevation_adjustment.BGL in their respective folders.  Yet if I searched KGOO, it would show me the file it's referencing is APX15180.bgl.  This is post navdata update mind you.  So, the simulator thinks that there is both a O17 and a KGOO causing a mismatch.  The way to eliminate this mismatch is to update the ICAO's in the aforementioned Orbx files.

 

Now updating ADEX_FTX_NCA_O17.bgl is easy.  I use a program called Airport Inspector and Editor by Herve Sors https://www.aero.sors.fr/navaids.html. In that program, you load the .bgl and open the airport/rwy editor and change the ICAO; in this case from O17 to KGOO.  That file is now updated, and is done.  Airport Inspector and Editor creates a backup for you prior to the save.

 

The ADE_FTX_NCA_O17_elevation_adjustment.BGL gets a little more tricky as Airport Inspector and Editor will not open it.  ADE will let you open it, but will not allow you to modify it.  So, we go to .xml.  For that, I use a program called Bgl2Xml by ScruffyDuck https://www.scruffyduck.org/bgl2xml/4584282773. In that program, I load the file in, and create an output.  You can choose any name you want, or use the default, but you will have to rename the file at some point.  This generates an .xml of the .bgl file.
I then open the newly created .xml file with a .xml editor.  I use the freeware Microsoft XML Notepad.  When open, under airport, there is a section for ident.  Go in there and change the ident from O17 to KGOO.  Save and close.

 

Open, not import,  the modified .xml file now in ADE.  Compile the file as you would any other scenery project.  Locate your newly modified .bgl and rename as necessary.  Place the new elevation adjustment .bgl in world/scenery folder and overwrite the existing.  Obviously you would have backed up your originals before hand.  

 

If you used Little Nav Map, then reload the scenery directory, and you should now find zero instances of O17, yet will see all three files referenced when you search KGOO.  This is purely optional.  More importantly in the sim, you should now see no instances of O17 and only see KGOO.

 

Load up, and enjoy your newly corrected scenery.

 

Of note, this can obviously cause problems the other direction if someone has never updated their core data.  However, if someone is looking for help with this issue, it is likely they have.  It's possible that the reason Orbx has elected not to update their own files is because they will then differ from the core files in the unmodified data set.  I will say, it is a lot easier to fix a core file than it is to correct the Orbx files though, but I digress.

 

I have done GOO, BVU, MPI, and was just about to knock out DIJ.  I'm sure there are others out there.  Anyway, hope this helps.

 

Nick

 

[Bsuslin]

For those of you that want to get into the weeds of fixing the problem orbx scenery,  you'll also need to download P3D SDK for use with the Airport Design Editor.  The workflow  is easy peasy after your first effort.  So easy in fact, that Orbx  could provide the solution to their customers on request without us (their customers) having to thrash-around on their support forum.

 

Bob

[Nick Cooper]

Hello,

thanks.

The weeds in this case are a result of adding another product that conflicts with addon airports using

the out of date FSX airport database, effectively adding a second addon airport.

If a customer wishes to use both these products together and they are not in some cases compatible,

it is not the responsibility of either developer to provide the customer with a bespoke solution though I am

quite sure that FS Aerodata or Aero.Sors would also be perfectly capable.

Your fellow customer, Nick has kindly provided the solution, I am sure that you will be able to apply it.

 

[Bsuslin]

don't hijack  my use of the term weeds.  I am referring to  the apparent daunting task one may feel at first blush  to fix the problem.  .  For your  edification  Medx421 and I collaborated

on the solution  without any assistance from you. 

Neither FSAD or Aero.Sors have an obligation or likely  disposition to offer to tweak your files.   Further,  the problem is ongoing and of  sufficient scale  that your weak excuse of having no obligation to provide a custom one-off  solution for multiple customers doesn't wash.

 Since I started this Post all you've done was try to  misdirect, blow smoke, and shrug  responsibility.   When that doesn't get the customer off your back ,  you revert to  passive aggressive

drivel and  a patronizing send off.  I am sure you will be able to apply  the same tact in the future.

[Bsuslin]

don't hijack  my use of the term weeds.  I am referring to  the apparent daunting task one may feel at first blush  to fix the problem.  .  For your  edification  Medx421 and I collaborated

on the solution  without any assistance from you. 

Neither FSAD or Aero.Sors have an obligation or likely  disposition to offer to tweak your files.   Further,  the problem is ongoing and of  sufficient scale  that your weak excuse of having no obligation to provide a custom one-off  solution for multiple customers doesn't wash.

 Since I started this Post all you've done was try to  misdirect, blow smoke, and shrug  responsibility.   When that doesn't get the customer off your back ,  you revert to  passive aggressive

drivel and  a patronizing send off.  I am sure you will be able to apply  the same tact in the future.

[Nick Cooper]

Throughout, I have tried to explain why the problem exists and why

Orbx are not doing anything about it.

I am sorry that you have apparently become so upset.