Hi all,
potentially I have a student who could spend some time on this topic.
Currently we have for G6 an addons module (bash script) [1] which
depends on nn-c library [2]. This library is distributed under MIT
licence, but partly it's depending on tringle library [3] (Delaunay
triangulation) which is not really open source.
I see three possible options:
1) create new GRASS lib for nn from scratch (this is probably to much
for student work)
2) use open source lib which has nn implemented, eg. CGAL [4]. This
would require a new dependency for GRASS. CGAL is very powerful
library and could be probably used by other modules in the future.
3) use nn-c and replace triangle lib by open source solution (in GRASS
we have Delaunay triangulation so probably it could be reused?) nn-c
is distributed under MIT licence so it could be probably integrated to
the main code as an extenal library (lib/external) if I am right...
Any ideas? Thanks in advance, Martin
[1] http://grasswiki.osgeo.org/wiki/AddOns/GRASS_6#r.surf.nnbathy
[2] http://code.google.com/p/nn-c/
[3] http://www.cs.cmu.edu/~quake/triangle.html
[4] http://doc.cgal.org/latest/Manual/packages.html#PartInterpolation
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
On 08/04/14 14:03, Martin Landa wrote:
Hi all,
potentially I have a student who could spend some time on this topic.
Currently we have for G6 an addons module (bash script) [1] which
depends on nn-c library [2]. This library is distributed under MIT
licence, but partly it's depending on tringle library [3] (Delaunay
triangulation) which is not really open source.
I see three possible options:
1) create new GRASS lib for nn from scratch (this is probably to much
for student work)
2) use open source lib which has nn implemented, eg. CGAL [4]. This
would require a new dependency for GRASS. CGAL is very powerful
library and could be probably used by other modules in the future.
Do you have an idea how CGAL compares to GEOS ? Could the former replace the latter for those functions where GEOS is used ?
3) use nn-c and replace triangle lib by open source solution (in GRASS
we have Delaunay triangulation so probably it could be reused?) nn-c
is distributed under MIT licence so it could be probably integrated to
the main code as an extenal library (lib/external) if I am right...
I think you can even integrate it into the main code. The result will be GPL'ed, even if the original code by itself remains under MIT.
If 3) is possible I would think it is preferable to 2, unless we see a lot of other uses for CGAL in GRASS.
Moritz
On 14/04/14 17:34, Moritz Lennert wrote:
On 08/04/14 14:03, Martin Landa wrote:
Hi all,
potentially I have a student who could spend some time on this topic.
Currently we have for G6 an addons module (bash script) [1] which
depends on nn-c library [2]. This library is distributed under MIT
licence, but partly it's depending on tringle library [3] (Delaunay
triangulation) which is not really open source.
I see three possible options:
1) create new GRASS lib for nn from scratch (this is probably to much
for student work)
2) use open source lib which has nn implemented, eg. CGAL [4]. This
would require a new dependency for GRASS. CGAL is very powerful
library and could be probably used by other modules in the future.
Do you have an idea how CGAL compares to GEOS ? Could the former replace
the latter for those functions where GEOS is used ?
3) use nn-c and replace triangle lib by open source solution (in GRASS
we have Delaunay triangulation so probably it could be reused?) nn-c
is distributed under MIT licence so it could be probably integrated to
the main code as an extenal library (lib/external) if I am right...
I think you can even integrate it into the main code. The result will be
GPL'ed, even if the original code by itself remains under MIT.
If 3) is possible I would think it is preferable to 2, unless we see a
lot of other uses for CGAL in GRASS.
One additional reflection, though: I don't think that CGAL provides a C-API which, IIUC, would mean that the module would have to be programmed in C++. Somewhat of a showstopper...
Moritz
Hi,
2014-04-14 18:03 GMT+02:00 Moritz Lennert <mlennert@club.worldonline.be>:
[...]
thanks for your useful comments!
One additional reflection, though: I don't think that CGAL provides a C-API
which, IIUC, would mean that the module would have to be programmed in C++.
Somewhat of a showstopper...
Right, such modules would be written in C++. We have already several
modules written in C++, so I wouldn't call it as a showstopper...
Martin
--
Martin Landa * http://geo.fsv.cvut.cz/gwiki/Landa
On 15/04/14 21:44, Martin Landa wrote:
Hi,
2014-04-14 18:03 GMT+02:00 Moritz Lennert <mlennert@club.worldonline.be>:
[...]
thanks for your useful comments!
One additional reflection, though: I don't think that CGAL provides a C-API
which, IIUC, would mean that the module would have to be programmed in C++.
Somewhat of a showstopper...
Right, such modules would be written in C++. We have already several
modules written in C++, so I wouldn't call it as a showstopper...
Well these modules are generally not core functionality, and for some (e.g. r.terraflow) C-equivalents exist. And IIRC general consenus on this list has been to try to avoid C++ code.
But you wrote:
On 08/04/14 14:03, Martin Landa wrote:
> This
> would require a new dependency for GRASS. CGAL is very powerful
> library and could be probably used by other modules in the future.
This would imply a more extensive use of the library and thus more C++ modules which would be a move away from current practice (at least in the way I have perceived it).
Moritz
2014-04-16 10:33 GMT+02:00 Moritz Lennert <mlennert@club.worldonline.be>:
Right, such modules would be written in C++. We have already several
modules written in C++, so I wouldn't call it as a showstopper...
Well these modules are generally not core functionality, and for some (e.g.
are you considering narural neighbor as "a core functionality"? 
r.terraflow) C-equivalents exist. And IIRC general consenus on this list has
been to try to avoid C++ code.
I would say that there is consensus about libraries, not modules. Martin