Jump to content

Sign in to follow this  
Guest lamont

Appeal to aircraft manufacturers : UNDF

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Guest

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.

Share this post


Link to post
Share on other sites
Guest mruane

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.

Share this post


Link to post
Share on other sites

>...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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Guest stang

>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

Share this post


Link to post
Share on other sites
Guest stang

>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

Share this post


Link to post
Share on other sites
Guest NAVData

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

Share this post


Link to post
Share on other sites

>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.

Share this post


Link to post
Share on other sites
Guest NAVData

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

Share this post


Link to post
Share on other sites

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...

Share this post


Link to post
Share on other sites
Guest lamont

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.

Share this post


Link to post
Share on other sites
Guest stang

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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...