How current is P3D's nav data?

[badderjet 181]

Hello,

 

as the search didn't quite return anything useful and also not much on their web site, I'd like to know if anyone knows about the age of P3D's nav and facility data. IIRC FSX had a data base dated 2005. Is more current data included in P3D or do we still have the same old data?

 

Thanks for any hint!

[greggerm 312]

It is the same as FSX / ESP / P3Dv1.

[badderjet 181]

Thanks. Wow, too bad, but then again not too surprising as well.

[fppilot 4,397]

Wow!  That is something they really need to address.  And use a data source that allows it to be updated.  P3D will continue on into the future and that just has to be a must to be viable for a "training" sim.  Man would that would also allow for some quicker free market competition in Nav avionics.  Just gotta happen.

[pmb 5,138]

Hi,

 

this has been discussed in the LM Forum, look there for details.

 

Nav data are hard coded in the bgl files, at present. LM would have to wade thought all of these numerous files and change them one at a time by hand. Highly improbable they are inclined to do that given their work with fixing and developing the core code.

 

The suggested way to go was taking these data out of the bgls and read them from a database instead, which could be updated continually. While this seems plausible and while we know such databases already exist, this has a major downside: It would break backwards compatibility of the whole simulator.

 

I doubt we will see a solution soon, as nasty as it may be to fly in 2006 data. 

 

Kind regards, Michael

[fppilot 4,397]

Michael,

There are more than one set of avionics out there today that use readily available nav databases.  Despite what is coded into .bgl files, it is a fact that information can be mostly ignored, replaced by a plug-in/add-on approach that uses a nav database that is already constantly updated for reasons other than flight sims.  What would be good for the industry would be for LM to adopt one of these standards and provide at least a cursory array of avionics that play off of the standard.  Then 3rd party developers would have a standard to write to and more interest in presenting to us offerings perhaps more robust that what might be offered within LM's product.

 

I cannot image that LM would make a business decision to establish and constantly update their own proprietary Nav database, much less constantly update .bgl files.  And I for one would rather see them use their resources to continue to develop the core of the platform.  Instead, adopt a standard with an already progressive flow of Nav data.

[mgh 89]

 

 

Wow! That is something they really need to address. And use a data source that allows it to be updated. P3D will continue on into the future and that just has to be a must to be viable for a "training" sim. Man would that would also allow for some quicker free market competition in Nav avionics. Just gotta happen.

 

The aeronautical data is updated on a 28 cycle example on a word-basis. Lockheed Martin isn't going to provide that.

 

Anywhere,  there are other firms that provide this  information on a commercial basis.

 

 

u

[fppilot 4,397]

Anywhere,  there are other firms that provide this  information on a commercial basis.

 

That was one of the exact points I was making.  The other point I was making is that LM should begin to ignore the NAV data embedded in the .bgl files and instead write into P3D the hooks for one of those other firm's Nav data.  Then LM will not have to worry about updating any Nav DATA itself.  Data is one part of it.  The other part is building in the segway for that data from another party to be easily used within P3D..

[mganz121 159]

@ fppilot .... And the ongoing cost of providing this is worn by who? And how?

 

Sent from my GT-N7100 using Tapatalk

[fppilot 4,397]

@ fppilot .... And the ongoing cost of providing this is worn by who? And how?

 

Whatever cost for developing in the path for the data would be born by LM, and of course in free enterprise ultimately by the consumer.  The cost for updated data would certainly be borne by the consumer, as it is in the case of data sets for FSX addons that exist.  That data would come from a 3rd party provider.  Likely one that maintains a database for separate reasons.  

 

I do not see why there seems to be such volatile argument.   RXP as only one example provided a way to infuse Garmin nav data into their add-on products, how to crossfeed that data, and how to link it to instruments in FSX aircraft.  For example I am able to create a flight plan in an RXP GN530 or GNS430 and with that link=on display the flight plan track on the glass avionics in almost any FSX aircraft.  If third parties can work their way in like that, then LM can do so also and in doing so perhaps adopt a standard.  Here are examples.  All of these are fed from Reality XP GPS models and fed by Garmin Nav updates.  It cannot be that difficult for LM to provide a path in that both LM and 3rd parties can develop to.

 

PA-46.  Note the flight plan on the RXP GPS and the flight plan track on the right screen of the PFD.

 

 

 

PA-46 again, and the PDF screen has been paged and now you can see the flight plan nav points on the PFD.

 

 

This one is from a freeware single person developed HondJet using standard FSX avionics and an RXP GNS 530.  You have to look harder as the resolution is lower in this model but look hard and you will see the center PFD shows both the flight plan track on the map and the flight plan nav points the right pane.

 

 

 

And finally here is the panel from an A36 with the GPS flight plan track displayed on the Avidyne.

 

[Hippo 34]

You may want to investigate the following:

 

http://www.aero.sors.fr/navaids3.html

[mgh 89]

Reality XP and Navigraph already can provide data for flight simulator.. Why then should Lockheed Martin bother - especially it's for benefit of third party developers?.

[fppilot 4,397]

Reality XP and Navigraph already can provide data for flight simulator.. Why then should Lockheed Martin bother - especially it's for benefit of third party developers?.

 

GOOD GRIEF!  Can nobody read?  Data.  How many times have I said above that the DATA would come from THIRD PARTIES, like Garmin or Navigraph.  This is exactly what I am saying.  What I am foremost saying is that LM should write in the path for its own instruments to use such data that would come from THIRD PARTIES.  I just did not mention Garmin or Navigraph by name.  If LM puts in that path then it might be easier for avionics third parties to develop to that path, rather than having to design paths of their own.  That might improve the number of avionics offerings.

[vonmar 124]

You may want to investigate the following:

 

http://www.aero.sors.fr/navaids3.html

 

That can mess up other things ... better, IMO, watch what you are doing.

 

Have you used it all in updating your own sims?

[Hippo 34]

That can mess up other things ... better, IMO, watch what you are doing.

 

Have you used it all in updating your own sims?

 

I entirely agree it has its risks (hence "you may want to investigate"), which are clearly explained in the documentation.  It also creates a backup of all the files it changes, so it's quite easy to revert.

 

I only found out about this utility on the LM forums recently (so only started using it recently with P3D v2.0).  I have installed all European navaids, and the intersection data, and have not had any problems.  I was practicing approaches, etc, in the south of Spain area and was having issues with navaids not matching current plates.  After updating with this utility everything was correct.  I am very happy with the results, although my usage has been very limited.