[GRASS-dev] GV_VOLUME: does it exist?

[Benjamin Ducke]

I was planning to eventually put up a more informative wiki 
page with illustrations of both 2D and 3D vector shapes.
But first I need to understand the vector model more completely.
Markus Metz' trac ticket confirms a lot of the suspicions
I have been having myself...

For now I will just get back to getting v.in.ogr/v.out.ogr
into better shape, as that is the most pressing issue for
me currently.

----- Original Message -----
From: "Markus Neteler" <neteler at osgeo.org>
To: "Benjamin Ducke" <benjamin.ducke at oxfordarch.co.uk>
Cc: "GRASS developers list" <grass-dev at lists.osgeo.org>
Sent: Friday, September 4, 2009 8:12:06 AM GMT +01:00 Amsterdam / Berlin / Bern / Rome / Stockholm / Vienna
Subject: Re: [GRASS-dev] GV_VOLUME: does it exist?

On Tue, Sep 1, 2009 at 3:26 PM, Benjamin
Ducke<benjamin.ducke at oxfordarch.co.uk> wrote:
...
> My current approach is to think about it like this:

Benjamin,

could you please add below ideas to
http://trac.osgeo.org/grass/wiki/Grass7/VectorLib

> 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.

This will hopefully change one day.

> 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.

Sounds reasonable but see the trac wiki page for comments from
MarkusM, too.

> 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.

Yes.

Markus



------
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.