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