Hello,
Norman Vine schrieb:
Martin Spott writes:
Great, this is almost exactly what Frederic and I discussed while
talking about his intended reorganization of FGSD :-)
Hm, as long as you did not yet patent it, there is not a problem, is it? ;-)
The beauty of storing things in a DB is that you can easily have
a history of the changes, maintain metadata, and have an easier
way to serve the data thru OGC Standard Interfaces.
Also once you start making any changes you have to go thru the DB
Interface anyway unless you just modify the originals.
My point was that we don't have to store the DEM data in raster format.
As long as there is no PostGIS support for raster data, we either need
to store the raster data outside of PostGIS or store it as vector data
such as contours.
The whole SRTM-DEM-set stored as contours however possibly would take
lots of space in the DB and throttle access to the data when generating
the scenery (correct me, if I'm wrong)
The original DEM-set is unlikely to change in detail, except for when a
new topography mission is started (AFAIK, the German Aerospace Center is
currently preparing for a mission for 1arcsec DEM data, however no free
download intended) and the data is disseminated. It is questionable
whether we'd want to record the changes in that.
The actual user-supplied modifications would be stored in vector format
in the database and would be subject to the change monitoring you
stated. Probably most of the surface of the earth would not have to be
touched at all ;-)
Also who knows Native PostGIS support for Raster Data may not be all
that far in the future :-)
Well, then it depends on who is ready first: us or "them" ;-)
In any case, any DB-support for raster data would need integration with
GIS-tools in some way.
Regards,
Ralf
_______________________________________________
Flightgear-devel mailing list
[email protected]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
