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.

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

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.

(which is actually better than what some other people might interpret as “we don’t know how to handle this yet”)

hehe Chris! Or online deathmatch with CF104s

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

… 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

Yeay! I’ll go for that Chris…. KIAD vs KBWI “Fair fight now gentlemen”

Nice to see you Chris..long time no see…FT56