date:20170316

Re: [R-sig-Geo] Same mask for two rasters, but obtaining different extents in R

2017-03-16 Thread Vijay Ramesh via R-sig-Geo

I re-checked the original extent and here it is: This is data obtained from
WorldClim.

> bio5
class   : RasterLayer
dimensions  : 3600, 8640, 31104000  (nrow, ncol, ncell)
resolution  : 0.0417, 0.0417  (x, y)
extent  : -180, 180, -60, *90.1 * (xmin, xmax, ymin, ymax) #This
varies at the 6th decimal place.
coord. ref. : +proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs
data source : C:\Users\rameshv\Downloads\Climate
Stability\Data_LGM_Present\Present\1_RawData\bio_5
names   : bio_5
values  : -86, 489  (min, max)
attributes  :
ID COUNT
 from: -86 1
 to  : 48938


> lg5
class   : RasterLayer
dimensions  : 3600, 8640, 31104000  (nrow, ncol, ncell)
resolution  : 0.0417, 0.0417  (x, y)
extent  : -180, 180, -60, 90  (xmin, xmax, ymin, ymax)
coord. ref. : +proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs
data source : C:\Users\rameshv\Downloads\Climate
Stability\Data_LGM_Present\LGM\1_RawData\cclgmbi5.tif
names   : cclgmbi5
values  : -204, 519  (min, max)

What do you suggest?

Also, any suggestions on aligning them before I crop them? I wouldn't want
to projectRaster using one of the rasters, as that creates extra number of
rows (when I coerce the raster to a Spatial Pixels Data Frame).



On Wed, Mar 15, 2017 at 1:13 PM, Sarah Goslee 
wrote:

