On Fri, 8 Sep 2006, Tim Keitt wrote: > On 9/8/06, Roger Bivand <[EMAIL PROTECTED]> 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.
Luckily this time the problem is resolved, but I agree that we'll need to work out what happens when R thinks that int is long. I don't have access to any 64-bit platforms to try this out, but from the lack of reports - and some people are running on 64-bit - maybe this just gets done correctly? Roger > > > > > 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 <[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] > > > > > > > > > -- 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
