AFAIU it is only really used by NVIZ so far for displaying 3D vector
volumes*, but I think it is important to keep it in a state ready to
be
implemented[* e.g. v.in.dxf (not -f) -> nviz
http://bambi.otago.ac.nz/hamish/grass/screenshots/nyc3d_nviz3_midtown.png
]
Hmmm,
A quick "grep" for the entire GRASS source tree produces no indication
that any GRASS module (including NVIZ) actually does anything with
a GV_VOLUME geometry. It is defined as a symbol and the vector type
checking in routines in Vlib will parse it, that's about it.
The v.in.dxf module also seems to export GV_FACE objects only, not
GV_VOLUME. Of course, it is perfectly possible for a mesh of GV_FACEs
to completely circumscribe an enclosed space, in which case it really
should be a GV_VOLUME, I guess. But for the purpose of visualization
there is no real difference.
> Is there some actual Vect library level support for processing
> such geometries or does GV_VOLUME just exist as a symbol for
> completeness' sake? So far I could not spot it in the "type="
> option of any GRASS module.not much as far as I've found, but hopefully that will change one
day.
I think I can confirm that now 
better defining it's purpose would definitely help.
one question I've always had: do kernels exist as centroids within a
closed volume (center of empty soccer ball), or one of the surface of
every 3D face? (ie on on each hexagonal/pentagonal patch of the
soccer
ball)
Exactly! I have been getting headaches over that same question.
My current approach is to think about it like this:
A) One additional dimension adds one degree of freedom to geometric
representation. It includes lower dimensional representations, thus
3D geometries can assume more different roles than 2D or 1D and
(just like with 2D boundaries and "regular" 2D polylines)
-> We need some user-controllable semantics to set a specific role.
B) A GV_FACE is essentially the same as a 2D area,
but with 3D vertices. Its GV_KERNEL should lie on the
interior plane defined by its vertices. A GV_FACE has at least 3
vertices (a triangle).
C) A GV_VOLUME is a minimum of 4 GV_FACES that form a complete "hull"
in 3D space (since we do not have GV_NURB or similar, we cannot have
curved primitives and thus need at least 4 triangular GV_FACES to
make the most simple hull -- correct?). In this case, the GV_KERNEL
should be placed in the gravitational center of the entire volume.
From a technological point of view, that differentiation may be
much less significant, though. At least as long as no actual
operations are being performed on vector geometries that concern
volume. It's really purely semantics, just like boundary vs. line.
But if, like you said, we can agree on a set of semantics for 3D
primitives, then it should not be too hard to implement those
in all affected GRASS modules. Right now, I can only think of
v.hull which currently generates a 3D hull as n faces + 1 kernel.
It should be changed to 1 volume + 1 kernel.
A use case for n faces + n kernels would be a 3D TIN from elevation
points. But there should never be n faces + 1 kernel or 1 face + n kernels.
Once we have a consensus on these issues, GV_VOLUME needs to
be added to the basic modules, such v.info and the
import/export modules, I guess.
Cheers,
Ben
Hamish
------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.