Hi,I have a dream:With all recent and past release of great airliners a problem has arisen: NavData & SID/STAR databases.Each and every aircraft/FMC is released with a proprietary NavData database. Some are included with a SID/STAR database, some are not.This makes it for us flight simmers a rather tedious job to collect/create/download/install several packages: a different one for each aircraft.We can consider ourselves very fortunate with people like Richard Stefan!Therefore the appeal:Wouldn't it be nice to have a Universal Nav Data Format (UNDF), where all aircraft manuafacturers comply to.The advantages are 2 ways:- Aircraft manufacturers don't have to worry about NavData and only have to develop 1 import routine- For users the advantages are also evident.I realise this is a long shot, but let's hope it can be realised for all aircrafts released for FS2006 and up.Thanks for listening.

It would be nice to have certainly and probably needs mainly a person to get the project started.If you feel so inclined you might want to contact several development groups (PSS, PMDG, Flight1, come to mind) and try to get a working group started in order to hammer out the requirements for the file format (what data should be in it, to what precision, etc.).Keep in mind that at least for the foreseeable future migration tools will be needed so resources will have to be set aside to create those.I might be able to help out somewhat but I've a rather busy life at the moment so may not be the best person to rely on to pull the wagon.

I second the motion but that's easy for me to do as I'm not a developer, just an end user. It certainly would simplify all our lives that's for sure. Jay EklundCAT V Second Officer KDENhttp://online.vatsimindicators.net/812321/764.png

Whilst the idea certainly is a good one, the chances are slim that it could be made to work. No reason why not of course, just too many "ducks to get in a row" and of course the required changes to existing FMS software. It could turn into a big job.In the meantime, perhaps an alternative (that is do-able) is to create a program that, once downloaded, can extract Navdata from a single common source file from Richard Stephan and load the converted data directly into the appopriate directories for each add-on.In that way, Richard only need create a single master Nav data file and we only need to download it once. We can then use the local extractor to export whatever format is required for each add-on that we have.

>...just too many "ducks to get in a row" and of course the>required changes to existing FMS software. It could turn into>a big job...>Hi,That's the reason why I proposed FS2006 as begin.The NAVData itself is not the issue, because that's is provided by Richard.The real problem is the SID/STAR database. LDS767 doesn't come with a SID/STAR database and depend on users to (manually) create one.Lago uses the old PIC767 database, but their FMC is not 100% compatible with PIC767 SID/STAR, hence users need to make manual adjustments. I'm a developer myself, and I'm confident that when a certain format has been agreed apon, it shouldn't be too difficult/time consuming for the aircraft publishers to make the necessary adaptor.Sure it cost time, but it is no rocket science.

Hear! hear!I strongly second this motion! And will do what I can from my perspective.Cheers,

There are flight planners both freeware and payware that include DP and STARS and can synch with Richard's NAVDATA. It would be nice if we could "cheat" and import the standard FS format into the FMC for those that don't want to mouse in and mouse toggle each waypoint. The other option is for FMC developed plans to be able to be exported in FS format for use by ATC add-ons such as Radar Contact.I agree that a standard should exist which also should include the ability to include crossing altitude restrictions.If this standard did exist perhaps ATC developers would be willing to interface with it.One caution is the reduction of DAFIF data as a free source this coming fall under pressure of some non-US governments flexing international copyrite muscle and international cooperation, etc., complaints. I do not know if this will impede NAVDATA updates. This thread topic has already been covered but it is a consideration.

>In the meantime, perhaps an alternative (that is do-able) is>to create a program that, once downloaded, can extract Navdata>from a single common source file from Richard Stephan and load>the converted data directly into the appopriate directories>for each add-on.If I recall correctly Richard had that idea of one master file a long time ago. Maybe it is not so easy afterall since he has not done it for his nav data. RegardsTerry

>The real problem is the SID/STAR database. LDS767 doesn't come>with a SID/STAR database and depend on users to (manually)>create one.I could help on this one since I provide the free terminal procedures (SIDs/STARs/IAPs) for the PMDG 737NG, the PSS Airbus Pro, 747, 777, and Dash 8, the Aviograsf A340, Flight 1 ATR72-500, the Wilco 767 PIC and next cycle the Feel There ERJ 135. Problem is that I have tried to contact LDS 4 times now but I've gotten no reply to my inquiries. I'd be happy to try again if someone has a contact at LDS. I can be contacted from my site listed below.RegardsTerryPlanePath http://home.sw.rr.com/filesherenow/index.html

Hi Terry,hi all,good idea - thanks Egberth for the input. We must split it into two parts.First one: Navdata-base-----------------------Currently i support over 16 different addons, with nearly 16 different formats. In the meantime, we have over 160 GB (in words: GIGABYTE) traffic each month, growing and growing and growing ... That

>Second: SID-STAR database>------------------------->This point is very, very difficult to realize with a "GENERIC>database". There are so many different FMC functions, there>are so many different formats and there are so many very>complex features in the FMCs that this is in my eyes>impossible. Hi Richard,Thanks for stepping in!I disagree with you that it is very difficult to realise.The format/database should provide all necessay data elements, so that the most complex FMC's can be supported, but also the more simple ones. In fact each manufacturer takes only those elements he needs for a specific solution.Defining a datamodel to facilitate this shouldn't be too difficult. And talking about elements, data and exchanging information.I think XML was just designed for this very purpose....As long as the aircraft manuafacturers adapt the idea too, it can be realised.

But Egberth, the source database (means the GENERIC) would be very, very large to hold all information (for complex and for simple fmc

I think the ideal solution would be to get a hold of the actual ARINC424 style SID/STAR database for a cycle and then create some sort of standard based on that that developers can use to program their FMC's for all the leg types etc.One issue I see with this too is what do you do with the unique system that PMDG has for their proceedure files where you just write the procedures in natural language, without worrying about lat/lon etc... I love that system for handmaking procedures, I wonder if it'd still be possible to support that alongside this new universal format...

Hi Terry, I'm a bit surprised no one over at LDS has replied back to you. Your program for creating SIDS/STARS for PIC-767 was absolutely invaluable to me. I'll post a message over at LDS with the link you provided.I hope Wade our Laurent contacts you.

This is an interesting conversation about ideas.>Defining a datamodel to facilitate this shouldn't be too>difficult. No, not difficult at all. In fact the standard data model has already been available. It is the 34.5 Meg DAFIF.>And talking about elements, data and exchanging information.>I think XML was just designed for this very purpose....Maybe so but I'm not a fan of XML from my viewpoint. It was harder to program in and is harder to update. I am working on a project now that uses the XML format and it takes my computer, a 2.53 GHz machine, over two hours to import my procedures into the planes database. I then have to see if there were any errors and if so, fix and import again. This is something the user will not see but I will every 28 days. >As long as the aircraft manuafacturers adapt the idea too, it>can be realised.A big if. When you step back and acknowledge developers already have a standard database available you must then start to look elsewhere as to why they don't supply terminal procedure updates every 28 days on the AIRAC cycle. IMO it is not the availability of a standard database, it is more likely economics and manpower to do the job.RegardsTerry YinglingPlanePath http://home.sw.rr.com/filesherenow/index.html