[GRASS-dev] GSoC, reimplementation of modules v.voronoi and v.delaunay

[Paul Kelly]

On Thu, 24 Apr 2008, Wolf Bergenheim wrote:

> On 24.04.2008 10:54, Martin Pavlovsky wrote:
>> Thank you for the warm welcome.
>> 
>> I think that having only one module has many advantages in different 
>> perspectives. Since VD and DT are so closely related, I presume that more 
>> than 70% of the code would be very similar for both modules if they were 
>> separated. This replication would be avoided by joining them together. The 
>> relationship between VD and DT would be more obvious for the user if there 
>> was a single module named "v.voronoi_delaunay" or sth similar. User will 
>> choose VD or DT by setting parameters, it seems to me as the most natural 
>> way. This DT -> VD and VD -> DT conversion is very important feature which 
>> is lacking in current implementation, I am all for it. One disadvantage of 
>> having only one module might be slightly steeper learning curve, but I 
>> don't see it as a major obstacle.
>
> I agree. It is better to have it as one module. I wonder what would be a good 
> name. v.voronoi.delauny seems a bit awkward but very obvious. I can't think 
> of a better name. Anybody else have some idea?
>
> Another way to handle it would be to make two modules, but re-use that 70% by 
> having it in a library or something.

The idea of a library for shared code appeals to me more - I suspect we'd 
end up creating wrapper scripts called v.voronoi and v.delaunay that would 
call the combined module with appropriate options anyway, in order to 
simplify things from a user perspective as has been done already e.g. with 
v.centroids as a wrapper for v.category.

If we go with the library option, it would be a static library that could 
be linked into both modules. Suggested directory layout: a new directory 
under vector/ to contain everything, e.g. call it "geometric" or "vordel" 
or something - then subdirectories lib, v.voronoi and v.delaunay. Perhaps 
something similar to what has been done for vector/v.lrs/ - but I think 
the subdirectory there should have been called simply lrs - it's confusing 
as there's no module called v.lrs - and I don't think the library should 
be a normal shared GRASS library installed with all the others, as has 
been done there - static is just fine in this case.

The connection between Delaunay triangulation and Voronoi tessellation 
could be made very clear in the man pages / documentation for both modules 
anyway.

That's what I think but it's Martin's project!

Paul