[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