from Microsoft quarterly and annually. I wouldn't mind paying a little fee for these updates.What do you folks think?

I think 99.9% of the FSX users don't care about updated navigation data. For those who do care there are other sources. It seems to me that MS would do better to put their efforts into fixing the many FSX problems still remaining rather than diverting those efforts to additional functionality (which, sadly, they have already done.)Doug

Jeppesen charge

It's been talked about quite a bit at all levels (3rd party to Jepp, 3rd party to MS and MS to Jepp)for many years now. I have tried myself for years...LOL.Basically Jepp will only do it by creating a customized (level of data service) D-base for each nav(fill) device (ie. GPS, FMC, etc.(additionally each type or brand as well)) to the initial cost of somewhere in the 10-20K USD range which includes the first cycle free to the end user and developer; and then allow every end user to log in to their web site/FTP and download each cycle (monthly) for a cost of about 20.00-30.00 USD.Then there's also the issue of the sim itself which would, in theory, also need to be updated monthly, especially since nav freqs change, etc.. So factor that one in as well. In other words if MS were to pass that cost down the pike you'd be paying about 60.00 USD per cycle/month for the sim and just 1 of your navigation avionics pieces.Also, MS pulls from several other world wide navdata sources since Jepp actually doesn't cover near as much as you would think.Just some food for thought :-) Mind boggeling isn't it?

When we purchased the sim the data came real cheap, right?!MS already has a mechanism in place so why not continue to use it.The data in FSX, I believe, is from about 05/2005. If this is correct the data is already two years old.Seems to me that MS could make some money on this and I would gladly pay, for example, $25 a year. I wonder how many FSX users would be willing to pay this much as year? Now many FSX users are there? There must be thousands and thousands. Take that number times $25 and MS will surely make a profit.

That's certainly a common sense perspective, and one I can relate to, but unfortunately no where close to how it works, or would work even for us simmers.Yes, the navdata is about that old, generally speaking.MS are not authorized resellers of navdata. Jepps make their money on a per user, per cycle, per fill unit basis, customized for the customer.What you see with Jepps as an MS partner is merely a 1 time, 1 version (sim) marketing agreement with one cycle/data set. Again, generally speaking.Where it's almost feasable to the end user is through 3rd party developers. The problem though, is that most 3rd party developers can't absorb the initial costs for Jepps to make each data base for each type of FMC/GPS device that the developer makes.Believe, me, I begged and pleaded and cried to Jepps on the phone for them to just sell us the raw data, and that we already had our own data base made, etc., but they wouldn't budge.Now having said that, for what Jepps does, it's really a great value for what they actually do for you, to anyone, because of the shear amount of time, the actual amount and types of navdata (I'm talking of stuff that's included that you never would have thought was in an AIRAC cycle).Where it really benefits the end user is even though the initial cost per cycle, per unit is somewhat high (or more in tune with the actual aviation world), a simmer could for all practical purposes get away with, safely, 1 cycle for almost a year or maybe longer.This would in effect, give you about 80 gazillion more SID/STAR/IAP, Airways, etc., then you would have had before hand, etc., etc.,LOLFor instance, the other day I decided to try out Navigraph's NDac service/demo. I actually bought the MYNN (Nassau) airport. If you search the web for any MYNN charts you would find just the AP diagram and the 1 VOR APPRoach plate, most likely. Well, did you know that there are actually 2 SID's, RNAV Approaches for all the RWY's and an ILS? Unless you had a chart service you would have never known this. I bet with this level of navdata service you'd at least have these approach and departure options in your little GPS's and FMC's that we haven't had before.Now take that for instance and just let it snow ball down the line for each airport.so 30 bucks for the end user once a year per unit or so is really not so bad when you think about it.There are more benefits, but I think you all can see my point.It's this that the average simmer wouldn't mind paying a little more for, because the value would be there.The problem is developers can't afford the initial costs yet.I also don't think that the sim is 'modularized' (if I can make up a word here) enough for the sim itself to benefit from current navdata cycles either.What we need to really hope for in the short term is for one of the current developers to be able to do as I described for 3rd party a/c. That alone would be worth the price of admission. 1 version with Jepps data and one lesser cost with Navigraph data. give you the choice. :-)Anyways, this gets pretty jumbled up now, especially since I'm the one writing, or trying to write. There's simply too many thoughts and stuff under the bridge to try and describe here.It's been almost a year now I think since I last gathered all this info, so maybe something's changed or better yet become more cost effective for all of us.*edited for crappy typing and spelling*

Here are some additional things to keep in mind:1) It's fairly useless to update only the nav data without simultaneously updating the sim's data at the same time. It would be like trying to navigate on Venus using navdata for Earth... Well, not quite that bad, but I should think the point's clear enough... ;)2) There isn't ONE, unified database in FS: the facilities and nav data are scattered in multiple files. Worse, the process of "updating" thse files isn't really suited for "automatic processing." It must be done (mostly) by hand. Also, it is more than simply "data," as the scenery must also be updated if facilities have moved or are new.3) Each FS "update" would require an HUGE download, mostly because of issue #2 above.While the idea certainly has some theoretical appeal, practical implementation would be a nightmare... :-ukliam

