[R-sig-Geo] followup on rgdal - invalid alignment error

[Roger Bivand]

On Fri, 8 Sep 2006, Tim Keitt wrote:

> One possibility is that the size of the GDAL data type is not the same
> as the size of the R data type. This will definitely cause problems as
> allocation is done by R and the pointer is cast to void when passed to
> GDAL. My original C++ code simply assumes that both are 32-bit (or at
> least equivalent size), but things will break if they are different.
> (Roger -- you probably noticed the "fix me!" comments to myself in
> there -- that was what I was talking about.)

(about line 750 in src/gdal-bindings.cpp)

Yes, but this is an example that is run very often on i386 at least, so 
I'm not sure why it should show up now on an other-endian platform? GDAL 
knows about endian-ness, doesn't it? Without access to the specific 
platform and build train, it would be difficult to debug? What else do we 
know about the platform? Is a G5 64-bit (ie. how big is an int)? What 
happens now is that sizeof(int) * ncells or sizeof(double) * ncells is 
made available for copying.

Note that there were changes in this code recently because 2.4.0 imposes 
stronger type checking, but I don't think that is it?

Roger

> 
> GDAL data types include the size information (e.g., UInt32), but R
> simply uses INTSXP and so on. Does anyone know how one determines for
> any particular build of R the size of these R types? If I know the
> size of INTSXP, then I can pick the corresponding GDAL data type.
> 
> THK
> 
> On 9/8/06, Roger Bivand <Roger.Bivand at nhh.no> wrote:
> > On Fri, 8 Sep 2006, Scott W Mitchell wrote:
> >
> > > After sending my last post, detailing my system setup with a working
> > > R/GDAL/rgdal installation on a Mac, I played a bit more and came
> > > across a glitch when I tried example(readGDAL) on the fresh build.
> >
> > Scott:
> >
> > Thanks very much for your detailed descriptions, and I hope updating to
> > try to help the original questioner hasn't broken things you need now.
> >
> > >
> > > It gets through translating the data set and the image command, but
> > > then on summary() I get:
> >
> > Can you re-run the example code by hand, line by line (copy & paste for
> > example)? From what you write, image displays correctly, is that right?
> > That suggests that the data has been read correctly, otherwise it would
> > not have displayed? Which image is this - several are read in the example?
> > Does example(GDAL.open) run smoothly? Something in the first band of the
> > data is causing sort to choke, could it be an NA? can you copy out the
> > band to a regular vector, and save it to file as an R object? If it is a
> > value in the band, it should be saved in a platform independent way. GDAL
> > also swaps to suit endianness.
> >
> > Roger
> >
> > >
> > > rdGDAL> summary(x)
> > >
> > > *** caught bus error ***
> > > address 0x17, cause 'invalid alignment'
> > >
> > > Traceback:
> > > 1: sort(x, partial = unique(c(lo, hi)))
> > > 2: quantile.default(object)
> > > 3: stats::quantile(object)
> > > 4: summary.default(X[[1]], ...)
> > > 5: FUN(X[[1]], ...)
> > > 6: lapply(as.list(object), summary, maxsum = maxsum, digits =
> > > 12,     ...)
> > > 7: summary.data.frame(object at att)
> > > 8: summary(object at data)
> > > 9: summary(object at data)
> > > 10: summary(x)
> > > 11: summary(x)
> > > 12: eval.with.vis(expr, envir, enclos)
> > > 13: eval.with.vis(ei, envir)
> > > 14: source(zfile, local, echo = echo, prompt.echo = prompt.echo,
> > > verbose = verbose, max.deparse.length = 250, encoding = encoding)
> > > 15: example(readGDAL)
> > >
> > > Possible actions:
> > > 1: abort (with core dump)
> > > 2: normal R exit
> > > 3: exit R without saving workspace
> > > 4: exit R saving workspace
> > > Selection:
> > >
> > > A byte-ordering issue???
> > >
> > > Any suggestions?
> > >
> > > Scott
> > >
> > >
> > >
> > >
> > > ----
> > > Scott Mitchell, Assistant Professor, Carleton University
> > > Department of Geography & Environmental Studies, Loeb B443A
> > > & Geomatics and Landscape Ecology Research Laboratory, Nesbitt 340
> > > Mailing:  Loeb B349, 1125 Colonel By Dr., Ottawa, ON K1S 5B6 Canada
> > > +1-613-520-2600 x2695 Fax: +1-613-520-4301 Scott_Mitchell at carleton.ca
> > >
> > > _______________________________________________
> > > R-sig-Geo mailing list
> > > R-sig-Geo at 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.Bivand at nhh.no
> >
> > _______________________________________________
> > R-sig-Geo mailing list
> > R-sig-Geo at 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.Bivand at nhh.no