> The most likely explanation seems to me that the rasters were not
> aligned before cropping, so they are not aligned after cropping.
>
> Have you checked the original extent and resolution?
>
> Sarah
>
> On Tue, Mar 14, 2017 at 5:31 PM, Vijay Ramesh via R-sig-Geo
>  wrote:
> > I loaded a shapefile in R, and cropped and masked it with the same mask,
> > but I get different extents. Any suggestions?
> >
> > Code below:
> >
> > library(raster)
> > library(rgdal)
> > library(GISTools)
> > library(sp)
> > library(maptools)
> >
> > ##Loading the first mask
> > Mask <- readOGR("C:\\Users\\rameshv\\Downloads\\Climate
> > Stability\\SPV_Mask\\mask.shp")
> > proj4string(Mask) <- CRS("+init=epsg:4326")
> >
> > #Loading the Rasters For Present and LGM and clipping them to the
> right
> > extent
> > bio5 <- raster("C:\\Users\\rameshv\\Downloads\\Climate
> > Stability\\Data_LGM_Present\\Present\\1_RawData\\bio_5")
> > proj4string(bio5) <- CRS("+init=epsg:4326")
> > lg5 <- raster("C:\\Users\\rameshv\\Downloads\\Climate
> > Stability\\Data_LGM_Present\\LGM\\1_RawData\\cclgmbi5.tif")
> > proj4string(lg5) <- CRS("+init=epsg:4326")
> >
> > ##Cropping by using the Crop and Mask functions
> > cr<- crop(bio5, extent(Mask))
> > bio5 <- mask(cr, Mask)
> >
> > cr2<- crop(lg5, extent(Mask))
> > lg5<- mask(cr2, Mask)
> >
> > > bio5
> >  class   : RasterLayer
> >  dimensions  : 339, 246, 83394  (nrow, ncol, ncell)
> >  resolution  : 0.0417, 0.0417  (x, y)
> >  extent  : 72.45835, 82.70835, 8.083337, 22.20834  (xmin, xmax,
> > ymin, ymax)
> >  coord. ref. : +init=epsg:4326 +proj=longlat +datum=WGS84 +no_defs
> > +ellps=WGS84 +towgs84=0,0,0
> >  data source : in memory
> >  names   : bio_5
> >  values  : 207, 432  (min, max)
> >  attributes  :
> > ID COUNT
> >  from: -86 1
> >  to  : 48938
> >
> >  > lg5
> >  class   : RasterLayer
> >  dimensions  : 339, 246, 83394  (nrow, ncol, ncell)
> >  resolution  : 0.0417, 0.0417  (x, y)
> >  extent  : 72.45833, 82.70833, 8.08, 22.20833  (xmin, xmax,
> > ymin, ymax)
> >  coord. ref. : +init=epsg:4326 +proj=longlat +datum=WGS84 +no_defs
> > +ellps=WGS84 +towgs84=0,0,0
> >  data source : in memory
> >  names   : cclgmbi5
> >  values  : 187, 392  (min, max)
> >
> >
>
> --
> Sarah Goslee
> http://www.functionaldiversity.org
>



-- 
Data Manager,
Barbara Han Lab,
Cary Institute of Ecosystem Studies,
2801 Sharon Turnpike, Millbrook, NY 12545
Lab Site : http://www.hanlab.science/
Personal Site : http://evolecol.weebly.com/
Phone : (845)-677-7600 Ext: 241

[[alternative HTML version deleted]]

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

[R-sig-Geo] Getis Ord G test in 3 dimensions

2017-03-16 Thread Juanma José via R-sig-Geo

> Dear all

> I am working on a 3D home range estimator, we want to calculated home ranges 
> and core areas on primates that were followed sleeping site to sleeping site. 
> We collected GPS locations and animals height at equal intervals along the 
> day. 
> We already calculates home ranges and core area in 2D using Delaunay 
> triangulation and then applying a hot spot analysis in ArcGis( Getis Ord G*) 
> using the perimeter of the triangles. Then, to calculate it on 3D we first 
> created a 3D convex hull formed by tetrahedrons using animals locations 
> (coordinates in meters)  and height.

> we are wondering if it is possible to use the function Local G or Global G 
> test (package Spdep) for 3D locatios (X,Y,Z) as we previously  did in 2D 
> (Hotspot with rendering, ArgGis)

Thanks in advance
> 
> 
> Juanma 

 
Juan Manuel José Domínguez
Postdoctoral Researcher 
  
Conservation Ecology Program
School of Bioresources & Technology
King Mongkut´s University of Technology Thonburi

49 Soi Tienthalay 25
Bangkhuntien-Chaithalay Road
Thakham, Bangkhuntien
Bangkok 10150
Thailand
http://cons-ecol-kmutt.weebly.com/
[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Maintain SRID with st_write to postgis db

2017-03-16 Thread Edzer Pebesma

Mike, Chris, the configure step should now pass regardless whether
liblwgeom is present, or not; the error message was my mistake.

sf will link to liblwgeom when its development version is present (on
ubuntu: liblwgeom-dev). If postgis is binary installed, liblwgeom may be
present, but not its dev version (needed for header files); that case is
now being caught too.

liblwgeom provides st_make_valid, essentially ST_makeValid in postgis;
see https://github.com/edzer/sfr/issues/67 . Since liblwgeom is not
available on the CRAN build farms, it's presence is not required by sf.

Best regards,

On 16/03/17 05:46, chris english wrote:
> Michael,
> 
> I have the very same failure, 
>> library(sf)
> Linking to GEOS 3.4.2, GDAL 2.1.3, proj.4 4.9.1
> (pre upgrade attempt, which still works just fine)
> 
> checking for geos_c.h... yes
> checking geos: linking with -lgeos_c... yes
> checking for lwgeom_version in -llwgeom... no
> configure: error: in `/tmp/RtmpsCmf6B/devtoolsd68e68107a/edzer-sfr-d620f3b':
> configure: error: lwgeom test failed (--without-readline to disable)
> 
> I could nearly copy your install output though on 16.04, and the same
> tangle of it depends on x but it won't be installed & etc. 
> But, if you have PostGIS, you have liblwgeom as it is fairly specific to
> PostGIS. Perhaps, rather than a devtools::github_install,
> a clone github lo a local directory and config, make, install might
> work, but I'm just imagining. 
> 
> then testing:
> config.log --snip --
> configure:3993: checking for lwgeom_version in -llwgeom
> configure:4018: gcc -std=gnu99 -o conftest -g -O2 -fstack-protector
> --param=ssp-
> buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -g
>  -I/usr/lo
> cal/include   -I/usr/local/include -I/usr/local/include
> -Wl,-Bsymbolic-functions
>  -Wl,-z,relro conftest.c -llwgeom  -lproj  -L/usr/local/lib -lproj  
> -L/usr/loca
> l/lib -lgdal -L/usr/local/lib -lgeos_c -lproj >&5
> /tmp/ccDBUh1h.o: In function `main':
> /home/chris/sfr/sfr/conftest.c:34: undefined reference to `lwgeom_version'
> collect2: error: ld returned 1 exit status
> configure:4018: $? = 1
> configure: failed program was:
> | /* confdefs.h */
> | #define PACKAGE_NAME ""
> | #define PACKAGE_TARNAME ""
> | #define PACKAGE_VERSION ""
> | #define PACKAGE_STRING ""
> | #define PACKAGE_BUGREPORT ""
> | #define PACKAGE_URL ""
> | #define STDC_HEADERS 1
> | #define HAVE_SYS_TYPES_H 1
> | #define HAVE_SYS_STAT_H 1
> | #define HAVE_STDLIB_H 1
> | #define HAVE_STRING_H 1
> | #define HAVE_MEMORY_H 1
> | #define HAVE_STRINGS_H 1
> | #define HAVE_INTTYPES_H 1
> | #define HAVE_STDINT_H 1
> | #define HAVE_UNISTD_H 1
> | #define HAVE_GDAL_H 1
> | #define HAVE_PROJ_API_H 1
> | #define HAVE_LIBPROJ 1
> | #define HAVE_GEOS_C_H 1
> | /* end confdefs.h.  */
> | 
> | /* Override any GCC internal prototype to avoid an error.
> |Use char because int might match the return type of a GCC
> |builtin and then its argument prototype would still apply.  */
> | #ifdef __cplusplus
> | extern "C"
> | #endif
> | char lwgeom_version ();
> | int
> | main ()
> | {
> | return lwgeom_version ();
> |   ;
> |   return 0;
> | }
> configure:4027: result: no
> configure:4036: error: in `/home/chris/sfr/sfr':
> configure:4038: error: lwgeom test failed (--without-readline to disable)
> See `config.log' for more details
> 
> so, it may or may not be the presence or absence of liblwgeom but simply
> an undefined reference as suggested above:
> 
> /home/chris/sfr/sfr/conftest.c:34: undefined reference to `lwgeom_version' ,
> 
> but I'm unclear how the version was being requested (well, I can kind of
> guess)
> but failing on undefined reference suggests it is not the version per se
> that may
> or may not be present (though is because you are using PostGIS), but how
> the version was requested. I intuit.
> 
> Ah, and reading  /* confdefs.h */, that it indeed ends with #define
> HAVE_GEOS_C_H 1,
> and indeed, conftest.c:34: would have an  undefined reference to
> `lwgeom_version'. 
> 
> And I've said as much as I understand.
> 
> Chris
> 
> On Wed, Mar 15, 2017 at 7:53 PM, Michael Treglia  > wrote:
> 
> Sorry - this follow-up isn't entirely an R question, so if best to take
> this off list, let me know:
> 
> Installing the dev version from github fails for me (installing on
> ubuntu
> 14.04.5) - I've included the output from the install process below -
> seems
> to fail due to failed check for liblwgeom version.
> 
> Looks like I don't have liblwgeom installed - and when I try (via sudo
> apt-get install liblwgeom-2.3-0), it indicates it requires libgeos-c1.
> Installing libgeos-c1, however, requires removal of a newer version of
> libgeos (libgeos-c1v5), which other FOSS GIS tools depend on (at
> least if
> my understanding is correct).  Is there a way around this?  Sorry if I'm
> just missing something, and thanks again for input.
> mike
> 
> 
> 
>

Re: [R-sig-Geo] Sentienl 2 gdal translate

2017-03-16 Thread Miguel Castro Gómez

Hi Loïc,

I have tried your code but it does not work yet. It just produces one tif file 
for the first band but this file is not correct (8 kb just). The R process keep 
working for a long time without any other output

Here are the versions I’m using

R version: 3.3.2
gdalUtils: v 2.0.1.7
raster: 2.5-8
gdal: 2.1.2, released 2016/10/24

When checking for the sentinel 2 driver in gdal (see red)

 gdal-config --formats | grep sentinel2
gxf gtiff hfa aigrid aaigrid ceos ceos2 iso8211 xpm sdts raw dted mem jdem 
envisat elas fit vrt usgsdem l1b nitf bmp airsar rs2 ilwis rmf leveller sgi 
srtmhgt idrisi gsg ingr ers jaxapalsar dimap gff cosar pds adrg coasp tsx 
terragen blx msgn til r northwood saga xyz hf2 kmlsuperoverlay ctg e00grid zmap 
ngsgeoid iris map cals safe sentinel2 mrf webp wcs wms plmosaic wmts dods grib 
bsb openjpeg jpeg2000 netcdf hdf5 hdf4 ogdi gif jpeg gta png pcraster fits 
pcidsk rik ozi rasterlite mbtiles postgisraster arg

I think the problem is the driver that is used to manage the jp2 file. Any idea 
how can I include in the R code the --config GDAL_SKIP JP2ECW option. 

Cheers,
M

> El 15 mar 2017, a las 23:13, Loïc Dutrieux  
> escribió:
> 
> Hi,
> 
> I tried your code with some S2 images I had lying around, and it works
> on my system. I modified it a bit to write the output layers to the same
> directory and not to my working directory.
> 
> library(gdalUtils)
> library(raster)
> 
> Image_Path<-'/path/to/images/'
> 
> S2_JP2_List <- list.files(Image_Path, full.names = TRUE, pattern = ".jp2$")
> 
> for (file in S2_JP2_List) {
>  out_file <- extension(file, 'tif')
>  gdal_translate(src_dataset = file, dst_dataset = out_file, ot =
> "UInt16", of = "GTiff")
> }
> 
> gdal has a sentinel 2 driver, but it's not extremely old, therefore it's
> possible that your installation doesn't have it; you can check with:
> 
> gdal-config --formats | grep sentinel2
> 
> Cheers,
> Loïc
> 
> 
> 
> On 15/03/17 12:49, Miguel Castro Gómez wrote:
>> Hi,
>> 
>> I have Sentinel 2 images (jp2) that I want to convert to GTiff using 
>> gdal_translate in R (from gdalutils package). Here is the code I’m using
>> 
>> Image_Path<-“/path/to/wd“
>> 
>> S2_JP2_List <- list.files(Image_Path, full.names = TRUE, pattern = ".jp2$")
>> 
>> for (i in 1:length(S2_JP2_List)) {
>> gdal_translate(src_dataset = S2_JP2_List[[i]], dst_dataset = paste("Band", i 
>> , "tif"), ot = "UInt16", of = “GTiff")
>>}
>> 
>> When running this code, the process starts without any error but its never 
>> ending neither producing any output
>> 
>> I've tried to do it in gdal and the same code works, except that it is 
>> necessary to skip  the default driver since it cannot manage large jp2 
>> files. 
>> 
>> gdal_translate -of GTiff /path/to/input/S2_b1.jp2  
>> /path/to/output/S2_b1converted.tif --config GDAL_SKIP JP2ECW
>> 
>> Any idea how could I run this in R?
>> 
>> Thanks 
>> M
>> 
>> 
>> 
>>  [[alternative HTML version deleted]]
>> 
>> ___
>> 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


[[alternative HTML version deleted]]

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

Re: [R-sig-Geo] Getis Ord G test in 3 dimensions

2017-03-16 Thread Roger Bivand


On Wed, 15 Mar 2017, Juanma José via R-sig-Geo wrote:


Dear all


I am working on a 3D home range estimator, we want to calculated home 
ranges and core areas on primates that were followed sleeping site to 
sleeping site. We collected GPS locations and animals height at equal 
intervals along the day. We already calculates home ranges and core 
area in 2D using Delaunay triangulation and then applying a hot spot 
analysis in ArcGis( Getis Ord G*) using the perimeter of the triangles. 
Then, to calculate it on 3D we first created a 3D convex hull formed by 
tetrahedrons using animals locations (coordinates in meters)  and 
height.


we are wondering if it is possible to use the function Local G or 
Global G test (package Spdep) for 3D locatios (X,Y,Z) as we previously 
did in 2D (Hotspot with rendering, ArgGis)


I replied to this off-list, but the OP hasn't taken my points into 
account:


Please note that hotspots are often seriously misleading unless missing 
values have been taken into account. For instance in your case, the 
presence of a predator may lead to clustering of prey birds in 3D, or 
insect-eating birds will cluster in voxels with higher insect densities. 
The case appears to be 2.5D, not 3D, which will undoubtedly affect 
the absence of hotspots underground.


Getis G/G* is a 2D measure, so you'd first have to show that the same 
statistical properties apply to 3D. Really you need 4D as time is crucial. 
My guess is that kernel densities generalize better than LISA, and there 
are better non-parametric statistical bases for carrying out inference 
from 3D kernels. There are quite a lot of R contributed packages providing 
KDE techniques: http://vita.had.co.nz/papers/density-estimation.pdf - in 
the listing you can see the #D. Choosing bandwidths is like choosing 
distance rings for G* but better founded. Note that many homerange 
estimators use a form of KDE, I think.


Please also see spatstat and its book. G* is probably not what you should 
be using.


Hope this clarifies,

Roger





Thanks in advance



Juanma



Juan Manuel José Domínguez
Postdoctoral Researcher

Conservation Ecology Program
School of Bioresources & Technology
King Mongkut´s University of Technology Thonburi

49 Soi Tienthalay 25
Bangkhuntien-Chaithalay Road
Thakham, Bangkhuntien
Bangkok 10150
Thailand
http://cons-ecol-kmutt.weebly.com/
[[alternative HTML version deleted]]

___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
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: roger.biv...@nhh.no
Editor-in-Chief of The R Journal, https://journal.r-project.org/index.html
http://orcid.org/-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0J&hl=en
http://depsy.org/person/444584___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: [R-sig-Geo] Same mask for two rasters, but obtaining different extents in R

2017-03-16 Thread Ben Tupper

Hi,

In the short term you could use raster::alignExtent() to get align bio5 to the 
the extent of lg5.  

I would also inspect the source of your data and compare it to your locally 
stored copy of it.  If they are different then it would be worthwhile to review 
the steps you used to download, manipulate and store it.

Cheers,
Ben 

 
> On Mar 15, 2017, at 1:21 PM, Vijay Ramesh via R-sig-Geo 
>  wrote:
> 
> I re-checked the original extent and here it is: This is data obtained from
> WorldClim.
> 
>> bio5
> class   : RasterLayer
> dimensions  : 3600, 8640, 31104000  (nrow, ncol, ncell)
> resolution  : 0.0417, 0.0417  (x, y)
> extent  : -180, 180, -60, *90.1 * (xmin, xmax, ymin, ymax) #This
> varies at the 6th decimal place.
> coord. ref. : +proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs
> data source : C:\Users\rameshv\Downloads\Climate
> Stability\Data_LGM_Present\Present\1_RawData\bio_5
> names   : bio_5
> values  : -86, 489  (min, max)
> attributes  :
>ID COUNT
> from: -86 1
> to  : 48938
> 
> 
>> lg5
> class   : RasterLayer
> dimensions  : 3600, 8640, 31104000  (nrow, ncol, ncell)
> resolution  : 0.0417, 0.0417  (x, y)
> extent  : -180, 180, -60, 90  (xmin, xmax, ymin, ymax)
> coord. ref. : +proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs
> data source : C:\Users\rameshv\Downloads\Climate
> Stability\Data_LGM_Present\LGM\1_RawData\cclgmbi5.tif
> names   : cclgmbi5
> values  : -204, 519  (min, max)
> 
> What do you suggest?
> 
> Also, any suggestions on aligning them before I crop them? I wouldn't want
> to projectRaster using one of the rasters, as that creates extra number of
> rows (when I coerce the raster to a Spatial Pixels Data Frame).
> 
> 
> 
> On Wed, Mar 15, 2017 at 1:13 PM, Sarah Goslee 
> wrote:
> 
>> The most likely explanation seems to me that the rasters were not
>> aligned before cropping, so they are not aligned after cropping.
>> 
>> Have you checked the original extent and resolution?
>> 
>> Sarah
>> 
>> On Tue, Mar 14, 2017 at 5:31 PM, Vijay Ramesh via R-sig-Geo
>>  wrote:
>>> I loaded a shapefile in R, and cropped and masked it with the same mask,
>>> but I get different extents. Any suggestions?
>>> 
>>> Code below:
>>> 
>>>library(raster)
>>>library(rgdal)
>>>library(GISTools)
>>>library(sp)
>>>library(maptools)
>>> 
>>>##Loading the first mask
>>>Mask <- readOGR("C:\\Users\\rameshv\\Downloads\\Climate
>>> Stability\\SPV_Mask\\mask.shp")
>>>proj4string(Mask) <- CRS("+init=epsg:4326")
>>> 
>>>#Loading the Rasters For Present and LGM and clipping them to the
>> right
>>> extent
>>>bio5 <- raster("C:\\Users\\rameshv\\Downloads\\Climate
>>> Stability\\Data_LGM_Present\\Present\\1_RawData\\bio_5")
>>>proj4string(bio5) <- CRS("+init=epsg:4326")
>>>lg5 <- raster("C:\\Users\\rameshv\\Downloads\\Climate
>>> Stability\\Data_LGM_Present\\LGM\\1_RawData\\cclgmbi5.tif")
>>>proj4string(lg5) <- CRS("+init=epsg:4326")
>>> 
>>>##Cropping by using the Crop and Mask functions
>>>cr<- crop(bio5, extent(Mask))
>>>bio5 <- mask(cr, Mask)
>>> 
>>>cr2<- crop(lg5, extent(Mask))
>>>lg5<- mask(cr2, Mask)
>>> 
 bio5
>>> class   : RasterLayer
>>> dimensions  : 339, 246, 83394  (nrow, ncol, ncell)
>>> resolution  : 0.0417, 0.0417  (x, y)
>>> extent  : 72.45835, 82.70835, 8.083337, 22.20834  (xmin, xmax,
>>> ymin, ymax)
>>> coord. ref. : +init=epsg:4326 +proj=longlat +datum=WGS84 +no_defs
>>> +ellps=WGS84 +towgs84=0,0,0
>>> data source : in memory
>>> names   : bio_5
>>> values  : 207, 432  (min, max)
>>> attributes  :
>>>ID COUNT
>>> from: -86 1
>>> to  : 48938
>>> 
 lg5
>>> class   : RasterLayer
>>> dimensions  : 339, 246, 83394  (nrow, ncol, ncell)
>>> resolution  : 0.0417, 0.0417  (x, y)
>>> extent  : 72.45833, 82.70833, 8.08, 22.20833  (xmin, xmax,
>>> ymin, ymax)
>>> coord. ref. : +init=epsg:4326 +proj=longlat +datum=WGS84 +no_defs
>>> +ellps=WGS84 +towgs84=0,0,0
>>> data source : in memory
>>> names   : cclgmbi5
>>> values  : 187, 392  (min, max)
>>> 
>>> 
>> 
>> --
>> Sarah Goslee
>> http://www.functionaldiversity.org
>> 
> 
> 
> 
> -- 
> Data Manager,
> Barbara Han Lab,
> Cary Institute of Ecosystem Studies,
> 2801 Sharon Turnpike, Millbrook, NY 12545
> Lab Site : http://www.hanlab.science/
> Personal Site : http://evolecol.weebly.com/
> Phone : (845)-677-7600 Ext: 241
> 
>   [[alternative HTML version deleted]]
> 
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> 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

___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
htt

Re: [R-sig-Geo] Maintain SRID with st_write to postgis db

2017-03-16 Thread chris english

Edzer,

Installs fine now, though st_make_valid is useful when cleaning messy
inputs. I
just installed new ubuntu binaries for PostGIS last night but will attend
to rebuild
from source.

 The only thing to come up in an otherwise smooth install:
** preparing package for lazy loading
in method for ‘coerce’ with signature ‘"Spatial","sf"’: no definition for
class “Spatial”
in method for ‘coerce’ with signature ‘"Spatial","sfc"’: no definition for
class “Spatial”
in method for ‘coerce’ with signature ‘"sf","Spatial"’: no definition for
class “Spatial”
in method for ‘coerce’ with signature ‘"sfc","Spatial"’: no definition for
class “Spatial”
** help
*** installing help indices
** building package indices
** installing vignettes
** testing if installed package can be loaded
* DONE (sf)
Reloading installed sf
Linking to GEOS 3.4.2, GDAL 2.1.3, proj.4 4.9.1

I'm guessing this refers to sp::Spatial-class as Spatial is capitalized. I
don't know
whether this will affect swapping in and out of sf <->sp, but include it
for completeness.

Thanks again,

Chris

On Thu, Mar 16, 2017 at 5:06 AM, Edzer Pebesma <
edzer.pebe...@uni-muenster.de> wrote:

> Mike, Chris, the configure step should now pass regardless whether
> liblwgeom is present, or not; the error message was my mistake.
>
> sf will link to liblwgeom when its development version is present (on
> ubuntu: liblwgeom-dev). If postgis is binary installed, liblwgeom may be
> present, but not its dev version (needed for header files); that case is
> now being caught too.
>
> liblwgeom provides st_make_valid, essentially ST_makeValid in postgis;
> see https://github.com/edzer/sfr/issues/67 . Since liblwgeom is not
> available on the CRAN build farms, it's presence is not required by sf.
>
> Best regards,
>
> On 16/03/17 05:46, chris english wrote:
> > Michael,
> >
> > I have the very same failure,
> >> library(sf)
> > Linking to GEOS 3.4.2, GDAL 2.1.3, proj.4 4.9.1
> > (pre upgrade attempt, which still works just fine)
> >
> > checking for geos_c.h... yes
> > checking geos: linking with -lgeos_c... yes
> > checking for lwgeom_version in -llwgeom... no
> > configure: error: in `/tmp/RtmpsCmf6B/devtoolsd68e68107a/edzer-sfr-
> d620f3b':
> > configure: error: lwgeom test failed (--without-readline to disable)
> >
> > I could nearly copy your install output though on 16.04, and the same
> > tangle of it depends on x but it won't be installed & etc.
> > But, if you have PostGIS, you have liblwgeom as it is fairly specific to
> > PostGIS. Perhaps, rather than a devtools::github_install,
> > a clone github lo a local directory and config, make, install might
> > work, but I'm just imagining.
> >
> > then testing:
> > config.log --snip --
> > configure:3993: checking for lwgeom_version in -llwgeom
> > configure:4018: gcc -std=gnu99 -o conftest -g -O2 -fstack-protector
> > --param=ssp-
> > buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -g
> >  -I/usr/lo
> > cal/include   -I/usr/local/include -I/usr/local/include
> > -Wl,-Bsymbolic-functions
> >  -Wl,-z,relro conftest.c -llwgeom  -lproj  -L/usr/local/lib -lproj
> > -L/usr/loca
> > l/lib -lgdal -L/usr/local/lib -lgeos_c -lproj >&5
> > /tmp/ccDBUh1h.o: In function `main':
> > /home/chris/sfr/sfr/conftest.c:34: undefined reference to
> `lwgeom_version'
> > collect2: error: ld returned 1 exit status
> > configure:4018: $? = 1
> > configure: failed program was:
> > | /* confdefs.h */
> > | #define PACKAGE_NAME ""
> > | #define PACKAGE_TARNAME ""
> > | #define PACKAGE_VERSION ""
> > | #define PACKAGE_STRING ""
> > | #define PACKAGE_BUGREPORT ""
> > | #define PACKAGE_URL ""
> > | #define STDC_HEADERS 1
> > | #define HAVE_SYS_TYPES_H 1
> > | #define HAVE_SYS_STAT_H 1
> > | #define HAVE_STDLIB_H 1
> > | #define HAVE_STRING_H 1
> > | #define HAVE_MEMORY_H 1
> > | #define HAVE_STRINGS_H 1
> > | #define HAVE_INTTYPES_H 1
> > | #define HAVE_STDINT_H 1
> > | #define HAVE_UNISTD_H 1
> > | #define HAVE_GDAL_H 1
> > | #define HAVE_PROJ_API_H 1
> > | #define HAVE_LIBPROJ 1
> > | #define HAVE_GEOS_C_H 1
> > | /* end confdefs.h.  */
> > |
> > | /* Override any GCC internal prototype to avoid an error.
> > |Use char because int might match the return type of a GCC
> > |builtin and then its argument prototype would still apply.  */
> > | #ifdef __cplusplus
> > | extern "C"
> > | #endif
> > | char lwgeom_version ();
> > | int
> > | main ()
> > | {
> > | return lwgeom_version ();
> > |   ;
> > |   return 0;
> > | }
> > configure:4027: result: no
> > configure:4036: error: in `/home/chris/sfr/sfr':
> > configure:4038: error: lwgeom test failed (--without-readline to disable)
> > See `config.log' for more details
> >
> > so, it may or may not be the presence or absence of liblwgeom but simply
> > an undefined reference as suggested above:
> >
> > /home/chris/sfr/sfr/conftest.c:34: undefined reference to
> `lwgeom_version' ,
> >
> > but I'm unclear how the version was being requested (well, I can kind of
> > guess)
> > but faili

Re: [R-sig-Geo] Maintain SRID with st_write to postgis db

2017-03-16 Thread Edzer Pebesma



On 16/03/17 14:53, chris english wrote:
> Edzer,
> 
> Installs fine now, though st_make_valid is useful when cleaning messy
> inputs. I
> just installed new ubuntu binaries for PostGIS last night but will
> attend to rebuild
> from source. 
> 
>  The only thing to come up in an otherwise smooth install:
> ** preparing package for lazy loading
> in method for ‘coerce’ with signature ‘"Spatial","sf"’: no definition
> for class “Spatial”
> in method for ‘coerce’ with signature ‘"Spatial","sfc"’: no definition
> for class “Spatial”
> in method for ‘coerce’ with signature ‘"sf","Spatial"’: no definition
> for class “Spatial”
> in method for ‘coerce’ with signature ‘"sfc","Spatial"’: no definition
> for class “Spatial”
> ** help
> *** installing help indices
> ** building package indices
> ** installing vignettes
> ** testing if installed package can be loaded
> * DONE (sf)
> Reloading installed sf
> Linking to GEOS 3.4.2, GDAL 2.1.3, proj.4 4.9.1
> 
> I'm guessing this refers to sp::Spatial-class as Spatial is capitalized.
> I don't know
> whether this will affect swapping in and out of sf <->sp, but include it
> for completeness.

You can safely ignore it.

If `sf' would import `sp' it would go away, but there is no need to do
so. Not importing packages makes it easier to understand where they are
being used, and so limits the search for where things can go wrong.

> 
> Thanks again,
> 
> Chris
> 
> On Thu, Mar 16, 2017 at 5:06 AM, Edzer Pebesma
> mailto:edzer.pebe...@uni-muenster.de>>
> wrote:
> 
> Mike, Chris, the configure step should now pass regardless whether
> liblwgeom is present, or not; the error message was my mistake.
> 
> sf will link to liblwgeom when its development version is present (on
> ubuntu: liblwgeom-dev). If postgis is binary installed, liblwgeom may be
> present, but not its dev version (needed for header files); that case is
> now being caught too.
> 
> liblwgeom provides st_make_valid, essentially ST_makeValid in postgis;
> see https://github.com/edzer/sfr/issues/67
>  . Since liblwgeom is not
> available on the CRAN build farms, it's presence is not required by sf.
> 
> Best regards,
> 
> On 16/03/17 05:46, chris english wrote:
> > Michael,
> >
> > I have the very same failure,
> >> library(sf)
> > Linking to GEOS 3.4.2, GDAL 2.1.3, proj.4 4.9.1
> > (pre upgrade attempt, which still works just fine)
> >
> > checking for geos_c.h... yes
> > checking geos: linking with -lgeos_c... yes
> > checking for lwgeom_version in -llwgeom... no
> > configure: error: in
> `/tmp/RtmpsCmf6B/devtoolsd68e68107a/edzer-sfr-d620f3b':
> > configure: error: lwgeom test failed (--without-readline to disable)
> >
> > I could nearly copy your install output though on 16.04, and the same
> > tangle of it depends on x but it won't be installed & etc.
> > But, if you have PostGIS, you have liblwgeom as it is fairly
> specific to
> > PostGIS. Perhaps, rather than a devtools::github_install,
> > a clone github lo a local directory and config, make, install might
> > work, but I'm just imagining.
> >
> > then testing:
> > config.log --snip --
> > configure:3993: checking for lwgeom_version in -llwgeom
> > configure:4018: gcc -std=gnu99 -o conftest -g -O2 -fstack-protector
> > --param=ssp-
> > buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -g
> >  -I/usr/lo
> > cal/include   -I/usr/local/include -I/usr/local/include
> > -Wl,-Bsymbolic-functions
> >  -Wl,-z,relro conftest.c -llwgeom  -lproj  -L/usr/local/lib -lproj
> > -L/usr/loca
> > l/lib -lgdal -L/usr/local/lib -lgeos_c -lproj >&5
> > /tmp/ccDBUh1h.o: In function `main':
> > /home/chris/sfr/sfr/conftest.c:34: undefined reference to
> `lwgeom_version'
> > collect2: error: ld returned 1 exit status
> > configure:4018: $? = 1
> > configure: failed program was:
> > | /* confdefs.h */
> > | #define PACKAGE_NAME ""
> > | #define PACKAGE_TARNAME ""
> > | #define PACKAGE_VERSION ""
> > | #define PACKAGE_STRING ""
> > | #define PACKAGE_BUGREPORT ""
> > | #define PACKAGE_URL ""
> > | #define STDC_HEADERS 1
> > | #define HAVE_SYS_TYPES_H 1
> > | #define HAVE_SYS_STAT_H 1
> > | #define HAVE_STDLIB_H 1
> > | #define HAVE_STRING_H 1
> > | #define HAVE_MEMORY_H 1
> > | #define HAVE_STRINGS_H 1
> > | #define HAVE_INTTYPES_H 1
> > | #define HAVE_STDINT_H 1
> > | #define HAVE_UNISTD_H 1
> > | #define HAVE_GDAL_H 1
> > | #define HAVE_PROJ_API_H 1
> > | #define HAVE_LIBPROJ 1
> > | #define HAVE_GEOS_C_H 1
> > | /* end confdefs.h.  */
> > |
> > | /* Override any GCC internal prototype to avoid an error.
> > |Use char because int might match the return type of a GCC
> > |builtin and then its argument prototype

Re: [R-sig-Geo] Sentienl 2 gdal translate

2017-03-16 Thread Loïc Dutrieux

Hi Miguel,

Briefly looking at the help and source code of
gdalUtils::gdal_translate(), I don't see any way to pass additional
options. Your best shot is therefore probably to build the expression
yourself and pass it via a system call.

library(raster)

Image_Path<-'/path/to/images/'

S2_JP2_List <- list.files(Image_Path, full.names = TRUE, pattern = ".jp2$")

for (file in S2_JP2_List) {
  out_file <- extension(file, 'tif')
  system2('gdal_translate', args = c('-of GTiff', file, out_file,
'--config GDAL_SKIP JPECW'))
}

But the real question here is why the simple gdal_translate call without
--config GDAL_SKIP JPECW did not work for you while you clearly have the
sentinel2 driver...

Cheers,
Loïc

On 16/03/17 06:02, Miguel Castro Gómez wrote:
> Hi Loïc,
> 
> I have tried your code but it does not work yet. It just produces one
> tif file for the first band but this file is not correct (8 kb just).
> The R process keep working for a long time without any other output
> 
> Here are the versions I’m using
> 
> R version: 3.3.2
> gdalUtils: v 2.0.1.7
> raster: 2.5-8
> gdal: 2.1.2, released 2016/10/24
> 
> When checking for the sentinel 2 driver in gdal (see red)
> 
>  gdal-config --formats | grep sentinel2
> gxf gtiff hfa aigrid aaigrid ceos ceos2 iso8211 xpm sdts raw dted mem
> jdem envisat elas fit vrt usgsdem l1b nitf bmp airsar rs2 ilwis rmf
> leveller sgi srtmhgt idrisi gsg ingr ers jaxapalsar dimap gff cosar pds
> adrg coasp tsx terragen blx msgn til r northwood saga xyz hf2
> kmlsuperoverlay ctg e00grid zmap ngsgeoid iris map cals safe *sentinel2*
> mrf webp wcs wms plmosaic wmts dods grib bsb openjpeg jpeg2000 netcdf
> hdf5 hdf4 ogdi gif jpeg gta png pcraster fits pcidsk rik ozi rasterlite
> mbtiles postgisraster arg
> 
> I think the problem is the driver that is used to manage the jp2 file.
> Any idea how can I include in the R code the --config GDAL_SKIP JP2ECW
> option. 
> 
> Cheers,
> M
> 
>> El 15 mar 2017, a las 23:13, Loïc Dutrieux
>> mailto:loic.dutri...@conabio.gob.mx>>
>> escribió:
>>
>> Hi,
>>
>> I tried your code with some S2 images I had lying around, and it works
>> on my system. I modified it a bit to write the output layers to the same
>> directory and not to my working directory.
>>
>> library(gdalUtils)
>> library(raster)
>>
>> Image_Path<-'/path/to/images/'
>>
>> S2_JP2_List <- list.files(Image_Path, full.names = TRUE, pattern =
>> ".jp2$")
>>
>> for (file in S2_JP2_List) {
>>  out_file <- extension(file, 'tif')
>>  gdal_translate(src_dataset = file, dst_dataset = out_file, ot =
>> "UInt16", of = "GTiff")
>> }
>>
>> gdal has a sentinel 2 driver, but it's not extremely old, therefore it's
>> possible that your installation doesn't have it; you can check with:
>>
>> gdal-config --formats | grep sentinel2
>>
>> Cheers,
>> Loïc
>>
>>
>>
>> On 15/03/17 12:49, Miguel Castro Gómez wrote:
>>> Hi,
>>>
>>> I have Sentinel 2 images (jp2) that I want to convert to GTiff using
>>> gdal_translate in R (from gdalutils package). Here is the code I’m using
>>>
>>> Image_Path<-“/path/to/wd“
>>>
>>> S2_JP2_List <- list.files(Image_Path, full.names = TRUE, pattern =
>>> ".jp2$")
>>>
>>> for (i in 1:length(S2_JP2_List)) {
>>> gdal_translate(src_dataset = S2_JP2_List[[i]], dst_dataset =
>>> paste("Band", i , "tif"), ot = "UInt16", of = “GTiff")
>>>}
>>>
>>> When running this code, the process starts without any error but its
>>> never ending neither producing any output
>>>
>>> I've tried to do it in gdal and the same code works, except that it
>>> is necessary to skip  the default driver since it cannot manage large
>>> jp2 files.
>>>
>>> gdal_translate -of GTiff /path/to/input/S2_b1.jp2
>>>  /path/to/output/S2_b1converted.tif --config GDAL_SKIP JP2ECW
>>>
>>> Any idea how could I run this in R?
>>>
>>> Thanks
>>> M
>>>
>>>
>>>
>>> [[alternative HTML version deleted]]
>>>
>>> ___
>>> 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
> 
> 
> 
> Email secured by Check Point
>

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

Re: [R-sig-Geo] Maintain SRID with st_write to postgis db

2017-03-16 Thread Michael Treglia

Thanks again Edzer - I've got the dev version installed sucessfully
now, but new issue popped up: my st_write statement now throws an
error:


>st_write(nypd_crime_current.sf, dsn="PG:dbname=dbname user=user 
>host=xx.xx.xx.xx", layer='health_safety.crime_current')

Writing layer `health_safety.crime_current' to data source
`PG:dbname=dbname user=user host=xx.xx.xx.xx' using driver
`PostgreSQL'
Dataset PG:dbname=dbname user=user host=xx.xx.xx.xx already exists;
remove first, or use update=TRUE to append.
Error in CPL_write_ogr(obj, dsn, layer, driver,
as.character(dataset_options),  :
  Dataset already exists.

> sessionInfo()
R version 3.3.1 (2016-06-21)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.5 LTS

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

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

other attached packages:
[1] RPostgreSQL_0.4-1 DBI_0.6   sf_0.4-0

loaded via a namespace (and not attached):
[1] magrittr_1.5  tools_3.3.1   units_0.4-2   Rcpp_0.12.9
udunits2_0.13 grid_3.3.1






The command works with the CRAN version of sf

> sessionInfo()
R version 3.3.1 (2016-06-21)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.5 LTS

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

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

other attached packages:
[1] sf_0.3-4

loaded via a namespace (and not attached):
[1] DBI_0.6   tools_3.3.1   units_0.4-2   Rcpp_0.12.9
udunits2_0.13 grid_3.3.1


(I realize st_write_db is an option, but not finding myself able to
specify a schema (it just gets written to public - if I name the table
'schema.tableName')

Sorry to keep bugging about this, and thanks again for these quick fixes!
mike

On Thu, Mar 16, 2017 at 11:15 AM, Edzer Pebesma
 wrote:
>
>
> On 16/03/17 14:53, chris english wrote:
>> Edzer,
>>
>> Installs fine now, though st_make_valid is useful when cleaning messy
>> inputs. I
>> just installed new ubuntu binaries for PostGIS last night but will
>> attend to rebuild
>> from source.
>>
>>  The only thing to come up in an otherwise smooth install:
>> ** preparing package for lazy loading
>> in method for ‘coerce’ with signature ‘"Spatial","sf"’: no definition
>> for class “Spatial”
>> in method for ‘coerce’ with signature ‘"Spatial","sfc"’: no definition
>> for class “Spatial”
>> in method for ‘coerce’ with signature ‘"sf","Spatial"’: no definition
>> for class “Spatial”
>> in method for ‘coerce’ with signature ‘"sfc","Spatial"’: no definition
>> for class “Spatial”
>> ** help
>> *** installing help indices
>> ** building package indices
>> ** installing vignettes
>> ** testing if installed package can be loaded
>> * DONE (sf)
>> Reloading installed sf
>> Linking to GEOS 3.4.2, GDAL 2.1.3, proj.4 4.9.1
>>
>> I'm guessing this refers to sp::Spatial-class as Spatial is capitalized.
>> I don't know
>> whether this will affect swapping in and out of sf <->sp, but include it
>> for completeness.
>
> You can safely ignore it.
>
> If `sf' would import `sp' it would go away, but there is no need to do
> so. Not importing packages makes it easier to understand where they are
> being used, and so limits the search for where things can go wrong.
>
>>
>> Thanks again,
>>
>> Chris
>>
>> On Thu, Mar 16, 2017 at 5:06 AM, Edzer Pebesma
>> mailto:edzer.pebe...@uni-muenster.de>>
>> wrote:
>>
>> Mike, Chris, the configure step should now pass regardless whether
>> liblwgeom is present, or not; the error message was my mistake.
>>
>> sf will link to liblwgeom when its development version is present (on
>> ubuntu: liblwgeom-dev). If postgis is binary installed, liblwgeom may be
>> present, but not its dev version (needed for header files); that case is
>> now being caught too.
>>
>> liblwgeom provides st_make_valid, essentially ST_makeValid in postgis;
>> see https://github.com/edzer/sfr/issues/67
>>  . Since liblwgeom is not
>> available on the CRAN build farms, it's presence is not required by sf.
>>
>> Best regards,
>>
>> On 16/03/17 05:46, chris english wrote:
>> > Michael,
>> >
>> > I have the very same failure,
>> >> library(sf)
>> > Linking to GEOS 3.4.2, GDAL 2.1.3, proj.4 4.9.1
>> > (pre upgrade attempt, which still works just fine)
>> >
>> > checking for geos_c.h... yes
>> > checking geos: linking with -lgeos_c... yes
>> > ch

Re: [R-sig-Geo] Maintain SRID with st_write to postgis db

2017-03-16 Thread Edzer Pebesma



On 16/03/17 20:01, Michael Treglia wrote:
> Thanks again Edzer - I've got the dev version installed sucessfully
> now, but new issue popped up: my st_write statement now throws an
> error:
> 
> 
>> st_write(nypd_crime_current.sf, dsn="PG:dbname=dbname user=user 
>> host=xx.xx.xx.xx", layer='health_safety.crime_current')
> 
> Writing layer `health_safety.crime_current' to data source
> `PG:dbname=dbname user=user host=xx.xx.xx.xx' using driver
> `PostgreSQL'
> Dataset PG:dbname=dbname user=user host=xx.xx.xx.xx already exists;
> remove first, or use update=TRUE to append.

with update=TRUE it will work.

So far, sf would simply overwrite existing files on st_write(), which is
not exactly a good idea, always - rgdal::writeOGR is much more careful.
I changed it this way now, but agree that it is not very satisfactory if
dsn is a database, which is expected to exist, so I expect the
requirement to add `update=TRUE' to disappear in a future release for
database dsn's.

more further down:

> Error in CPL_write_ogr(obj, dsn, layer, driver,
> as.character(dataset_options),  :
>   Dataset already exists.
> 
>> sessionInfo()
> R version 3.3.1 (2016-06-21)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 14.04.5 LTS
> 
> locale:
>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
> LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
>  [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
> LC_PAPER=en_US.UTF-8   LC_NAME=C
>  [9] LC_ADDRESS=C   LC_TELEPHONE=C
> LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
> 
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
> 
> other attached packages:
> [1] RPostgreSQL_0.4-1 DBI_0.6   sf_0.4-0
> 
> loaded via a namespace (and not attached):
> [1] magrittr_1.5  tools_3.3.1   units_0.4-2   Rcpp_0.12.9
> udunits2_0.13 grid_3.3.1
> 
> 
> 
> 
> 
> 
> The command works with the CRAN version of sf
> 
>> sessionInfo()
> R version 3.3.1 (2016-06-21)
> Platform: x86_64-pc-linux-gnu (64-bit)
> Running under: Ubuntu 14.04.5 LTS
> 
> locale:
>  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
> LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
>  [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
> LC_PAPER=en_US.UTF-8   LC_NAME=C
>  [9] LC_ADDRESS=C   LC_TELEPHONE=C
> LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
> 
> attached base packages:
> [1] stats graphics  grDevices utils datasets  methods   base
> 
> other attached packages:
> [1] sf_0.3-4
> 
> loaded via a namespace (and not attached):
> [1] DBI_0.6   tools_3.3.1   units_0.4-2   Rcpp_0.12.9
> udunits2_0.13 grid_3.3.1
> 
> 
> (I realize st_write_db is an option, but not finding myself able to
> specify a schema (it just gets written to public - if I name the table
> 'schema.tableName')

try table = c("schema", "table")

> 
> Sorry to keep bugging about this, and thanks again for these quick fixes!
> mike
> 
> On Thu, Mar 16, 2017 at 11:15 AM, Edzer Pebesma
>  wrote:
>>
>>
>> On 16/03/17 14:53, chris english wrote:
>>> Edzer,
>>>
>>> Installs fine now, though st_make_valid is useful when cleaning messy
>>> inputs. I
>>> just installed new ubuntu binaries for PostGIS last night but will
>>> attend to rebuild
>>> from source.
>>>
>>>  The only thing to come up in an otherwise smooth install:
>>> ** preparing package for lazy loading
>>> in method for ‘coerce’ with signature ‘"Spatial","sf"’: no definition
>>> for class “Spatial”
>>> in method for ‘coerce’ with signature ‘"Spatial","sfc"’: no definition
>>> for class “Spatial”
>>> in method for ‘coerce’ with signature ‘"sf","Spatial"’: no definition
>>> for class “Spatial”
>>> in method for ‘coerce’ with signature ‘"sfc","Spatial"’: no definition
>>> for class “Spatial”
>>> ** help
>>> *** installing help indices
>>> ** building package indices
>>> ** installing vignettes
>>> ** testing if installed package can be loaded
>>> * DONE (sf)
>>> Reloading installed sf
>>> Linking to GEOS 3.4.2, GDAL 2.1.3, proj.4 4.9.1
>>>
>>> I'm guessing this refers to sp::Spatial-class as Spatial is capitalized.
>>> I don't know
>>> whether this will affect swapping in and out of sf <->sp, but include it
>>> for completeness.
>>
>> You can safely ignore it.
>>
>> If `sf' would import `sp' it would go away, but there is no need to do
>> so. Not importing packages makes it easier to understand where they are
>> being used, and so limits the search for where things can go wrong.
>>
>>>
>>> Thanks again,
>>>
>>> Chris
>>>
>>> On Thu, Mar 16, 2017 at 5:06 AM, Edzer Pebesma
>>> mailto:edzer.pebe...@uni-muenster.de>>
>>> wrote:
>>>
>>> Mike, Chris, the configure step should now pass regardless whether
>>> liblwgeom is present, or not; the error message was my mistake.
>>>
>>> sf will link to liblwgeom when its development version is present (on
>>> ubuntu: liblwgeom-dev). If postgis is binary installed, liblwgeom may be
>>> present, but not its dev version (needed for header files); t

Re: [R-sig-Geo] Same mask for two rasters, but obtaining different extents in R

[R-sig-Geo] Getis Ord G test in 3 dimensions

Re: [R-sig-Geo] Maintain SRID with st_write to postgis db

Re: [R-sig-Geo] Sentienl 2 gdal translate

Re: [R-sig-Geo] Getis Ord G test in 3 dimensions

Re: [R-sig-Geo] Same mask for two rasters, but obtaining different extents in R

Re: [R-sig-Geo] Maintain SRID with st_write to postgis db

Re: [R-sig-Geo] Maintain SRID with st_write to postgis db

Re: [R-sig-Geo] Sentienl 2 gdal translate

Re: [R-sig-Geo] Maintain SRID with st_write to postgis db

Re: [R-sig-Geo] Maintain SRID with st_write to postgis db

11 matches

Site Navigation

Mail list logo

Footer information