Appeal to aircraft manufacturers : UNDF

[Egbert Drenth 250]

Hi Terry,>No, not difficult at all. In fact the standard data model has>already been available. It is the 34.5 Meg DAFIF.DAFIF or AIRAC is not the standard I'm refering about. Those are used (partially) as the sources for the data, together with input from us pilots.The datamodel of DAFIF for example is way too extensive to be practical. Pilots need be to able to understand the format so thay can update the SID/STAR themselves. This is impossible with a datamodel like DAFIF.Don't get me wrong: We need databases like DAFIF, but only as a data source, not as a standard format.>Maybe so but I'm not a fan of XML from my viewpoint. It was>harder to program in and is harder to update....XML performance can't be really an issue when it is used in an FMC. Surely you as a SID/STAR provider are converting, enriching huge amounts of data and that takes time.But when the (prepared) data is used in the FMC, only fragments of the data is needed. This can't give any performance issue.>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.See my remarks above. AIRAC/DAFIF's are definately needed but as sources, not as the standard itself.Maybe there is already a standard like the old PIC767 or the new LDF-767 format.What my point is, is that the publishers need to agree on a certain format (either already existing or newly designed), that is suitable for all their needs and simple enough for pilots to update (i.e. the SID/STARs).This way it will be a lot more efficient for all parties (publishers and pilots) to update and maintain the data.

[Guest stang]

Hi EgbertThis discussion is interesting to me so if you don't mind I will continue to provide another view.>DAFIF or AIRAC is not the standard I'm refering about. Yes I realize that but you do realize they are a standard and that both contain enough data to produce the terminal procedures we all want to fly with?>are used (partially) as the sources for the data, together>with input from us pilots.I don't understand what inputs you are referring to? I would think if another standard database was established it would contain all the terminal procedures published thereby negating the need for any updates from individual sim pilots. It would be a tremendous expenditure of resources just to establish a 3rd standard database if it only contained what is already available.>The datamodel of DAFIF for example is way too extensive to be>practical. How so? Yes there is a lot of data that may not be needed but that does not mean it is not a standard that can not be used. A standard database should always contain more information than any one user wants so as to allow for much more flexibility and growth by the user.>Pilots need be to able to understand the format so thay can>update the SID/STAR themselves. This is impossible with a >datamodel like DAFIF.Sorry, I disagree. Once you know the format it is straightforward to work with. A standard format does not mean it has to be easy, just well documented. The DAFIF is well documented.>Don't get me wrong: We need databases like DAFIF, but only as>a data source, not as a standard format.Now I am confused. A standard database implies it is a source otherwise all you are doing is changing the format of the original standard database. Perhaps when you are saying "standard database" you are meaning a standard terminal procedures only database?>XML performance can't be really an issue when it is used in an>FMC. I would agree once it is read in and interpreted but as I said my comment was from my viewpoint which is different from the user of the data who does not have to manipulate that data.>Maybe there is already a standard like the old PIC767 or the>new LDF-767 format.I would not call them a standard. They are nothing more than the developers way of storing the terminal procedure data, just like all the others that are out there now. >What my point is, is that the publishers need to agree on a>certain format (either already existing or newly designed),> that is suitable for all their needs and simple enough for>pilots to update (i.e. the SID/STARs).I think I am beginning to understand what you are after. What I am thinking and obviously correct me so that we can understand each other better, is first that you don't care where the original source data comes from. Someone out there, an agency or person gathers all the terminal procedure data and puts it into some database. Then you want someone else to get that database and convert it into another terminal procedure database. This second database is one that all developers would agreed upon to use. OK so far?Next, to further make it easier for you to use you want the second database in some format that you consider easy to read. Do I have it correct? >This way it will be a lot more efficient for all parties>(publishers and pilots) to update and maintain the data.I am not sure it would be any more efficient for the developers. They would still have to pick what data they want to use and still have to put it into a form they like for their plane. Pick data from format A or from format B, no difference to them. It's just a matter of knowing the format of the source data. But, of course, they would prefer to design their own format so they are comfortable with it and it is their own. Unmentioned is that this "standard" format procedures database has to be updated by someone or some agency every 28 days. Who would do that I wonder?I'm thinking there are some mighty big obstacles to overcome. 1. Pick someone to mediate.2. Get all developers together.3. Establish a SID/STAR/IAP format all can use while allowing for future unknown capabilities.4. Establish what source data to use and where to get it.5. Establish who will pay for getting the data and then converting it to the "standard" format.6. Establish who will maintain the data every 28 days.7. Establish some mechanism to be able to modify the standard format should that be necessary in the future.Woo hoo those are some big bumps in the road. Seems to me it would be more practicable to just have each developer print a nice manual explaining how to make their interpretation of SIDs/STARs/IAPs. Those that really want to add or modify procedures could get those manuals and go at it.RegardsTerry

[Egbert Drenth 250]

