I am proud to announce that I have been accepted to GSoC. I would also like to congratulate my fellow GSoCers on being accepted. My project is about reimplementation of modules v.voronoi and v.delaunay using more efficient algorithms. The goal is to implement Guibas-Stolfi divide-and-conquer algorithm and Fortune’s plane sweep algorithm. For more details see my proposal at http://www.doc.ic.ac.uk/~mp107/GSoC_proposal.txt I am really looking forward to working on the project and collaborating with the community.
On Wednesday 23 April 2008, Martin Pavlovsky wrote:
Hello everyone,
I am proud to announce that I have been accepted to GSoC. I would also like
to congratulate my fellow GSoCers on being accepted. My project is about
reimplementation of modules v.voronoi and v.delaunay using more efficient
algorithms. The goal is to implement Guibas-Stolfi divide-and-conquer
algorithm and Fortune's plane sweep algorithm. For more details see my
proposal at http://www.doc.ic.ac.uk/~mp107/GSoC_proposal.txt<http://www.doc.ic.ac.uk/%7
Emp107/GSoC_proposal.txt>I am really looking forward to working on the
project and collaborating with
the community.
Regards,
Martin Pavlovsky
Congrats! Always nice to have a couple shiny new algorithms in GRASS. I am
anxious to try the revamped voronoi and delaunay modules, as they may factor
into some of the terrain analysis operations I am pursuing.
2008/4/23, Martin Pavlovsky <mpavlovsky@gmail.com>:
I am proud to announce that I have been accepted to GSoC. I would also like
to congratulate my fellow GSoCers on being accepted. My project is about
reimplementation of modules v.voronoi and v.delaunay using more efficient
algorithms. The goal is to implement Guibas-Stolfi divide-and-conquer
algorithm and Fortune's plane sweep algorithm. For more details see my
proposal at http://www.doc.ic.ac.uk/~mp107/GSoC_proposal.txt I am
really looking forward to working on the project and collaborating with the
community.
Ehh.. I easily make the mistake of replying directly. I'm bringing this back to the list, since I feel it will interest all of the community.
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.
--Wolf
On Thu, Apr 24, 2008 at 5:57 AM, Wolf Bergenheim <wolf+grass@bergenheim.net <mailto:wolf%2Bgrass@bergenheim.net>> wrote:
Welcome! And congrats once again. I hope you'll have as much fun
here as I do!
Do you plan on making two modules (like we have now), or one one
single module that can create either a DT or VD depending on switches?
One thing which you talk about, and it would be cool to have. Given
either a DT or VD, it would be cool to be able to use the module to
convert it to the other, since they are the duals of each other.
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.
Decision if we have one joint module “vordel” instead of two separate ones as it is today is very important, but I think it can be taken in later stage of development. From users’ perspective it is easier to maintain status quo, i.e. keep two modules. Otherwise some users might be confused and start asking “where have v.voronoi/v.deluanay disappeared?”
Decision if we have one joint module "vordel" instead of two separate
ones as it is today is very important, but I think it can be taken in
later stage of development. From users' perspective it is easier to
maintain status quo, i.e. keep two modules. Otherwise some users might
be confused and start asking "where have v.voronoi/v.deluanay
disappeared?"
if two conceptual tasks, then two module front-ends.
(but let them share as much code internally as possible)
sorry for joining this discussion late, I was away all last week,
but will now be available for support via email.
First of all, congrats on being accepted to the GSoC!
Second, I agree that users need to be able to have two distinct modules,
otherwise they will wonder where to find their stuff.
One alternative you might want to consider is creating two separate
binaries v.voronoi and v.delaunay using two Makefile targets
that share exactly the same code base.
You could then simply use argv[0] to check which one the user called
and use appropriate program logics to set up GRASS options and
parameters etc.
Best,
Benjamin
----- Original Message -----
From: "Martin Pavlovsky" <mpavlovsky@gmail.com>
To: "Paul Kelly" <paul-grass@stjohnspoint.co.uk>
Cc: "Wolf Bergenheim" <wolf+grass@bergenheim.net>, "GRASS developers list" <grass-dev@lists.osgeo.org>
Sent: 26 April 2008 08:16:57 o'clock (GMT) Europe/London
Subject: Re: [GRASS-dev] GSoC, reimplementation of modules v.voronoi and v.delaunay
------
Files attached to this email may be in ISO 26300 format (OASIS Open Document Format). If you have difficulty opening them, please visit http://iso26300.info for more information.