[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 > _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
