Mapserver

From FlightGear wiki
Revision as of 21:06, 10 April 2016 by Hooray (talk | contribs)
Jump to navigation Jump to search
This article is a stub. You can help the wiki by expanding it.


First announced in April 2006 [1], 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 [2] for use by FlightGear-related tools like TerraGear and TerraGear GUI to help create scenery tiles for FlightGear.

For the time being, the service has been discontinued [3] [4] (i.e. is no longer operational [5] [6] [7], and the underlying data are unavailable [8])

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

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.[10]

FlightGear core developer Torsten has since begun exploring alternatives, i.e. starting over with a fresh landcover database [11], including a BOINC-based approach [12] - as well as creating surrounding infrastructure/tools like TerraFS [13].

  1. Martin Spott (Apr 8th, 2006). [Flightgear-devel] Mapserver interface.
  2. Martin Spott (Dec 26th, 2011). [Flightgear-devel] PostGIS update @ Landcover-DB.
  3. Martin Spott (Jul 3rd, 2007). [Flightgear-devel] Looking at a nice project from outside.
  4. Martin Spott (Feb 23rd, 2012). Re: [Flightgear-devel] Looking at a nice project from outside.
  5. Torsten Dreyer (Nov 17th, 2015). [Flightgear-devel] Some thoughts regarding scenemodels and terrascenery.
  6. psadro_gm (Mar 23rd, 2016). Re: Is the Scenery Workflow broken?.
  7. Torsten (Nov 9th, 2015).  and terrasync are going .
  8. Torsten (Mar 23rd, 2016). Re: Is the Scenery Workflow broken?.
  9. HB-GRAL (Aug 24th, 2011). [Flightgear-devel] New experimental mapserver.
  10. Hooray (Apr 10th, 2016). Re: OSGearth as default scenery?.
  11. Torsten (Mar 23rd, 2016). Re: Is the .
  12. Torsten Dreyer (Dec 3rd, 2015). [Flightgear-devel] Continous, Distributed Generation of Terrain.
  13. Torsten Dreyer (Mar 27th, 2016). [Flightgear-devel] TerraSync, the lazy way: terrafs.

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[1]


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.[2]