A quick note on an issue that apparently came up during the X-Plane Town Hall (I have not had a chance to listen to any recording or read a transcript; Austin just pinged meo n this):
What if two people submit library buildings for the same airport?
We actually already have to cope with this since we already crowd-source taxiway layouts.
My view is: we’ll put infrastructure in place when the problem occurs; there are a lot of of ways to cope with collisions of contribution, and the problem has been solved in many cases already. So I want to wait and see what kind of collisions occur and then pick the best method (whether technological or organizational) to deal with them.
Robin already tracks who submitted data, so we have the basis to identify when there has been a change or a possible collision.
This is an interesting subject.
For basic nav-aid data, there is very little subjectivity in determining accuracy. If the lat/lon is correct (within the sim’s accuracy limitations) and the name and frequency are also correct, then we can say with some certainty that the data is “good”. (Of course, for some global locations it is hard to find authoritative source data for the ‘correctness’ of some of this nav-aid information – but that’s a separate issue.)
For airport runways, there is still very little subjectivity. But the taxiway layouts are much more subjective and open to interpretation. How much detail to include? How many Bezier CPs to include? Include taxiway shoulders? It’s almost a fractal-like issue – you can add as much detail as you wish … but is it accurate? Will the detail drag down the sim’s performance on ‘average’ hardware? How do you keep it up-to-date?
The AI taxi routes are even more subjective. They cannot include every possibility.
For the new library buildings, it is also very subjective. Creativity skills in using the stock art assets will vary. Users’ definition of ‘plausible’ or ‘accurate’ will also vary. It will also be hard for the arbiters of this work (Ben, me, …) to determine its legitimacy – it’s easy to zoom in on Google Earth to review an airport’s taxiways but harder and *much* more time consuming to review its structures and other features in #3D.
But I am looking forward to receiving this new content in our data. There will be a steep learning curve.
– Robin
Seems that some sort of voting system would be best, not sure how you would implement it…maybe some sort of automated screenshot generator and a web-based ranking system? Even then, ranking new, better submissions against older ones is difficult, unless you do random “which one looks better?” against A/B of the same airport.
Will there be a central tracking system so people know what’s being done, what’s finished and what nobody has started yet? It seems like a waste to have the people actually willing to do the work repeating the work of others.
I was the one who asked the question at the town hall. My concern was this: Say that I am not an artistic type or have any modeling skills, but I think I have a knack for doing the AI taxiways/flows. I research, create and submit a highly accurate AI package. Then along comes someone with the opposite skillsets who submits a nice graphical package but a “barely there” AI package. How does that get reconciled? I think Robin has it right…it is going to be steep uphill slog.
I don’t think this is so hard. Robin could send you guys both an email saying “you both submitting X, please work together to merge your work.” You can then import both into WED, cut out the data to make a composite, and submit it.
… which is what happens now. It’s weird, but every so often I seem to get parallel efforts on a specific airport. Often I am not familiar with the location, so I invite the protagonists to work together. It’s always always a positive outcome!
– Robin
The number one issue is that we can’t have an average built scenery (that looks like a circus, many people think that filling in Airports with simply everything they can is good taste) replacing an extremely well done one, some how the creme has to rise to the top.
Voting could help like Brian mentioned, but what of the case where someone improves on the original, yes that could overwrite the older file.
There is the idea that someone could book an airport to work on it, in other words you put your name down for an Airport and you are given the Airport to work on, when finished it will be uploaded for us to vote on (either better or worse than the original), if it gets the tick then it goes up, then someone else can book that airport and do their work on that same file…
This is a good system because there will be only one file instead of 20 KJFK’s coming in at the same time, It mean that the most files presented is only two, the original and the updated for choice.
FT56
I would say absolutely NO to an exclusivity system! Such a system discourages competition from the very beginning. If I work on JFK and Simon also works on JFK completely separate from me, and if my version isn’t up to snuff as Simon’s then that’s my problem — but Simon shouldn’t have exclusive rights to work on an airport. That’s just not fair to everyone else.
A better approach would be to see a list of what has already been committed to the database, comments about what has changed, and to be able to see the status of just your submission (whether it’s been accepted or rejected).
Seeing the status of other people’s un-committed submissions is NOT important as it may falsely discourage another person from submitting similar work (which may be better).
This is the submission model that many open collaborative projects use (such as OSM), so why should it be different for x-plane’s airport scenery submission?
Yes, a simple DB of who’s working on what, would help everyone avoid the double ups, or get ppl TALKING or WORKING TOGETHER (eg ‘you do this half, I’ll do that bit’). It might even speed up some airports if ppl work together in that way.
Ben or Robin, our blog would be happy to host a simple Google docs listing of apts in progress to assist this approach. If you think it’s the way you want to go.
I did have a thread at the .org for this very purpose. It worked OK … but there were some designers who ‘claimed’ an airport and then never delivered anything. That’s OK – sometimes our priorities change. Whatever mechanism we implement can be very simple for all to use!
– Robin
I vote for a cage-match…winner takes all!
Yeay! I’ll go for that Chris…. KIAD vs KBWI “Fair fight now gentlemen”
Nice to see you Chris..long time no see…FT56
hehe Chris! Or online deathmatch with CF104s
Sooo… the official reply right now on this issue (which you say has already occurred on occasion), is that you don’t give an official reply?
(which is actually better than what some other people might interpret as “we don’t know how to handle this yet”)
No. The official apply is: we are not going to make a decision until the data is in. We’ll solve the real problem when it really exists, rather than proposing a speculative solution based on what _might_ go wrong.
I suffered colisions with apts I submitted to Robin a few times.
One problem I observed was that some people do not necessarily work on the latest official release, but they gather a large collection of customized data and don’t keep syncronized with the current official database. They may commit their changes to this customized dataset bypassing possible enhancements already present in the latest official revisions.
These type of collisions where someone commits data based on a deprecated dataset could be easily detected if dataset versions where tracked some way, and people where allowed to commit only those changes based on the latest version. This is standard practice in revision control systems used for software development (svn, git, etc), where you are forced to update and resolve conflicts yourself before committing.
The apt stanzas are pure text, so having a revision control approach through source code management systems should be very feasible. It would promote incremental updates, so artistically less-inclined people (like me) could plop down boundaries and maybe some basic buildings, e.g., from OSM tiles. Later on, people with more time, better data or just plain more skill could easily find those places and do more fine work. It would also enable easy access to specific up-to-date data between “proper” apt.dat releases.
The most important thing early on is, IMO, to get a lot of boundaries straight and see how much terrain flattening is needed. To that end, even the dirtiest solution for conflict resolution should be rather good.