On Fri, Feb 14, 2014 at 2:59 AM, Roger Bivand <Roger.Bivand@nhh.no> wrote:

> Tim,
>
> Thanks for taking the initiative on this, re:
>
> https://stat.ethz.ch/pipermail/r-sig-geo/2014-January/020241.html
>
> Your choice of Rcpp is one that the extension of R to include reference
> classes recently, provoked by Rcpp, makes possible and attractive.
>

Rcpp eases the wrapping a bit, which is nice, but it does not do enums and
a number of other types used by GDAL, so there is still a lot of manual
boilerplate. It would be really nice if Rcpp was extended to handle a few
more C-like constructs used in the GDAL interface.

I started with SWIG, which to my surprise actually works with R (it did not
last time I looked years ago). That was easier, but I did not like the
generated bindings and switched to Rcpp.


>
> Would you prefer to use this list for postings with regard to rgdal2, or
> gdal-dev, the wiki on the github repository, or some alternative?
>

I've not thought about it. I just want to get the docs finished so it can
be packaged, and I need it for a workshop I am teaching later this spring.


>
> Would you consider perhaps aligning rgdal2 with GDAL 2.0, rather than the
> GDAL 1.* series? In GDAL 2, breaking changes will be introduced - as Even
> writes: "this will require projects using GDAL to adapt multiple times":
>
> http://lists.osgeo.org/pipermail/gdal-dev/2014-February/038126.html
>
> This would give rgdal2 the advantage of being ready when GDAL 2 is ready,
> and puts GDAL 1.* and rgdal in "maintenance mode" while GDAL 1.* is still
> with us?
>

I've chosen to stay with the GDAL public C API rather than C++ methods. My
understanding is the Frank will not allow the C API to change. It may be
expanded to add new functionality.

While it may seem klunky to do so, I find the C API to give a cleaner
separation between the GDAL library and the R code. I just pass void
pointers and GDAL internally casts them to the proper class. (You will find
GDAL/OGR classes redeclared in my code, but they only function to document
what is being passed in the void pointer and to provide a template argument
to Rcpp. I could have given them any name.)


>
> I see many issues with clang and gcc 4.8.2 in the present code, but this
> isn't the right forum to take them up. Probably also building with clang is
> sensible future-proofing. On the R side, I've recently been running CMD
> check with pqR too (but some pqR efficiency changes are being applied to
> R-devel anyway, so other R-like engines are maybe not so important.
>

So far it compiles everywhere Rcpp compiles. Obviously I've not tested it
on lots of systems. You are right however that there may be looming growing
pains in the R ecosystem as folks start to focus more on improving the
low-level engine.


>
> Finally, do you know whether Julia supports an Rcpp-like interface, in
> which case jgdal2 might also be a personality of what you are proposing?
>

I've started on Julia. The Julia engine for generating wrappings is not
complete. It will be much better than Rcpp because of the tight integration
with llvm/clang. I dream of R being re-hosted on llvm in the way Julia was
developed (and in fact discussed that very idea with Viral many years ago
prior to Julia!).

THK


>
> I'll post this on gdal-dev too.
>
> Roger
>
> On Thu, 13 Feb 2014, Tim Keitt wrote:
>
>  Hi All,
>>
>> I've made a start on a rewrite of rgdal. You can find it at
>> https://github.com/thk686/rgdal2.
>>
>> There is still lots to do. I would be happy to have a GSOC student work on
>> this project if anyone is interested (via R or OSGeo). In particular I
>> would really like to have a test suite. Writing the examples is what is
>> slowing me down at this point.
>>
>> I do not store the auto-generated files in git, so you need roxygen2 and
>> Rcpp to build.
>>
>> Some of the goals of the project are to expose GDAL/OGR facilities through
>> a native R interface emulating arrays, lists, etc; to make it easy to
>> iterate over raster blocks and vector features; and to provide support for
>> raster-vector operations.
>>
>> It is semi-useable at this point; I'd be happy to have folks test it out.
>>
>> THK
>>
>>
>>
> --
> Roger Bivand
> Department of Economics, Norwegian School of Economics,
> Helleveien 30, N-5045 Bergen, Norway.
> voice: +47 55 95 93 55; fax +47 55 95 95 43
> e-mail: Roger.Bivand@nhh.no
>
>


-- 
http://www.keittlab.org/

	[[alternative HTML version deleted]]