Hi Terry,We (almost) understand each other ;) You are making it/thinking a bit too complicated (or I for that matter, hehe).The idea is very simple, let me explain it with an example.When PMDG developed their Boeing 737NG series they decided to use the existing PIC767 NavData instead of designing a new NavData format/database.If all other manufacturers had done the same (i.e. using PIC767 database) I wouldn't have had to write my appeal.The underlying source is the PIC767 is DAFIF, and I think we still need such a source in the future. The datamodel of PIC767 is very simple, which makes it possible for regular users to update. (Unlike the DAFIF datamodel)DAFIF does not contains all SID/STAR, hence users must be able to add/update it and share their work on a website (like the one of Richard, or yours)Bottomline: if all manufacturers decide to adapt the PIC767 format (for example), we have the UNDF.IDEALLY however (and that is what you are referring about, is my guess) we should have only a single source (like DAFIF), which contains ALL information necessary. Unfortunately this is not the case.

[Guest jacaru]

I think i undertand the idea and i think at some point some people is getting lost.First:- We can have more than 1 source (DAFIF, etc...)- We can have more than 1 user (PMDG, LDS, ...)So we cannot not rely on the source format neither on the user format. We need a common format (for navdata & SID/STARS) so we can generate conversion routines from sources to this common format and from this common format to users format.It simplifies a lot the data managing and beleive me this is a standard solution, it is not a great idea of mine.Idependantly from the complexity of this we first need to agree that this is a standard good solution. I beleive this is what stefan does.Benefits of this:- We have all current navdata available for all addons- Including sid stars (this means a same place for navdata & SID stars)Now what it has been proposed in this thread is to encourage addon developers to use directly the common format so we dont worry on developing the routines to convert it to user format.Benefits for user:- Dont need to download 1 hundred files, saves bandwith saves space- Less hassle to make sure all airacs of all addosn are synced.- Dont need to manage SID and STAR separately from NAVDATA.Benefits for developers:- They do not have to think about a data format.- Access routines to read the data will be available = less work- They do not have to worry to maintain their navdata, can be done by a third partyBenefits for data mantainer:- Addon independant, only worry would be to convert source data to this common format.SORCE DATADAFIF is not complete so we cannot rely on DAFIF as common format. Maybe today is the most complete format but maybe in the future we find a more complete one or we can combine more than one data source.With DAFIF we get poor non US SID & STARS which sucks.COMMON FORMATIt has to be adecuate for data mantainer as he is the one to generate it from source and to provide common read routines for addon developer. XML is not slow (you have plenty options to precess it, , you just have to find a fast one), easy to hack in if needed as is readable, self documented and is extensible, so i find it a good option.COMPLEXITYYes it is complex, because we have no idea what format would be suitable for all developers and because there is a lot of data to manage. So these are to problems to solve.The idea is for the common format to be complete data independantly of the limitations of the addons and MFS. Acces routines would give third parties options to acces the data they wish, to get it the way they wish etc...When microsoft asked for FS2006 suggestions i proposed them to develop this common format as a way to improve the SDK (decouple scenery from navdata). I think it would be great also that not only addons coulb be updated with current airac, but FS too.

[Guest jacaru]

>Seems to me it>would be more practicable to just have each developer print a>nice manual explaining how to make their interpretation of>SIDs/STARs/IAPs. Those that really want to add or modify>procedures could get those manuals and go at it.>>Regards>TerryYou are wrong. If you add up the effort of each single persondoing each single procedure for each single addon it is way more. Maybe you see this as an easy task because it is what you handle every 28 days.What we have here is a big, difficult and complex project that will result in a big & great achievement on one of the big problems of virtual simulation and which main objective is make everyones life easier. Such great things as this are not supposed to be easy to handle. It can be done. It does not have to be done in 2 days. We just need people that wants to take this project with interest, ambition, no rush, some free time and having fun at it.The main concern is making developers agree on this. Having good navdata is a good selling point for an addon. Common sense tells me this is useful for them, but bussines sense tells me otherwise. What i have yet not understood is why the myriad developers working on FS are yet to agree on something when they are developing for the same platform. We only have FSUIPC & FS SDK. More yet: with all the advantage 3rd party developers take from FSUIPC, how come they do not collaborate on expanding it, etc...I just see it a bit shelfish. Instead of having to pay for FSUIPC they should jump in the wagon and help, at the end FSUIPC is much for their developments to be possible.

[ronzie 21]

One thing that should not be overlooked is that FS data files, AFCADs, etc. must match data used by all nav systems. Scenery (airport and approach/departure terrain) must match as well. AI guidance needs to match the same database used to fly the user aircraft for realistic path merging and seperation.Some apps derive their databases from the FS various databases including add-on scenery.Any navigation system needs to integrate with the FS environment and not totally stand alone for larger IFR operations.The purpose of SIDs (DPs now), STARs, is to insure an efficient common flow of traffic for sequencing by ATC. In the real world Tower Routes (TRACON overlapping routing for an entire route) is becoming common for dense areas such as the US NE corridor leaving ARTCC for controlling longer, higher flights. These of course are just FP waypoints.So if you are going to incorporate DPs and STARs, then somehow it would be appropriate for FS AI to use them as well. FS10 maybe? That way I'd get to see more traffic enroute within DP and STAR routes before I get to the final approach stages within 30 nm. Of course at 30nm. vectored aircraft by now have left the STAR routing for final landing merges as necessary.

[Guest lamont]

As it stands now I seriously doubt if MS will be incorporating the AI and ATC to effectively handle STARS/SIDS. Primarily the reason for this topic is for online flying.