Mapserver

This article is a stub. You can help the wiki by expanding it.

mapserver screenshot

First announced in April 2006 , the Landcover DB (database) was a web service/server that used to provide GIS data (mainly shapefiles and elevation data) via a PostgreSQL/PostGIS database behind the MapServer and Scenemodels websites for use by FlightGear-related tools like TerraGear and TerraGear GUI to help provide data for creating scenery tiles for FlightGear.

The primary intention of the Scenemodels repository is and has ever been from it's initial start to have a common repository which is collaboratively filled with the best scenery models we have for the entire world and which are 'compatible' with the GPL.

Before Martin Spott started the "Landcover-DB"-project we were having an ongoing dispute about wether the underlying land cover data or some "tweaking the data"-techniques in the TerraGear toolchain had been responsible for certain "unexpected effects" in FlightGear's Scenery.

Finally, to resolve this issue, Martin stuffed all our land cover data into a PostGIS database, put a MapServer as a frontend so everyone could have a look at what's been the actual input to our Scenery processing

For the time being, the service has been discontinued (i.e. is no longer operational , and the underlying data are unavailable )

The data now missing represents man-months of research and tests in GIS land, building and testing tools, building and maintaining the database, shaping all the data into its current form and loading it into the DB, researching and testing how to build detailed airport layouts with TerraGear, the same with OSM roads, ensuring a certain quality level for the land cover data as well as for the Scenemodels repository

Various more or less complete attempts at re-creating this infrastructure have been discussed/attempted meanwhile

In addition, several contributors have discussed providing osgEarth-based scenery at least as a temporary workaround while the disturbances caused by the mapserver's disappearance are sorted out.

FlightGear core developer Torsten has since begun exploring alternatives, i.e. starting over with a fresh landcover database , including a BOINC-based approach (see also elgaton's ongoing status updates in the archives )- as well as creating surrounding infrastructure/tools like TerraFS .

Status

(last updated in 04/2016)

Because of Torsten's work, we will be able to keep up the current service of maintaining a scenemodels database and regular updates to the distributed scenery. We will freeze the terrain at its current state to improve the way we handle it today.

Currently almost all of our scenery is maintained in a database and the resulting files are automatically generated. We try hard to avoid incompatible chunks of scenery that don't match at their corners. Martin Spott has alway tried to encourage people to maintain data upstream and we would like follow this path.

The vision is having a solid tool chain generating a world scenery from a detailed and common database.

Lets avoid gaps, elevation steps, overlapping and incompatible scenery tiles and work together on a one-fits-all scenery.

Until we have that, the suggestion is this: Somebody provides self-contained and tested chunks of Terrain to be merged into Terrasync. That "somebody" is responsible for the usability of that terrain chunk. By "provide" I mean:

• make it available by rsync, tarball or anything else to be fetched, unpacked into terrasync without human interaction.
• Work out a method to discover new or outdated chunks
• Work out a method how to tell scenemodels-db which objects need new elevations
• Somehow "sign" the chunk so we have somebody who gurantees GPL compatibility
• Work out a method how to avoid mutual exclusive changes (one person updating EDFE, another improving EDDF [both share a tile])

Not everything need to be ready in detail but I'd like at least have an idea how this should work.

What will not be accepted is: Follow some dropbox / gg-drive links, unpack an archive, guess what it might be, remove all side effects, do some hours of test flying, resetting object elevations by guessing the area etc. etc.

And always remember - at one day we will have Martin's landcover db back and hopefully a working toolchain. Whenever that happens, we build a new "world scenery". What happens to all those manual updates? I fear they are lost.

History

Originally, Martin Spott and Ralf Gerlich's work was concentrated on making more and different datasources accessible for scenery creation.

Martin was doing a pretty good job in aggregating a huge set of datasources in the common landcover database (see http://mapserver.flightgear.org/ for a quick look at the data already available) in cooperation with the OSGeo foundation.

They also wanted to make use of freely available raster data, such as Landsat ETM+, for automatic classification of landcover and conversion to vector data which can then be used to replace the low-accuracy VMAP0 data at least partially both in terms of space and content (e.g. we won't be able to extract streets from 28.5m- resp. 14.25m-resolution Landsat bands).

You can still see some results of their original experiments in the landsat_* layers at the above-mentioned mapserver URL and a bit more detailed look at the process at http://custom-scenery.org/Satellite-Image.304.0.html

Whereas CORINE and quite likely all the other datasets, which have mostly been aquired from remote sensing, just contain the coverage you can see from above, VMap is significantly different in it's structure. CORINE shows just the vegetation, let's say evergreen forest _or_ the bare soil, where _no_ vegetation is present. VMap instead may feature the forest _and_ the soil, on which the forest grows, in the same place. Even in really big areas, not just in small, accidential snippets. Thus, in order to transform VMap0 into a topology of the CORINE style, you have to cut feature A out of B and store the remains of B as M. Then add A plus M as, let's say, X, cut X out of C and store the remains of C as N, add X and N into Y, .... and so on. That's rather time consuming, even in GRASS. Unfortunately there's no reliable progress meter. Well, there is one, but in certain cases it rises up to 98 % in just two hours and remains there for an undetermined period. Thus you never know wether your job is going to take just a few days, a few weeks or a few months. I don't like jobs running several months. I had a few of these but the most promising ones were killed when the machine had to be rebooted due to a planned power outage - or an unplanned power outage - or some other reason. Therefore I've recently been trying to re-run the VMap0 cleaning using a slightly different approach. After VMap0 has proven to be really clean, the next step would be to either cut the CLC06 coverage out of CLC00 and then cut the result out of VMap0, or first cut CLC00 out of VMap0 and later replace CLC00 by CLC06 where available.