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 <[EMAIL PROTECTED]> 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([EMAIL PROTECTED]) > > > 8: summary([EMAIL PROTECTED]) > > > 9: summary([EMAIL PROTECTED]) > > > 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 [EMAIL PROTECTED] > > > > > > _______________________________________________ > > > 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: [EMAIL PROTECTED] > > > > _______________________________________________ > > 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: [EMAIL PROTECTED] _______________________________________________ R-sig-Geo mailing list R-sig-Geo@stat.math.ethz.ch https://stat.ethz.ch/mailman/listinfo/r-sig-geo
