Talk:Airport data (apt.dat) update: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
No edit summary
Line 13: Line 13:
:::: 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...
:::: 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...
:::: [[User:Gijs|Gijs]] 11:45, 28 February 2013 (UTC)
:::: [[User:Gijs|Gijs]] 11:45, 28 February 2013 (UTC)
::::: I understand your points, GiJs. But the idea of (officially) releasing *up-to-date* apt.dat data means:
::::: 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.
:::::* 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 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 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.
:::::* Offering *anyone* to pull *any* version of the data, not just the latest one.
Line 26: Line 27:
:::::  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...
:::::  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"
:::::* "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.
:::::  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
:::::  Conversions can simply be made by awk, sql, etc. there are large tools available and this is not an issue yet.
:::::  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.
:::::So. - Having the ability of bringing apt.dat to the next generation or remaining dependent to one single, unresponsive maintainer... Make a wise joice.
:::::[[User:Mcantsin|Mcantsin]] 12:44, 28 February 2013 (UTC)
:::::[[User:Mcantsin|Mcantsin]] 12:44, 28 February 2013 (UTC)
:::::P.S. I don't say that it has to be [http://github.com/mcantsin/x-plane-navdata/wiki 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.
:::::P.S. I don't say that it has to be [http://github.com/mcantsin/x-plane-navdata/wiki 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.

Revision as of 13:00, 28 February 2013

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.