[GRASSLIST:2679] Re:Re: New Interested!

[Roberto Micarelli]

Greg Sepesi:
>
> > 
> > Hi all, Hi Radim. It's a while I'm out of this job. I'm still wondering to start
> > back with development of DGLib. It's a hard work for free... I'm happy to
> > see that it was somehow useful. At the user's conference in september 2002
> > there was little interest and it was one of the reasons that made me give up
> > developing in that direction. I know there are design limits in the library (use
> > of AVLs); it is suitable for low-degree graphs, as road-networks are.
> > 
> > Roberto
> > 
> 
> Hello!
> 
> The infamous Roberto Micarelli really exists!  I have never been to a
> GRASS conference, so I don't know what the reaction was to DGLib in
> 2002, but there certainly seems to be a lot of people now interested in
> GRASS's new vector capabilities including DGLib.  I'm not sure where
> Radim gets his energy.
> 
> Last summer I spent a couple days looking at DGLib, and didn't
> understand your use of AVL trees enough to attempt to use it.  In my
> application, I'm more concerned with graph search speed than graph
> update flexibility (which I presume was your reasoning behind using AVL
> trees), so I implemented a LGPL directed graph library based upon lookup
> tables.  I called it dgtable and the doxygen documentation for it is at
> 
> 	http://www.eduneer.com/gad/html/index.html
> 
> In addition to the use of lookup tables, another deviation from DGLib is
> that most of dgtable's directed graph algorithm results are stored in a
> "directed graph state" (instead of a newly created result directed
> graph) that gets attached to a directed graph.  After noticing that most
> directed graph algorithms don't produce results with more vertices than
> there are vertices in the graph, I just added more storage for directed
> graph algorithm results to each vertex storage that was already required
> by the directed graph state.  Therefore dgtable doesn't need to create
> and maintain graphs for results, except for vertex generating algorithms
> such as Delauney triangulation.
> 
> Aside from my investigation of DGLib, I haven't spent much time working
> with GRASS because my application is more focused on geographical
> documentation rather geographical analysis.  However I do think there is
> an intriguing complementary relationship between the two.  I've written
> about it at
> 
> 	http://www.eduneer.com/gad/anvdoc.pdf
> 
> and would welcome a discussion of how geographical analysis, GRASS in
> particular, and geographical documentation could benifit from and
> integrate with each other.
> 
> Greg
> 

In the next months I'm going to close some boring commercial developments.
My idea is to start back from the requirements of a new library version, mainly
focusing on GRASS needs.
DGLib didn't start that way and was later adapted to use in GRASS.
I'll try to read and understand your work.
What do you think about starting a team? I mean: you (Greg), Radim and me...
and every one else interested. Radim is a great requirements pusher! He can
make you program one year following a five minutes conversation. :-)
It would be worth having some funds to do it...

Roberto