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.

You are conflating two completely separate sets of data. Navigation data and airport facilities data.

 

In FS/P3D these two sets of data are currently scattered within several thousand separate .bgl files.

 

RXP and other third-party navigation system use alternative sources. RXP uses the data from the Garmin Trainer program, while others use alternative sources such as Navigraph.

 

The downside is that their more current navigational data does not synch with the sim's internal data, so there is always going to be a disconnect. Even using the "updated data" from Herve' Sors is not a perfect match, although it is considerably closer.

 

What none of the above do however addresses the airport facilities data (runways, tower/ground frequencies, ILS/GS frequencies, or onsite NDB locations and frequencies, all of which is "baked" into individual airport .bgl files. Actually compounding the issue is that many airports are clumped together into a single .bgl file.

 

Microsoft's ACES coders did not create these AFD files by hand! They licensed the data from various sources (including Jeppeson), then wrote a program that auto-generated the .bgl files for them. Only selected major airports received "special treatment" with extensive hand-editing. If I recall correctly at this late date that was 24 highly detailed airports.

 

Now there is a certain merit to the suggestion that L-M simply leave things as they currently are, and create a totally new and integrated, single-source database that could be used in lieu of the 'baked data' system, which would include both navigational data and airport facilities data. What though would be the benefit to them? I would posit none whatsoever.

 

In any event, even should L-M do so, it still wouldn't fix the most fundamental underlying problem, which is that many of the airports themselves would still have their old runway and taxiway geometry, and that would not in many cases match up with the current real world configuration.

 

Just as a quick example, my local airport KGYY has been added to so much that it barely resembles what is in the sim.  Boeing's corporate hanger and ramp on the west end of rwy 12/30 where they keep their 3 Challengers and 2 BBJ's, the closure of taxiway D at the north end of rwy 20, the on-going extension of rwy 12/30, and the addition of the Indiana National Guard facility at the southwestern corner of rwy 12 are just the tip of the changes since FSX's 'baked data' was generated. There is also a completely new passenger terminal with two moving jetways, although they are currently unused.

 

In short, this is not a trivial problem to solve... :unsure:

 

 

What though would be the benefit to them? I would posit none whatsoever

 

That is my position too.

 

 

Now there is a certain merit to the suggestion that L-M simply leave things as they currently are, and create a totally new and integrated, single-source database that could be used in lieu of the 'baked data' system, which would include both navigational data and airport facilities data.

 

That is my primary point.  The benefit to LM is that would facilitate the future of their product by enhancing its appeal to most target markets (I for one believe they recognize all of P3D's customer segments for revenue even if they continue to stress the training segment as "sole") and by perpetuating the product's appeal and then accordingly those revenue streams.

 

In regard to airport runways and taxiways and alignment.  Don't know how they could best address that issue, but I have long relied on third parties for those corrections (both payware and freeware), just as I have for avionics and aircraft.  Sure, that limits the number of corrected airports, but I personally find the number of them available to be numerous.

 

 

What though would be the benefit to them? I would posit none whatsoever.

 

Hmm... I would argue that as a training simulator, it would be of great benefit to LM's potential commercial customers to have an upgradable, accurate database.  And what would benefit LM's commercial customers would likely benefit LM in this endeavor.  The cost for the database itself wouldn't need to shouldered by LM, after all, much in the same way that the cost for updating the Navigraph database that we use for the various FMS's in existence isn't shouldered by each individual developer.

 

However, as you very thoroughly and wisely pointed out, this problem extends to far, far more than just a nav database for GPS or FMS units to draw from, and is thus, for all intents and purposes, rather hard-coded in the sim.

However, as you very thoroughly and wisely pointed out, this problem extends to far, far more than just a nav database for GPS or FMS units to draw from, and is thus, for all intents and purposes, rather hard-coded in the sim.

 

I fully agree, and that aspect of it makes the platform itself more work intensive to keep updated, or to keep current.  It appears to be one of the inherent design elements that perhaps has led to abandonment on more than one occasion.  An abandonment by MS that appears now to be permanent on its part.  So what can reduce or eliminate this issue for LM or any future successor (should that ever happen)?  If that/those database(s) were maintained separately......

I think we should make difference between navaids (antennas on the ground with appropriate beams simulated) and navigation database.

 

Database is just for navigation computers - easy way is to build a new nav computer, or retrofit the old one to use new database.

 

The real question is how to update all radio navaids. They need to be planted on the ground, as part of scenery. not stored in database for computer use.

They need to be planted on the ground, as part of scenery. not stored in database for computer use.

 

Why can they not be geocoded into a separate database?  They have physical positions in the world.  I can produce the lat/lon coordinates for the big oak tree in my front yard.  What is so different about a stationary antenna?

Why can they not be geocoded into a separate database?  They have physical positions in the world.  I can produce the lat/lon coordinates for the big oak tree in my front yard.  What is so different about a stationary antenna?

Of course it can be geocoded into a separate database. The difference is it's part of the virtual world and not part of database for GPS.

When a bed is made it usually has a fitted sheet, then a flat sheet, then a blanket or two, then a quilt or bedspread on top.  ##### cares if it requires two separate databases or not.  That is not the point.  The point is pull it out of hardcoding (or write mods to ignore the hardcoding) and make and use layers that are realistic in terms of effort or separate availability to use and keep updated.  To continue the thought, such layers should be easier then to keep aligned over time.  "Gee that blanket is hanging over the far edge too much, lets pull it back this way a bit."

 

Then it also can become: "who has a better blanket (or sheet, or bedspread)". i.e. competition and free market enterprise. Just takes re-designing the bed.  Then the layers can fit over it.