I do agree that orthophoto-based scenery would not be scenery that you share as part of collective work to improve the global scenery – it might require too much hardware, or too much storage, to be part of the global scenery.

BUT…you still have the same question: do you build the new DSF from source data + orthos, or the old DSF + orthos.

Now you CAN (today) make new DSFs out of old ones using PhotoSceneryX. I won’t be providing this tool not only because it is not my preferred approach, but because Justin has already done it!!

But you can also make that new DSF using source data (coastlines, DEM, land use, photo placements).

I prefer this technique because:
– It lets you correct elevation as well as photo placement…DEMs are easy to get with SRTM around, and editing them is pretty straight forward as well.

– You don’t pick up accumulated error from importing and rebuilding the finished DSF.

– The mesh will be allocated more efficiently if it is rebuilt with orthophoto placements, rather than simply having additional cuts burned in to place the photos.

Basically if you ONLY want to repaint orthophotos, then editing the DSF might make snese – but this technique isn’t “scalable” – as soon as you want to edit the DEM, change coastlines, etc., rebuilding from source makes more sense.

We provide our land use data now to make MeshTool a workable options…DEMs and coastlines are up to you. (DEMs are easy to get…coastlines are a bit tricky…I hope to add shape-file coastlines to MeshTool someday so that you can use SWBD as a coastline source.)

Final note: the reason I say the mesh is “less efficient” is this…our mesh algorithm places more vertices in places where there is more mesh detail — that is, lots of vertices on mountains and vey few on a flat valley. If you provide a NEW DEM and simply edit the existing DSF, because you are not reallocating the vertices, vertices might not be used in the most “interesting” places, resulting in less accuracy for a given triangle count.

My issue is that the edits are being made to a lossy derived data format and not the original source!

To use a coding example:

Users submitting the DSF edits would be the equivalent of users submitting their patches to Linux in ASSEMBLY LANGUAGE and not C.

It would be much harder to merge those patches because the “context” of the patch (assembly) would not be stable due to edits to the original source.

From a google documents perspective, it’s as if you make an edit, but while you did, I converted the entire thing to French! Context – gone!

The fundamental problem is that the final cooked data (DSF) appears to change radically in a way that isn’t easily predictable from mods to the sources. This is what invalidates DSF-level patches.

So the issue here isn’t one of merging, it is one of de-compiling.

(And lest I get myself into even more trouble, yes, it IS possible to derive the original data back from the DSF – we could attempt to isolate the road mesh, the DEM, etc. But do we really want to do this? DSF is a LOSSY format? The result would be an increase in error bounds in the data every time we took a patch.)

If we were doing image editing, would we want our patches submitted as edits to the original layers in a photoshop document, or edits to a 50 KB JPEG that was optimized for the web?

or u might take a look to google docs. they do it too. but i understand that this is not something that can be implemented over the weekend. ..and its not really necessary for xplan these days.

im looking forward to the way the scenery data will be shared and what kind of version-control (& sign-in sign-out) u implement.

if that is done right the sim could benefit alot.

i still dream about a joint-venture with the google earth team since both programms work on the same thing and redundancy in such case is always wasted effort.

http://xplanescenery.blogspot.com/2007/01/airport-flattening-untold-story.html

Looking forward to the time we’ll be able to do corrections to base DSF.
Both corecting bad sampling errors, and making “runway follows land countours” option –which I love, but had to give up on– usable depend on this.

Would you be kind enough to give an explanation of why the airport flattening causes weird water cliffs/hills when the airport is close to shore?

Those bad water artifacts do not occur with “runway follows land countours” on, but it has its own problems like very steep taxiways, and converted scenery objects sinking/floating.

“Hi Ben,
Would it be possible to establish some kind of centralised database which stored only corrections (contributed by X-Plane users) to default X-Plane scenery (base mesh, objects and landclass info)?
In this way Laminal R would secure that full X-Plane installation is required and maybe limit the amount of data to store and transfer. X-Plane users could easily download (on their request) corrections from the database with a tool similar to X-Plane installer which merged local DSF with downloaded patches.
Since database supervising and solving problems with the conflicting data would require a lot of men-hours the database would be run rather by community (like x-plane.org) instead of Laminal R. I am sure that people can do amazing things if you provide them tools capable of doing this…
Would it be feasible? Rob”

Rob, I’m sorry I had to move your comment – I’m not sure which post you were trying to post to – I accidentally dumped a blank post up last night.

Anyway, the answer is basically: no. Please see today’s post. We can’t work with “diffs” to DSFs, we need to work with the source data – otherwise all the fixes will be lost on a regular basis.

We need to track changes to the SOURCE materials.