Why We Must Edit the Source Data

My previous post on scenery tools stirred up some discussion; y-man brought up a point fundamental enough that I think it warrants explanation.

The questions is whether to fix broken DSFs by editing the source data or the DSFs themselves.

Let me be clear: both are viable options, both have limitations, and neither are possible today. So in choosing one over the other, I am picking a strategy that I think is superior, and discounting the other not because I think it is useless, but because it is less useful and development time is very limited (doing both would take away from other good features).

Basically the two ways to fix a DSF are:

1. Edit the DSF itself until it looks correct.
2. Edit the source data and then rebuild the DSF from scratch.

I strongly believe we must pursue the second strategy for this simple reason: if we correct a DSF but don't fix the source data, the same mistakes will be made in the future.

We have to keep recutting the global scenery to keep up with:

• Higher capacities for detail in newer computers.
• New global data that becomes available.
• Improved generation algorithms that makes better results from existing data.

To lose any of these would be a big set-back in scenery quality, so not recutting DSFs isn't a great option. (Furthermore, improvements in scenery often come from new global data, so picking user changes over new data would be a tough choice.)

By letting users change the source data, we can have the best of both worlds: problems are fixed while new technology is adopted.

To answer y-man's direct questions:

But that data is not available to us users is it? If it is, where is it, and where is the spec to work with it?

It is not available yet! I am proposing to focus on making the data available and creating the infrastructure to share data and receive improvements (choice 2) rather than providing a DSF mesh editor (choice 1).

Alternatively, a user who goes thru the trouble of correcting base DSF could send in the modified DSF, or may be even a diff between before and after states of DSF text files, and attach an explanation of purpose.

Here's the problem: we can't preserve the diff to the DSF and apply it to future renderings.

Imagine, or example, that you relocate 500 mesh vertices from the existing DSFs to correct a coastline. (I am being generous here and assuming a clear, single, unifying edit. But some authors would more likely move the vertices to make a number of improvements.)

In the meantime, another author creates an airport nearby, and someone else improves the SRTMs (there is at least one person attributed in our about box who has been collecting void-filled SRTM tiles). The effect of the nearby airport's pavement changing size and the raw elevation changing height is to change greatly how the mesh is generated, such that 400 of the 500 vertices that were moved simply no longer exist, and 450 new vertices are in the nearby area now that were not in the original DSF.

This case is known as a "merge conflict" in computer programming terms (and happens when two changes to a program are "merged"). The problem is that we can't sanely know what to do with our 500 edited vertices in this case. Do we take the 100 vertices that still exist and move them without the others? What if that produces very strange results? (Triangles might become inside-out because some vertices are moved a lot but their neighbors are not because they did not match the diff.)

We could try to apply some kind of change to the new vertices similar to what happened to the old, but how do we know if this is making things better or worse? What if that change simply deforms the outline of the airport that was added?

I can go on and on with these kinds of examples, but the point is this: you can't unbake a cake. A DSF is similar; you can't necessarily recover the sources that were processed together to form the final product.

This is why it's important that we create infrastructure to correct source data, rather than focus on editing the final DSFs. I can assure you that my negative attitude toward editing DSFs is not a negative attitude toward user participation!

There are still a lot of details to be worked out about how we can work together. Who will own the data, and on what terms? How will it be distributed? How will it be shared?

Unfortunately I can't answer those questions yet. I still need to do more research into what is technologically possible - then we can figure out how to proceed.