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

[Hamish]

[fwd->grass-dev]


==========================================================
Re: [GRASS-dev] Re: [tlaronde: ticket #542: vector for GRASS 7]
Sunday, December 6, 2009
From: "t laronde" 


Hello,

On Sat, Dec 05, 2009 at 08:32:50PM -0800, Hamish wrote:
> Thierry:
> > [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...]
>
> FWIW the curses like interface has been dropped for grass 7, so the only
> bits of i.ortho.photo that remain are the libs. The idea is to keep the
> algorithms but rewrite the rest in a platform independent way. this needs
> a volunteer interested in photogrammetry (& has for years).

I have tackled the task for KerGIS (put the User Interface apart) and it
has been a complete nightmare for all the code from this programmer that
absolutely didn't understand C and has copied Shapiro's code again and
again, modifying/hardcoding slights divergences and so on. From what I
have seen, there is not a lot of "algorithms" (departing from Shapiro's)
around, except perhaps for the camera caracteristics.

But I'm also a photogrammeter and I have started to play with this (and
stereoscopie) for KerGIS...

>
> > I have better wording in french, but not polyline.
>
> what is it?

"arête" from the latin "arista", because it is not only an "edge" but
convay a more fuzzy meaning of something thin or sharp. (A line has no
thickness, length but not width---except for display...)

The problem is that the correct word would be: ligne (line), because it
is only a series of vertices but without an intrinsic direction. Once
the topology is built, you consider then "arcs" that are directed (hence
signed) series of vertices.

More profoundly, the "arêtes" or lines are the _numbers_ of GRASS
vectorial. But if this makes sense for a mathematician, this is too
abstract for end users. Hence choices of words that can bear a "new"
meaning to depart from overloaded words, but close enough to something
existing.

>
> > In KerGIS, I have added a flag to encode the _function_ linking the
> > vertices
>
> ie f(x) ?

Yes but a list of defined functions. In the new vector for KerGIS,
there is a tetrabyte flag (a "long" in C is guaranteed to be at least
32 bits whatever the machine's word is), encoding the status (dead or
alive) etc. and one byte encoding a defined "linking function" (at
the moment this is mainly used for the display: the user can
construct natural geometrical forms that are converted to arcs).
As Donald Knuth has done for METAFONT (and Hobby for MetaPost), I
only support Bezier curves that is the function is predefined and
can approximate reasonably well a natural continuous line.

This is also used for importing modules (DXF for example) to describe
the objects and let conversion routines shared in the mathematical
libraries do the conversion.

>
>
> > 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.
>
> Not necessarily, they may be historic locations of churches or sampling
> stations, or any x,y,z[,t[,n]] singularity (not limited by imagination)
> for that matter. Not just spot samples of some continuous surface.

Yes, but what I mean is that, when the "sites" are, whether
singularities, isolated,  or a mesh, they do not need topology because
they are whether isolated or their links (the mesh) are predefined.

If the points (sites) are, for example, lampposts connected to
electrical lines, it makes sense to put them in the vectorial since the
node of the site is a node of the electrical network.

If this is not the case, you overload the vector with a bunch of nodes
that have strictly nothing to do with the remaining data and are "fat"
leading to a disaster for efficiency. Hence the "tricks" proposed to
solve (speed) things when the solution is to see that there are two
distinct uses, and one (the sites) has nothing to do here. And I guess
that a huge amount of resources (time and memory) is wasted encoding a
topology that is of no use, and extracting the data overloaded in a
format that was not designed for this.

>
> > 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).
>
> modern grass has those things, but they need some finishing touches AFAIU.
> see past Google Summer of Code projects.

For KerGIS (there was a Delaunay in the contrib sources but I'm unsure
about the licence) I will simply implement Donald Knuth's algorithm.
Perhaps not the fastest, but not encumbered and I guess doing correctly
the work and efficient enough.

>
> if you wanted to be a hero :) you could work on a BSD version of this:
>   http://www.cs.cmu.edu/~quake/triangle.html
>
> (very well implemented but non-free for commercial use*, so sadly mostly
> unusable..)

Since in KerGIS, I depend almost on nothing external (I have implemented
my own Shape lib; I will resurrect the Tiff one; I have developped my
own "Tk" for the display [it's special too...] and so on and I have
seen that I can do reasonable 3D rendering, starting from d.3d even
without using in a first step OpenGL...), I will probably do
something in this area some day.

But contrary to "bazaar" ;) I think at length about the problem (this
can take months) and once I do know exactly what I want I speed the
implementation.  So don't hold your breath...

Cheers,
-- 
Thierry Laronde (Alceste) <tlaronde +AT+ polynum +dot+ com>
                 http://www.kergis.com/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C