On Tue, Sep 1, 2009 at 3:26 PM, Benjamin Ducke<[email protected]> 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 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
