[GRASS-dev] Fwd: Re: [tlaronde: ticket #542: vector for GRASS 7]

[Hamish]

[fwd'd intact, except for yahoo destroying the linewrap; sorry 'bout that]



> From: t laronde
> Date: Saturday, December 5, 2009, 3:31 AM
> [You can CC to grass-dev parts at
> your option.]
> 
> Hello Hamish,
> 
> Just a note for other potential readers: I'm bold and my
> comments
> are. But since I have for myself done mistakes,
> introducing
> modifications that I thought, without knowing enough of the
> details,
> good and had the obligation to revert the changes leading
> to
> "strange" and unwanted effects, I know clearly this: if you
> do not
> understand completely the problem and you have something
> that works
> to some extent, try first to reorganize the code, simplify
> the
> files etc. to understand the whole thing _before_
> introducing
> novations that will not play well with the existing if you
> don't
> know the existing...
> 
> [The exception for CERL GRASS siblings is i.ortho.photo and
> the like:
> send everything to /dev/null and code from scratch. It's a
> nightmare...]
> 
> 
> On Sat, Dec 05, 2009 at 02:25:06AM -0800, Hamish wrote:
> > thanks for providing your comments Thierry.
> > I agree with a fair amount of what you say,
> specifically education is
> > more work but far better than reinvention (poorly).
> there certainly is
> > a lot of hidden wisdom in the grass code for us to
> learn from.
> > 
> > a few minor points:
> > 
> > > avoid the confusion between "lines" and "arcs"
> for example.
> > 
> > please, "polyline" is much better than arc. for one
> thing the name-
> > space is well and truly taken, for another it's the
> term the rendering
> > library uses, and for a last point from a mathematical
> standpoint an
> > arc to me is a pure curve not a broken line
> approximating a curved line.
> > (arguing semantics will always be a chore of picking
> the best from
> > among imperfect terms)
> 
> I have better wording in french, but not polyline. In
> KerGIS, I have
> added a flag to encode the _function_ linking the vertices
> (even if it
> is not used at the moment), i.e. a series of vertices (arc)
> can be
> a rectiline or a curviline, a polyline---succession of
> lines,
> segments---or a curve. There is a distinction between
> vertices
> (control points) and function to describe the "line"---even
> in
> Euclide, the definition of "line" is difficult and special;
> this
> is a very interesting part of geometry.
> 
> So polyline: IMO, no. But in a sense, even in the level 0,
> the storage
> of "arcs", they are not really "arcs" since they are
> described in a
> direction but have not, intrinsically, a direction. Only
> when topology
> is built, the sign of the identifier indicates the
> direction (relative
> to the level 0 definition).
> 
> > 
> > > merging the Sites as Points in the vector was,
> IMO, an error.
> > 
> > both have their strengths and their weaknesses, but
> regardless of that
> > it is done now and with minor extra-topological
> ugliness we can store
> > massive point datasets in the current framework. it's
> not ideal, and
> > we've lost users to eg PostGIS because of it, but this
> is not the
> > trickiest problem we face so we'll see what future
> solutions introduce
> > themselves.
> 
> I think the "problem" is the point of view. When keeping
> Sites
> (singularities) apart, you see more that they are, too, a
> connected 
> network of control points to describe a surface. There was
> a lot that
> could be done with the ASCII listing of sites (there could
> have been a
> binary version for symetry to speed things) and with Unix
> powertools
> that is difficult to achieve dragging topology and so on.
> 
> Triangulation, Delaunay are a critical part of what should
> be here in a
> GIS (GPL GRASS has things as far as I know; KerGIS not for
> the moment).
> 
> > 
> > 
> > > Secondly, the introduction of 3D in vector is not
> perhaps a great idea
> > > if you remember what a GIS is mainly for.
> > 
> > important: s/is/has been/
> > don't limit yourself by what others have done in the
> past.
> > to me the interesting thing about grass is not what it
> can do, but
> > what it could easily be extended to do.
> > 
> > I work in the water which is inherently a 3D
> environment, I think I can
> > speak for all our geologic, atmospheric,
> archaeological, and so on
> > refugees from other GIS when I say that the 3D support
> is a big reason
> > we use GRASS.
> > 
> > 
> > to me, the biggest software gap we have from a vector
> perspective besdies
> > the LiDAR problem is to get a mature non-encumbered
> reimplimentation of
> > the Triangle library out there to the world. (see
> nnbathy threads)
> 
> I have seen too that for "excavations" or caves, when there
> is not
> really an open surface (a "floor") but a cylinder or
> something like
> that, my point of view is more difficult. But all in all,
> there could be
> at least two flavors of vectorial: 2D and 3D (I don't know
> if this is
> already the case for the new GPL GRASS vector engine. I
> even plan
> for KerGIS a scaled integers version of the vector since in
> a lot
> of applications and with the advent of 64 bits, the
> coordinates
> will be good enough...); or the 3D can be done as 2.5D
> (using attributes
> [categories]); or a closed surface can be split as the
> union of
> two open surfaces (half cylinders) and this will do etc. 
> 
> Regards,
> -- 
> Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+
> com>
>              
>    http://www.kergis.com/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1
> AE95 6006 F40C
>