Robert Osfield wrote:
2) My recent submission on osgTerrain building in specific support for
vector data sets should be considered. I should be stronger and say that
height data by default should be considered as vector rather than
raster. The majority of height data from various agencies around the
World are vector data sets.
GDAL incorporates vector data via OGR (I think) but the formats are
fairly limited.
I haven't had a chance to review these changes yet. When you say
vector data, what exactly do you mean? It could cover a huge range of
data usage, do you mean lines? Do you mean clouds of x,y,z point?
I use vector reservedly here, primarily to differentiate from raster /
image data. I mean specific height point data sets which can effectively
be considered a matrix or grid of points. HeightField is a vector data
set in this terminology. The height is defined at a point rather than
over a cell (which has dimensions) in a raster data set.
The data is usually over a grid and a good example is the GB OS Profile
data which is a grid of height data at 10m spacing. There is also the GB
OS Panorama data set which has 50m spacing and is typically in 20km
tiles. A good free example (can be downloaded) is the US 7.5min DEM data
which is 30m spacing and covers a quadrangle map (I think). This can
provide a more difficult test for systems as not all of a tile
(rectangular region) is covered by the quadrangle, whose sides are rotated.
Anyone doing real landscape work would most likely be using this type of
data. However, some country's data is poor and often may only be
available as contour lines. Interpolating contours can be a complete
minefield.
Regards
Alan
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
