You make some good points here, and I think you are right that the issues with “integration effects” do NOT prohibit the editing of existing DSFs…the point I am trying to make is only that it is more tedious (relative to editing the source data) because a large number of small elements must be manually correlated (or I must rewrite into the tool some “reintegration” code).

Regarding the airport areas: two thoughts:
– You are right that draped polygons did not exist in v8.0, heck they didn’t exist until version 850. They also depend on the asynchronous threaded build-up of 3-d scenery, something that is much more viable now that dualcore chips have become the rage.

– Even if we did use overlays for all airport areas, the most important effect of the airport creation and prep code is not just that it changes the texture, but that it changes the mesh (flattening it) in a manner that is much more sophisticated than x-plane can do, and this flattening has an effect on the shape of the triangles (generally making them bigger) that helps the overlay polygon code run efficiently.

So I think we must do a lot of preprocessing to airports even if we use .pol files for the surface areas…given this and the general tendency of airports not to move after they’re built, I suspect we’ll continue with the existing strategy and continue to bake airports into the terrrain in the next major render.

Remember that .pols are always overlays – thereh as to be something under them. I don’t see any harm in that thing being airport grass. 🙂

—–
* If you moved an airport, the airport grass would stay in its own location.

This editing feature would seem to be the toughest to implement properly due to the terrain mesh needing re-textured. When I first encountered this, I was actually quite surprised that the decision was made to hard code the airport grassy areas into the DSF terrain mesh. The later developed draped polygon feature with a seperate polygonal boundry for a flattening code would have been a much better option though I realize that it was not available at the time. It would be nice to see this changed in the next round (ie v9). That said, the majority of the large airports are fine in this regard. Albeit, there are smaller airports that are drastically wrong. I think most people can live with a bit of extra grass here and there.

—–
* If you moved an airport over a road, the road would still be there.

The ability to create, delete, edit and move roads is really a must have option. Any thoughts of not having this feature is not viable. Therefore, if an author did move an airport, he would be able to see this conflict and move/delete the road. This makes this somewhat of a non-issue.

—–
* If you changed a city street to a highway, it would not form an overpass.

This is where the road editing feature as well as most other features would really gain from a proofing code that checks for these things in the areas that have been edited. But as with the airport, the scenery creator should be able to easily edit the road.

—–
* If you moved a road on top of a generated building, the building would remain in place.

Same as above with the exception that proofing code to check if a building is placed on a road would be a nice option.

—-
* If you changed the ground elevation, buildings would not change their orientation to face the new slope.

As above, the scenery creator should be able to create/delete/move buildings with WED. This, like road editing, is also a must have in reality.

—–

It seems that the tack that is being taken is to steer scenery creators toward scratch built DSFs. I can understand if this is the case. Editing full DSF’s is a royal PITA due to the amount of data involved. For the most part, the Global Scenery terrain is great and just needs touching up (ie move/change/add/delete a building/road here or there). If editing requires a scratch build, a lot of potential users are going to be put off from creating scenery as it will just take far too much time for them.

Regards,
Voynik

– Cormac

Andras Fabian / alpilotx