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

[Tim Keitt]

On 9/8/06, Roger Bivand <Roger.Bivand at nhh.no> wrote:
> 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.

If its 64 bit, this is likely the problem. GDAL's types are the same
size regardless of the platform, but my guess is that R's types change
size.

>
> 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?

Nope. Shouldn't be a problem.

THK

>
> 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
>
>
>


-- 
Timothy H. Keitt
http://www.keittlab.org/