For my final post on airport authoring, a few comments on the sharing process and moderation process. This is where we’ve gotten the most questions about procedure, etc.
A New Website
Traditionally, airports have gone to Robin Peel – he maintains a private SQL database where submissions are tracked.
We have a developer working now on a new portal website for the global airports – the website will support upload of new airports, tracking of airports by administrators, and downloading of pre-release airports before they are brought into X-Plane.
The site provides back-end tracking for us so that we can see what has been submitted and changed, etc.
To upload data on the site you’ll need a free account – this way we will have contact information for anyone sharing airports. (Very often we want to email the author and say “could you please fix the one PAPI that is facing in the wrong direction.”)
The Ratchet
The big question is: what about quality? How will we fix problems in the shared airports, and what will the quality bar be?
My current thinking is: quality should be like a ratchet: no user submission should ever make things worse than they were before. Over time, this will allow us to continually improve the airports.
This means a few things:
- If you upload a newer version of an airport, and your work is worse than what was there before in some way, your upload will probably not be used as the new official airport version. For example, if you add buildings but accidentally delete a runway, the upload is worse and won’t be used.
- This also means that you have to include every type of data present before-hand. If the previous airport has buildings, you need to include these buildings in your version even if you are only editing ATC data. You can’t upload just one kind of data.*
- If you upload new data (E.g. new buildings) they don’t have to be perfect. We should not reject uploads because they aren’t as perfect as possible – over time we’ll ratchet up quality. Let’s walk before we run.
- On the other hand, if your upload just looks totally broken, expect it to not be used. If there are no buildings at the airport and you put a hangar on the runway itself, we can’t use it.
One reason that we want you to include all data in every upload is that it’s important to check that the data is all synchronized. If users submit apt.dat and ATC data separately, the taxi routes could be misaligned from the pavement and the authors would not see this. By having everything in your package you can see that alignment is correct between all data sources before uploading.
Moderators and Collaboration
The system is being designed to support multiple moderators; one thing that seems clear so far is that the work of keeping an eye on this data has gone way up now that we have buildings too.
If there is a conflict between two legitimate layouts, both very good but different, we have the emails of the authors – we can email both and say “you guys work out a compromise for the location”.
One final thought: I have seen a lot of postings on forums, email to me, and blog comments, all expressing concern about what to do about bad data and how to stomp it out.
I think it’s important to take a step back and not get too carried away here. The goal of the global airports is to share data, with the moderators spotting bugs. No author that I have spoken to has ever said “I really want to post bad data to your database!” The moderators will be more like editors of a book than police catching criminals.
I bring this up because I have participated in other crowd-sourced projects, some that presume the authors are innocent until proven guilty (e.g. they assume authors know what they’re doing) and some that are guilty until proven innocent (e.g. no contribution goes up without a super-thorough review).
Invariably, the more relaxed projects end up with significantly more contributions, and in the long term end up with higher quality data, driven by a larger and more motivated authoring community. By comparison, the projects that put a huge emphasis on stopping contributors from erring as a primary goal end up deterring user contributions, and end up with worse data as a whole due to a lack of man-power.
One thing Robin has done right for quite a long time with X-Plane’s airport (which might not be obvious – sometimes when you do soemthing correctly its invisible) is to not alienate contributors who have had data quality issues. I want to make sure that we preserve a positive attitude toward contributors as we grow the global airport process.
This is excellent news!
A dedicated website and softly moderated approach to putting new airports into the database is just what is needed to make this really work the way it was intended, in my opinion.
I am really looking forward to the new process, especially since it seems to be able to finally see which airports are already “improved”, so duplicate work is less likely.
Jan
Ben, will that website permit us to somehow update even the default Global scenery airports?
I mean, if I find i.e. a missing or a wrong frequency in an airport could I make the correction through the website or should I still send the correction to Robin?
Angelo
The website will be used to update ONLY the default global scenery airports – basically the website will provide automation to what Robin is doing now.
Hello
I have 2 questions for now
1. What do you plan to do with objcect libraries like opensceneryx and ruscenery and others.
2. How I will be able to upload airport which is using these libs (and not only these)?
thank you
Hi Yuri,
You _cannot_ upload airports that use third party libraries to the default scenery. The default airports _must_ be able to run without third party enhancement.
ruscenery and opensceneryx are great, but they fall into the category of building third party scenery, not scenery for the core sim package. WED already will refuse to validate a global-airport contribution that has external dependencies.
Submitting global airports is only _one_ part of the whole ecosystem of scenery, which can include default airports (no external dependencies), custom scenery enhanced with third party libraries, truly custom modeled airports, and airports that do all 3 (use x-plane’s libraries, third party libraries, and custom modeling).
WED 1.3 will have UI features to help view specific libraries in the left-side library browser – this should help manage the complexities of using third party libraries.
cheers
Ben
What is wrong with making semi-official a 3rd party free attempt to give access to more common library items?
I mean the point of opensceneryx is to be a more rich “lego” repository to make new things. Why ignore it if you don’t implement something similar?
If you son’t include it (and scenery that uses it) you are leaving out a big part of the world already done.
Personally I would love to see LR take over the project (or better, take it under its wings) and encourage it. Except if there are other (“political”) issues against that.
We are _not_ trying to muscle in and take over third party scenery development or distribution in any way! We are focusing on only _one_ part of the scenery eco-system: the default scenery that you see when you get the sim out of the box.
It’s simply outside the scope of this project to use third party libraries – they would have to become non-third-party libraries.
Ben,
In adition to manage 3rd party libs in WED 1.3, may be it would be good idea to create say a ‘common library’ and manage it in a same way as you plan to manage the airport database. This way the airport authors would decide what to put to airport scenery and what to put in a common library and thus allow others to reuse objects.
So at first you would create part on a new website where others may only upload the objects, polys, lines, etc, and then define rules how these objects may be reference in other airports… tricky enough…
As the second step to make the initial content of this library may be it would be good to meet the agreement with authors of opensceneryx and rusceneryx. As immediate adwanage of this agreement you may include a lot quality built of airports which are already made into default scenery.
Even more as I now may see it even doesn’t violate licenses which allows to use opensceneryx and ruscenery objects.
sorry for my English and misprints..
We are definitely _not_ trying to collect and share art assets, either by licensing third party content libraries or by collecting those art assets directly.
We can’t get into the business of trying to sanity check third party modeling for performance efficiency, modeling quality, etc., and we don’t want to go around telling people “no, you can’t submit your airport control tower because it has too many/too few vertices.”
Furthermore, such an approach would end up in a sea of one-off textures used for the individual art assets, which would hurt the performance of the core scenery; the default built-in lego brick airport library (and autogen) are both carefully built to re-use a small number of textures for performance.
Sounds pretty cool, sounds almost like a git repository for airports. It would be pretty cool to have WED include a fetch and commit feature built in to stream line the process.
Yep – we actually looked hard at using git for the underlying representation, but came to the conclusion that it wasn’t a good fit, since individual ICAO airports are basically fully separate silos of versioning.
In the long term we do hope to _directly_ integrate WED with upload/download from within WED. For the shorter term, an upload/download in the web page is still an improvement over everyone blasting the hell out of Robin’s email. 🙂
I’m assuming the overhead for having a separate branch for each airport is too much?
It’d be worse – a branch per ICAO per person, so that we could track a ‘latest by author X’. We also thought visualizing the merges might be pretty terrifying – admins want to look at each airport on the ICAO level. We considered one repo per ICAO as a way to ‘slice’ that way.
In the end we concluded that we weren’t going to get a ton of leverage out of GIT, but it was going to be an awkward fit. (Not that I didn’t try that fit a bunch of ways first…I went around telling everybody that we were being stupid to reinvent the wheel, until it became clear that GIT is a different wheel than we need.)
Oh, if you had to have a branch per ICAO per user that would be a big pain. One branch per ICAO would be awesome… too bad it didn’t work out.
Hopefully what you guys settled on works out well. Is it another “standard” version control system or is it something made in-house?
We settled on a straight database of meta-data storing info about the binary blobs — no VCS.
From the small size of the current upload files produced by the latest version of WED that go to Robin’s mailbox right now, it would appear that the earth.wed.xml file for each airport is not transmitted with the submission. Although one can import from apt.dat and the proper .dsf files into a new WED name and thus generate a new WED encapsulation of any available airport, as it becomes more and more complete, the resulting airport hierarchy of the structure , its groupings, and names would seem likely to be lost. Have you possibly considered the acceptance of the WED file from each submission to be filed with the Global Airport in your data base, so that further work on each airport can use the organization “earth.wed.xml” contributes to the design? Otherwise, the generation of the hierarchy from raw imported Global apt.dat and .dsf data will loose a significant part of the organization of the design already done.
Right now we are set up to take only the finished output data. I did confirm that importing the submitted airport and then re-exporting it does not produce data changes, so diffs should be clean (unless a user intentionally moves everything).
The problem with the earth.wed.xml is that it isn’t airport specific – you can easily put 5 local airports in one WED file and work that way. You might even want to edit the data in a program other than WED.
A user who has a hierarchy for an airport can always re-submit a modified airport from the original WED file.
Hi,
I might be missing something…
But, the url of the new site is….?
This one: ??
http://www.xp-lb.com
Thanks
No URL – the new site isn’t up yet. xp-lb.com is a site by a third party.
So now we get an extra source for addons in a way?
Or is it something transparent to the end user? I mean, for the end user this just means that with new official updates, the updated scenery is to be included?
Will there be a way to manage conflicting scenery ever?
For example there is xaddonmanager, which is nice (and would expect it as a user to be part of X-Plane), but there is no actual (non-manual) way to implement something like “yeah the NYC scenery you are trying to add is conflicting with newer stock scenery” (or with some other X-whatever addon).
Isn’t it time to have something like that?
In Skyrim (excuse the comparison, just to see my point), there are tools that will read all your DLC and extra 3rd party mods and will present you a specific list of conflicts not just GENERAL conflicts (“this addon with that mod”), but even specifically like “the textures of that addon with the textures of that mod” and also allow you to define what overlaps what! (plus there are nice people that even suggest what you should set to overlap what – but that is clearly a matter of the community)
Are we VERY far from something like that in X-Plane?
(except if it is already possible and I don’t know)
No. This site is _not_ an extra source of scenery. It is not a portal or distribution system for third party scenery in any way.
What the site does do is make the existing infrastructure to manage default built-in airports (which we have had for years, via Robin) more accessible to contributors.
Users who just want the latest scenery do not have to use the site at all – we will load the latest official versions of all default airports into the sim in sim updates.
Re: conflicts and priority management, the existing config files make it possible to write such an add-on manager now – the file formats are all public. We’re not that close to having one built into X-Plane; I do think we can fix some very basic use cases (e.g. ensuring that our global airports are low priority) before we get a more powerful tool.
Authors need to correctly put exclusion zones in their third party sceneries; without this, no tool can fix conflicts.
Hi,Ben!
I will tell you as an artist to the artist. Add a bricks to default library. I mean digits and letters for marking taxiways and aprons.
Will Robin Peel be one of the moderators in this new system ?
Daniel
Yes, I think so!
Hi Ben,
I was wondering if there is a rule of thumb regarding the “tuning” of the number of airport objects for the different detail settings, in other words:
.What should be the ratios of objects number for max (“extreme”) vs min (“default”) settings? 10:1? 100:1? 500:1?
.Do you advice a fixed ratio (e.g. 10-20-40-80-160-320), or a fixed amount of added objects (e.g. 10-70-130-190-250-310) between consecutive detail settings?
We don’t have any such rule now. I would say this: at minimal object settings, include only objects that are necessary for operations.
Do you intend to expand the set of default scenery objects at all?
I’m currently flitting around northern South America replacing taxyways in WED, in the kind of airport which can operate 737s but only one at a time. For instance, the terminal at SKCO: http://commons.wikimedia.org/wiki/File:La_Florida.JPG
Looking through the default scenery objects, it seems the focus is for much larger airports. There’s several huge control towers, but no small 3-storey ones. More shocking- there appear to be no air-stairs?? Plenty of choices of jetways, but no truck with steps. Possibly the most ubiquitous ramp vehicle! I mention these two just as examples – will you be dragging Tom away from the MU-2 again to make some more stock assets some time 😉
Kind of related, is there a way to separate an object from an .agp? I’m often finding a useful asset locked away inside a scene I can’t use. For instance the vintage hangar_tower.agp – at SKCO I’d like to use just the tower but ditch the hangar and paving. If there isn’t a way to do this while remaining a viable candidate for the global scenery database, perhaps you could consider aiming to make the constituent .objs available along with the .agps? As it is, I used the hangar-tower.agp as a substitute for the terminal building but the character isn’t quite the same.
This is a really awesome direction that you’re going with the scenery. It’s fun and quite cathartic to drag taxyway bezier curves around!
Hi Dozer,
A few things:
1. We _do_ intend to extend the airport library. We think we can get more detail and variety around the existing texture set!
2. The goal of the library is to provide nice looking art assets, reasonable plausible approximations of the real world, but NOT to exactly reproduce every airport in every detail or replace custom scenery. So there is a limit to how much extensions will affect the library.
So with that in mind, if there are classes of architecture that are totally missing, or ramp equipment that is missing, please file a bug – include a link to a pic of the real thing. The cases you’ve brought up sound valid…I just don’t want people emailing going “you have a brick tower with 3 floors, one staircase, and dark tan masonry, but I need two staircases and light tan masonry.”
Second, re: AGP vs OBJ, please file a bug indicating the OBJs that you want ‘released’. The default setup is to assume that the AGP cannot be ‘stripped for parts’ – in some case we can be less conservative and release the OBJS, in others the OBJs don’t make sense on their own. I want to avoid the case of ‘release everything now’ because we need to not rename/change those OBJs that are publicly in the library or we’ll break people’s airports. Hence the need for some caution and examination.
Cheers
Ben
Ben,
Does that mean we could have acces to the XML wed file from older contributors ?
That would make sens to re-use the grouping, etc… from previous contributors…
Cheers
It is not our plan to share the XML at this time.
Marginal’s Overlay Editor allows for editing road networks. Is it possible to submit a custom airport to the global database with a modified road network, or will you only accept changes that are possible to do with WED?
We can accept airports from OE if you can get them into the format we need.
But we are _not_ accepting road network edits. There is not a sane way to do this for overlay airports right now.