On Tue, 19 Jan 2010, adrian.badde...@csiro.au wrote:
Nicholas Lewin-Koh and others have asked about the licence for the R
package 'gpclib'. This is based on the C library 'gpclib' by Alan
Murtagh which has a non-GPL licence.
Recently I contacted the licence holders for the C library, with a
formal request that the licence be changed to GPL. After contacting Alan
Murtagh they replied that it has been decided, definitively, not to
alter the licence.
Hence we are currently looking for a FOSS replacement for gpclib. Any
volunteers?
Adrian,
The rgeos package on R-Forge is almost ready for release.
https://r-forge.r-project.org/projects/rgeos/
http://trac.osgeo.org/geos/
The proof-of-concept has been to link it tightly to sp classes at the C
level. The way GEOS is structured makes tight coupling hard to avoid - so
similar R <-> C interfaces will be needed for other packages. Because it
isn't just for clipping, it doesn't fit the hole left by gpclib neatly.
Finally, it has an external dependency, the GEOS DLL and headers, which
can be met for Windows binary packages with Uwe Ligges' help (tried but
not yet operative on R-Forge, ready to roll when rgeos is on CRAN). For
Unix/Linux users, either install GEOS from source or binaries (works on
Debian/Ubuntu - libgeos, libgeos-c1, libgeos-dev), for OSX using the
Kyngchaos GEOS framework (untried http://www.kyngchaos.com/ -> software ->
frameworks).
An alternative that ought to be followed up at least as proof-of-concept
is the Boost GGL library:
http://reviews.slashgeo.org/article.pl?sid=09/11/30/1638211
http://trac.osgeo.org/ggl
Build for GGL is as other Boost software, through a mystical graph of
C++ headers - like the R RBGL package, which ships with the Boost headers
in a gzipped tar archive in src/ to create the Boost framework at compile
time. It is, however, not C++ written as C, it is modern C++. So for me,
the GEOS C API was easier to handle (for a chosen definition of easier).
In the meantime, packages that depend on gpclib could use the following
strategy that we have adopted for 'spatstat'. The 'spatstat' package
previously 'Depend'ed on gpclib. I have reorganised spatstat so that it
only 'Suggests' gpclib, and the gpclib-dependent code can be enabled or
disabled using a flag, spatstat.options("gpclib") which is initialised
to FALSE. If you are an academic or non-profit, set
spatstat.options(gpclib=TRUE). If you're commercial, leave it as FALSE
and have a nice day...
Even if you are academic, but doing contracted research, I'd be concerned
with the lack of clarity in:
"Commercial use of GPC (for example: product development / commercial
research)"
http://www.cs.manchester.ac.uk/~toby/alan/software/#Licensing
which is very much broader than compiling GPC into software for sale. I
guess it depends on your half-full/half-empty status ...
Unreleased maptools on the sourceforge r-spatial project follows your lead
on this (different mechanism - flag hidden in environment, same
principle), but where rgeos is present, uses that instead everywhere
gpclib was used before. Partly because of the use of C, it yields the same
results quicker. I'd be very grateful for anyone able to install source
packages trying out rgeos, and then installing maptools from a cvs
checkout from r-spatial. When I have some feedback, I'll release.
Helpers very welcome!
Roger
Adrian Baddeley
_______________________________________________
R-sig-Geo mailing list
R-sig-Geo@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
--
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: roger.biv...@nhh.no
_______________________________________________
R-sig-Geo mailing list
R-sig-Geo@stat.math.ethz.ch
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