Remember that DAFIF stopped providing public access to it world-wide charts because of copyright issues raised by those countries that sold the charts themselves. Those countries effectvely own that information.Jeppesen must have agreements with other countries that allow it e publish this information commercially. It seems likely that those agreements would be tightly drawn and limit the use Jeppesen can make of the information. These agreements almost certainly would have to be re-negotiated if Jeppesen wanted to sell this information cheaply for use with FS. Jeppesen may well take the view that providing information for a few dollars a time isn't its mainstream business and not worth the effort. It's a hard commercial world out there.

That's not really the issue. Jepps has been selling this info, in their format, since people found out the earth was round...rofl.I doubt there are any legal issues with any countries, especially since Jepps, if memory serves me correct, actually carto's the info from the start, so in reality, if anything, it's Jepps to begin with.I've also approached Jepps with the 'perceived' math approach, dollar figures from future subscriptions, etc..

Bill,Just to be clear for the cusual end user....what you're talking about is updating ths sim itself and the things inside the sim that the data coresponds with.In other words, so folks don't get scared, it has nothing do do with the navdata that's used my FMC's and GPS's, which can be current (some debate and theories about that though as well).Anything above and beyond that to which is in the sim even though not technically under NDA, I did promise the Z man a while back, I'd keep it on the low, if you know what I mean.:-)

As a post script here, I should also point out that my response is as it pertains to us as simmers, because the sale or re-sale of this info WOULD be at the same price, relatively, just as real world navigation units.Notice I said "same price".Any contractual issues between other countries or Jepps contractors/vendors should already be taken care of in their existing licensee to reseller clauses, as it were.

>Just to be clear for the cusual end user....what you're>talking about is updating ths sim itself and the things inside>the sim that the data coresponds with.Of course, which was why I made point #1:1) It's fairly useless to update only the nav data without simultaneously updating the sim's data at the same time. It would be like trying to navigate on Venus using navdata for Earth... Well, not quite that bad, but I should think the point's clear enough...Perhaps a better analogy would be trying to navigate in today's London using a map from the 18th century.The point being that if there isn't a 1:1 relationship between the nav data used and the "physical reality" as determined by the sim's own database, there will necessarily be an increasing "disconnect" between the two... ;)

Hehe, well, yeah, what you're saying is correct. I should have been more clear on that point, But people aren't going to understand that though. You have to look at the posters perspective. There could be instances where current navdata can look like a ghost, sure, but I'm not sure how frequent that is.The vast majority here are using 3rd party a/c with fairly up to date navdata that don't throw up errors as they navigate with it (please....please...please don't re-open the possible CTD theory...ROFL) you know what I mean.Now to your, point, which is the correct way of doing things...LOL, would take forever and a re-write...haha. :-) I just didn't want to get into the next logical idea step with everyone here in public in order to keep my promise...:-)

Why can't MS create a format for the NavData that can be updated by 3rd party users, or replaced by 3rd party files? Seems that would be the easiest way to get new navigational aids. Would it cover the entire world? No. Would it work for the larger more popular airports and areas? Yes.

NAVDATA is not a separate item in FS like it is in the real world.When Garmin or Boeing updates their GPS/FMS - they only need data which relates to navigation. They do not design and control the physical world with their data.Microsoft does design and control the virtual physical world partially with their navigation data.If the Garmin GPS or Boeing FMS has an runway 100M out of location or 20 degrees off heading - the pilot makes a correction and lands at the airport.If that data is off in FS, the airport polygon is just one of the many things which can be wrong.Look at these three airports in FS - NZMF - real world elevation 10F/3.0M - FSX elevation 846.1F/257.9MPGRO - real world elevation 607F/185M - FSX elevation 16.1F/4.9MKNFJ - real world elevation 102F/31.1M - FSX elevation 358F/109.1M (The new tallest mountain in Florida)They are all what happens when NAVDATA gets corrupted and is applied to a virtual physical world.NAVDATA is not something which sits alone by itself above the FS world - it is an integral part of the design of that world.Runways, aprons, taxiways and parkings spots are all part of the 'navdata' in FS. They are not separate items. FS also includes data like fences, taxiway signs, etc.The files holding this data are:APXnnnn0.bgl - 1,525 files - 89.1 MBNVXnnnn0.bgl - 72 files - 1.71 MBThere is a way to add new data and make some updates with new files. But it would be a very complex task.The real key really, really big issues would be new runways, runways with changed designators and removing old NAVAIDS.Those would require the original files to be replaced with updated files.That could also make your nice payware scenery no longer workable / crash.Yes, MS could do it differently, making the NAVDATA not directly tied to the physical world.I would expect significantly more issues and discrepancies when airport data would be in two different places and formats. When our aircraft would have to shift from one to the other.