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