The Future of WED

WED 1.0 has gone RC. The only change from beta 5 is that I have the latest manual changes from Tom (including Cormac's illustrations of taxiway signs). Both of them did some great work - the WED manual is a lot nicer than the docs I have done myself for the other tools.

A while ago I posted a tools update...has anything changed? Not a whole lot.

• WED is definitely the future of the "heavy" scenery tools (ones with extensive UI) - it has a lot of infrastructure for features like multiple undo, multiple selection, hiearchial editing, etc.
  
• The next big feature for WED will be some kind of overlay editing. I don't think this will happen very soon though - my todo list is pretty out of control.
• In the long term, I think WED may provide a visual way to do MeshTool-like operations. In other words, you'll be able to build a base mesh in WED by specifying polygons for airports, applying orthophotos, and importing one big DEM per tile.
• I don't think that WED will ever be a DSF editor - that is, you won't be able to open an existing DSF, move a single node, and re-save it. This just isn't high on my priority list.

To this last point, how are you supposed to fix scenery if you can't edit DSFs? Well, I'll try to post more on that over the next few weeks, but the short answer is that we need structured edits to source data.

A DSF is a compiled result of a very complex set of processes. The vertex that you adjust in the mesh to fix a mountain top may not exist in the DSF if another user submits an updated airport layout, even if they are fifty kilometers apart. (All parts of the DSF affect each other through the adaptive irregular mesh.) So I don't want to take user submitted corrections to the final DSF because those changes would be lost at the next render.

We've been down this road before - when the V6 global scenery was done, the plan was: now we'll take user-edited ENVs. The problem was that this plan assumed that we'd never re-render the ENVs again, which proved totally wrong - we re-rendered them at the end of the v6 run with improved algorithms.

What we need to do is identify what components of the source data are reasonable candidates for user editing, and set up processes (similar to Robin's collection of apt.dat data) to gather data and share it.

(We are looking at OSM - it is still under investigation!)