Re: [R-sig-Geo] CRAN releases of sp, rgdal and rgeos

[MacQueen, Don via R-sig-Geo]

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" 
 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: roger.biv...@nhh.no
http://orcid.org/-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0J=en

___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo


___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: [R-sig-Geo] What is the Coordinate Reference System?

[Sergio Ibarra]

Yes, thanks for the explanations.


Have a nice week! :)

Em seg, 18 de jun de 2018 às 10:29, Ben Tupper 
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  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,  >
> > 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.0834, 0.0834  (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 
> 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, 
> >> wrote:
> 
> > Greetings,
> >
> > I'm want to read NetCDF spatial data from a meteorological model (WRF
> > model). The NetCDF can have one of these 

Re: [R-sig-Geo] What is the Coordinate Reference System?

[Ben Tupper]

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  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, 
> 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/
>> ).
>> 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.0834, 0.0834  (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  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, 
>> 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 

Re: [R-sig-Geo] What is the Coordinate Reference System?

[Michael Sumner]

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, 
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/
> ).
> 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.0834, 0.0834  (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  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, 
> 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 <- 

Re: [R-sig-Geo] What is the Coordinate Reference System?

[Edzer Pebesma]

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/ 
> ). 
>  The OBPG docs (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/ 
> 
> 
> 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/ 
> 
> 
> 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.0834, 0.0834  (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  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,  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)
>>>
>>>
>>>

[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

[Tomislav Hengl]

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
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo