Subscribe to R-sig-geo feed
This is an archive for R-sig-geo, not a forum. It is not possible to post through Nabble - you may not start a new thread nor follow up an existing thread. If you wish to post, but are not subscribed to the list through the list homepage, subscribe first (through the list homepage, not via Nabble) and post from your subscribed email address. Until 2015-06-20, subscribers could post through Nabble, but policy has been changed as too many non-subscribers misunderstood the interface.
Updated: 10 min 10 sec ago

Re: CRAN releases of sp, rgdal and rgeos

Mon, 06/18/2018 - 14:39
Success!

This morning I upgraded a Mac to OS 10.13.5 (the so-called High Sierra version), then

 - Installed R 3.5.0 from CRAN (installed ever 3.3.x)
 - Installed sp 1.3-1, rgdal 1.3-2, rgeos 0.3-28, also sf 0.6-3, from the CRAN binaries that are now available
 - Ran my personal test suite, which exercises the kinds of tasks I perform with those packages

All tests succeeded.

I forgot to control the order of installation, so I don't know if I installed sp first, as advised. But I expect that with the binary versions it doesn't matter.

(I don't think it matters for the above, but I also installed the clang and gfortran version provided on CRAN's Mac "tools" page, and successfully compiled some source packages that require fortran, and others that require C).

Thank again for all your work
-Don

--
Don MacQueen
Lawrence Livermore National Laboratory
7000 East Ave., L-627
Livermore, CA 94550
925-423-1062
Lab cell 925-724-7509
 
 

On 6/8/18, 11:15 AM, "R-sig-Geo on behalf of Roger Bivand" <[hidden email] on behalf of [hidden email]> wrote:

    There are new releases of sp, rgdal and rgeos on CRAN. Please install sp
    first, then the other two, which link to the installed sp. They all
    address so-called rchk issues, which have not so far been a problem, but
    might have become more fragile as R's internal memory management is made
    even more efficient. This involves compiled code using memory allocated by
    R to be freed by R's garbage collector, which has to know if an object is
    still being used. Tomas Kalibera, the author of rchk, helped resolve and
    explain the issues encountered - what was good coding practice fifteen
    years ago isn't always still good practice.
   
    In addition, the earliest versions of GDAL and PROJ with which rgdal will
    work have been updated, and set to PROJ 4.8.0 and GDAL 1.11.4. The current
    released versions of PROJ and GDAL are to be prefered, as bugs have been
    fixed and new features and drivers introduced. A check has been put
    in place to trap attempts to install rgdal without a C++11-capable
    compiler when the GDAL version is >=2.3.0 - which requires C++11. rgeos is
    ready for the forthcoming version of GEOS.
   
    The CRAN team has also been very supportive of our efforts to bring
    compiled code in these packages into rchk compliance.
   
    Please get in touch if you see any loose ends in these releases.
   
    Roger
   
    --
    Roger Bivand
    Department of Economics, Norwegian School of Economics,
    Helleveien 30, N-5045 Bergen, Norway.
    voice: +47 55 95 93 55; e-mail: [hidden email]
    http://orcid.org/0000-0003-2392-6140
    https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
   
    _______________________________________________
    R-sig-Geo mailing list
    [hidden email]
    https://stat.ethz.ch/mailman/listinfo/r-sig-geo
   

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: What is the Coordinate Reference System?

Mon, 06/18/2018 - 08:49
Yes, thanks for the explanations.


Have a nice week! :)

Em seg, 18 de jun de 2018 às 10:29, Ben Tupper <[hidden email]>
escreveu:

> Hi,
>
> I will blissfully proceed as I have in the past.   Thanks to each of you
> for the clear explanations.
>
> Cheers,
> Ben
>
> > On Jun 18, 2018, at 6:26 AM, Michael Sumner <[hidden email]> wrote:
> >
> > Agree with Edzer this application of eqc is anomalous and after it
> confused
> > us initially we now ignore it and apply the unproblematic proj=longlat
> > interpretation to these products (after checking).
> >
> > I might explore the L3 products to find out why this occurred, but the
> > ocean colour forum is the usual place to find discussion.
> >
> > Cheers, Mike
> >
> > On Mon, 18 Jun 2018, 15:59 Edzer Pebesma, <[hidden email]
> >
> > wrote:
> >
> >> Plate carree is essentially a linear mapping of long and lat to x and y,
> >> without changing aspect ratio (scale factor 1 at equator).
> >>
> >> projecting long/lat towards plate caree using the proj4 string you
> >> mention will however change the units from degrees to m. So while the
> >> plots of of data in linear long/lat (with aspect ration 1) looks
> >> identical to the one obtained in plate caree (with aspect ratio 1), the
> >> numerical values along their axes are very different.
> >>
> >> Many netcdf files carry a grid (raster) with the x and y coordinates of
> >> grid cells (centers?) in another coordinate system, but the ones you
> >> mention below don't, as far as I can tell. I think what they mean by
> >> mentioning plate carree is just saying that this is a regular long/lat
> >> degree grid; rather unlucky wording IMO.
> >>
> >> On 06/15/2018 08:14 PM, Ben Tupper wrote:
> >>> Hi,
> >>>
> >>> That's an interesting approach.
> >>>
> >>> On the other hand, sometimes I get bitten (well, muddled really) when I
> >> use raster to determine the crs of a ncdf resource.  It all sort of
> depends.
> >>>
> >>> Below is an example for Aqua MODIS imagery from OBPG (
> >>
> https://oceandata.sci.gsfc.nasa.gov/MODIS-Aqua/Mapped/Daily/9km/sst/2017/
> >> <
> https://oceandata.sci.gsfc.nasa.gov/MODIS-Aqua/Mapped/Daily/9km/sst/2017/
> >).
> >> The OBPG docs (https://oceancolor.gsfc.nasa.gov/products/ <
> >> https://oceancolor.gsfc.nasa.gov/products/>) state that the data is
> >> served up as 'Plate Carrée' which I think has a crs ...
> >>>
> >>> '+proj=eqc +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84
> >> +datum=WGS84 +units=m +no_defs '
> >>>
> >>> ... as described here http://spatialreference.org/ref/epsg/32662/ <
> >> http://spatialreference.org/ref/epsg/32662/>
> >>>
> >>> You can see below that raster comes up with...
> >>>
> >>> '+proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0'
> >>>
> >>> ... which is http://spatialreference.org/ref/epsg/4326/ <
> >> http://spatialreference.org/ref/epsg/4326/>
> >>>
> >>> Explicitly setting the crs while reading doesn't help.  I have never
> >> resolved if it is an OBPG documentation bug, my confusion about
> >> projections, or some other mystery.  So, my usual practice is to assume
> >> that raster makes the right call.
> >>>
> >>> #### start
> >>>
> >>> library(raster)
> >>> URI = '
> >>
> https://oceandata.sci.gsfc.nasa.gov/cgi/getfile/A2017175.L3m_DAY_SST_sst_9km.nc
> >> '
> >>>
> >>> # ~3.8MB
> >>> ok = download.file(URI, basename(URI))
> >>>
> >>> R = raster::raster(basename(URI), varname = 'sst')
> >>> R
> >>> # class       : RasterLayer
> >>> # dimensions  : 2160, 4320, 9331200  (nrow, ncol, ncell)
> >>> # resolution  : 0.08333334, 0.08333334  (x, y)
> >>> # extent      : -180, 180, -90, 90  (xmin, xmax, ymin, ymax)
> >>> # coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
> >>> # data source : /Users/Shared/code/R/others/record/spnc/
> >> A2017175.L3m_DAY_SST_sst_9km.nc
> >>> # names       : Sea.Surface.Temperature
> >>> # zvar        : sst
> >>>
> >>> S = raster::raster(basename(URI), varname = "sst", crs = '+proj=eqc
> >> +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84
> >> +units=m +no_defs')
> >>> # Warning message:
> >>> # In .getProj(prj, crs) :
> >>> #  argument "crs" ignored because the file provides a crs
> >>>
> >>> #### end
> >>>
> >>>
> >>> Cheers,
> >>> Ben
> >>>
> >>>
> >>>> On Jun 14, 2018, at 6:42 PM, Michael Sumner <[hidden email]>
> wrote:
> >>>>
> >>>> Try raster::projection(raster::raster(a)) first, then delve if
> necessary
> >>>> into the ncdump summary with print(raster::raster(a)))
> >>>>
> >>>> But, raster(a) may be enough here? To get that stuff more directly
> from
> >> the
> >>>> NetCDF API you have to use the inq and att functions of ncdf4 or
> RNetCDF
> >>>> and that's no fun.
> >>>>
> >>>> I'd also try raster(rgdal::readGDAL(a)) which is a totally different
> but
> >>>> equivalent read path.
> >>>>
> >>>> Cheers, Mike
> >>>>
> >>>> On Thu, 14 Jun 2018, 11:03 Sergio Ibarra, <[hidden email]>
> >> wrote:
> >>>>
> >>>>> Greetings,
> >>>>>
> >>>>> I'm want to read NetCDF spatial data from a meteorological model (WRF
> >>>>> model). The NetCDF can have one of these three projections:
> >>>>>
> >>>>> Polar stereographic
> >>>>> Lambert conformal
> >>>>> Mercator projection
> >>>>>
> >>>>> (See figure
> >>>>>
> >>>>>
> >>
> https://user-images.githubusercontent.com/27447280/41389756-ed23f91a-6f68-11e8-961e-6ba901913c54.png
> >>>>> )
> >>>>>
> >>>>> What is the  Coordinate Reference System for each case?
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>> Here an example with ncdf4 and raster:
> >>>>>
> >>>>> library(ncdf4)
> >>>>> library(raster)
> >>>>> a <- tempfile()
> >>>>> download.file(url = "
> >>>>>
> >>
> http://www.unidata.ucar.edu/software/netcdf/examples/wrfout_v2_Lambert.nc
> >>>>> ",
> >>>>>             destfile = a) #78 Mb
> >>>>> wrf <- nc_open(a)
> >>>>> paste("The file has",wrf$nvars,"variables")
> >>>>> paste("The file has",names(wrf$var))
> >>>>> lat <- ncvar_get( wrf, "XLAT" )
> >>>>> lon <- ncvar_get( wrf, "XLONG" )
> >>>>> t2 <- ncvar_get( wrf, "T2" ) - 273.15
> >>>>> dim(t2) #73 60 13
> >>>>> #image
> >>>>> image(t2[, , 12])
> >>>>> # raster
> >>>>> rt2 <- raster(t(t2[1:dim(t2)[1],
> >>>>>                  dim(t2)[2]:1,
> >>>>>                  12]),
> >>>>>             xmn = min(lon),
> >>>>>             xmx = max(lon),
> >>>>>             ymn = min(lat),
> >>>>>             ymx = max(lat),
> >>>>> *              crs="+init=epsg:4326") # ???*
> >>>>> spplot(rt2)
> >>>>>
> >>>>>
> >>>>>
> >>>>> --
> >>>>> ​Sergio Ibarra Espinosa
> >>>>> Post Doc
> >>>>> PhD in Atmospheric Sciences
> >>>>> Instituto de Astronomia, Geofísica e Ciências Atmosféricas
> >>>>> Universidade de São Paulo
> >>>>> Rua do Matão, 1226
> >>>>> São Paulo-SP - Brasil -
> >>>>> 05508-090
> >>>>> +55-11-97425-3791 <(11)%2097425-3791>
> >>>>> Skype: sergio_ibarra1
> >>>>>
> >>>>>       [[alternative HTML version deleted]]
> >>>>>
> >>>>> _______________________________________________
> >>>>> R-sig-Geo mailing list
> >>>>> [hidden email]
> >>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >>>>>
> >>>> --
> >>>> Dr. Michael Sumner
> >>>> Software and Database Engineer
> >>>> Australian Antarctic Division
> >>>> 203 Channel Highway
> >>>> Kingston Tasmania 7050 Australia
> >>>>
> >>>>     [[alternative HTML version deleted]]
> >>>>
> >>>> _______________________________________________
> >>>> R-sig-Geo mailing list
> >>>> [hidden email]
> >>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >>>>
> >>>
> >>> Ben Tupper
> >>> Bigelow Laboratory for Ocean Scien
> <https://maps.google.com/?q=for+Ocean+Scien&entry=gmail&source=g>ces
> >>> 60 Bigelow Drive, P.O. Box 380
> >>> East Boothbay, Maine 04544
> >>> http://www.bigelow.org
> >>>
> >>> Ecological Forecasting: https://eco.bigelow.org/
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>      [[alternative HTML version deleted]]
> >>>
> >>> _______________________________________________
> >>> R-sig-Geo mailing list
> >>> [hidden email]
> >>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >>>
> >>
> >> --
> >> Edzer Pebesma
> >> Institute for Geoinformatics
> >> Heisenbergstrasse 2, 48151 Muenster, Germany
> >> Phone: +49 251 8333081 <+49%20251%208333081>
> >>
> >> _______________________________________________
> >> R-sig-Geo mailing list
> >> [hidden email]
> >> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >>
> > --
> > Dr. Michael Sumner
> > Software and Database Engineer
> > Australian Antarctic Division
> > 203 Channel Highway
> > Kingston Tasmania 7050 Australia
> >
> >       [[alternative HTML version deleted]]
> >
> > _______________________________________________
> > R-sig-Geo mailing list
> > [hidden email]
> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >
>
> Ben Tupper
> Bigelow Laboratory for Ocean Sciences
> 60 Bigelow Drive, P.O. Box 380
> East Boothbay, Maine 04544
> http://www.bigelow.org
>
> Ecological Forecasting: https://eco.bigelow.org/
>
>
>
>
>
>
>         [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> --
​Sergio Ibarra Espinosa
Post Doc
PhD in Atmospheric Sciences
Instituto de Astronomia, Geofísica e Ciências Atmosféricas
Universidade de São Paulo
Rua do Matão, 1226
São Paulo-SP - Brasil -
05508-090
+55-11-97425-3791
Skype: sergio_ibarra1

        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: What is the Coordinate Reference System?

Mon, 06/18/2018 - 08:22
Hi,

I will blissfully proceed as I have in the past.   Thanks to each of you for the clear explanations.  

Cheers,
Ben

> On Jun 18, 2018, at 6:26 AM, Michael Sumner <[hidden email]> wrote:
>
> Agree with Edzer this application of eqc is anomalous and after it confused
> us initially we now ignore it and apply the unproblematic proj=longlat
> interpretation to these products (after checking).
>
> I might explore the L3 products to find out why this occurred, but the
> ocean colour forum is the usual place to find discussion.
>
> Cheers, Mike
>
> On Mon, 18 Jun 2018, 15:59 Edzer Pebesma, <[hidden email]>
> wrote:
>
>> Plate carree is essentially a linear mapping of long and lat to x and y,
>> without changing aspect ratio (scale factor 1 at equator).
>>
>> projecting long/lat towards plate caree using the proj4 string you
>> mention will however change the units from degrees to m. So while the
>> plots of of data in linear long/lat (with aspect ration 1) looks
>> identical to the one obtained in plate caree (with aspect ratio 1), the
>> numerical values along their axes are very different.
>>
>> Many netcdf files carry a grid (raster) with the x and y coordinates of
>> grid cells (centers?) in another coordinate system, but the ones you
>> mention below don't, as far as I can tell. I think what they mean by
>> mentioning plate carree is just saying that this is a regular long/lat
>> degree grid; rather unlucky wording IMO.
>>
>> On 06/15/2018 08:14 PM, Ben Tupper wrote:
>>> Hi,
>>>
>>> That's an interesting approach.
>>>
>>> On the other hand, sometimes I get bitten (well, muddled really) when I
>> use raster to determine the crs of a ncdf resource.  It all sort of depends.
>>>
>>> Below is an example for Aqua MODIS imagery from OBPG (
>> https://oceandata.sci.gsfc.nasa.gov/MODIS-Aqua/Mapped/Daily/9km/sst/2017/
>> <https://oceandata.sci.gsfc.nasa.gov/MODIS-Aqua/Mapped/Daily/9km/sst/2017/>).
>> The OBPG docs (https://oceancolor.gsfc.nasa.gov/products/ <
>> https://oceancolor.gsfc.nasa.gov/products/>) state that the data is
>> served up as 'Plate Carrée' which I think has a crs ...
>>>
>>> '+proj=eqc +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84
>> +datum=WGS84 +units=m +no_defs '
>>>
>>> ... as described here http://spatialreference.org/ref/epsg/32662/ <
>> http://spatialreference.org/ref/epsg/32662/>
>>>
>>> You can see below that raster comes up with...
>>>
>>> '+proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0'
>>>
>>> ... which is http://spatialreference.org/ref/epsg/4326/ <
>> http://spatialreference.org/ref/epsg/4326/>
>>>
>>> Explicitly setting the crs while reading doesn't help.  I have never
>> resolved if it is an OBPG documentation bug, my confusion about
>> projections, or some other mystery.  So, my usual practice is to assume
>> that raster makes the right call.
>>>
>>> #### start
>>>
>>> library(raster)
>>> URI = '
>> https://oceandata.sci.gsfc.nasa.gov/cgi/getfile/A2017175.L3m_DAY_SST_sst_9km.nc
>> '
>>>
>>> # ~3.8MB
>>> ok = download.file(URI, basename(URI))
>>>
>>> R = raster::raster(basename(URI), varname = 'sst')
>>> R
>>> # class       : RasterLayer
>>> # dimensions  : 2160, 4320, 9331200  (nrow, ncol, ncell)
>>> # resolution  : 0.08333334, 0.08333334  (x, y)
>>> # extent      : -180, 180, -90, 90  (xmin, xmax, ymin, ymax)
>>> # coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
>>> # data source : /Users/Shared/code/R/others/record/spnc/
>> A2017175.L3m_DAY_SST_sst_9km.nc
>>> # names       : Sea.Surface.Temperature
>>> # zvar        : sst
>>>
>>> S = raster::raster(basename(URI), varname = "sst", crs = '+proj=eqc
>> +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84
>> +units=m +no_defs')
>>> # Warning message:
>>> # In .getProj(prj, crs) :
>>> #  argument "crs" ignored because the file provides a crs
>>>
>>> #### end
>>>
>>>
>>> Cheers,
>>> Ben
>>>
>>>
>>>> On Jun 14, 2018, at 6:42 PM, Michael Sumner <[hidden email]> wrote:
>>>>
>>>> Try raster::projection(raster::raster(a)) first, then delve if necessary
>>>> into the ncdump summary with print(raster::raster(a)))
>>>>
>>>> But, raster(a) may be enough here? To get that stuff more directly from
>> the
>>>> NetCDF API you have to use the inq and att functions of ncdf4 or RNetCDF
>>>> and that's no fun.
>>>>
>>>> I'd also try raster(rgdal::readGDAL(a)) which is a totally different but
>>>> equivalent read path.
>>>>
>>>> Cheers, Mike
>>>>
>>>> On Thu, 14 Jun 2018, 11:03 Sergio Ibarra, <[hidden email]>
>> wrote:
>>>>
>>>>> Greetings,
>>>>>
>>>>> I'm want to read NetCDF spatial data from a meteorological model (WRF
>>>>> model). The NetCDF can have one of these three projections:
>>>>>
>>>>> Polar stereographic
>>>>> Lambert conformal
>>>>> Mercator projection
>>>>>
>>>>> (See figure
>>>>>
>>>>>
>> https://user-images.githubusercontent.com/27447280/41389756-ed23f91a-6f68-11e8-961e-6ba901913c54.png
>>>>> )
>>>>>
>>>>> What is the  Coordinate Reference System for each case?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Here an example with ncdf4 and raster:
>>>>>
>>>>> library(ncdf4)
>>>>> library(raster)
>>>>> a <- tempfile()
>>>>> download.file(url = "
>>>>>
>> http://www.unidata.ucar.edu/software/netcdf/examples/wrfout_v2_Lambert.nc
>>>>> ",
>>>>>             destfile = a) #78 Mb
>>>>> wrf <- nc_open(a)
>>>>> paste("The file has",wrf$nvars,"variables")
>>>>> paste("The file has",names(wrf$var))
>>>>> lat <- ncvar_get( wrf, "XLAT" )
>>>>> lon <- ncvar_get( wrf, "XLONG" )
>>>>> t2 <- ncvar_get( wrf, "T2" ) - 273.15
>>>>> dim(t2) #73 60 13
>>>>> #image
>>>>> image(t2[, , 12])
>>>>> # raster
>>>>> rt2 <- raster(t(t2[1:dim(t2)[1],
>>>>>                  dim(t2)[2]:1,
>>>>>                  12]),
>>>>>             xmn = min(lon),
>>>>>             xmx = max(lon),
>>>>>             ymn = min(lat),
>>>>>             ymx = max(lat),
>>>>> *              crs="+init=epsg:4326") # ???*
>>>>> spplot(rt2)
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> ​Sergio Ibarra Espinosa
>>>>> Post Doc
>>>>> PhD in Atmospheric Sciences
>>>>> Instituto de Astronomia, Geofísica e Ciências Atmosféricas
>>>>> Universidade de São Paulo
>>>>> Rua do Matão, 1226
>>>>> São Paulo-SP - Brasil -
>>>>> 05508-090
>>>>> +55-11-97425-3791
>>>>> Skype: sergio_ibarra1
>>>>>
>>>>>       [[alternative HTML version deleted]]
>>>>>
>>>>> _______________________________________________
>>>>> R-sig-Geo mailing list
>>>>> [hidden email]
>>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>>>
>>>> --
>>>> Dr. Michael Sumner
>>>> Software and Database Engineer
>>>> Australian Antarctic Division
>>>> 203 Channel Highway
>>>> Kingston Tasmania 7050 Australia
>>>>
>>>>     [[alternative HTML version deleted]]
>>>>
>>>> _______________________________________________
>>>> R-sig-Geo mailing list
>>>> [hidden email]
>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>>
>>>
>>> Ben Tupper
>>> Bigelow Laboratory for Ocean Sciences
>>> 60 Bigelow Drive, P.O. Box 380
>>> East Boothbay, Maine 04544
>>> http://www.bigelow.org
>>>
>>> Ecological Forecasting: https://eco.bigelow.org/
>>>
>>>
>>>
>>>
>>>
>>>
>>>      [[alternative HTML version deleted]]
>>>
>>> _______________________________________________
>>> R-sig-Geo mailing list
>>> [hidden email]
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>
>>
>> --
>> Edzer Pebesma
>> Institute for Geoinformatics
>> Heisenbergstrasse 2, 48151 Muenster, Germany
>> Phone: +49 251 8333081
>>
>> _______________________________________________
>> R-sig-Geo mailing list
>> [hidden email]
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
> --
> Dr. Michael Sumner
> Software and Database Engineer
> Australian Antarctic Division
> 203 Channel Highway
> Kingston Tasmania 7050 Australia
>
> [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>
Ben Tupper
Bigelow Laboratory for Ocean Sciences
60 Bigelow Drive, P.O. Box 380
East Boothbay, Maine 04544
http://www.bigelow.org

Ecological Forecasting: https://eco.bigelow.org/






        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: What is the Coordinate Reference System?

Mon, 06/18/2018 - 05:26
Agree with Edzer this application of eqc is anomalous and after it confused
us initially we now ignore it and apply the unproblematic proj=longlat
interpretation to these products (after checking).

I might explore the L3 products to find out why this occurred, but the
ocean colour forum is the usual place to find discussion.

Cheers, Mike

On Mon, 18 Jun 2018, 15:59 Edzer Pebesma, <[hidden email]>
wrote:

> Plate carree is essentially a linear mapping of long and lat to x and y,
> without changing aspect ratio (scale factor 1 at equator).
>
> projecting long/lat towards plate caree using the proj4 string you
> mention will however change the units from degrees to m. So while the
> plots of of data in linear long/lat (with aspect ration 1) looks
> identical to the one obtained in plate caree (with aspect ratio 1), the
> numerical values along their axes are very different.
>
> Many netcdf files carry a grid (raster) with the x and y coordinates of
> grid cells (centers?) in another coordinate system, but the ones you
> mention below don't, as far as I can tell. I think what they mean by
> mentioning plate carree is just saying that this is a regular long/lat
> degree grid; rather unlucky wording IMO.
>
> On 06/15/2018 08:14 PM, Ben Tupper wrote:
> > Hi,
> >
> > That's an interesting approach.
> >
> > On the other hand, sometimes I get bitten (well, muddled really) when I
> use raster to determine the crs of a ncdf resource.  It all sort of depends.
> >
> > Below is an example for Aqua MODIS imagery from OBPG (
> https://oceandata.sci.gsfc.nasa.gov/MODIS-Aqua/Mapped/Daily/9km/sst/2017/
> <https://oceandata.sci.gsfc.nasa.gov/MODIS-Aqua/Mapped/Daily/9km/sst/2017/>).
> The OBPG docs (https://oceancolor.gsfc.nasa.gov/products/ <
> https://oceancolor.gsfc.nasa.gov/products/>) state that the data is
> served up as 'Plate Carrée' which I think has a crs ...
> >
> > '+proj=eqc +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84
> +datum=WGS84 +units=m +no_defs '
> >
> > ... as described here http://spatialreference.org/ref/epsg/32662/ <
> http://spatialreference.org/ref/epsg/32662/>
> >
> > You can see below that raster comes up with...
> >
> > '+proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0'
> >
> > ... which is http://spatialreference.org/ref/epsg/4326/ <
> http://spatialreference.org/ref/epsg/4326/>
> >
> > Explicitly setting the crs while reading doesn't help.  I have never
> resolved if it is an OBPG documentation bug, my confusion about
> projections, or some other mystery.  So, my usual practice is to assume
> that raster makes the right call.
> >
> > #### start
> >
> > library(raster)
> > URI = '
> https://oceandata.sci.gsfc.nasa.gov/cgi/getfile/A2017175.L3m_DAY_SST_sst_9km.nc
> '
> >
> > # ~3.8MB
> > ok = download.file(URI, basename(URI))
> >
> > R = raster::raster(basename(URI), varname = 'sst')
> > R
> > # class       : RasterLayer
> > # dimensions  : 2160, 4320, 9331200  (nrow, ncol, ncell)
> > # resolution  : 0.08333334, 0.08333334  (x, y)
> > # extent      : -180, 180, -90, 90  (xmin, xmax, ymin, ymax)
> > # coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
> > # data source : /Users/Shared/code/R/others/record/spnc/
> A2017175.L3m_DAY_SST_sst_9km.nc
> > # names       : Sea.Surface.Temperature
> > # zvar        : sst
> >
> > S = raster::raster(basename(URI), varname = "sst", crs = '+proj=eqc
> +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84
> +units=m +no_defs')
> > # Warning message:
> > # In .getProj(prj, crs) :
> > #  argument "crs" ignored because the file provides a crs
> >
> > #### end
> >
> >
> > Cheers,
> > Ben
> >
> >
> >> On Jun 14, 2018, at 6:42 PM, Michael Sumner <[hidden email]> wrote:
> >>
> >> Try raster::projection(raster::raster(a)) first, then delve if necessary
> >> into the ncdump summary with print(raster::raster(a)))
> >>
> >> But, raster(a) may be enough here? To get that stuff more directly from
> the
> >> NetCDF API you have to use the inq and att functions of ncdf4 or RNetCDF
> >> and that's no fun.
> >>
> >> I'd also try raster(rgdal::readGDAL(a)) which is a totally different but
> >> equivalent read path.
> >>
> >> Cheers, Mike
> >>
> >> On Thu, 14 Jun 2018, 11:03 Sergio Ibarra, <[hidden email]>
> wrote:
> >>
> >>> Greetings,
> >>>
> >>> I'm want to read NetCDF spatial data from a meteorological model (WRF
> >>> model). The NetCDF can have one of these three projections:
> >>>
> >>> Polar stereographic
> >>> Lambert conformal
> >>> Mercator projection
> >>>
> >>> (See figure
> >>>
> >>>
> https://user-images.githubusercontent.com/27447280/41389756-ed23f91a-6f68-11e8-961e-6ba901913c54.png
> >>> )
> >>>
> >>> What is the  Coordinate Reference System for each case?
> >>>
> >>> Thanks!
> >>>
> >>> Here an example with ncdf4 and raster:
> >>>
> >>> library(ncdf4)
> >>> library(raster)
> >>> a <- tempfile()
> >>> download.file(url = "
> >>>
> http://www.unidata.ucar.edu/software/netcdf/examples/wrfout_v2_Lambert.nc
> >>> ",
> >>>              destfile = a) #78 Mb
> >>> wrf <- nc_open(a)
> >>> paste("The file has",wrf$nvars,"variables")
> >>> paste("The file has",names(wrf$var))
> >>> lat <- ncvar_get( wrf, "XLAT" )
> >>> lon <- ncvar_get( wrf, "XLONG" )
> >>> t2 <- ncvar_get( wrf, "T2" ) - 273.15
> >>> dim(t2) #73 60 13
> >>> #image
> >>> image(t2[, , 12])
> >>> # raster
> >>> rt2 <- raster(t(t2[1:dim(t2)[1],
> >>>                   dim(t2)[2]:1,
> >>>                   12]),
> >>>              xmn = min(lon),
> >>>              xmx = max(lon),
> >>>              ymn = min(lat),
> >>>              ymx = max(lat),
> >>> *              crs="+init=epsg:4326") # ???*
> >>> spplot(rt2)
> >>>
> >>>
> >>>
> >>> --
> >>> ​Sergio Ibarra Espinosa
> >>> Post Doc
> >>> PhD in Atmospheric Sciences
> >>> Instituto de Astronomia, Geofísica e Ciências Atmosféricas
> >>> Universidade de São Paulo
> >>> Rua do Matão, 1226
> >>> São Paulo-SP - Brasil -
> >>> 05508-090
> >>> +55-11-97425-3791
> >>> Skype: sergio_ibarra1
> >>>
> >>>        [[alternative HTML version deleted]]
> >>>
> >>> _______________________________________________
> >>> R-sig-Geo mailing list
> >>> [hidden email]
> >>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >>>
> >> --
> >> Dr. Michael Sumner
> >> Software and Database Engineer
> >> Australian Antarctic Division
> >> 203 Channel Highway
> >> Kingston Tasmania 7050 Australia
> >>
> >>      [[alternative HTML version deleted]]
> >>
> >> _______________________________________________
> >> R-sig-Geo mailing list
> >> [hidden email]
> >> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >>
> >
> > Ben Tupper
> > Bigelow Laboratory for Ocean Sciences
> > 60 Bigelow Drive, P.O. Box 380
> > East Boothbay, Maine 04544
> > http://www.bigelow.org
> >
> > Ecological Forecasting: https://eco.bigelow.org/
> >
> >
> >
> >
> >
> >
> >       [[alternative HTML version deleted]]
> >
> > _______________________________________________
> > R-sig-Geo mailing list
> > [hidden email]
> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >
>
> --
> Edzer Pebesma
> Institute for Geoinformatics
> Heisenbergstrasse 2, 48151 Muenster, Germany
> Phone: +49 251 8333081
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> --
Dr. Michael Sumner
Software and Database Engineer
Australian Antarctic Division
203 Channel Highway
Kingston Tasmania 7050 Australia

        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: What is the Coordinate Reference System?

Mon, 06/18/2018 - 03:59
Plate carree is essentially a linear mapping of long and lat to x and y,
without changing aspect ratio (scale factor 1 at equator).

projecting long/lat towards plate caree using the proj4 string you
mention will however change the units from degrees to m. So while the
plots of of data in linear long/lat (with aspect ration 1) looks
identical to the one obtained in plate caree (with aspect ratio 1), the
numerical values along their axes are very different.

Many netcdf files carry a grid (raster) with the x and y coordinates of
grid cells (centers?) in another coordinate system, but the ones you
mention below don't, as far as I can tell. I think what they mean by
mentioning plate carree is just saying that this is a regular long/lat
degree grid; rather unlucky wording IMO.

On 06/15/2018 08:14 PM, Ben Tupper wrote:
> Hi,
>
> That's an interesting approach.  
>
> On the other hand, sometimes I get bitten (well, muddled really) when I use raster to determine the crs of a ncdf resource.  It all sort of depends.
>
> Below is an example for Aqua MODIS imagery from OBPG (https://oceandata.sci.gsfc.nasa.gov/MODIS-Aqua/Mapped/Daily/9km/sst/2017/ <https://oceandata.sci.gsfc.nasa.gov/MODIS-Aqua/Mapped/Daily/9km/sst/2017/>).  The OBPG docs (https://oceancolor.gsfc.nasa.gov/products/ <https://oceancolor.gsfc.nasa.gov/products/>) state that the data is served up as 'Plate Carrée' which I think has a crs ...
>
> '+proj=eqc +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs '
>
> ... as described here http://spatialreference.org/ref/epsg/32662/ <http://spatialreference.org/ref/epsg/32662/>
>
> You can see below that raster comes up with...
>
> '+proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0'
>
> ... which is http://spatialreference.org/ref/epsg/4326/ <http://spatialreference.org/ref/epsg/4326/>
>
> Explicitly setting the crs while reading doesn't help.  I have never resolved if it is an OBPG documentation bug, my confusion about projections, or some other mystery.  So, my usual practice is to assume that raster makes the right call.
>
> #### start
>
> library(raster)
> URI = 'https://oceandata.sci.gsfc.nasa.gov/cgi/getfile/A2017175.L3m_DAY_SST_sst_9km.nc'
>
> # ~3.8MB
> ok = download.file(URI, basename(URI))
>
> R = raster::raster(basename(URI), varname = 'sst')
> R
> # class       : RasterLayer
> # dimensions  : 2160, 4320, 9331200  (nrow, ncol, ncell)
> # resolution  : 0.08333334, 0.08333334  (x, y)
> # extent      : -180, 180, -90, 90  (xmin, xmax, ymin, ymax)
> # coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
> # data source : /Users/Shared/code/R/others/record/spnc/A2017175.L3m_DAY_SST_sst_9km.nc
> # names       : Sea.Surface.Temperature
> # zvar        : sst
>
> S = raster::raster(basename(URI), varname = "sst", crs = '+proj=eqc +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs')
> # Warning message:
> # In .getProj(prj, crs) :
> #  argument "crs" ignored because the file provides a crs
>
> #### end
>
>
> Cheers,
> Ben
>
>
>> On Jun 14, 2018, at 6:42 PM, Michael Sumner <[hidden email]> wrote:
>>
>> Try raster::projection(raster::raster(a)) first, then delve if necessary
>> into the ncdump summary with print(raster::raster(a)))
>>
>> But, raster(a) may be enough here? To get that stuff more directly from the
>> NetCDF API you have to use the inq and att functions of ncdf4 or RNetCDF
>> and that's no fun.
>>
>> I'd also try raster(rgdal::readGDAL(a)) which is a totally different but
>> equivalent read path.
>>
>> Cheers, Mike
>>
>> On Thu, 14 Jun 2018, 11:03 Sergio Ibarra, <[hidden email]> wrote:
>>
>>> Greetings,
>>>
>>> I'm want to read NetCDF spatial data from a meteorological model (WRF
>>> model). The NetCDF can have one of these three projections:
>>>
>>> Polar stereographic
>>> Lambert conformal
>>> Mercator projection
>>>
>>> (See figure
>>>
>>> https://user-images.githubusercontent.com/27447280/41389756-ed23f91a-6f68-11e8-961e-6ba901913c54.png
>>> )
>>>
>>> What is the  Coordinate Reference System for each case?
>>>
>>> Thanks!
>>>
>>> Here an example with ncdf4 and raster:
>>>
>>> library(ncdf4)
>>> library(raster)
>>> a <- tempfile()
>>> download.file(url = "
>>> http://www.unidata.ucar.edu/software/netcdf/examples/wrfout_v2_Lambert.nc
>>> ",
>>>              destfile = a) #78 Mb
>>> wrf <- nc_open(a)
>>> paste("The file has",wrf$nvars,"variables")
>>> paste("The file has",names(wrf$var))
>>> lat <- ncvar_get( wrf, "XLAT" )
>>> lon <- ncvar_get( wrf, "XLONG" )
>>> t2 <- ncvar_get( wrf, "T2" ) - 273.15
>>> dim(t2) #73 60 13
>>> #image
>>> image(t2[, , 12])
>>> # raster
>>> rt2 <- raster(t(t2[1:dim(t2)[1],
>>>                   dim(t2)[2]:1,
>>>                   12]),
>>>              xmn = min(lon),
>>>              xmx = max(lon),
>>>              ymn = min(lat),
>>>              ymx = max(lat),
>>> *              crs="+init=epsg:4326") # ???*
>>> spplot(rt2)
>>>
>>>
>>>
>>> --
>>> ​Sergio Ibarra Espinosa
>>> Post Doc
>>> PhD in Atmospheric Sciences
>>> Instituto de Astronomia, Geofísica e Ciências Atmosféricas
>>> Universidade de São Paulo
>>> Rua do Matão, 1226
>>> São Paulo-SP - Brasil -
>>> 05508-090
>>> +55-11-97425-3791
>>> Skype: sergio_ibarra1
>>>
>>>        [[alternative HTML version deleted]]
>>>
>>> _______________________________________________
>>> R-sig-Geo mailing list
>>> [hidden email]
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>
>> --
>> Dr. Michael Sumner
>> Software and Database Engineer
>> Australian Antarctic Division
>> 203 Channel Highway
>> Kingston Tasmania 7050 Australia
>>
>> [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> R-sig-Geo mailing list
>> [hidden email]
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>
> Ben Tupper
> Bigelow Laboratory for Ocean Sciences
> 60 Bigelow Drive, P.O. Box 380
> East Boothbay, Maine 04544
> http://www.bigelow.org
>
> Ecological Forecasting: https://eco.bigelow.org/
>
>
>
>
>
>
> [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>
--
Edzer Pebesma
Institute for Geoinformatics
Heisenbergstrasse 2, 48151 Muenster, Germany
Phone: +49 251 8333081

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Call for manuscripts "Technological and Methodological Advances in Measuring, Mapping and Monitoring Soil Carbon and Nutrients in Space and Spacetime" Special issue in Nutrient Cycling in Agroecosystems Journal

Mon, 06/18/2018 - 02:56

This is the first call for manuscripts for a special issue
"Technological and Methodological Advances in Measuring, Mapping and
Monitoring Soil Carbon and Nutrients in Space and Spacetime" Nutrient
Cycling in Agroecosystems Journal (https://link.springer.com/journal/10705).

We aim at producing a special issue listing good practice examples of
how novel technologies such as soil sensing and image recognition,
automated sensor networks, unmanned aerial vehicles (UAVs) and publicly
available remote sensing products (such as NASA's Landsat 7 & 8 and
ASTER missions, ESA's Sentinel 2 and other Copernicus land products,
JAXA's Advanced Land Observing Satellite ALOS, LiDAR, TanDEMx and
similar missions), in combination with statistical / machine learning,
data mining and high performance computing, can be used to generate most
accurate maps of soil carbon and soil nutrients in space and spacetime.

We require that all articles submitted for this issue come with
documented computational steps (code) and/or data processing tutorials
which are available publicly (github, Rpubs, Launchpad, Bitbucket or
similar) and can be used to reproduce at least 2/3rd of key results (key
tabular and graphical results). This corresponds to Level 2 or 3
standards of the Reproducible Research as defined in
http://dx.doi.org/10.1126/science.aab2374

First five (5) accepted papers for this special issue will be awarded a
waived registration fees (names to be chosen by the contact author of
the accepted paper) at the next OpenGeoHub Summer School 2019 (former
GEOSTAT Summer School, see: https://geostat-course.org/2018).

For more information refer to: http://opengeohub.org/

Special issue editors: T. (Tom) Hengl, M. (Madlene) Nussbaum and P.
(Pierre) Roudier
Editor-in-Chief: J. (Johannes) Lehmann

Important dates:

- First call: 2018, June 1st.
- Manuscript submission until 2018, December 1st.
- Manuscript evaluation until 2019, February 20th.
- Special issue publication in 2019, March.

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: rgdal installation on Fedora 28

Sun, 06/17/2018 - 10:51
Barry,

No, and it's not that easy. Matching GDAL and PROJ versions, source or binary, multiplies the combinations, and putting aws instances into a box is hard (was missing ldconfig of /usr/local, not rgdal). Docker is always a heavy download, and doesn't work for me on the road and my laptop.

A network of actual users  with problems is arguably as efficient, and includes those with problems in looking for solutions, which is harder for a system solution to do. I for example do not know how to configure R and GDAL versions in a container with Fedora despite doing Dirk's workshop, where we used pre-configured Debian systems.

Somehow people come out of this quite well, don't they?

Just some thoughts,

Roger

Roger Bivand
Norwegian School of Economics
Bergen, Norway



Fra: Barry Rowlingson
Sendt: søndag 17. juni, 16.13
Emne: Re: [R-sig-Geo] rgdal installation on Fedora 28
Til: Sarah Goslee
Kopi: Roger Bivand, r-sig-geo


Just a quick note to point out that you can test installations on systems without having to install such a system by using Docker. Fedora 28 images are available on Docker Hub.

You have to figure out how to install the toolchain and other components for building R etc but that helps make a reproducible installation procedure.

Is everyone doing this already?

Barry


On Sun, Jun 17, 2018 at 2:50 PM, Sarah Goslee <[hidden email]<mailto:[hidden email]>> wrote:
I can confirm that the patched R-Forge version of rgdal installs
correctly on my systems with no other change.

Thank you to Roger and Colin, and everyone else who took a look. The R
community is the BEST.

Sarah

On Sat, Jun 16, 2018 at 5:55 PM, Roger Bivand <[hidden email]<mailto:[hidden email]>> wrote:
> On Sat, 16 Jun 2018, Colin Rundel wrote:
>
>> As I mentioned in the tweet, I was able to fix this on both a Fedora 23
>> and
>> Fedora 27 machine by making the following change to configure.ac<http://configure.ac>:
>>
>> diff --git a/configure.ac<http://configure.ac> b/configure.ac<http://configure.ac>
>> index 8ff72be..ab4c772 100644
>> --- a/configure.ac<http://configure.ac>
>> +++ b/configure.ac<http://configure.ac>
>> @@ -3,6 +3,8 @@ define([pkgversion], esyscmd([sh -c "grep Version:
>> DESCRIPTION | cut -d' ' -f2 |
>> AC_INIT(rgdal, [pkgversion], [hidden email]<mailto:[hidden email]>)
>> AC_CONFIG_SRCDIR(src/gdal-bindings.cpp)
>>
>> +AC_PROG_CXX()
>> +
>> # find R home and set correct compiler + flags
>> : ${R_HOME=`R RHOME`}
>> if test -z "${R_HOME}"; then
>>
>> rerunning autoconf (also assuming m4/ax_cxx_compile_stdcxx.m4 is added)
>> results in ./configure working for me. I don't have a deep enough
>> understanding of the vagaries of autoconf to know why exactly this is
>> necessary on redhat systems and why this fixes it but at least everything
>> seems to work.
>
>
> Thanks very much, committed to R-forge as revision 758.
>
> Roger
>
>
>>
>> -Colin
>>
>> On Fri, Jun 15, 2018 at 7:29 PM Thiago V. dos Santos via R-sig-Geo <
>> [hidden email]<mailto:[hidden email]>> wrote:
>>
>>> The following lines in your config.log:
>>>
>>> /usr/bin/ld: /tmp/cc9pfZ1b.o: relocation R_X86_64_32 against .rodata' can
>>> not be used when making a shared object; recompile with -fPIC
>>>
>>> make me wonder: maybe there is a -fPIC compilation flag lacking for you
>>> platform in the makefile?
>>>
>>> Greetings, -- Thiago V. dos Santos
>>> Postdoctoral Research FellowDepartment of Climate and Space Science and
>>> EngineeringUniversity of Michigan
>>>
>>>     On Friday, June 15, 2018, 3:27:44 PM EDT, Sarah Goslee <
>>> [hidden email]<mailto:[hidden email]>> wrote:
>>>
>>>  Hi folks,
>>>
>>> I updated all of my linux computers to Fedora 28, and now can’t install
>>> rgdal.
>>>
>>> I can install sf with no problems, so it doesn't appear to be an issue
>>> with GDAL or with proj.
>>>
>>> I checked with Roger Bivand, the package maintainer, who asked me to
>>> confirm whether I could install sf, to make sure it wasn’t a
>>> dependency issue, and to post the logs online, then ask on the
>>> R-sig-geo mailing list. I’m putting the full problem here, and the
>>> abbreviated version on the mailing list.
>>>
>>> I’d appreciate any thoughts: I rely very heavily on the incredibly
>>> useful rgdal package.
>>>
>>>> sessionInfo()
>>>
>>> R version 3.5.0 (2018-04-23)
>>> Platform: x86_64-redhat-linux-gnu (64-bit)
>>> Running under: Fedora 28 (Workstation Edition)
>>>
>>> Matrix products: default
>>> BLAS/LAPACK: /usr/lib64/R/lib/libRblas.so
>>>
>>> locale:
>>>  [1] LC_CTYPE=en_US.UTF-8      LC_NUMERIC=C
>>>  [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
>>>  [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
>>>  [7] LC_PAPER=en_US.UTF-8      LC_NAME=C
>>>  [9] LC_ADDRESS=C              LC_TELEPHONE=C
>>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>>>
>>> attached base packages:
>>> [1] stats    graphics  grDevices utils    datasets  methods  base
>>>
>>> loaded via a namespace (and not attached):
>>> [1] compiler_3.5.0 tools_3.5.0</code>
>>>
>>>
>>> The install message is:
>>>
>>> installing *source* package ‘rgdal’ ...
>>> ** package ‘rgdal’ successfully unpacked and MD5 sums checked
>>> configure: CC: gcc -m64
>>> configure: CXX: g++ -m64
>>> configure: rgdal: 1.3-2
>>> checking for /usr/bin/svnversion... no
>>> configure: svn revision: 755
>>> checking whether the C++ compiler works... yes
>>> checking for C++ compiler default output file name... a.out
>>> checking for suffix of executables...
>>> checking whether we are cross compiling... configure: error: in
>>> `/tmp/RtmpfMGBY5/R.INSTALL66c3b8deddb/rgdal':
>>> configure: error: cannot run C++ compiled programs.
>>> If you meant to cross compile, use `--host'.
>>> See `config.log' for more details
>>> ERROR: configuration failed for package ‘rgdal’
>>> * removing ‘/usr/lib64/R/library/rgdal’
>>> * restoring previous ‘/usr/lib64/R/library/rgdal’
>>>
>>>
>>> The complete information and config.log are posted online at:
>>>
>>> http://numberwright.com/2018/06/stuck-on-rgdal/
>>>
>>>
>>> Any ideas? Or any other information that would be useful?
>>>
>>> Thanks!
>>> Sarah
>>>
_______________________________________________
R-sig-Geo mailing list
[hidden email]<mailto:[hidden email]>
https://stat.ethz.ch/mailman/listinfo/r-sig-geo




        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Roger Bivand
Department of Economics
Norwegian School of Economics
Helleveien 30
N-5045 Bergen, Norway

Re: rgdal installation on Fedora 28

Sun, 06/17/2018 - 10:13
Just a quick note to point out that you can test installations on systems
without having to install such a system by using Docker. Fedora 28 images
are available on Docker Hub.

You have to figure out how to install the toolchain and other components
for building R etc but that helps make a reproducible installation
procedure.

Is everyone doing this already?

Barry


On Sun, Jun 17, 2018 at 2:50 PM, Sarah Goslee <[hidden email]>
wrote:

> I can confirm that the patched R-Forge version of rgdal installs
> correctly on my systems with no other change.
>
> Thank you to Roger and Colin, and everyone else who took a look. The R
> community is the BEST.
>
> Sarah
>
> On Sat, Jun 16, 2018 at 5:55 PM, Roger Bivand <[hidden email]> wrote:
> > On Sat, 16 Jun 2018, Colin Rundel wrote:
> >
> >> As I mentioned in the tweet, I was able to fix this on both a Fedora 23
> >> and
> >> Fedora 27 machine by making the following change to configure.ac:
> >>
> >> diff --git a/configure.ac b/configure.ac
> >> index 8ff72be..ab4c772 100644
> >> --- a/configure.ac
> >> +++ b/configure.ac
> >> @@ -3,6 +3,8 @@ define([pkgversion], esyscmd([sh -c "grep Version:
> >> DESCRIPTION | cut -d' ' -f2 |
> >> AC_INIT(rgdal, [pkgversion], [hidden email])
> >> AC_CONFIG_SRCDIR(src/gdal-bindings.cpp)
> >>
> >> +AC_PROG_CXX()
> >> +
> >> # find R home and set correct compiler + flags
> >> : ${R_HOME=`R RHOME`}
> >> if test -z "${R_HOME}"; then
> >>
> >> rerunning autoconf (also assuming m4/ax_cxx_compile_stdcxx.m4 is added)
> >> results in ./configure working for me. I don't have a deep enough
> >> understanding of the vagaries of autoconf to know why exactly this is
> >> necessary on redhat systems and why this fixes it but at least
> everything
> >> seems to work.
> >
> >
> > Thanks very much, committed to R-forge as revision 758.
> >
> > Roger
> >
> >
> >>
> >> -Colin
> >>
> >> On Fri, Jun 15, 2018 at 7:29 PM Thiago V. dos Santos via R-sig-Geo <
> >> [hidden email]> wrote:
> >>
> >>> The following lines in your config.log:
> >>>
> >>> /usr/bin/ld: /tmp/cc9pfZ1b.o: relocation R_X86_64_32 against .rodata'
> can
> >>> not be used when making a shared object; recompile with -fPIC
> >>>
> >>> make me wonder: maybe there is a -fPIC compilation flag lacking for you
> >>> platform in the makefile?
> >>>
> >>> Greetings, -- Thiago V. dos Santos
> >>> Postdoctoral Research FellowDepartment of Climate and Space Science and
> >>> EngineeringUniversity of Michigan
> >>>
> >>>     On Friday, June 15, 2018, 3:27:44 PM EDT, Sarah Goslee <
> >>> [hidden email]> wrote:
> >>>
> >>>  Hi folks,
> >>>
> >>> I updated all of my linux computers to Fedora 28, and now can’t install
> >>> rgdal.
> >>>
> >>> I can install sf with no problems, so it doesn't appear to be an issue
> >>> with GDAL or with proj.
> >>>
> >>> I checked with Roger Bivand, the package maintainer, who asked me to
> >>> confirm whether I could install sf, to make sure it wasn’t a
> >>> dependency issue, and to post the logs online, then ask on the
> >>> R-sig-geo mailing list. I’m putting the full problem here, and the
> >>> abbreviated version on the mailing list.
> >>>
> >>> I’d appreciate any thoughts: I rely very heavily on the incredibly
> >>> useful rgdal package.
> >>>
> >>>> sessionInfo()
> >>>
> >>> R version 3.5.0 (2018-04-23)
> >>> Platform: x86_64-redhat-linux-gnu (64-bit)
> >>> Running under: Fedora 28 (Workstation Edition)
> >>>
> >>> Matrix products: default
> >>> BLAS/LAPACK: /usr/lib64/R/lib/libRblas.so
> >>>
> >>> locale:
> >>>  [1] LC_CTYPE=en_US.UTF-8      LC_NUMERIC=C
> >>>  [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
> >>>  [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
> >>>  [7] LC_PAPER=en_US.UTF-8      LC_NAME=C
> >>>  [9] LC_ADDRESS=C              LC_TELEPHONE=C
> >>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
> >>>
> >>> attached base packages:
> >>> [1] stats    graphics  grDevices utils    datasets  methods  base
> >>>
> >>> loaded via a namespace (and not attached):
> >>> [1] compiler_3.5.0 tools_3.5.0</code>
> >>>
> >>>
> >>> The install message is:
> >>>
> >>> installing *source* package ‘rgdal’ ...
> >>> ** package ‘rgdal’ successfully unpacked and MD5 sums checked
> >>> configure: CC: gcc -m64
> >>> configure: CXX: g++ -m64
> >>> configure: rgdal: 1.3-2
> >>> checking for /usr/bin/svnversion... no
> >>> configure: svn revision: 755
> >>> checking whether the C++ compiler works... yes
> >>> checking for C++ compiler default output file name... a.out
> >>> checking for suffix of executables...
> >>> checking whether we are cross compiling... configure: error: in
> >>> `/tmp/RtmpfMGBY5/R.INSTALL66c3b8deddb/rgdal':
> >>> configure: error: cannot run C++ compiled programs.
> >>> If you meant to cross compile, use `--host'.
> >>> See `config.log' for more details
> >>> ERROR: configuration failed for package ‘rgdal’
> >>> * removing ‘/usr/lib64/R/library/rgdal’
> >>> * restoring previous ‘/usr/lib64/R/library/rgdal’
> >>>
> >>>
> >>> The complete information and config.log are posted online at:
> >>>
> >>> http://numberwright.com/2018/06/stuck-on-rgdal/
> >>>
> >>>
> >>> Any ideas? Or any other information that would be useful?
> >>>
> >>> Thanks!
> >>> Sarah
> >>>
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>
        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: rgdal installation on Fedora 28

Sun, 06/17/2018 - 08:56
Sarah, thanks for checking and reporting back!

Roger

Roger Bivand
Norwegian School of Economics
Bergen, Norway



Fra: Sarah Goslee
Sendt: søndag 17. juni, 14.50
Emne: Re: [R-sig-Geo] rgdal installation on Fedora 28
Til: Roger Bivand
Kopi: Colin Rundel, [hidden email]


I can confirm that the patched R-Forge version of rgdal installs correctly on my systems with no other change. Thank you to Roger and Colin, and everyone else who took a look. The R community is the BEST. Sarah On Sat, Jun 16, 2018 at 5:55 PM, Roger Bivand wrote: > On Sat, 16 Jun 2018, Colin Rundel wrote: > >> As I mentioned in the tweet, I was able to fix this on both a Fedora 23 >> and >> Fedora 27 machine by making the following change to configure.ac: >> >> diff --git a/configure.ac b/configure.ac >> index 8ff72be..ab4c772 100644 >> --- a/configure.ac >> +++ b/configure.ac >> @@ -3,6 +3,8 @@ define([pkgversion], esyscmd([sh -c "grep Version: >> DESCRIPTION | cut -d' ' -f2 | >> AC_INIT(rgdal, [pkgversion], [hidden email]) >> AC_CONFIG_SRCDIR(src/gdal-bindings.cpp) >> >> +AC_PROG_CXX() >> + >> # find R home and set correct compiler + flags >> : ${R_HOME=`R RHOME`} >> if test -z "${R_HOME}"; then >> >> rerunning autoconf (also assuming m4/ax_cxx_compile_stdcxx.m4 is added) >> results in ./configure working for me. I don't have a deep enough >> understanding of the vagaries of autoconf to know why exactly this is >> necessary on redhat systems and why this fixes it but at least everything >> seems to work. > > > Thanks very much, committed to R-forge as revision 758. > > Roger > > >> >> -Colin >> >> On Fri, Jun 15, 2018 at 7:29 PM Thiago V. dos Santos via R-sig-Geo < >> [hidden email]> wrote: >> >>> The following lines in your config.log: >>> >>> /usr/bin/ld: /tmp/cc9pfZ1b.o: relocation R_X86_64_32 against .rodata' can >>> not be used when making a shared object; recompile with -fPIC >>> >>> make me wonder: maybe there is a -fPIC compilation flag lacking for you >>> platform in the makefile? >>> >>> Greetings, -- Thiago V. dos Santos >>> Postdoctoral Research FellowDepartment of Climate and Space Science and >>> EngineeringUniversity of Michigan >>> >>> On Friday, June 15, 2018, 3:27:44 PM EDT, Sarah Goslee < >>> [hidden email]> wrote: >>> >>> Hi folks, >>> >>> I updated all of my linux computers to Fedora 28, and now can’t install >>> rgdal. >>> >>> I can install sf with no problems, so it doesn't appear to be an issue >>> with GDAL or with proj. >>> >>> I checked with Roger Bivand, the package maintainer, who asked me to >>> confirm whether I could install sf, to make sure it wasn’t a >>> dependency issue, and to post the logs online, then ask on the >>> R-sig-geo mailing list. I’m putting the full problem here, and the >>> abbreviated version on the mailing list. >>> >>> I’d appreciate any thoughts: I rely very heavily on the incredibly >>> useful rgdal package. >>> >>>> sessionInfo() >>> >>> R version 3.5.0 (2018-04-23) >>> Platform: x86_64-redhat-linux-gnu (64-bit) >>> Running under: Fedora 28 (Workstation Edition) >>> >>> Matrix products: default >>> BLAS/LAPACK: /usr/lib64/R/lib/libRblas.so >>> >>> locale: >>> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C >>> [3] LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 >>> [5] LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 >>> [7] LC_PAPER=en_US.UTF-8 LC_NAME=C >>> [9] LC_ADDRESS=C LC_TELEPHONE=C >>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C >>> >>> attached base packages: >>> [1] stats graphics grDevices utils datasets methods base >>> >>> loaded via a namespace (and not attached): >>> [1] compiler_3.5.0 tools_3.5.0 >>> >>> >>> The install message is: >>> >>> installing *source* package ‘rgdal’ ... >>> ** package ‘rgdal’ successfully unpacked and MD5 sums checked >>> configure: CC: gcc -m64 >>> configure: CXX: g++ -m64 >>> configure: rgdal: 1.3-2 >>> checking for /usr/bin/svnversion... no >>> configure: svn revision: 755 >>> checking whether the C++ compiler works... yes >>> checking for C++ compiler default output file name... a.out >>> checking for suffix of executables... >>> checking whether we are cross compiling... configure: error: in >>> `/tmp/RtmpfMGBY5/R.INSTALL66c3b8deddb/rgdal': >>> configure: error: cannot run C++ compiled programs. >>> If you meant to cross compile, use `--host'. >>> See `config.log' for more details >>> ERROR: configuration failed for package ‘rgdal’ >>> * removing ‘/usr/lib64/R/library/rgdal’ >>> * restoring previous ‘/usr/lib64/R/library/rgdal’ >>> >>> >>> The complete information and config.log are posted online at: >>> >>> http://numberwright.com/2018/06/stuck-on-rgdal/ >>> >>> >>> Any ideas? Or any other information that would be useful? >>> >>> Thanks! >>> Sarah >>>


        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Roger Bivand
Department of Economics
Norwegian School of Economics
Helleveien 30
N-5045 Bergen, Norway

Re: rgdal installation on Fedora 28

Sun, 06/17/2018 - 08:50
I can confirm that the patched R-Forge version of rgdal installs
correctly on my systems with no other change.

Thank you to Roger and Colin, and everyone else who took a look. The R
community is the BEST.

Sarah

On Sat, Jun 16, 2018 at 5:55 PM, Roger Bivand <[hidden email]> wrote:
> On Sat, 16 Jun 2018, Colin Rundel wrote:
>
>> As I mentioned in the tweet, I was able to fix this on both a Fedora 23
>> and
>> Fedora 27 machine by making the following change to configure.ac:
>>
>> diff --git a/configure.ac b/configure.ac
>> index 8ff72be..ab4c772 100644
>> --- a/configure.ac
>> +++ b/configure.ac
>> @@ -3,6 +3,8 @@ define([pkgversion], esyscmd([sh -c "grep Version:
>> DESCRIPTION | cut -d' ' -f2 |
>> AC_INIT(rgdal, [pkgversion], [hidden email])
>> AC_CONFIG_SRCDIR(src/gdal-bindings.cpp)
>>
>> +AC_PROG_CXX()
>> +
>> # find R home and set correct compiler + flags
>> : ${R_HOME=`R RHOME`}
>> if test -z "${R_HOME}"; then
>>
>> rerunning autoconf (also assuming m4/ax_cxx_compile_stdcxx.m4 is added)
>> results in ./configure working for me. I don't have a deep enough
>> understanding of the vagaries of autoconf to know why exactly this is
>> necessary on redhat systems and why this fixes it but at least everything
>> seems to work.
>
>
> Thanks very much, committed to R-forge as revision 758.
>
> Roger
>
>
>>
>> -Colin
>>
>> On Fri, Jun 15, 2018 at 7:29 PM Thiago V. dos Santos via R-sig-Geo <
>> [hidden email]> wrote:
>>
>>> The following lines in your config.log:
>>>
>>> /usr/bin/ld: /tmp/cc9pfZ1b.o: relocation R_X86_64_32 against .rodata' can
>>> not be used when making a shared object; recompile with -fPIC
>>>
>>> make me wonder: maybe there is a -fPIC compilation flag lacking for you
>>> platform in the makefile?
>>>
>>> Greetings, -- Thiago V. dos Santos
>>> Postdoctoral Research FellowDepartment of Climate and Space Science and
>>> EngineeringUniversity of Michigan
>>>
>>>     On Friday, June 15, 2018, 3:27:44 PM EDT, Sarah Goslee <
>>> [hidden email]> wrote:
>>>
>>>  Hi folks,
>>>
>>> I updated all of my linux computers to Fedora 28, and now can’t install
>>> rgdal.
>>>
>>> I can install sf with no problems, so it doesn't appear to be an issue
>>> with GDAL or with proj.
>>>
>>> I checked with Roger Bivand, the package maintainer, who asked me to
>>> confirm whether I could install sf, to make sure it wasn’t a
>>> dependency issue, and to post the logs online, then ask on the
>>> R-sig-geo mailing list. I’m putting the full problem here, and the
>>> abbreviated version on the mailing list.
>>>
>>> I’d appreciate any thoughts: I rely very heavily on the incredibly
>>> useful rgdal package.
>>>
>>>> sessionInfo()
>>>
>>> R version 3.5.0 (2018-04-23)
>>> Platform: x86_64-redhat-linux-gnu (64-bit)
>>> Running under: Fedora 28 (Workstation Edition)
>>>
>>> Matrix products: default
>>> BLAS/LAPACK: /usr/lib64/R/lib/libRblas.so
>>>
>>> locale:
>>>  [1] LC_CTYPE=en_US.UTF-8      LC_NUMERIC=C
>>>  [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
>>>  [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
>>>  [7] LC_PAPER=en_US.UTF-8      LC_NAME=C
>>>  [9] LC_ADDRESS=C              LC_TELEPHONE=C
>>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>>>
>>> attached base packages:
>>> [1] stats    graphics  grDevices utils    datasets  methods  base
>>>
>>> loaded via a namespace (and not attached):
>>> [1] compiler_3.5.0 tools_3.5.0</code>
>>>
>>>
>>> The install message is:
>>>
>>> installing *source* package ‘rgdal’ ...
>>> ** package ‘rgdal’ successfully unpacked and MD5 sums checked
>>> configure: CC: gcc -m64
>>> configure: CXX: g++ -m64
>>> configure: rgdal: 1.3-2
>>> checking for /usr/bin/svnversion... no
>>> configure: svn revision: 755
>>> checking whether the C++ compiler works... yes
>>> checking for C++ compiler default output file name... a.out
>>> checking for suffix of executables...
>>> checking whether we are cross compiling... configure: error: in
>>> `/tmp/RtmpfMGBY5/R.INSTALL66c3b8deddb/rgdal':
>>> configure: error: cannot run C++ compiled programs.
>>> If you meant to cross compile, use `--host'.
>>> See `config.log' for more details
>>> ERROR: configuration failed for package ‘rgdal’
>>> * removing ‘/usr/lib64/R/library/rgdal’
>>> * restoring previous ‘/usr/lib64/R/library/rgdal’
>>>
>>>
>>> The complete information and config.log are posted online at:
>>>
>>> http://numberwright.com/2018/06/stuck-on-rgdal/
>>>
>>>
>>> Any ideas? Or any other information that would be useful?
>>>
>>> Thanks!
>>> Sarah
>>>
_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: rgdal installation on Fedora 28

Sat, 06/16/2018 - 16:55
On Sat, 16 Jun 2018, Colin Rundel wrote:

> As I mentioned in the tweet, I was able to fix this on both a Fedora 23 and
> Fedora 27 machine by making the following change to configure.ac:
>
> diff --git a/configure.ac b/configure.ac
> index 8ff72be..ab4c772 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -3,6 +3,8 @@ define([pkgversion], esyscmd([sh -c "grep Version:
> DESCRIPTION | cut -d' ' -f2 |
> AC_INIT(rgdal, [pkgversion], [hidden email])
> AC_CONFIG_SRCDIR(src/gdal-bindings.cpp)
>
> +AC_PROG_CXX()
> +
> # find R home and set correct compiler + flags
> : ${R_HOME=`R RHOME`}
> if test -z "${R_HOME}"; then
>
> rerunning autoconf (also assuming m4/ax_cxx_compile_stdcxx.m4 is added)
> results in ./configure working for me. I don't have a deep enough
> understanding of the vagaries of autoconf to know why exactly this is
> necessary on redhat systems and why this fixes it but at least everything
> seems to work. Thanks very much, committed to R-forge as revision 758.

Roger

>
> -Colin
>
> On Fri, Jun 15, 2018 at 7:29 PM Thiago V. dos Santos via R-sig-Geo <
> [hidden email]> wrote:
>
>> The following lines in your config.log:
>>
>> /usr/bin/ld: /tmp/cc9pfZ1b.o: relocation R_X86_64_32 against .rodata' can
>> not be used when making a shared object; recompile with -fPIC
>>
>> make me wonder: maybe there is a -fPIC compilation flag lacking for you
>> platform in the makefile?
>>
>> Greetings, -- Thiago V. dos Santos
>> Postdoctoral Research FellowDepartment of Climate and Space Science and
>> EngineeringUniversity of Michigan
>>
>>     On Friday, June 15, 2018, 3:27:44 PM EDT, Sarah Goslee <
>> [hidden email]> wrote:
>>
>>  Hi folks,
>>
>> I updated all of my linux computers to Fedora 28, and now can’t install
>> rgdal.
>>
>> I can install sf with no problems, so it doesn't appear to be an issue
>> with GDAL or with proj.
>>
>> I checked with Roger Bivand, the package maintainer, who asked me to
>> confirm whether I could install sf, to make sure it wasn’t a
>> dependency issue, and to post the logs online, then ask on the
>> R-sig-geo mailing list. I’m putting the full problem here, and the
>> abbreviated version on the mailing list.
>>
>> I’d appreciate any thoughts: I rely very heavily on the incredibly
>> useful rgdal package.
>>
>>> sessionInfo()
>> R version 3.5.0 (2018-04-23)
>> Platform: x86_64-redhat-linux-gnu (64-bit)
>> Running under: Fedora 28 (Workstation Edition)
>>
>> Matrix products: default
>> BLAS/LAPACK: /usr/lib64/R/lib/libRblas.so
>>
>> locale:
>>  [1] LC_CTYPE=en_US.UTF-8      LC_NUMERIC=C
>>  [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
>>  [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
>>  [7] LC_PAPER=en_US.UTF-8      LC_NAME=C
>>  [9] LC_ADDRESS=C              LC_TELEPHONE=C
>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>>
>> attached base packages:
>> [1] stats    graphics  grDevices utils    datasets  methods  base
>>
>> loaded via a namespace (and not attached):
>> [1] compiler_3.5.0 tools_3.5.0</code>
>>
>>
>> The install message is:
>>
>> installing *source* package ‘rgdal’ ...
>> ** package ‘rgdal’ successfully unpacked and MD5 sums checked
>> configure: CC: gcc -m64
>> configure: CXX: g++ -m64
>> configure: rgdal: 1.3-2
>> checking for /usr/bin/svnversion... no
>> configure: svn revision: 755
>> checking whether the C++ compiler works... yes
>> checking for C++ compiler default output file name... a.out
>> checking for suffix of executables...
>> checking whether we are cross compiling... configure: error: in
>> `/tmp/RtmpfMGBY5/R.INSTALL66c3b8deddb/rgdal':
>> configure: error: cannot run C++ compiled programs.
>> If you meant to cross compile, use `--host'.
>> See `config.log' for more details
>> ERROR: configuration failed for package ‘rgdal’
>> * removing ‘/usr/lib64/R/library/rgdal’
>> * restoring previous ‘/usr/lib64/R/library/rgdal’
>>
>>
>> The complete information and config.log are posted online at:
>>
>> http://numberwright.com/2018/06/stuck-on-rgdal/
>>
>>
>> Any ideas? Or any other information that would be useful?
>>
>> Thanks!
>> Sarah
>>
>> --
>> Sarah Goslee
>> http://www.functionaldiversity.org
>>
>> _______________________________________________
>> R-sig-Geo mailing list
>> [hidden email]
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>         [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> R-sig-Geo mailing list
>> [hidden email]
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
>
> [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> --
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: [hidden email]
http://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Roger Bivand
Department of Economics
Norwegian School of Economics
Helleveien 30
N-5045 Bergen, Norway

Re: rgdal installation on Fedora 28

Sat, 06/16/2018 - 11:40
As I mentioned in the tweet, I was able to fix this on both a Fedora 23 and
Fedora 27 machine by making the following change to configure.ac:

diff --git a/configure.ac b/configure.ac
index 8ff72be..ab4c772 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3,6 +3,8 @@ define([pkgversion], esyscmd([sh -c "grep Version:
DESCRIPTION | cut -d' ' -f2 |
 AC_INIT(rgdal, [pkgversion], [hidden email])
 AC_CONFIG_SRCDIR(src/gdal-bindings.cpp)

+AC_PROG_CXX()
+
 # find R home and set correct compiler + flags
 : ${R_HOME=`R RHOME`}
 if test -z "${R_HOME}"; then

rerunning autoconf (also assuming m4/ax_cxx_compile_stdcxx.m4 is added)
results in ./configure working for me. I don't have a deep enough
understanding of the vagaries of autoconf to know why exactly this is
necessary on redhat systems and why this fixes it but at least everything
seems to work.

-Colin

On Fri, Jun 15, 2018 at 7:29 PM Thiago V. dos Santos via R-sig-Geo <
[hidden email]> wrote:

> The following lines in your config.log:
>
> /usr/bin/ld: /tmp/cc9pfZ1b.o: relocation R_X86_64_32 against .rodata' can
> not be used when making a shared object; recompile with -fPIC
>
> make me wonder: maybe there is a -fPIC compilation flag lacking for you
> platform in the makefile?
>
> Greetings, -- Thiago V. dos Santos
> Postdoctoral Research FellowDepartment of Climate and Space Science and
> EngineeringUniversity of Michigan
>
>     On Friday, June 15, 2018, 3:27:44 PM EDT, Sarah Goslee <
> [hidden email]> wrote:
>
>  Hi folks,
>
> I updated all of my linux computers to Fedora 28, and now can’t install
> rgdal.
>
> I can install sf with no problems, so it doesn't appear to be an issue
> with GDAL or with proj.
>
> I checked with Roger Bivand, the package maintainer, who asked me to
> confirm whether I could install sf, to make sure it wasn’t a
> dependency issue, and to post the logs online, then ask on the
> R-sig-geo mailing list. I’m putting the full problem here, and the
> abbreviated version on the mailing list.
>
> I’d appreciate any thoughts: I rely very heavily on the incredibly
> useful rgdal package.
>
> > sessionInfo()
> R version 3.5.0 (2018-04-23)
> Platform: x86_64-redhat-linux-gnu (64-bit)
> Running under: Fedora 28 (Workstation Edition)
>
> Matrix products: default
> BLAS/LAPACK: /usr/lib64/R/lib/libRblas.so
>
> locale:
>  [1] LC_CTYPE=en_US.UTF-8      LC_NUMERIC=C
>  [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
>  [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
>  [7] LC_PAPER=en_US.UTF-8      LC_NAME=C
>  [9] LC_ADDRESS=C              LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats    graphics  grDevices utils    datasets  methods  base
>
> loaded via a namespace (and not attached):
> [1] compiler_3.5.0 tools_3.5.0</code>
>
>
> The install message is:
>
> installing *source* package ‘rgdal’ ...
> ** package ‘rgdal’ successfully unpacked and MD5 sums checked
> configure: CC: gcc -m64
> configure: CXX: g++ -m64
> configure: rgdal: 1.3-2
> checking for /usr/bin/svnversion... no
> configure: svn revision: 755
> checking whether the C++ compiler works... yes
> checking for C++ compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... configure: error: in
> `/tmp/RtmpfMGBY5/R.INSTALL66c3b8deddb/rgdal':
> configure: error: cannot run C++ compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details
> ERROR: configuration failed for package ‘rgdal’
> * removing ‘/usr/lib64/R/library/rgdal’
> * restoring previous ‘/usr/lib64/R/library/rgdal’
>
>
> The complete information and config.log are posted online at:
>
> http://numberwright.com/2018/06/stuck-on-rgdal/
>
>
> Any ideas? Or any other information that would be useful?
>
> Thanks!
> Sarah
>
> --
> Sarah Goslee
> http://www.functionaldiversity.org
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>         [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>
        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: rgdal installation on Fedora 28

Fri, 06/15/2018 - 18:22
The following lines in your config.log:

/usr/bin/ld: /tmp/cc9pfZ1b.o: relocation R_X86_64_32 against .rodata' can not be used when making a shared object; recompile with -fPIC

make me wonder: maybe there is a -fPIC compilation flag lacking for you platform in the makefile?

Greetings, -- Thiago V. dos Santos
Postdoctoral Research FellowDepartment of Climate and Space Science and EngineeringUniversity of Michigan

    On Friday, June 15, 2018, 3:27:44 PM EDT, Sarah Goslee <[hidden email]> wrote:  
 
 Hi folks,

I updated all of my linux computers to Fedora 28, and now can’t install rgdal.

I can install sf with no problems, so it doesn't appear to be an issue
with GDAL or with proj.

I checked with Roger Bivand, the package maintainer, who asked me to
confirm whether I could install sf, to make sure it wasn’t a
dependency issue, and to post the logs online, then ask on the
R-sig-geo mailing list. I’m putting the full problem here, and the
abbreviated version on the mailing list.

I’d appreciate any thoughts: I rely very heavily on the incredibly
useful rgdal package.

> sessionInfo()
R version 3.5.0 (2018-04-23)
Platform: x86_64-redhat-linux-gnu (64-bit)
Running under: Fedora 28 (Workstation Edition)

Matrix products: default
BLAS/LAPACK: /usr/lib64/R/lib/libRblas.so

locale:
 [1] LC_CTYPE=en_US.UTF-8      LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=en_US.UTF-8      LC_NAME=C
 [9] LC_ADDRESS=C              LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats    graphics  grDevices utils    datasets  methods  base

loaded via a namespace (and not attached):
[1] compiler_3.5.0 tools_3.5.0</code>


The install message is:

installing *source* package ‘rgdal’ ...
** package ‘rgdal’ successfully unpacked and MD5 sums checked
configure: CC: gcc -m64
configure: CXX: g++ -m64
configure: rgdal: 1.3-2
checking for /usr/bin/svnversion... no
configure: svn revision: 755
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... configure: error: in
`/tmp/RtmpfMGBY5/R.INSTALL66c3b8deddb/rgdal':
configure: error: cannot run C++ compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
ERROR: configuration failed for package ‘rgdal’
* removing ‘/usr/lib64/R/library/rgdal’
* restoring previous ‘/usr/lib64/R/library/rgdal’


The complete information and config.log are posted online at:

http://numberwright.com/2018/06/stuck-on-rgdal/


Any ideas? Or any other information that would be useful?

Thanks!
Sarah

--
Sarah Goslee
http://www.functionaldiversity.org

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo 
        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: rgdal installation on Fedora 28

Fri, 06/15/2018 - 16:24
On Fri, 15 Jun 2018, Sarah Goslee wrote:

> If you read that whole thread, as far as I can tell it's a permissions
> error, possibly due to using an external drive.
>
> I can't see how it would apply to installing an R package from /tmp as
> root. Other compiled packages install correctly; rgdal is the only one
> giving me this error.
>
> Am I missing something in that thread?

I agree that it doesn't look like that. The main thread here, mostly OSX,
was: https://stat.ethz.ch/pipermail/r-sig-geo/2018-June/026622.html,
earlier https://stat.ethz.ch/pipermail/r-sig-geo/2018-May/026591.html.

That was where the CXX11 test need came from. See also
https://github.com/OSGeo/gdal/issues/681, but I don't think it is that.

Can you unpack the source tarball, remove lines 41-47 from configure.ac,
run autoconf to rebuild configure, and see whether removing the test
helps? This is based on a number of off-list contacts.

Roger


>
> Sarah
>
>
> On Fri, Jun 15, 2018 at 4:31 PM Ista Zahn <[hidden email]> wrote:
>
>>
>> https://askubuntu.com/questions/360329/error-cannot-run-c-compiled-programs-if-you-meant-to-cross-compile-use-host
>> might help.
>>
>> --Ista
>>
>> On Fri, Jun 15, 2018 at 3:27 PM, Sarah Goslee <[hidden email]>
>> wrote:
>>> Hi folks,
>>>
>>> I updated all of my linux computers to Fedora 28, and now can’t install
>> rgdal.
>>>
>>> I can install sf with no problems, so it doesn't appear to be an issue
>>> with GDAL or with proj.
>>>
>>> I checked with Roger Bivand, the package maintainer, who asked me to
>>> confirm whether I could install sf, to make sure it wasn’t a
>>> dependency issue, and to post the logs online, then ask on the
>>> R-sig-geo mailing list. I’m putting the full problem here, and the
>>> abbreviated version on the mailing list.
>>>
>>> I’d appreciate any thoughts: I rely very heavily on the incredibly
>>> useful rgdal package.
>>>
>>>> sessionInfo()
>>> R version 3.5.0 (2018-04-23)
>>> Platform: x86_64-redhat-linux-gnu (64-bit)
>>> Running under: Fedora 28 (Workstation Edition)
>>>
>>> Matrix products: default
>>> BLAS/LAPACK: /usr/lib64/R/lib/libRblas.so
>>>
>>> locale:
>>>  [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
>>>  [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
>>>  [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
>>>  [7] LC_PAPER=en_US.UTF-8       LC_NAME=C
>>>  [9] LC_ADDRESS=C               LC_TELEPHONE=C
>>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>>>
>>> attached base packages:
>>> [1] stats     graphics  grDevices utils     datasets  methods   base
>>>
>>> loaded via a namespace (and not attached):
>>> [1] compiler_3.5.0 tools_3.5.0</code>
>>>
>>>
>>> The install message is:
>>>
>>> installing *source* package ‘rgdal’ ...
>>> ** package ‘rgdal’ successfully unpacked and MD5 sums checked
>>> configure: CC: gcc -m64
>>> configure: CXX: g++ -m64
>>> configure: rgdal: 1.3-2
>>> checking for /usr/bin/svnversion... no
>>> configure: svn revision: 755
>>> checking whether the C++ compiler works... yes
>>> checking for C++ compiler default output file name... a.out
>>> checking for suffix of executables...
>>> checking whether we are cross compiling... configure: error: in
>>> `/tmp/RtmpfMGBY5/R.INSTALL66c3b8deddb/rgdal':
>>> configure: error: cannot run C++ compiled programs.
>>> If you meant to cross compile, use `--host'.
>>> See `config.log' for more details
>>> ERROR: configuration failed for package ‘rgdal’
>>> * removing ‘/usr/lib64/R/library/rgdal’
>>> * restoring previous ‘/usr/lib64/R/library/rgdal’
>>>
>>>
>>> The complete information and config.log are posted online at:
>>>
>>> http://numberwright.com/2018/06/stuck-on-rgdal/
>>>
>>>
>>> Any ideas? Or any other information that would be useful?
>>>
>>> Thanks!
>>> Sarah
>>>
>>> --
>>> Sarah Goslee
>>> http://www.functionaldiversity.org
>>>
>>> _______________________________________________
>>> R-sig-Geo mailing list
>>> [hidden email]
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
> --
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: [hidden email]
http://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Roger Bivand
Department of Economics
Norwegian School of Economics
Helleveien 30
N-5045 Bergen, Norway

Re: rgdal installation on Fedora 28

Fri, 06/15/2018 - 15:48
If you read that whole thread, as far as I can tell it's a permissions
error, possibly due to using an external drive.

I can't see how it would apply to installing an R package from /tmp as
root. Other compiled packages install correctly; rgdal is the only one
giving me this error.

Am I missing something in that thread?

Sarah


On Fri, Jun 15, 2018 at 4:31 PM Ista Zahn <[hidden email]> wrote:

>
> https://askubuntu.com/questions/360329/error-cannot-run-c-compiled-programs-if-you-meant-to-cross-compile-use-host
> might help.
>
> --Ista
>
> On Fri, Jun 15, 2018 at 3:27 PM, Sarah Goslee <[hidden email]>
> wrote:
> > Hi folks,
> >
> > I updated all of my linux computers to Fedora 28, and now can’t install
> rgdal.
> >
> > I can install sf with no problems, so it doesn't appear to be an issue
> > with GDAL or with proj.
> >
> > I checked with Roger Bivand, the package maintainer, who asked me to
> > confirm whether I could install sf, to make sure it wasn’t a
> > dependency issue, and to post the logs online, then ask on the
> > R-sig-geo mailing list. I’m putting the full problem here, and the
> > abbreviated version on the mailing list.
> >
> > I’d appreciate any thoughts: I rely very heavily on the incredibly
> > useful rgdal package.
> >
> >> sessionInfo()
> > R version 3.5.0 (2018-04-23)
> > Platform: x86_64-redhat-linux-gnu (64-bit)
> > Running under: Fedora 28 (Workstation Edition)
> >
> > Matrix products: default
> > BLAS/LAPACK: /usr/lib64/R/lib/libRblas.so
> >
> > locale:
> >  [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
> >  [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
> >  [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
> >  [7] LC_PAPER=en_US.UTF-8       LC_NAME=C
> >  [9] LC_ADDRESS=C               LC_TELEPHONE=C
> > [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
> >
> > attached base packages:
> > [1] stats     graphics  grDevices utils     datasets  methods   base
> >
> > loaded via a namespace (and not attached):
> > [1] compiler_3.5.0 tools_3.5.0</code>
> >
> >
> > The install message is:
> >
> > installing *source* package ‘rgdal’ ...
> > ** package ‘rgdal’ successfully unpacked and MD5 sums checked
> > configure: CC: gcc -m64
> > configure: CXX: g++ -m64
> > configure: rgdal: 1.3-2
> > checking for /usr/bin/svnversion... no
> > configure: svn revision: 755
> > checking whether the C++ compiler works... yes
> > checking for C++ compiler default output file name... a.out
> > checking for suffix of executables...
> > checking whether we are cross compiling... configure: error: in
> > `/tmp/RtmpfMGBY5/R.INSTALL66c3b8deddb/rgdal':
> > configure: error: cannot run C++ compiled programs.
> > If you meant to cross compile, use `--host'.
> > See `config.log' for more details
> > ERROR: configuration failed for package ‘rgdal’
> > * removing ‘/usr/lib64/R/library/rgdal’
> > * restoring previous ‘/usr/lib64/R/library/rgdal’
> >
> >
> > The complete information and config.log are posted online at:
> >
> > http://numberwright.com/2018/06/stuck-on-rgdal/
> >
> >
> > Any ideas? Or any other information that would be useful?
> >
> > Thanks!
> > Sarah
> >
> > --
> > Sarah Goslee
> > http://www.functionaldiversity.org
> >
> > _______________________________________________
> > R-sig-Geo mailing list
> > [hidden email]
> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> --
Sarah Goslee
http://www.stringpage.com
http://www.sarahgoslee.com
http://www.functionaldiversity.org

        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: rgdal installation on Fedora 28

Fri, 06/15/2018 - 15:31
https://askubuntu.com/questions/360329/error-cannot-run-c-compiled-programs-if-you-meant-to-cross-compile-use-host
might help.

--Ista

On Fri, Jun 15, 2018 at 3:27 PM, Sarah Goslee <[hidden email]> wrote:
> Hi folks,
>
> I updated all of my linux computers to Fedora 28, and now can’t install rgdal.
>
> I can install sf with no problems, so it doesn't appear to be an issue
> with GDAL or with proj.
>
> I checked with Roger Bivand, the package maintainer, who asked me to
> confirm whether I could install sf, to make sure it wasn’t a
> dependency issue, and to post the logs online, then ask on the
> R-sig-geo mailing list. I’m putting the full problem here, and the
> abbreviated version on the mailing list.
>
> I’d appreciate any thoughts: I rely very heavily on the incredibly
> useful rgdal package.
>
>> sessionInfo()
> R version 3.5.0 (2018-04-23)
> Platform: x86_64-redhat-linux-gnu (64-bit)
> Running under: Fedora 28 (Workstation Edition)
>
> Matrix products: default
> BLAS/LAPACK: /usr/lib64/R/lib/libRblas.so
>
> locale:
>  [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
>  [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
>  [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
>  [7] LC_PAPER=en_US.UTF-8       LC_NAME=C
>  [9] LC_ADDRESS=C               LC_TELEPHONE=C
> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>
> attached base packages:
> [1] stats     graphics  grDevices utils     datasets  methods   base
>
> loaded via a namespace (and not attached):
> [1] compiler_3.5.0 tools_3.5.0</code>
>
>
> The install message is:
>
> installing *source* package ‘rgdal’ ...
> ** package ‘rgdal’ successfully unpacked and MD5 sums checked
> configure: CC: gcc -m64
> configure: CXX: g++ -m64
> configure: rgdal: 1.3-2
> checking for /usr/bin/svnversion... no
> configure: svn revision: 755
> checking whether the C++ compiler works... yes
> checking for C++ compiler default output file name... a.out
> checking for suffix of executables...
> checking whether we are cross compiling... configure: error: in
> `/tmp/RtmpfMGBY5/R.INSTALL66c3b8deddb/rgdal':
> configure: error: cannot run C++ compiled programs.
> If you meant to cross compile, use `--host'.
> See `config.log' for more details
> ERROR: configuration failed for package ‘rgdal’
> * removing ‘/usr/lib64/R/library/rgdal’
> * restoring previous ‘/usr/lib64/R/library/rgdal’
>
>
> The complete information and config.log are posted online at:
>
> http://numberwright.com/2018/06/stuck-on-rgdal/
>
>
> Any ideas? Or any other information that would be useful?
>
> Thanks!
> Sarah
>
> --
> Sarah Goslee
> http://www.functionaldiversity.org
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

rgdal installation on Fedora 28

Fri, 06/15/2018 - 14:27
Hi folks,

I updated all of my linux computers to Fedora 28, and now can’t install rgdal.

I can install sf with no problems, so it doesn't appear to be an issue
with GDAL or with proj.

I checked with Roger Bivand, the package maintainer, who asked me to
confirm whether I could install sf, to make sure it wasn’t a
dependency issue, and to post the logs online, then ask on the
R-sig-geo mailing list. I’m putting the full problem here, and the
abbreviated version on the mailing list.

I’d appreciate any thoughts: I rely very heavily on the incredibly
useful rgdal package.

> sessionInfo()
R version 3.5.0 (2018-04-23)
Platform: x86_64-redhat-linux-gnu (64-bit)
Running under: Fedora 28 (Workstation Edition)

Matrix products: default
BLAS/LAPACK: /usr/lib64/R/lib/libRblas.so

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C
 [9] LC_ADDRESS=C               LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_3.5.0 tools_3.5.0</code>


The install message is:

installing *source* package ‘rgdal’ ...
** package ‘rgdal’ successfully unpacked and MD5 sums checked
configure: CC: gcc -m64
configure: CXX: g++ -m64
configure: rgdal: 1.3-2
checking for /usr/bin/svnversion... no
configure: svn revision: 755
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... configure: error: in
`/tmp/RtmpfMGBY5/R.INSTALL66c3b8deddb/rgdal':
configure: error: cannot run C++ compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details
ERROR: configuration failed for package ‘rgdal’
* removing ‘/usr/lib64/R/library/rgdal’
* restoring previous ‘/usr/lib64/R/library/rgdal’


The complete information and config.log are posted online at:

http://numberwright.com/2018/06/stuck-on-rgdal/


Any ideas? Or any other information that would be useful?

Thanks!
Sarah

--
Sarah Goslee
http://www.functionaldiversity.org

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: What is the Coordinate Reference System?

Fri, 06/15/2018 - 13:14
Hi,

That's an interesting approach.  

On the other hand, sometimes I get bitten (well, muddled really) when I use raster to determine the crs of a ncdf resource.  It all sort of depends.

Below is an example for Aqua MODIS imagery from OBPG (https://oceandata.sci.gsfc.nasa.gov/MODIS-Aqua/Mapped/Daily/9km/sst/2017/ <https://oceandata.sci.gsfc.nasa.gov/MODIS-Aqua/Mapped/Daily/9km/sst/2017/>).  The OBPG docs (https://oceancolor.gsfc.nasa.gov/products/ <https://oceancolor.gsfc.nasa.gov/products/>) state that the data is served up as 'Plate Carrée' which I think has a crs ...

'+proj=eqc +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs '

... as described here http://spatialreference.org/ref/epsg/32662/ <http://spatialreference.org/ref/epsg/32662/>

You can see below that raster comes up with...

'+proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0'

... which is http://spatialreference.org/ref/epsg/4326/ <http://spatialreference.org/ref/epsg/4326/>

Explicitly setting the crs while reading doesn't help.  I have never resolved if it is an OBPG documentation bug, my confusion about projections, or some other mystery.  So, my usual practice is to assume that raster makes the right call.

#### start

library(raster)
URI = 'https://oceandata.sci.gsfc.nasa.gov/cgi/getfile/A2017175.L3m_DAY_SST_sst_9km.nc'

# ~3.8MB
ok = download.file(URI, basename(URI))

R = raster::raster(basename(URI), varname = 'sst')
R
# class       : RasterLayer
# dimensions  : 2160, 4320, 9331200  (nrow, ncol, ncell)
# resolution  : 0.08333334, 0.08333334  (x, y)
# extent      : -180, 180, -90, 90  (xmin, xmax, ymin, ymax)
# coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
# data source : /Users/Shared/code/R/others/record/spnc/A2017175.L3m_DAY_SST_sst_9km.nc
# names       : Sea.Surface.Temperature
# zvar        : sst

S = raster::raster(basename(URI), varname = "sst", crs = '+proj=eqc +lat_ts=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=WGS84 +datum=WGS84 +units=m +no_defs')
# Warning message:
# In .getProj(prj, crs) :
#  argument "crs" ignored because the file provides a crs

#### end


Cheers,
Ben


> On Jun 14, 2018, at 6:42 PM, Michael Sumner <[hidden email]> wrote:
>
> Try raster::projection(raster::raster(a)) first, then delve if necessary
> into the ncdump summary with print(raster::raster(a)))
>
> But, raster(a) may be enough here? To get that stuff more directly from the
> NetCDF API you have to use the inq and att functions of ncdf4 or RNetCDF
> and that's no fun.
>
> I'd also try raster(rgdal::readGDAL(a)) which is a totally different but
> equivalent read path.
>
> Cheers, Mike
>
> On Thu, 14 Jun 2018, 11:03 Sergio Ibarra, <[hidden email]> wrote:
>
>> Greetings,
>>
>> I'm want to read NetCDF spatial data from a meteorological model (WRF
>> model). The NetCDF can have one of these three projections:
>>
>> Polar stereographic
>> Lambert conformal
>> Mercator projection
>>
>> (See figure
>>
>> https://user-images.githubusercontent.com/27447280/41389756-ed23f91a-6f68-11e8-961e-6ba901913c54.png
>> )
>>
>> What is the  Coordinate Reference System for each case?
>>
>> Thanks!
>>
>> Here an example with ncdf4 and raster:
>>
>> library(ncdf4)
>> library(raster)
>> a <- tempfile()
>> download.file(url = "
>> http://www.unidata.ucar.edu/software/netcdf/examples/wrfout_v2_Lambert.nc
>> ",
>>              destfile = a) #78 Mb
>> wrf <- nc_open(a)
>> paste("The file has",wrf$nvars,"variables")
>> paste("The file has",names(wrf$var))
>> lat <- ncvar_get( wrf, "XLAT" )
>> lon <- ncvar_get( wrf, "XLONG" )
>> t2 <- ncvar_get( wrf, "T2" ) - 273.15
>> dim(t2) #73 60 13
>> #image
>> image(t2[, , 12])
>> # raster
>> rt2 <- raster(t(t2[1:dim(t2)[1],
>>                   dim(t2)[2]:1,
>>                   12]),
>>              xmn = min(lon),
>>              xmx = max(lon),
>>              ymn = min(lat),
>>              ymx = max(lat),
>> *              crs="+init=epsg:4326") # ???*
>> spplot(rt2)
>>
>>
>>
>> --
>> ​Sergio Ibarra Espinosa
>> Post Doc
>> PhD in Atmospheric Sciences
>> Instituto de Astronomia, Geofísica e Ciências Atmosféricas
>> Universidade de São Paulo
>> Rua do Matão, 1226
>> São Paulo-SP - Brasil -
>> 05508-090
>> +55-11-97425-3791
>> Skype: sergio_ibarra1
>>
>>        [[alternative HTML version deleted]]
>>
>> _______________________________________________
>> R-sig-Geo mailing list
>> [hidden email]
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>
> --
> Dr. Michael Sumner
> Software and Database Engineer
> Australian Antarctic Division
> 203 Channel Highway
> Kingston Tasmania 7050 Australia
>
> [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>
Ben Tupper
Bigelow Laboratory for Ocean Sciences
60 Bigelow Drive, P.O. Box 380
East Boothbay, Maine 04544
http://www.bigelow.org

Ecological Forecasting: https://eco.bigelow.org/






        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Problems with Spatial Kriging (krige)

Fri, 06/15/2018 - 07:02
Hi, I am trying to do Spatial ordinary kriging with participatory sensing
air quality data.
I made the empirical variogram, the fitted model, and the prediction grid
(new data).
However when I call the krige function, as result given by the function I
got a SpatialPointsDataFrame which consists of the prediction grid (which I
created passing THE SpatialPointsDataFrame containing my measures to
spsample function)..
Why I get this wrong result?

Kind regards.

        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: What is the Coordinate Reference System?

Thu, 06/14/2018 - 17:42
Try raster::projection(raster::raster(a)) first, then delve if necessary
into the ncdump summary with print(raster::raster(a)))

But, raster(a) may be enough here? To get that stuff more directly from the
NetCDF API you have to use the inq and att functions of ncdf4 or RNetCDF
and that's no fun.

I'd also try raster(rgdal::readGDAL(a)) which is a totally different but
equivalent read path.

Cheers, Mike

On Thu, 14 Jun 2018, 11:03 Sergio Ibarra, <[hidden email]> wrote:

> Greetings,
>
> I'm want to read NetCDF spatial data from a meteorological model (WRF
> model). The NetCDF can have one of these three projections:
>
> Polar stereographic
> Lambert conformal
> Mercator projection
>
> (See figure
>
> https://user-images.githubusercontent.com/27447280/41389756-ed23f91a-6f68-11e8-961e-6ba901913c54.png
> )
>
> What is the  Coordinate Reference System for each case?
>
> Thanks!
>
> Here an example with ncdf4 and raster:
>
> library(ncdf4)
> library(raster)
> a <- tempfile()
> download.file(url = "
> http://www.unidata.ucar.edu/software/netcdf/examples/wrfout_v2_Lambert.nc
> ",
>               destfile = a) #78 Mb
> wrf <- nc_open(a)
> paste("The file has",wrf$nvars,"variables")
> paste("The file has",names(wrf$var))
> lat <- ncvar_get( wrf, "XLAT" )
> lon <- ncvar_get( wrf, "XLONG" )
> t2 <- ncvar_get( wrf, "T2" ) - 273.15
> dim(t2) #73 60 13
> #image
> image(t2[, , 12])
> # raster
> rt2 <- raster(t(t2[1:dim(t2)[1],
>                    dim(t2)[2]:1,
>                    12]),
>               xmn = min(lon),
>               xmx = max(lon),
>               ymn = min(lat),
>               ymx = max(lat),
> *              crs="+init=epsg:4326") # ???*
> spplot(rt2)
>
>
>
> --
> ​Sergio Ibarra Espinosa
> Post Doc
> PhD in Atmospheric Sciences
> Instituto de Astronomia, Geofísica e Ciências Atmosféricas
> Universidade de São Paulo
> Rua do Matão, 1226
> São Paulo-SP - Brasil -
> 05508-090
> +55-11-97425-3791
> Skype: sergio_ibarra1
>
>         [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> --
Dr. Michael Sumner
Software and Database Engineer
Australian Antarctic Division
203 Channel Highway
Kingston Tasmania 7050 Australia

        [[alternative HTML version deleted]]

_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Pages