Calling PMDG, FeelThere, LevelD, PSS, Eaglesoft, FSBuild and all you other fine developers that I forgot to mention.For future developments, I wish that all of you would gather together at some point and agree to use ONE unified AIRAC and SID/STAR database. It is ridiculous to have a half dozen databases with the same information that all need to be synched up. There are tons of people working on customized SID/STARs that all need to be re-developed and synchronized across all those databases.Maybe even MS could maintain such a database with FSX, but I guess that's more wishful thinking.Pat

I agree. What we have no is unecessarily clumsy.Rob

hahahahahaha ... unnecessarily clumsy ... right ... but FREE ... and based upon FREELY available (at least for a while) US Govt DAFIF data, not 100% plametary coverage but FREEOnce a month I go to NavData and to Terry Yingling's side, d/l and install ... (and to Feelthere also) takes 5 minutes.Sid/Stars ... I guess that is maybe an issue where the devil's in the details ... Terry Yingling does seem to have the Sid/Star available for most systems .... also for free ...Question: if someone were to contract with Jeppeson or (is it ARINC? I'm not sure ???)and supply a monthly service ...would you pay for it ... have never explored costs, but believe that this would be very expensive ... even if 1000 people signed up and paid in advance. .. How much would you be willing to pay? And then would Jeppesen or (whoever else) be willing to let someone else sell their data?Anyone with an desire to start a small business?Otherwise, FREE is really great ...but I do agree that "standards" would be a great thing ... but at this point ... would be very hard to do with an international group of people for whom this is a "hobby" more than a full time career.Good Luck!Best Regards,Paul BenoitKSAN

I think this is a good idea, and Egbert Drenth asked the same a little more than 1 year ago.Maybe it does not come true because vendors all have particular needs different from the other?ORMaybe it does not come true because the problem has to be taken the other way around: with the experience both Richard and Terry have accumulated, they could:1) Determine the data coverage information needed for a database (for example, a RUNWAY has to have this and this information)2) Offer the database in a single form, with published data format (like all database vendors do, like DAFIF or Jeppesen or any other)3) Invite any vendor to use the database in its fixed format4) Eventually if needs be to cover costs, offer a subscription service to the userDatabase format is their field of expertise, not vendor's field of expertise. Furthermore, in maintaining a single format, they streamline their own processes and reduce their own costs. Furthermore, a customer with 1 subscription is guaranteed to have a working database for any aircraft abiding to the format.Sure enough, vendors in promoting this database, instead of another, especially if there is a subscription service, could be incited to get a form of royalty from the database vendor because the aircraft vendor, in supporting this database instead of another, is favoring revenue stream toward one instead of the other.Nevertheless, subscription apart, in my opinion one way to achieve the goal of a unified database for all vendors is not in having all vendors gather and decide together, but is in having the database provider offering a single data format to the vendors that covers all vendors needs. This is their field of expertise to come up with a unified dataset, not vendor's field.And I'm sure that vendors will embrace such unified format for the most part.Hope this helps!

We have to agree with JL on this one. At this point, developers/vendors have chosen to use different approaches and techniques to acheive the desired goal. A "Standard" for all developers would be handy for most developers:-)There is the question of return on investment for those who have worked very hard to establish their own techniques but even they may be interested in such a "Standard":-)

I think it would be easy to achieve, because all Navdata feature the same information, but just fields are arranged differently.As for the techniques: I think from what I have seen is that most developers use the AIRACS either in plain MS Access or in a MS Jet DB format. The SID/STARS are usually just plain text files, which makes sense, because they're easy to swap and upgrade, if a new release comes out without having the need to upgrade the entire DB.Now put that all in a folder called "Navdata" in the FS9 root, open up the DB structure and the SID/STAR format, make the format public and I am sure most developers would be happy to use this in future projects.Pat

You'd probably need a commitee, and developers would have to be bound by that commitee's decisions regarding formats etc.Some developers/vendors Im sure would sign on to it, but doubt all would.I certainly wouldn't, in the end I make the final decision regarding file formats on my projects. I can't see myself giving that authority to a committee.I doubt such a commitee would work anyway. The first developer who is told 'no' by the commitee on a format specification will be the first one to leave the commitee and do it his own way.What is stated in Jean Luc's last paragraph is probably the only thing that would work. A single 'source' database that each developer can use and convert to their respective formats.But really that's what you already have with DAFIF, the problem is DAFIF was never complete when it came to Sid/Stars and goes away in October.Regards.Ernie.

I don't think that a commitee or any virtual FS Developers Association would be necessary. Compare it to FSUIPC, which has slowly become a standard for virtually all FS9 developments.I doubt that standardizing fields would harm any developements, because you're simply accessing the data which are unified across the board. Just look at your forum about users whining "I don't have KXYZ STAR/SID", "Where is AIRAC XYZ, it's on the navdata.at site, where is yours?". One issue less for you to worry about.Just let one developer take the lead to open up their AIRAC and SID/STAR format, provide some documentation how to access the fields and be done with it.Pat

Perhaps I am missing something here, or don't quite understand the issue being raised (and I do have systems with NAVaid differences). I do run into this issue at times, and regardless of the consistancy of any database, either updated, or outdated in the 'real world', the main issue is what the navaid info is within the scenery .bgl's.If the database does not jive with the scenery nav's, it's kinda worthless when you are lining up to land via an ILS approach, you know you have an updated frequancy, but your scenery ILS is 'outdated', and you can't get the ILS to capture.I'm not sure how a consistant, and updated, NAV package would solve the issue of what is 'in' the scenery.SIDS ans STARS (and GPS waypoints) are one thing....ILS, VOR, NBD, etc are more difficult to 'control'.

Ernie, your concerns are valid in that no developer that we know would submit to a commitee making final decisons for their projects.The only matter under discussion is whether certain folks would wish to help set/provide a "standard" which developers could easily access/use if they so choose. Seems a win, win for developers and customers alike.:-)So far, we see no compulsion for anyone to participate if they do not wish to do so.

Correct Brian, seems the heavy iron, full FMS group are the folks who wish to have DBs which may be updated and include ease of use when it comes to SIDS/STARS.:-)

Guess I fly the Cirri, Liberty, Champion, Cessna's, Piper's, etc etc too much Ron.....Like, all the time... :DBiggest iron I typically climb in is the DC-3 ;)

Pat you bring up a great point regarding the Navdata issue. One thing that has really disappointed me over the years is that the SSW Navdata never gets done, which is a real bummer. I mean that addon has been out for about three years and none of the big name navdata developers such as navdata.at or Terry's database have made an Airac for it. I'm sure this isn't the only addon experiencing this problem and for other people that have this problem can undertsand my frustration regarding this issue and where I'm coming from. Lastly I'm sure you can now see the advantages of a joint venture for one exclusive FS database that gets updated monthly. Because resources are more available when you have many people together and things just start working out. But we'll have to see what the future of FS and the community does with this.Best Regards,Emil Serafino Jr.