Talk:Airport data (apt.dat) update

Independent apt.dat source

I would like to suggest to use an independent, community based source for apt.dat data, such as this project on github. Mcantsin 01:57, 28 February 2013 (UTC)

Then maybe you can explain what is not independent and community based on Robin's data? It's GPL and a new release is around the corner. --Papillon81 11:09, 28 February 2013 (UTC)

If you read the description you will learn why. Mcantsin 11:23, 28 February 2013 (UTC)

Hi Luther,

Your GitHub is also maintained by a single maintainer (you), right? So how's that different, other than being a Git repository?

The idea in itself is interesting, but I see lots of issues, just to name a few:

• How would you deal with merging back changes that are made to the official data?
• Do changes made in your repository get merged in Robin's?
• What if your and Robin's data conflict; who is "right"?
• What if a new apt.dat format is designed, how will you be able to convert the data to that new format?

When I can choose between two sources of data: one having all kind of infrastructure in place to ensure easy maintenance and dozens of contributors, and one with no infrastructure and just a single commiter, I'd choose for the first option...

Gijs 11:45, 28 February 2013 (UTC)

I understand your points, GiJs. But the idea of (officially) releasing *up-to-date* apt.dat data through git(hub) means:

• Having the ability of keeping track (publicly visible) of the changed data through version control.
• Offering the possibility to a group of multiple people to publish "releases", which can be argued and officially announced. (e.g. official "master" tree).
• Offering *anyone* to pull, change and publish his own tree.
• Offering to *anyone* to contribute to the source data directly withouth obstacles.
• Offering *anyone* to pull *any* version of the data, not just the latest one.
• Disposing of the fact that Robin is unresponsive to data correction submissions. (I have waited 11 months to receive a cheap answer to my e-mail to Robin, saying that he is too busy...)

Regarding your questions:

• Who would maintain the "official" master tree

I would be most happy to let the FG dev team name and appoint the individuals forming some sort of "official data" group. - They would be the ones drafting rules for data submissions (format, procedure etc.) in the first place.

• Robin's data

Frankly spoken I don't care about Robin's data any longer, as it is largely out of data and out of accuracy. I wrote my own awk shell script, which converts my navigraph data into apt.dat and that does a wonderful job for my personal use. I don't pull Robin's data any longer...

• "Conflict"

There would not be a "conflict", as Robin's data simply is not accurate any longer and in case of a "official fg data release group" a possible conflict could be argued, then discussed and decided. - Not by one single person that only has a focus on local airports and nav data, but by an international community. And in case of conflict the real life data can simply be adapted. (There are many real life ATC's and Pilots who would deliver this most accurate data to be used in case of a conflict.)

• Conversions

Conversions can simply be made using GNU awk, sql, etc. there are large tools available and this is not an issue yet.

So. - Having the ability of bringing apt.dat to the next generation or remaining dependent to one single, unresponsive maintainer... Make a wise joice.

Mcantsin 12:44, 28 February 2013 (UTC)

P.S. I don't say that it has to be this particular project. What I offer is just a suggestion of thinking about the benefit of using git for maintaining up-to-date and accurate data.

I have to agree with Mcantsin about submissions to Robin: he doesn't acknowledge them nor include those from others,despite his heading. I submitted several Canadian suggestions which I (naively) expected to see in the 2.10 release of FG's nav.dat and fix.dat, but they were not to be found. They were submitted well in advance, so lateness shouldn't be an excuse for them not to be there. As to conflicting about accuracy, most of what I'm finding are misplaced navaids, or those which have not yet made it into the list. As with anything in the scenery, I think an argument about who is 'right' or more accurate would be as senseless as some other arguments I see on FG. I have corrected several NDB poistions, and fixes, which led me off track on a final approach to runway, and after my corrections, that no longer happened, as I test my corrections before submitting them. I would trust that anyone who is submitting corrections or new navaids would at least fly them to ensure they're where they're supposed to be in relation to the function for which they placed there in the first place. I support this effort, as I"m tired of being disappointed with each new release and the same old errors and omissions in navaids and fixes are still there. I would like to encourage the devs to access this database, combine our efforts with those of Robin, allowing us, in some small way, to contribute to the project and generally make flying more enjoyable for everyone. "Never put all your eggs in one basket," might seem to be a good analogy here; if we're going to stubbornly stick to one source (Robin's) I believe we're doing a disservice to the project, and those who use it. Trennor 04:45, 2 April 2013 (UTC)

Ahem, flightgear is still using the old 8.10 apt.dat format file, thus the outdated data. That does not mean a change in the way apt.dat source is maintained and updated is not a good idea. --Aep 11:40, 2 April 2013 (UTC)

To complement what's said by Aep, FlightGear is currently using the .dat files from a long time ago. Simply because FlightGear does/did not support the new format that X-Plane (and Robin) have moved to. Luckily we're catching up fast and scenery with the new format will probably be available this summer. In order to have matching navigational data and scenery, it is important that we update both at the same time (which is why we cannot just update the nav data right now).

I've spoken to several FlightGear people who sent changes to Robin and all of them were included in the latest files from http://data.x-plane.com Please check those files to see if your changes are in (make sure you download "Latest data"). It's not fair to blame Robin for something he has no control over.

Needless to say that we cannot "combine our efforts" maintaining two independent databases.

Gijs 16:16, 2 April 2013 (UTC)

Well. I hereby would like to express my deepest sympathy and condolences for Robin's feelings. - But let's focus on how to frame the publishing of accurate and up-to-date navigation data for that flightsimulators can be used for training of (real life) pilots and ATC's.

So I kindly & heartily invite you to discuss and draft a **true** GPL based navigation data source. Mcantsin 18:35, 2 April 2013 (UTC)

I want to see an example of outdated or inaccurate nav data in Robin's database, not what we ship with flightgear. Changing datasources is NOT going to happen (at least in the short term) - It's taken a team of 3 people over 2 years now to update the scenery generation tools to use the x-plane 8.50 - 10.00 formats. We should have the results finalized by summer. Remember - the data involved contains all of the airport (runways, taxiways, towers, parking positions, etc) as well as nav data. If you have nav data that doesn't contain the layout of the airport, guess what - your ILS landings will take you into the grass, not the runway. </end rant> --Psadro gm 19:57, 2 April 2013 (UTC)

Navigraph today announced X-Plane support in the upcoming AIRAC1406! \o/ Mcantsin (talk) 18:27, 12 May 2014 (UTC)