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: 2 hours 14 min ago

Re: Eurostat shapefiles & google maps offset

Fri, 03/24/2017 - 08:42
Hello, you'll need to reproject either your shapefiles or the background
images.  The mapmisc package can get you background images in a specified
projection
https://journal.r-project.org/archive/2016-1/brown.pdf

p


> Message: 1
> Date: Wed, 22 Mar 2017 18:19:01 +0100
> From: Martin Zuba <[hidden email]>
> To: [hidden email]
> Subject: [R-sig-Geo] Eurostat shapefiles & google maps offset
> Message-ID:
>         <CAG3rrX6XbtNo8B9oTa=5=Yu7pN3WAA9m+BNC=dXKssA2D_un6Q@
> mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Dear list,
>
> I would like to plot shaded shapefiles with static google maps background
> images.
>
> I obtain the shapefiles from Eurostat, via the eurostat R package.
>
> I obtain the static google background images from using the get_map wrapper
> from the R package ggmap.
>
> My problem is that there seems to be an offset between those two coordinate
> systems. I know that the Eurostat files uss the coordinate reference system
> ETRS89 and google maps uses WSG84, which should be (almost) identical.
>
> However, google images and the shapefiles are somwhat off; and that offset
> is not constant, which indicates that there might be a problem related to
> projections.
>
>
> illustration:
> https://www.dropbox.com/s/34k2ace42ubjjek/eurostatVSgoogle.png?dl=0
>
> replication:
> https://www.dropbox.com/s/hhoc84lrmo42imf/niceEurostat.R?dl=0
>
>
> I welcome any suggestions.
>
> Best Regards,
>
> Martin Zuba
>
>         [[alternative HTML version deleted]]
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>
> ------------------------------
>
> End of R-sig-Geo Digest, Vol 163, Issue 20
> ******************************************
>
        [[alternative HTML version deleted]]

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

Eurostat shapefiles & google maps offset

Wed, 03/22/2017 - 11:19
Dear list,

I would like to plot shaded shapefiles with static google maps background
images.

I obtain the shapefiles from Eurostat, via the eurostat R package.

I obtain the static google background images from using the get_map wrapper
from the R package ggmap.

My problem is that there seems to be an offset between those two coordinate
systems. I know that the Eurostat files uss the coordinate reference system
ETRS89 and google maps uses WSG84, which should be (almost) identical.

However, google images and the shapefiles are somwhat off; and that offset
is not constant, which indicates that there might be a problem related to
projections.


illustration:
https://www.dropbox.com/s/34k2ace42ubjjek/eurostatVSgoogle.png?dl=0

replication:
https://www.dropbox.com/s/hhoc84lrmo42imf/niceEurostat.R?dl=0


I welcome any suggestions.

Best Regards,

Martin Zuba

        [[alternative HTML version deleted]]

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

Re: read the .nc file and obtain the vector data of a region

Mon, 03/20/2017 - 19:31
There are some packages like gdal or the overlay/extract function of sp
that can help you. The most important is to open the information and once
you have the matrix (of the data) if you have the positions in the matrix
which correspond to your geographical units (china) you can extract only
those pixels/positions.

All the best,

Andres

On 21 Mar 2017 02:26, "hnstedu" <[hidden email]> wrote:

Hi, dear friend,
I have download the surface PM2.5 data provided in  NetCDF [.nc] file (
http://fizz.phys.dal.ca/~atmos/martin/?page_id=140).
My goal is to obtain the PM2.5 data of various provinces in China using
this nc file. I know wo can employ the "ncdf4" package
to load the nc file in R. However, I have no idea to obtain the
corresponding data of one region (e.g. China Provinces).
Any idea?


Thanks very much !


Bests,
wanhaiyou
        [[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

read the .nc file and obtain the vector data of a region

Mon, 03/20/2017 - 19:25
Hi, dear friend,
I have download the surface PM2.5 data provided in  NetCDF [.nc] file (http://fizz.phys.dal.ca/~atmos/martin/?page_id=140).
My goal is to obtain the PM2.5 data of various provinces in China using this nc file. I know wo can employ the "ncdf4" package
to load the nc file in R. However, I have no idea to obtain the corresponding data of one region (e.g. China Provinces).
Any idea?


Thanks very much !


Bests,
wanhaiyou
        [[alternative HTML version deleted]]

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

Re: Sentienl 2 gdal translate

Fri, 03/17/2017 - 11:12
Hi Miguel,

Do you have more than one installation of gdal? That could potentially
explain why your first try with gdal_translate() did not work.

library(gdalUtils)
length(getOption("gdalUtils_gdalPath"))

should give you the number of installations you have on your system.

If more than 1, gdal_chooseInstallation(hasDrivers=c("SENTINEL2"))
should set the correct path for gdal_translate().

Cheers,
Loïc

On 17/03/17 05:45, Miguel Castro Gómez wrote:
> Hi Loïc,
>
> Thanks for your help,
>
> When trying the system2 option this is what happens:
>
> 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'))
> }
>
> sh: gdal_translate: command not found
>
>
> I have been checking and the problem may be that R cannot find the
> gdal_translate command. Here are the paths:
>
> Sys.getenv('R_HOME’)
> "/Library/Frameworks/R.framework/Resources"
> Sys.getenv('PATH')
> "/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin”
>
> In terminal:
> user$ echo $PATH
> /Library/Frameworks/GDAL.framework/Programs:/Library/Frameworks/GDAL.framework/Programs:/Library/Frameworks/GDAL.framework/Programs:/Users/Miguel/anaconda/bin:/Library/Frameworks/Python.framework/Versions/3.5/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
>
>
> I think it has to match but not sure how can I change the path that R is
> using to find the command gdal_translate
>
> Regarding sentinel2 driver, any idea why is not working? Any help on that
>
> Cheers
> M
>
>
>> El 16 mar 2017, a las 19:21, Loïc Dutrieux
>> <[hidden email] <mailto:[hidden email]>>
>> escribió:
>>
>> 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
>>>> <[hidden email]
>>>> <mailto:[hidden email]> <mailto:[hidden email]>>
>>>> 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
>>>>> [hidden email]
>>>>> <mailto:[hidden email]> <mailto:[hidden email]>
>>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>>>
>>>>
>>>> _______________________________________________
>>>> R-sig-Geo mailing list
>>>> [hidden email]
>>>> <mailto:[hidden email]> <mailto:[hidden email]>
>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>
>>>
>>>
>>> Email secured by Check Point
>
>
>
> Email secured by Check Point
>
_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: xlsx or rJava issue

Fri, 03/17/2017 - 05:59
Thank you Thiago that worked!

Rgui:

 > library(rJava)
 > library(xlsx)
Loading required package: xlsxjars
 >


On 17/03/2017 10:17, Thiago V. dos Santos wrote:
> Didier, I noticed you are using macOS. Are you by any chance using RStudio as well? If yes, besides Edzer's suggestion, the following command has also helped me in the past:
>
> sudo ln -f -s $(/usr/libexec/java_home)/jre/lib/server/libjvm.dylib /usr/local/lib
>
> Then, try re-installing rJava - *from source* - now. It should work.
>   Hope this helps,
>   -- Thiago V. dos Santos
>
> PhD student
> Land and Atmospheric Science
> University of Minnesota
>
>
>
> On Friday, March 17, 2017 4:52 AM, Dr Didier G. Leibovici <[hidden email]> wrote:
> Hi,
>
> I had some issues with java settings when using xlsx.
>
> I had re-installed rJava as well.
>
>> library(xlsx)
> Error : .onLoad failed in loadNamespace() for 'xlsx', details:
>     call: .jinit()
>     error: JNI_GetCreatedJavaVMs returned -1
>
> Error: package or namespace load failed for ‘xlsx’
> JavaVM: requested Java version ((null)) not available. Using Java at ""
> instead.
> JavaVM: Failed to load JVM: /bundle/Libraries/libserver.dylib
> JavaVM FATAL: Failed to load the jvm library.
>
> that file on my machine is in:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home/jre/lib/server/
>
> is it a particular JAVA_HOME setting or a PATH issue?
>
> I added this in the PATH, re-installed rJava, re-installed xlsx ... nope!
> thanks,
>
> Didier
>
> on R version 3.3.2 (2016-10-31)
>
--
Dr Didier G. Leibovici
    d-d'ye    ley-bow-v-c
Senior Research Fellow
Geocomputational Modelling & Geospatial Statistics
Nottingham Geospatial Institute
University of Nottingham, UK
+44 (0)115 84 13924
http://www.nottingham.ac.uk/ngi/people/didier.leibovici
Google+ [hidden email]
Skype didierleibovici





This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it.

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.


        [[alternative HTML version deleted]]

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

Re: Sentienl 2 gdal translate

Fri, 03/17/2017 - 05:45
Hi Loïc,

Thanks for your help,

When trying the system2 option this is what happens:

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'))
}

sh: gdal_translate: command not found


I have been checking and the problem may be that R cannot find the gdal_translate command. Here are the paths:

Sys.getenv('R_HOME’)
"/Library/Frameworks/R.framework/Resources"
Sys.getenv('PATH')
"/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin”

In terminal:
user$ echo $PATH
/Library/Frameworks/GDAL.framework/Programs:/Library/Frameworks/GDAL.framework/Programs:/Library/Frameworks/GDAL.framework/Programs:/Users/Miguel/anaconda/bin:/Library/Frameworks/Python.framework/Versions/3.5/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin


I think it has to match but not sure how can I change the path that R is using to find the command gdal_translate

Regarding sentinel2 driver, any idea why is not working? Any help on that

Cheers
M


> El 16 mar 2017, a las 19:21, Loïc Dutrieux <[hidden email]> escribió:
>
> 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
>>> <[hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>>
>>> 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
>>>> [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>
>>>>
>>>
>>> _______________________________________________
>>> R-sig-Geo mailing list
>>> [hidden email] <mailto:[hidden email]> <mailto:[hidden email] <mailto:[hidden email]>>
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>
>>
>>
>>
>> Email secured by Check Point

        [[alternative HTML version deleted]]

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

Re: xlsx or rJava issue

Fri, 03/17/2017 - 04:17
Didier, I noticed you are using macOS. Are you by any chance using RStudio as well? If yes, besides Edzer's suggestion, the following command has also helped me in the past:

sudo ln -f -s $(/usr/libexec/java_home)/jre/lib/server/libjvm.dylib /usr/local/lib

Then, try re-installing rJava - *from source* - now. It should work.
 Hope this helps,
 -- Thiago V. dos Santos

PhD student
Land and Atmospheric Science
University of Minnesota



On Friday, March 17, 2017 4:52 AM, Dr Didier G. Leibovici <[hidden email]> wrote:
Hi,

I had some issues with java settings when using xlsx.

I had re-installed rJava as well.

> library(xlsx)
Error : .onLoad failed in loadNamespace() for 'xlsx', details:
   call: .jinit()
   error: JNI_GetCreatedJavaVMs returned -1

Error: package or namespace load failed for ‘xlsx’
JavaVM: requested Java version ((null)) not available. Using Java at ""
instead.
JavaVM: Failed to load JVM: /bundle/Libraries/libserver.dylib
JavaVM FATAL: Failed to load the jvm library.

that file on my machine is in:
/Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home/jre/lib/server/

is it a particular JAVA_HOME setting or a PATH issue?

I added this in the PATH, re-installed rJava, re-installed xlsx ... nope!
thanks,

Didier

on R version 3.3.2 (2016-10-31)

--
Dr Didier G. Leibovici
    d-d'ye    ley-bow-v-c
Senior Research Fellow
Geocomputational Modelling & Geospatial Statistics
Nottingham Geospatial Institute
University of Nottingham, UK
+44 (0)115 84 13924
http://www.nottingham.ac.uk/ngi/people/didier.leibovici
Google+ [hidden email]
Skype didierleibovici





This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it.

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.


    [[alternative HTML version deleted]]

_______________________________________________
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: xlsx or rJava issue

Fri, 03/17/2017 - 04:12
Yes, thanks Edzer I found this solution though Rgui didn't seem to get
it (could that be after a reboot?) thanks, Didier


On 17/03/2017 09:56, Edzer Pebesma wrote:
> Didier, this is somewhat off-topic for this list, but in the past I've
> solved all my R/java troubles with running, as root
>
> R CMD javareconf
>
> On 17/03/17 10:46, Dr Didier G. Leibovici wrote:
>> Hi,
>>
>> I had some issues with java settings when using xlsx.
>>
>> I had re-installed rJava as well.
>>
>>   > library(xlsx)
>> Error : .onLoad failed in loadNamespace() for 'xlsx', details:
>>     call: .jinit()
>>     error: JNI_GetCreatedJavaVMs returned -1
>>
>> Error: package or namespace load failed for �xlsx�
>> JavaVM: requested Java version ((null)) not available. Using Java at ""
>> instead.
>> JavaVM: Failed to load JVM: /bundle/Libraries/libserver.dylib
>> JavaVM FATAL: Failed to load the jvm library.
>>
>> that file on my machine is in:
>> /Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home/jre/lib/server/
>>
>> is it a particular JAVA_HOME setting or a PATH issue?
>>
>> I added this in the PATH, re-installed rJava, re-installed xlsx ... nope!
>> thanks,
>>
>> Didier
>>
>> on R version 3.3.2 (2016-10-31)
>>
>
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo--
Dr Didier G. Leibovici
    d-d'ye    ley-bow-v-c
Senior Research Fellow
Geocomputational Modelling & Geospatial Statistics
Nottingham Geospatial Institute
University of Nottingham, UK
+44 (0)115 84 13924
http://www.nottingham.ac.uk/ngi/people/didier.leibovici
Google+ [hidden email]
Skype didierleibovici





This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it.

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.


        [[alternative HTML version deleted]]


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

Re: xlsx or rJava issue

Fri, 03/17/2017 - 04:10
A bit of dig up on google and I found
(http://stackoverflow.com/questions/35179151/cannot-load-r-xlsx-package-on-mac-os-10-11)
which resolves the thing in a terminal but when using Rgui same thing (?)

I tried re-installing in Rgui and now it is library(rJava) which cannot
load (?)

library(xlsx)
Loading required package: rJava
Error : .onLoad failed in loadNamespace() for 'rJava', details:
   call: dyn.load(file, DLLpath = DLLpath, ...)
   error: unable to load shared object
'/Users/lgzdl/Library/R/3.3/library/rJava/libs/rJava.so':
   dlopen(/Users/lgzdl/Library/R/3.3/library/rJava/libs/rJava.so, 6):
Library not loaded: @rpath/libjvm.dylib
   Referenced from: /Users/lgzdl/Library/R/3.3/library/rJava/libs/rJava.so
   Reason: image not found
Error: package ‘rJava’ could not be loaded

but at least I can work with R in a terminal!

cheers to SanjayIV,

Didier



On 17/03/2017 09:46, Dr Didier G. Leibovici wrote:
> Hi,
>
> I had some issues with java settings when using xlsx.
>
> I had re-installed rJava as well.
>
>   > library(xlsx)
> Error : .onLoad failed in loadNamespace() for 'xlsx', details:
>     call: .jinit()
>     error: JNI_GetCreatedJavaVMs returned -1
>
> Error: package or namespace load failed for ‘xlsx’
> JavaVM: requested Java version ((null)) not available. Using Java at ""
> instead.
> JavaVM: Failed to load JVM: /bundle/Libraries/libserver.dylib
> JavaVM FATAL: Failed to load the jvm library.
>
> that file on my machine is in:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home/jre/lib/server/
>
> is it a particular JAVA_HOME setting or a PATH issue?
>
> I added this in the PATH, re-installed rJava, re-installed xlsx ... nope!
> thanks,
>
> Didier
>
> on R version 3.3.2 (2016-10-31)
>
--
Dr Didier G. Leibovici
    d-d'ye    ley-bow-v-c
Senior Research Fellow
Geocomputational Modelling & Geospatial Statistics
Nottingham Geospatial Institute
University of Nottingham, UK
+44 (0)115 84 13924
http://www.nottingham.ac.uk/ngi/people/didier.leibovici
Google+ [hidden email]
Skype didierleibovici





This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it.

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.


        [[alternative HTML version deleted]]

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

Re: xlsx or rJava issue

Fri, 03/17/2017 - 03:56
Didier, this is somewhat off-topic for this list, but in the past I've
solved all my R/java troubles with running, as root

R CMD javareconf

On 17/03/17 10:46, Dr Didier G. Leibovici wrote:
> Hi,
>
> I had some issues with java settings when using xlsx.
>
> I had re-installed rJava as well.
>
>  > library(xlsx)
> Error : .onLoad failed in loadNamespace() for 'xlsx', details:
>    call: .jinit()
>    error: JNI_GetCreatedJavaVMs returned -1
>
> Error: package or namespace load failed for ‘xlsx’
> JavaVM: requested Java version ((null)) not available. Using Java at ""
> instead.
> JavaVM: Failed to load JVM: /bundle/Libraries/libserver.dylib
> JavaVM FATAL: Failed to load the jvm library.
>
> that file on my machine is in:
> /Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home/jre/lib/server/
>
> is it a particular JAVA_HOME setting or a PATH issue?
>
> I added this in the PATH, re-installed rJava, re-installed xlsx ... nope!
> thanks,
>
> Didier
>
> on R version 3.3.2 (2016-10-31)
> --
Edzer Pebesma
Institute for Geoinformatics  (ifgi),  University of Münster
Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081
Journal of Statistical Software:   http://www.jstatsoft.org/
Computers & Geosciences:   http://elsevier.com/locate/cageo/


_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
signature.asc (484 bytes) Download Attachment

xlsx or rJava issue

Fri, 03/17/2017 - 03:46
Hi,

I had some issues with java settings when using xlsx.

I had re-installed rJava as well.

 > library(xlsx)
Error : .onLoad failed in loadNamespace() for 'xlsx', details:
   call: .jinit()
   error: JNI_GetCreatedJavaVMs returned -1

Error: package or namespace load failed for ‘xlsx’
JavaVM: requested Java version ((null)) not available. Using Java at ""
instead.
JavaVM: Failed to load JVM: /bundle/Libraries/libserver.dylib
JavaVM FATAL: Failed to load the jvm library.

that file on my machine is in:
/Library/Java/JavaVirtualMachines/jdk1.8.0_25.jdk/Contents/Home/jre/lib/server/

is it a particular JAVA_HOME setting or a PATH issue?

I added this in the PATH, re-installed rJava, re-installed xlsx ... nope!
thanks,

Didier

on R version 3.3.2 (2016-10-31)

--
Dr Didier G. Leibovici
    d-d'ye    ley-bow-v-c
Senior Research Fellow
Geocomputational Modelling & Geospatial Statistics
Nottingham Geospatial Institute
University of Nottingham, UK
+44 (0)115 84 13924
http://www.nottingham.ac.uk/ngi/people/didier.leibovici
Google+ [hidden email]
Skype didierleibovici





This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please send it back to me, and immediately delete it.

Please do not use, copy or disclose the information contained in this
message or in any attachment.  Any views or opinions expressed by the
author of this email do not necessarily reflect the views of the
University of Nottingham.

This message has been checked for viruses but the contents of an
attachment may still contain software viruses which could damage your
computer system, you are advised to perform your own checks. Email
communications with the University of Nottingham may be monitored as
permitted by UK legislation.


        [[alternative HTML version deleted]]

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

Re: Maintain SRID with st_write to postgis db

Thu, 03/16/2017 - 15:17


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-8        LC_COLLATE=en_US.UTF-8
>  [5] LC_MONETARY=en_US.UTF-8    LC_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-8        LC_COLLATE=en_US.UTF-8
>  [5] LC_MONETARY=en_US.UTF-8    LC_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
> <[hidden email]> 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
>>> <[hidden email] <mailto:[hidden email]>>
>>> 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
>>>     <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
>>>     <[hidden email] <mailto:[hidden email]>
>>>     > <mailto:[hidden email] <mailto:[hidden email]>>> 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
>>>     >
>>>     >
>>>     >
>>>     >     #Output of install from github
>>>     >     > install_github("edzer/sfr")
>>>     >     Downloading GitHub repo edzer/sfr@master
>>>     >     from URL https://api.github.com/repos/edzer/sfr/zipball/master
>>>     <https://api.github.com/repos/edzer/sfr/zipball/master>
>>>     >     <https://api.github.com/repos/edzer/sfr/zipball/master
>>>     <https://api.github.com/repos/edzer/sfr/zipball/master>>
>>>     >     Installing sf
>>>     >     '/usr/lib/R/bin/R' --no-site-file --no-environ --no-save
>>>     --no-restore
>>>     >     --quiet  \
>>>     >       CMD INSTALL
>>>     '/tmp/RtmpKLmhyt/devtools9fd11eb9c3/edzer-sfr-d620f3b'  \
>>>     >       --library='/home/mlt244/R/x86_64-pc-linux-gnu-library/3.3'
>>>     >     --install-tests
>>>     >
>>>     >     * installing *source* package ‘sf’ ...
>>>     >     configure: CC: gcc -std=gnu99
>>>     >     configure: CXX: g++
>>>     >     configure: :
>>>     >     checking for gdal-config... /usr/bin/gdal-config
>>>     >     checking gdal-config usability... yes
>>>     >     configure: GDAL: 2.1.0
>>>     >     checking GDAL version >= 2.0.0... yes
>>>     >     checking for gcc... gcc -std=gnu99
>>>     >     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... no
>>>     >     checking for suffix of object files... o
>>>     >     checking whether we are using the GNU C compiler... yes
>>>     >     checking whether gcc -std=gnu99 accepts -g... yes
>>>     >     checking for gcc -std=gnu99 option to accept ISO C89... none
>>>     needed
>>>     >     checking how to run the C preprocessor... gcc -std=gnu99 -E
>>>     >     checking for grep that handles long lines and -e... /bin/grep
>>>     >     checking for egrep... /bin/grep -E
>>>     >     checking for ANSI C header files... yes
>>>     >     checking for sys/types.h... yes
>>>     >     checking for sys/stat.h... yes
>>>     >     checking for stdlib.h... yes
>>>     >     checking for string.h... yes
>>>     >     checking for memory.h... yes
>>>     >     checking for strings.h... yes
>>>     >     checking for inttypes.h... yes
>>>     >     checking for stdint.h... yes
>>>     >     checking for unistd.h... yes
>>>     >     checking gdal.h usability... yes
>>>     >     checking gdal.h presence... yes
>>>     >     checking for gdal.h... yes
>>>     >     checking GDAL: linking with --libs only... yes
>>>     >     checking GDAL: /usr/share/gdal/2.1/pcs.csv readable... yes
>>>     >     checking GDAL: checking whether PROJ.4 is available for
>>>     linking:... yes
>>>     >     checking GDAL: checking whether PROJ.4 is available fur
>>>     running:... yes
>>>     >     checking proj_api.h usability... yes
>>>     >     checking proj_api.h presence... yes
>>>     >     checking for proj_api.h... yes
>>>     >     checking for pj_init_plus in -lproj... yes
>>>     >     checking PROJ.4: epsg found and readable... yes
>>>     >     proj_conf_test.c: In function 'main':
>>>     >     proj_conf_test.c:5:5: error: unknown type name 'PAFile'
>>>     >          PAFile fp;
>>>     >          ^
>>>     >     proj_conf_test.c:8:5: warning: implicit declaration of function
>>>     >     'pj_open_lib' [-Wimplicit-function-declaration]
>>>     >          fp = pj_open_lib(ctx, "conus", "rb");
>>>     >          ^
>>>     >     proj_conf_test.c:9:12: warning: comparison between pointer and
>>>     integer
>>>     >     [enabled by default]
>>>     >          if (fp == NULL) exit(1);
>>>     >                 ^
>>>     >     proj_conf_test.c:10:5: warning: implicit declaration of function
>>>     >     'pj_ctx_fclose' [-Wimplicit-function-declaration]
>>>     >          pj_ctx_fclose(ctx, fp);
>>>     >          ^
>>>     >     ./configure: line 3834: ./proj_conf_test: No such file or
>>>     directory
>>>     >     checking PROJ.4: conus found and readable... yes
>>>     >     checking geos-config usability... yes
>>>     >     configure: GEOS: 3.5.0
>>>     >     checking GEOS version >= 3.3.0... yes
>>>     >     checking geos_c.h usability... yes
>>>     >     checking geos_c.h presence... yes
>>>     >     checking for geos_c.h... yes
>>>     >     checking geos: linking with -lgeos_c... yes
>>>     >     checking for lwgeom_version in -llwgeom... no
>>>     >     configure: error: in
>>>     >     `/tmp/RtmpKLmhyt/devtools9fd11eb9c3/edzer-sfr-d620f3b':
>>>     >     configure: error: lwgeom test failed (--without-readline to
>>>     disable)
>>>     >     See `config.log' for more details
>>>     >     ERROR: configuration failed for package ‘sf’
>>>     >     * removing ‘/home/mlt244/R/x86_64-pc-linux-gnu-library/3.3/sf’
>>>     >     * restoring previous
>>>     ‘/home/mlt244/R/x86_64-pc-linux-gnu-library/3.3/sf’
>>>     >     Error: Command failed (1)
>>>     >
>>>     >
>>>     >     On Wed, Mar 15, 2017 at 6:14 PM, Michael Treglia
>>>     <[hidden email] <mailto:[hidden email]>
>>>     >     <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>>>     >
>>>     >     > Wow - thanks so much for this quick fix, Edzer! I like your
>>>     >     solution to
>>>     >     > having syntatically different but semantically identical
>>>     >     proj4string. Will
>>>     >     > try this in a bit, and write back if I have any issues.
>>>     >     > Best,
>>>     >     > mike
>>>     >     >
>>>     >     > On Wed, Mar 15, 2017 at 5:58 PM, Edzer Pebesma <
>>>     >     > [hidden email] <mailto:[hidden email]>
>>>     >     <mailto:[hidden email]
>>>     <mailto:[hidden email]>>> wrote:
>>>     >     >
>>>     >     >> Great question! Short answer: now solved in the dev version on
>>>     >     github;
>>>     >     >> data are written directly to postgis having epsg 2263.
>>>     >     >>
>>>     >     >>
>>>     >     >> Long answer:
>>>     >     >>
>>>     >     >> I believe this was caused by gdal and proj.4 doing different
>>>     >     things when
>>>     >     >> resolving epsg codes to proj4strings. sf uses proj.4 for
>>>     this. When
>>>     >     >> writing a proj4string either gdal or postgis don't
>>>     recognize the
>>>     >     >> proj4string that proj.4 returns on the epsg code. Neither
>>>     gdal nor
>>>     >     >> postgis understand that syntactically different
>>>     proj4strings may be
>>>     >     >> semantically identical.
>>>     >     >>
>>>     >     >>
>>>     >     >> After running your example, in postgis
>>>     >     >>
>>>     >     >> # select proj4text from spatial_ref_sys where SRID = 900914;
>>>     >     >>
>>>     >     >> gives:
>>>     >     >>
>>>     >     >>  +proj=lcc +lat_1=41.03333333333333 +lat_2=40.66666666666666
>>>     >     >> +lat_0=40.16666666666666 +lon_0=-74 +x_0=300000 +y_0=0
>>>     +ellps=GRS80
>>>     >     >> +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs
>>>     >     >>
>>>     >     >> # select proj4text from spatial_ref_sys where SRID = 2263;
>>>     >     >>
>>>     >     >> gives:
>>>     >     >>
>>>     >     >>  +proj=lcc +lat_1=41.03333333333333 +lat_2=40.66666666666666
>>>     >     >> +lat_0=40.16666666666666 +lon_0=-74 +x_0=300000.0000000001
>>>     +y_0=0
>>>     >     >> +datum=NAD83 +units=us-ft +no_defs
>>>     >     >>
>>>     >     >> sf causes this:
>>>     >     >>
>>>     >     >> > st_crs(2263)
>>>     >     >> $epsg
>>>     >     >> [1] 2263
>>>     >     >>
>>>     >     >> $proj4string
>>>     >     >> [1] "+proj=lcc +lat_1=41.03333333333333
>>>     +lat_2=40.66666666666666
>>>     >     >> +lat_0=40.16666666666666 +lon_0=-74 +x_0=300000.0000000001
>>>     +y_0=0
>>>     >     >> +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs"
>>>     >     >>
>>>     >     >> attr(,"class")
>>>     >     >> [1] "crs"
>>>     >     >>
>>>     >     >> because it uses proj.4 directly to resolve SRID strings:
>>>     >     >>
>>>     >     >> /usr/share/proj/epsg has:
>>>     >     >>
>>>     >     >> # NAD83 / New York Long Island (ftUS)
>>>     >     >> <2263> +proj=lcc +lat_1=41.03333333333333
>>>     +lat_2=40.66666666666666
>>>     >     >> +lat_0=40.16666666666666 +lon_0=-74 +x_0=300000.0000000001
>>>     +y_0=0
>>>     >     >> +datum=NAD83 +units=us-ft +no_defs  <>
>>>     >     >>
>>>     >     >>
>>>     >     >> The change I made to sf (
>>>     >     >>
>>>     https://github.com/edzer/sfr/commit/d620f3b748d487bae910e388
>>>     <https://github.com/edzer/sfr/commit/d620f3b748d487bae910e388>
>>>     >     <https://github.com/edzer/sfr/commit/d620f3b748d487bae910e388
>>>     <https://github.com/edzer/sfr/commit/d620f3b748d487bae910e388>>
>>>     >     >> 4c554fa9e3ce7090)
>>>     >     >> now first asks gdal to resolve the epsg (in case it is not
>>>     NA), and
>>>     >     >> otherwise resolve the proj4string (if not NA), instead of ONLY
>>>     >     trying to
>>>     >     >> resolve a non-NA proj4string.
>>>     >     >>
>>>     >     >> On 15/03/17 20:50, Michael Treglia wrote:
>>>     >     >> > Hi All,
>>>     >     >> >
>>>     >     >> > Been working to import and manipulate a CSV file with
>>>     point data
>>>     >     >> > (lat/long), and then export to a PostGIS db.
>>>     >     >> >
>>>     >     >> > Overall, successful, but one thing I'd like to fix - when I
>>>     >     write out
>>>     >     >> the
>>>     >     >> > layer to postgis, the SRID is not maintained. The final
>>>     EPSG/SRID
>>>     >     >> should be
>>>     >     >> > 2263, but when I check in PostGIS, it comes up as 900914.
>>>     >     >> >
>>>     >     >> > Below is my code and sessionInfo, and the data are from here:
>>>     >     >> >
>>>     https://data.cityofnewyork.us/Public-Safety/NYPD-Complaint-D
>>>     <https://data.cityofnewyork.us/Public-Safety/NYPD-Complaint-D>
>>>     >     <https://data.cityofnewyork.us/Public-Safety/NYPD-Complaint-D
>>>     <https://data.cityofnewyork.us/Public-Safety/NYPD-Complaint-D>>
>>>     >     >> ata-Current-YTD/5uac-w243
>>>     >     >> > (downloaded as plain old CSV)
>>>     >     >> >
>>>     >     >> > Anything I might be missing? Thanks in advance for giving a
>>>     >     quick look!
>>>     >     >> > Mike
>>>     >     >> >
>>>     >     >> >
>>>     >     >> > ##Start Code
>>>     >     >> >
>>>     >     >> > #load packages
>>>     >     >> > library(sf)
>>>     >     >> > library(RPostgreSQL)
>>>     >     >> >
>>>     >     >> > #read data
>>>     >     >> > crime_current <-
>>>     read.csv("NYPD_Complaint_Data_Current_YTD.csv",
>>>     >     >> > stringsAsFactors = FALSE)
>>>     >     >> >
>>>     >     >> > #format time columns for easier reading in postgres (I
>>>     think), as
>>>     >     >> keeping
>>>     >     >> > as date format caused problems in export
>>>     >     >> > crime_current$CMPLNT_FR_TIME <-
>>>     >     >> > as.character(as.POSIXct(paste(crime_current$CMPLNT_FR_DT,
>>>     >     >> > crime_current$CMPLNT_FR_TM), format="%m/%d/%Y\ %H:%M",
>>>     tz=""))
>>>     >     >> > crime_current$CMPLNT_TO_TIME <-
>>>     >     >> > as.character(as.POSIXct(paste(crime_current$CMPLNT_TO_DT,
>>>     >     >> > crime_current$CMPLNT_TO_TM), format="%m/%d/%Y\ %H:%M",
>>>     tz=""))
>>>     >     >> > crime_current$RPT_DT <-
>>>     >     as.character(as.POSIXct(crime_current$RPT_DT,
>>>     >     >> > format="%m/%d/%Y", tz=""))
>>>     >     >> >
>>>     >     >> > #convert to sf object
>>>     >     >> > crime_current.sf <- st_as_sf(crime_current, coords =
>>>     c("Longitude",
>>>     >     >> > "Latitude"), crs = 4326)
>>>     >     >> > #reproject to EPSG 2263
>>>     >     >> > crime_current.sf <- st_transform(crime_current.sf, crs=2263)
>>>     >     >> >
>>>     >     >> > #write to postgres
>>>     >     >> > st_write(crime_current.sf, "PG:dbname=mydb user=user
>>>     >     host=xx.xx.xx.xx",
>>>     >     >> > 'health_safety.crime_current')
>>>     >     >> > ###End Code
>>>     >     >> >
>>>     >     >> >
>>>     >     >> >
>>>     >     >> >> 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-8        LC_COLLATE=en_US.UTF-8
>>>     >     >> >  [5] LC_MONETARY=en_US.UTF-8    LC_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] sp_1.2-3          RPostgreSQL_0.4-1 DBI_0.6
>>>      sf_0.3-4
>>>     >     >> >
>>>     >     >> > loaded via a namespace (and not attached):
>>>     >     >> > [1] tools_3.3.1     units_0.4-2     Rcpp_0.12.9
>>>      udunits2_0.13
>>>     >     >> > grid_3.3.1      lattice_0.20-33
>>>     >     >> >
>>>     >     >> >       [[alternative HTML version deleted]]
>>>     >     >> >
>>>     >     >> > _______________________________________________
>>>     >     >> > R-sig-Geo mailing list
>>>     >     >> > [hidden email] <mailto:[hidden email]>
>>>     <mailto:[hidden email] <mailto:[hidden email]>>
>>>     >     >> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>
>>>     >     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>>
>>>     >     >> >
>>>     >     >>
>>>     >     >> --
>>>     >     >> Edzer Pebesma
>>>     >     >> Institute for Geoinformatics  (ifgi),  University of Münster
>>>     >     >> Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081 <tel:%2B49%20251%2083%2033081>
>>>     >     <tel:%2B49%20251%2083%2033081>
>>>     >     >> Journal of Statistical Software:   http://www.jstatsoft.org/
>>>     >     >> Computers & Geosciences:   http://elsevier.com/locate/cageo/ <http://elsevier.com/locate/cageo/>
>>>     >     <http://elsevier.com/locate/cageo/ <http://elsevier.com/locate/cageo/>>
>>>     >     >>
>>>     >     >>
>>>     >     >> _______________________________________________
>>>     >     >> R-sig-Geo mailing list
>>>     >     >> [hidden email] <mailto:[hidden email]>
>>>     <mailto:[hidden email] <mailto:[hidden email]>>
>>>     >     >> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>
>>>     >     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>>
>>>     >     >>
>>>     >     >
>>>     >     >
>>>     >
>>>     >             [[alternative HTML version deleted]]
>>>     >
>>>     >     _______________________________________________
>>>     >     R-sig-Geo mailing list
>>>     >     [hidden email] <mailto:[hidden email]>
>>>     <mailto:[hidden email] <mailto:[hidden email]>>
>>>     >     https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>
>>>     >     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>>
>>>     >
>>>     >
>>>
>>>     --
>>>     Edzer Pebesma
>>>     Institute for Geoinformatics  (ifgi),  University of Münster
>>>     Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081
>>>     <tel:%2B49%20251%2083%2033081>
>>>     Journal of Statistical Software:   http://www.jstatsoft.org/
>>>     Computers & Geosciences:   http://elsevier.com/locate/cageo/
>>>     <http://elsevier.com/locate/cageo/>
>>>
>>>
>>
>> --
>> Edzer Pebesma
>> Institute for Geoinformatics  (ifgi),  University of Münster
>> Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081
>> Journal of Statistical Software:   http://www.jstatsoft.org/
>> Computers & Geosciences:   http://elsevier.com/locate/cageo/
>> --
Edzer Pebesma
Institute for Geoinformatics  (ifgi),  University of Münster
Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081
Journal of Statistical Software:   http://www.jstatsoft.org/
Computers & Geosciences:   http://elsevier.com/locate/cageo/


_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
signature.asc (484 bytes) Download Attachment

Re: Maintain SRID with st_write to postgis db

Thu, 03/16/2017 - 13:01
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-8        LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8    LC_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-8        LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=en_US.UTF-8    LC_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
<[hidden email]> 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
>> <[hidden email] <mailto:[hidden email]>>
>> 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
>>     <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
>>     <[hidden email] <mailto:[hidden email]>
>>     > <mailto:[hidden email] <mailto:[hidden email]>>> 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
>>     >
>>     >
>>     >
>>     >     #Output of install from github
>>     >     > install_github("edzer/sfr")
>>     >     Downloading GitHub repo edzer/sfr@master
>>     >     from URL https://api.github.com/repos/edzer/sfr/zipball/master
>>     <https://api.github.com/repos/edzer/sfr/zipball/master>
>>     >     <https://api.github.com/repos/edzer/sfr/zipball/master
>>     <https://api.github.com/repos/edzer/sfr/zipball/master>>
>>     >     Installing sf
>>     >     '/usr/lib/R/bin/R' --no-site-file --no-environ --no-save
>>     --no-restore
>>     >     --quiet  \
>>     >       CMD INSTALL
>>     '/tmp/RtmpKLmhyt/devtools9fd11eb9c3/edzer-sfr-d620f3b'  \
>>     >       --library='/home/mlt244/R/x86_64-pc-linux-gnu-library/3.3'
>>     >     --install-tests
>>     >
>>     >     * installing *source* package ‘sf’ ...
>>     >     configure: CC: gcc -std=gnu99
>>     >     configure: CXX: g++
>>     >     configure: :
>>     >     checking for gdal-config... /usr/bin/gdal-config
>>     >     checking gdal-config usability... yes
>>     >     configure: GDAL: 2.1.0
>>     >     checking GDAL version >= 2.0.0... yes
>>     >     checking for gcc... gcc -std=gnu99
>>     >     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... no
>>     >     checking for suffix of object files... o
>>     >     checking whether we are using the GNU C compiler... yes
>>     >     checking whether gcc -std=gnu99 accepts -g... yes
>>     >     checking for gcc -std=gnu99 option to accept ISO C89... none
>>     needed
>>     >     checking how to run the C preprocessor... gcc -std=gnu99 -E
>>     >     checking for grep that handles long lines and -e... /bin/grep
>>     >     checking for egrep... /bin/grep -E
>>     >     checking for ANSI C header files... yes
>>     >     checking for sys/types.h... yes
>>     >     checking for sys/stat.h... yes
>>     >     checking for stdlib.h... yes
>>     >     checking for string.h... yes
>>     >     checking for memory.h... yes
>>     >     checking for strings.h... yes
>>     >     checking for inttypes.h... yes
>>     >     checking for stdint.h... yes
>>     >     checking for unistd.h... yes
>>     >     checking gdal.h usability... yes
>>     >     checking gdal.h presence... yes
>>     >     checking for gdal.h... yes
>>     >     checking GDAL: linking with --libs only... yes
>>     >     checking GDAL: /usr/share/gdal/2.1/pcs.csv readable... yes
>>     >     checking GDAL: checking whether PROJ.4 is available for
>>     linking:... yes
>>     >     checking GDAL: checking whether PROJ.4 is available fur
>>     running:... yes
>>     >     checking proj_api.h usability... yes
>>     >     checking proj_api.h presence... yes
>>     >     checking for proj_api.h... yes
>>     >     checking for pj_init_plus in -lproj... yes
>>     >     checking PROJ.4: epsg found and readable... yes
>>     >     proj_conf_test.c: In function 'main':
>>     >     proj_conf_test.c:5:5: error: unknown type name 'PAFile'
>>     >          PAFile fp;
>>     >          ^
>>     >     proj_conf_test.c:8:5: warning: implicit declaration of function
>>     >     'pj_open_lib' [-Wimplicit-function-declaration]
>>     >          fp = pj_open_lib(ctx, "conus", "rb");
>>     >          ^
>>     >     proj_conf_test.c:9:12: warning: comparison between pointer and
>>     integer
>>     >     [enabled by default]
>>     >          if (fp == NULL) exit(1);
>>     >                 ^
>>     >     proj_conf_test.c:10:5: warning: implicit declaration of function
>>     >     'pj_ctx_fclose' [-Wimplicit-function-declaration]
>>     >          pj_ctx_fclose(ctx, fp);
>>     >          ^
>>     >     ./configure: line 3834: ./proj_conf_test: No such file or
>>     directory
>>     >     checking PROJ.4: conus found and readable... yes
>>     >     checking geos-config usability... yes
>>     >     configure: GEOS: 3.5.0
>>     >     checking GEOS version >= 3.3.0... yes
>>     >     checking geos_c.h usability... yes
>>     >     checking geos_c.h presence... yes
>>     >     checking for geos_c.h... yes
>>     >     checking geos: linking with -lgeos_c... yes
>>     >     checking for lwgeom_version in -llwgeom... no
>>     >     configure: error: in
>>     >     `/tmp/RtmpKLmhyt/devtools9fd11eb9c3/edzer-sfr-d620f3b':
>>     >     configure: error: lwgeom test failed (--without-readline to
>>     disable)
>>     >     See `config.log' for more details
>>     >     ERROR: configuration failed for package ‘sf’
>>     >     * removing ‘/home/mlt244/R/x86_64-pc-linux-gnu-library/3.3/sf’
>>     >     * restoring previous
>>     ‘/home/mlt244/R/x86_64-pc-linux-gnu-library/3.3/sf’
>>     >     Error: Command failed (1)
>>     >
>>     >
>>     >     On Wed, Mar 15, 2017 at 6:14 PM, Michael Treglia
>>     <[hidden email] <mailto:[hidden email]>
>>     >     <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>>     >
>>     >     > Wow - thanks so much for this quick fix, Edzer! I like your
>>     >     solution to
>>     >     > having syntatically different but semantically identical
>>     >     proj4string. Will
>>     >     > try this in a bit, and write back if I have any issues.
>>     >     > Best,
>>     >     > mike
>>     >     >
>>     >     > On Wed, Mar 15, 2017 at 5:58 PM, Edzer Pebesma <
>>     >     > [hidden email] <mailto:[hidden email]>
>>     >     <mailto:[hidden email]
>>     <mailto:[hidden email]>>> wrote:
>>     >     >
>>     >     >> Great question! Short answer: now solved in the dev version on
>>     >     github;
>>     >     >> data are written directly to postgis having epsg 2263.
>>     >     >>
>>     >     >>
>>     >     >> Long answer:
>>     >     >>
>>     >     >> I believe this was caused by gdal and proj.4 doing different
>>     >     things when
>>     >     >> resolving epsg codes to proj4strings. sf uses proj.4 for
>>     this. When
>>     >     >> writing a proj4string either gdal or postgis don't
>>     recognize the
>>     >     >> proj4string that proj.4 returns on the epsg code. Neither
>>     gdal nor
>>     >     >> postgis understand that syntactically different
>>     proj4strings may be
>>     >     >> semantically identical.
>>     >     >>
>>     >     >>
>>     >     >> After running your example, in postgis
>>     >     >>
>>     >     >> # select proj4text from spatial_ref_sys where SRID = 900914;
>>     >     >>
>>     >     >> gives:
>>     >     >>
>>     >     >>  +proj=lcc +lat_1=41.03333333333333 +lat_2=40.66666666666666
>>     >     >> +lat_0=40.16666666666666 +lon_0=-74 +x_0=300000 +y_0=0
>>     +ellps=GRS80
>>     >     >> +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs
>>     >     >>
>>     >     >> # select proj4text from spatial_ref_sys where SRID = 2263;
>>     >     >>
>>     >     >> gives:
>>     >     >>
>>     >     >>  +proj=lcc +lat_1=41.03333333333333 +lat_2=40.66666666666666
>>     >     >> +lat_0=40.16666666666666 +lon_0=-74 +x_0=300000.0000000001
>>     +y_0=0
>>     >     >> +datum=NAD83 +units=us-ft +no_defs
>>     >     >>
>>     >     >> sf causes this:
>>     >     >>
>>     >     >> > st_crs(2263)
>>     >     >> $epsg
>>     >     >> [1] 2263
>>     >     >>
>>     >     >> $proj4string
>>     >     >> [1] "+proj=lcc +lat_1=41.03333333333333
>>     +lat_2=40.66666666666666
>>     >     >> +lat_0=40.16666666666666 +lon_0=-74 +x_0=300000.0000000001
>>     +y_0=0
>>     >     >> +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs"
>>     >     >>
>>     >     >> attr(,"class")
>>     >     >> [1] "crs"
>>     >     >>
>>     >     >> because it uses proj.4 directly to resolve SRID strings:
>>     >     >>
>>     >     >> /usr/share/proj/epsg has:
>>     >     >>
>>     >     >> # NAD83 / New York Long Island (ftUS)
>>     >     >> <2263> +proj=lcc +lat_1=41.03333333333333
>>     +lat_2=40.66666666666666
>>     >     >> +lat_0=40.16666666666666 +lon_0=-74 +x_0=300000.0000000001
>>     +y_0=0
>>     >     >> +datum=NAD83 +units=us-ft +no_defs  <>
>>     >     >>
>>     >     >>
>>     >     >> The change I made to sf (
>>     >     >>
>>     https://github.com/edzer/sfr/commit/d620f3b748d487bae910e388
>>     <https://github.com/edzer/sfr/commit/d620f3b748d487bae910e388>
>>     >     <https://github.com/edzer/sfr/commit/d620f3b748d487bae910e388
>>     <https://github.com/edzer/sfr/commit/d620f3b748d487bae910e388>>
>>     >     >> 4c554fa9e3ce7090)
>>     >     >> now first asks gdal to resolve the epsg (in case it is not
>>     NA), and
>>     >     >> otherwise resolve the proj4string (if not NA), instead of ONLY
>>     >     trying to
>>     >     >> resolve a non-NA proj4string.
>>     >     >>
>>     >     >> On 15/03/17 20:50, Michael Treglia wrote:
>>     >     >> > Hi All,
>>     >     >> >
>>     >     >> > Been working to import and manipulate a CSV file with
>>     point data
>>     >     >> > (lat/long), and then export to a PostGIS db.
>>     >     >> >
>>     >     >> > Overall, successful, but one thing I'd like to fix - when I
>>     >     write out
>>     >     >> the
>>     >     >> > layer to postgis, the SRID is not maintained. The final
>>     EPSG/SRID
>>     >     >> should be
>>     >     >> > 2263, but when I check in PostGIS, it comes up as 900914.
>>     >     >> >
>>     >     >> > Below is my code and sessionInfo, and the data are from here:
>>     >     >> >
>>     https://data.cityofnewyork.us/Public-Safety/NYPD-Complaint-D
>>     <https://data.cityofnewyork.us/Public-Safety/NYPD-Complaint-D>
>>     >     <https://data.cityofnewyork.us/Public-Safety/NYPD-Complaint-D
>>     <https://data.cityofnewyork.us/Public-Safety/NYPD-Complaint-D>>
>>     >     >> ata-Current-YTD/5uac-w243
>>     >     >> > (downloaded as plain old CSV)
>>     >     >> >
>>     >     >> > Anything I might be missing? Thanks in advance for giving a
>>     >     quick look!
>>     >     >> > Mike
>>     >     >> >
>>     >     >> >
>>     >     >> > ##Start Code
>>     >     >> >
>>     >     >> > #load packages
>>     >     >> > library(sf)
>>     >     >> > library(RPostgreSQL)
>>     >     >> >
>>     >     >> > #read data
>>     >     >> > crime_current <-
>>     read.csv("NYPD_Complaint_Data_Current_YTD.csv",
>>     >     >> > stringsAsFactors = FALSE)
>>     >     >> >
>>     >     >> > #format time columns for easier reading in postgres (I
>>     think), as
>>     >     >> keeping
>>     >     >> > as date format caused problems in export
>>     >     >> > crime_current$CMPLNT_FR_TIME <-
>>     >     >> > as.character(as.POSIXct(paste(crime_current$CMPLNT_FR_DT,
>>     >     >> > crime_current$CMPLNT_FR_TM), format="%m/%d/%Y\ %H:%M",
>>     tz=""))
>>     >     >> > crime_current$CMPLNT_TO_TIME <-
>>     >     >> > as.character(as.POSIXct(paste(crime_current$CMPLNT_TO_DT,
>>     >     >> > crime_current$CMPLNT_TO_TM), format="%m/%d/%Y\ %H:%M",
>>     tz=""))
>>     >     >> > crime_current$RPT_DT <-
>>     >     as.character(as.POSIXct(crime_current$RPT_DT,
>>     >     >> > format="%m/%d/%Y", tz=""))
>>     >     >> >
>>     >     >> > #convert to sf object
>>     >     >> > crime_current.sf <- st_as_sf(crime_current, coords =
>>     c("Longitude",
>>     >     >> > "Latitude"), crs = 4326)
>>     >     >> > #reproject to EPSG 2263
>>     >     >> > crime_current.sf <- st_transform(crime_current.sf, crs=2263)
>>     >     >> >
>>     >     >> > #write to postgres
>>     >     >> > st_write(crime_current.sf, "PG:dbname=mydb user=user
>>     >     host=xx.xx.xx.xx",
>>     >     >> > 'health_safety.crime_current')
>>     >     >> > ###End Code
>>     >     >> >
>>     >     >> >
>>     >     >> >
>>     >     >> >> 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-8        LC_COLLATE=en_US.UTF-8
>>     >     >> >  [5] LC_MONETARY=en_US.UTF-8    LC_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] sp_1.2-3          RPostgreSQL_0.4-1 DBI_0.6
>>      sf_0.3-4
>>     >     >> >
>>     >     >> > loaded via a namespace (and not attached):
>>     >     >> > [1] tools_3.3.1     units_0.4-2     Rcpp_0.12.9
>>      udunits2_0.13
>>     >     >> > grid_3.3.1      lattice_0.20-33
>>     >     >> >
>>     >     >> >       [[alternative HTML version deleted]]
>>     >     >> >
>>     >     >> > _______________________________________________
>>     >     >> > R-sig-Geo mailing list
>>     >     >> > [hidden email] <mailto:[hidden email]>
>>     <mailto:[hidden email] <mailto:[hidden email]>>
>>     >     >> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>
>>     >     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>>
>>     >     >> >
>>     >     >>
>>     >     >> --
>>     >     >> Edzer Pebesma
>>     >     >> Institute for Geoinformatics  (ifgi),  University of Münster
>>     >     >> Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081 <tel:%2B49%20251%2083%2033081>
>>     >     <tel:%2B49%20251%2083%2033081>
>>     >     >> Journal of Statistical Software:   http://www.jstatsoft.org/
>>     >     >> Computers & Geosciences:   http://elsevier.com/locate/cageo/ <http://elsevier.com/locate/cageo/>
>>     >     <http://elsevier.com/locate/cageo/ <http://elsevier.com/locate/cageo/>>
>>     >     >>
>>     >     >>
>>     >     >> _______________________________________________
>>     >     >> R-sig-Geo mailing list
>>     >     >> [hidden email] <mailto:[hidden email]>
>>     <mailto:[hidden email] <mailto:[hidden email]>>
>>     >     >> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>
>>     >     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>>
>>     >     >>
>>     >     >
>>     >     >
>>     >
>>     >             [[alternative HTML version deleted]]
>>     >
>>     >     _______________________________________________
>>     >     R-sig-Geo mailing list
>>     >     [hidden email] <mailto:[hidden email]>
>>     <mailto:[hidden email] <mailto:[hidden email]>>
>>     >     https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>
>>     >     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>>
>>     >
>>     >
>>
>>     --
>>     Edzer Pebesma
>>     Institute for Geoinformatics  (ifgi),  University of Münster
>>     Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081
>>     <tel:%2B49%20251%2083%2033081>
>>     Journal of Statistical Software:   http://www.jstatsoft.org/
>>     Computers & Geosciences:   http://elsevier.com/locate/cageo/
>>     <http://elsevier.com/locate/cageo/>
>>
>>
>
> --
> Edzer Pebesma
> Institute for Geoinformatics  (ifgi),  University of Münster
> Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081
> Journal of Statistical Software:   http://www.jstatsoft.org/
> Computers & Geosciences:   http://elsevier.com/locate/cageo/
>
_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: Sentienl 2 gdal translate

Thu, 03/16/2017 - 12:21
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
>> <[hidden email] <mailto:[hidden email]>>
>> 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
>>> [hidden email] <mailto:[hidden email]>
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>>>
>>
>> _______________________________________________
>> R-sig-Geo mailing list
>> [hidden email] <mailto:[hidden email]>
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>
>
>
> Email secured by Check Point
>
_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: Maintain SRID with st_write to postgis db

Thu, 03/16/2017 - 09:15


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
> <[hidden email] <mailto:[hidden email]>>
> 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
>     <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
>     <[hidden email] <mailto:[hidden email]>
>     > <mailto:[hidden email] <mailto:[hidden email]>>> 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
>     >
>     >
>     >
>     >     #Output of install from github
>     >     > install_github("edzer/sfr")
>     >     Downloading GitHub repo edzer/sfr@master
>     >     from URL https://api.github.com/repos/edzer/sfr/zipball/master
>     <https://api.github.com/repos/edzer/sfr/zipball/master>
>     >     <https://api.github.com/repos/edzer/sfr/zipball/master
>     <https://api.github.com/repos/edzer/sfr/zipball/master>>
>     >     Installing sf
>     >     '/usr/lib/R/bin/R' --no-site-file --no-environ --no-save
>     --no-restore
>     >     --quiet  \
>     >       CMD INSTALL
>     '/tmp/RtmpKLmhyt/devtools9fd11eb9c3/edzer-sfr-d620f3b'  \
>     >       --library='/home/mlt244/R/x86_64-pc-linux-gnu-library/3.3'
>     >     --install-tests
>     >
>     >     * installing *source* package ‘sf’ ...
>     >     configure: CC: gcc -std=gnu99
>     >     configure: CXX: g++
>     >     configure: :
>     >     checking for gdal-config... /usr/bin/gdal-config
>     >     checking gdal-config usability... yes
>     >     configure: GDAL: 2.1.0
>     >     checking GDAL version >= 2.0.0... yes
>     >     checking for gcc... gcc -std=gnu99
>     >     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... no
>     >     checking for suffix of object files... o
>     >     checking whether we are using the GNU C compiler... yes
>     >     checking whether gcc -std=gnu99 accepts -g... yes
>     >     checking for gcc -std=gnu99 option to accept ISO C89... none
>     needed
>     >     checking how to run the C preprocessor... gcc -std=gnu99 -E
>     >     checking for grep that handles long lines and -e... /bin/grep
>     >     checking for egrep... /bin/grep -E
>     >     checking for ANSI C header files... yes
>     >     checking for sys/types.h... yes
>     >     checking for sys/stat.h... yes
>     >     checking for stdlib.h... yes
>     >     checking for string.h... yes
>     >     checking for memory.h... yes
>     >     checking for strings.h... yes
>     >     checking for inttypes.h... yes
>     >     checking for stdint.h... yes
>     >     checking for unistd.h... yes
>     >     checking gdal.h usability... yes
>     >     checking gdal.h presence... yes
>     >     checking for gdal.h... yes
>     >     checking GDAL: linking with --libs only... yes
>     >     checking GDAL: /usr/share/gdal/2.1/pcs.csv readable... yes
>     >     checking GDAL: checking whether PROJ.4 is available for
>     linking:... yes
>     >     checking GDAL: checking whether PROJ.4 is available fur
>     running:... yes
>     >     checking proj_api.h usability... yes
>     >     checking proj_api.h presence... yes
>     >     checking for proj_api.h... yes
>     >     checking for pj_init_plus in -lproj... yes
>     >     checking PROJ.4: epsg found and readable... yes
>     >     proj_conf_test.c: In function 'main':
>     >     proj_conf_test.c:5:5: error: unknown type name 'PAFile'
>     >          PAFile fp;
>     >          ^
>     >     proj_conf_test.c:8:5: warning: implicit declaration of function
>     >     'pj_open_lib' [-Wimplicit-function-declaration]
>     >          fp = pj_open_lib(ctx, "conus", "rb");
>     >          ^
>     >     proj_conf_test.c:9:12: warning: comparison between pointer and
>     integer
>     >     [enabled by default]
>     >          if (fp == NULL) exit(1);
>     >                 ^
>     >     proj_conf_test.c:10:5: warning: implicit declaration of function
>     >     'pj_ctx_fclose' [-Wimplicit-function-declaration]
>     >          pj_ctx_fclose(ctx, fp);
>     >          ^
>     >     ./configure: line 3834: ./proj_conf_test: No such file or
>     directory
>     >     checking PROJ.4: conus found and readable... yes
>     >     checking geos-config usability... yes
>     >     configure: GEOS: 3.5.0
>     >     checking GEOS version >= 3.3.0... yes
>     >     checking geos_c.h usability... yes
>     >     checking geos_c.h presence... yes
>     >     checking for geos_c.h... yes
>     >     checking geos: linking with -lgeos_c... yes
>     >     checking for lwgeom_version in -llwgeom... no
>     >     configure: error: in
>     >     `/tmp/RtmpKLmhyt/devtools9fd11eb9c3/edzer-sfr-d620f3b':
>     >     configure: error: lwgeom test failed (--without-readline to
>     disable)
>     >     See `config.log' for more details
>     >     ERROR: configuration failed for package ‘sf’
>     >     * removing ‘/home/mlt244/R/x86_64-pc-linux-gnu-library/3.3/sf’
>     >     * restoring previous
>     ‘/home/mlt244/R/x86_64-pc-linux-gnu-library/3.3/sf’
>     >     Error: Command failed (1)
>     >
>     >
>     >     On Wed, Mar 15, 2017 at 6:14 PM, Michael Treglia
>     <[hidden email] <mailto:[hidden email]>
>     >     <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>     >
>     >     > Wow - thanks so much for this quick fix, Edzer! I like your
>     >     solution to
>     >     > having syntatically different but semantically identical
>     >     proj4string. Will
>     >     > try this in a bit, and write back if I have any issues.
>     >     > Best,
>     >     > mike
>     >     >
>     >     > On Wed, Mar 15, 2017 at 5:58 PM, Edzer Pebesma <
>     >     > [hidden email] <mailto:[hidden email]>
>     >     <mailto:[hidden email]
>     <mailto:[hidden email]>>> wrote:
>     >     >
>     >     >> Great question! Short answer: now solved in the dev version on
>     >     github;
>     >     >> data are written directly to postgis having epsg 2263.
>     >     >>
>     >     >>
>     >     >> Long answer:
>     >     >>
>     >     >> I believe this was caused by gdal and proj.4 doing different
>     >     things when
>     >     >> resolving epsg codes to proj4strings. sf uses proj.4 for
>     this. When
>     >     >> writing a proj4string either gdal or postgis don't
>     recognize the
>     >     >> proj4string that proj.4 returns on the epsg code. Neither
>     gdal nor
>     >     >> postgis understand that syntactically different
>     proj4strings may be
>     >     >> semantically identical.
>     >     >>
>     >     >>
>     >     >> After running your example, in postgis
>     >     >>
>     >     >> # select proj4text from spatial_ref_sys where SRID = 900914;
>     >     >>
>     >     >> gives:
>     >     >>
>     >     >>  +proj=lcc +lat_1=41.03333333333333 +lat_2=40.66666666666666
>     >     >> +lat_0=40.16666666666666 +lon_0=-74 +x_0=300000 +y_0=0
>     +ellps=GRS80
>     >     >> +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs
>     >     >>
>     >     >> # select proj4text from spatial_ref_sys where SRID = 2263;
>     >     >>
>     >     >> gives:
>     >     >>
>     >     >>  +proj=lcc +lat_1=41.03333333333333 +lat_2=40.66666666666666
>     >     >> +lat_0=40.16666666666666 +lon_0=-74 +x_0=300000.0000000001
>     +y_0=0
>     >     >> +datum=NAD83 +units=us-ft +no_defs
>     >     >>
>     >     >> sf causes this:
>     >     >>
>     >     >> > st_crs(2263)
>     >     >> $epsg
>     >     >> [1] 2263
>     >     >>
>     >     >> $proj4string
>     >     >> [1] "+proj=lcc +lat_1=41.03333333333333
>     +lat_2=40.66666666666666
>     >     >> +lat_0=40.16666666666666 +lon_0=-74 +x_0=300000.0000000001
>     +y_0=0
>     >     >> +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs"
>     >     >>
>     >     >> attr(,"class")
>     >     >> [1] "crs"
>     >     >>
>     >     >> because it uses proj.4 directly to resolve SRID strings:
>     >     >>
>     >     >> /usr/share/proj/epsg has:
>     >     >>
>     >     >> # NAD83 / New York Long Island (ftUS)
>     >     >> <2263> +proj=lcc +lat_1=41.03333333333333
>     +lat_2=40.66666666666666
>     >     >> +lat_0=40.16666666666666 +lon_0=-74 +x_0=300000.0000000001
>     +y_0=0
>     >     >> +datum=NAD83 +units=us-ft +no_defs  <>
>     >     >>
>     >     >>
>     >     >> The change I made to sf (
>     >     >>
>     https://github.com/edzer/sfr/commit/d620f3b748d487bae910e388
>     <https://github.com/edzer/sfr/commit/d620f3b748d487bae910e388>
>     >     <https://github.com/edzer/sfr/commit/d620f3b748d487bae910e388
>     <https://github.com/edzer/sfr/commit/d620f3b748d487bae910e388>>
>     >     >> 4c554fa9e3ce7090)
>     >     >> now first asks gdal to resolve the epsg (in case it is not
>     NA), and
>     >     >> otherwise resolve the proj4string (if not NA), instead of ONLY
>     >     trying to
>     >     >> resolve a non-NA proj4string.
>     >     >>
>     >     >> On 15/03/17 20:50, Michael Treglia wrote:
>     >     >> > Hi All,
>     >     >> >
>     >     >> > Been working to import and manipulate a CSV file with
>     point data
>     >     >> > (lat/long), and then export to a PostGIS db.
>     >     >> >
>     >     >> > Overall, successful, but one thing I'd like to fix - when I
>     >     write out
>     >     >> the
>     >     >> > layer to postgis, the SRID is not maintained. The final
>     EPSG/SRID
>     >     >> should be
>     >     >> > 2263, but when I check in PostGIS, it comes up as 900914.
>     >     >> >
>     >     >> > Below is my code and sessionInfo, and the data are from here:
>     >     >> >
>     https://data.cityofnewyork.us/Public-Safety/NYPD-Complaint-D
>     <https://data.cityofnewyork.us/Public-Safety/NYPD-Complaint-D>
>     >     <https://data.cityofnewyork.us/Public-Safety/NYPD-Complaint-D
>     <https://data.cityofnewyork.us/Public-Safety/NYPD-Complaint-D>>
>     >     >> ata-Current-YTD/5uac-w243
>     >     >> > (downloaded as plain old CSV)
>     >     >> >
>     >     >> > Anything I might be missing? Thanks in advance for giving a
>     >     quick look!
>     >     >> > Mike
>     >     >> >
>     >     >> >
>     >     >> > ##Start Code
>     >     >> >
>     >     >> > #load packages
>     >     >> > library(sf)
>     >     >> > library(RPostgreSQL)
>     >     >> >
>     >     >> > #read data
>     >     >> > crime_current <-
>     read.csv("NYPD_Complaint_Data_Current_YTD.csv",
>     >     >> > stringsAsFactors = FALSE)
>     >     >> >
>     >     >> > #format time columns for easier reading in postgres (I
>     think), as
>     >     >> keeping
>     >     >> > as date format caused problems in export
>     >     >> > crime_current$CMPLNT_FR_TIME <-
>     >     >> > as.character(as.POSIXct(paste(crime_current$CMPLNT_FR_DT,
>     >     >> > crime_current$CMPLNT_FR_TM), format="%m/%d/%Y\ %H:%M",
>     tz=""))
>     >     >> > crime_current$CMPLNT_TO_TIME <-
>     >     >> > as.character(as.POSIXct(paste(crime_current$CMPLNT_TO_DT,
>     >     >> > crime_current$CMPLNT_TO_TM), format="%m/%d/%Y\ %H:%M",
>     tz=""))
>     >     >> > crime_current$RPT_DT <-
>     >     as.character(as.POSIXct(crime_current$RPT_DT,
>     >     >> > format="%m/%d/%Y", tz=""))
>     >     >> >
>     >     >> > #convert to sf object
>     >     >> > crime_current.sf <- st_as_sf(crime_current, coords =
>     c("Longitude",
>     >     >> > "Latitude"), crs = 4326)
>     >     >> > #reproject to EPSG 2263
>     >     >> > crime_current.sf <- st_transform(crime_current.sf, crs=2263)
>     >     >> >
>     >     >> > #write to postgres
>     >     >> > st_write(crime_current.sf, "PG:dbname=mydb user=user
>     >     host=xx.xx.xx.xx",
>     >     >> > 'health_safety.crime_current')
>     >     >> > ###End Code
>     >     >> >
>     >     >> >
>     >     >> >
>     >     >> >> 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-8        LC_COLLATE=en_US.UTF-8
>     >     >> >  [5] LC_MONETARY=en_US.UTF-8    LC_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] sp_1.2-3          RPostgreSQL_0.4-1 DBI_0.6        
>      sf_0.3-4
>     >     >> >
>     >     >> > loaded via a namespace (and not attached):
>     >     >> > [1] tools_3.3.1     units_0.4-2     Rcpp_0.12.9  
>      udunits2_0.13
>     >     >> > grid_3.3.1      lattice_0.20-33
>     >     >> >
>     >     >> >       [[alternative HTML version deleted]]
>     >     >> >
>     >     >> > _______________________________________________
>     >     >> > R-sig-Geo mailing list
>     >     >> > [hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>
>     >     >> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>
>     >     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>>
>     >     >> >
>     >     >>
>     >     >> --
>     >     >> Edzer Pebesma
>     >     >> Institute for Geoinformatics  (ifgi),  University of Münster
>     >     >> Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081 <tel:%2B49%20251%2083%2033081>
>     >     <tel:%2B49%20251%2083%2033081>
>     >     >> Journal of Statistical Software:   http://www.jstatsoft.org/
>     >     >> Computers & Geosciences:   http://elsevier.com/locate/cageo/ <http://elsevier.com/locate/cageo/>
>     >     <http://elsevier.com/locate/cageo/ <http://elsevier.com/locate/cageo/>>
>     >     >>
>     >     >>
>     >     >> _______________________________________________
>     >     >> R-sig-Geo mailing list
>     >     >> [hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>
>     >     >> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>
>     >     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>>
>     >     >>
>     >     >
>     >     >
>     >
>     >             [[alternative HTML version deleted]]
>     >
>     >     _______________________________________________
>     >     R-sig-Geo mailing list
>     >     [hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>
>     >     https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>
>     >     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>>
>     >
>     >
>
>     --
>     Edzer Pebesma
>     Institute for Geoinformatics  (ifgi),  University of Münster
>     Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081
>     <tel:%2B49%20251%2083%2033081>
>     Journal of Statistical Software:   http://www.jstatsoft.org/
>     Computers & Geosciences:   http://elsevier.com/locate/cageo/
>     <http://elsevier.com/locate/cageo/>
>
> --
Edzer Pebesma
Institute for Geoinformatics  (ifgi),  University of Münster
Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081
Journal of Statistical Software:   http://www.jstatsoft.org/
Computers & Geosciences:   http://elsevier.com/locate/cageo/


_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
signature.asc (484 bytes) Download Attachment

Re: Maintain SRID with st_write to postgis db

Thu, 03/16/2017 - 07:53
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 <
[hidden email]> 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 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 <[hidden email]
> > <mailto:[hidden email]>> 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
> >
> >
> >
> >     #Output of install from github
> >     > install_github("edzer/sfr")
> >     Downloading GitHub repo edzer/sfr@master
> >     from URL https://api.github.com/repos/edzer/sfr/zipball/master
> >     <https://api.github.com/repos/edzer/sfr/zipball/master>
> >     Installing sf
> >     '/usr/lib/R/bin/R' --no-site-file --no-environ --no-save --no-restore
> >     --quiet  \
> >       CMD INSTALL '/tmp/RtmpKLmhyt/devtools9fd11eb9c3/edzer-sfr-d620f3b'
> \
> >       --library='/home/mlt244/R/x86_64-pc-linux-gnu-library/3.3'
> >     --install-tests
> >
> >     * installing *source* package ‘sf’ ...
> >     configure: CC: gcc -std=gnu99
> >     configure: CXX: g++
> >     configure: :
> >     checking for gdal-config... /usr/bin/gdal-config
> >     checking gdal-config usability... yes
> >     configure: GDAL: 2.1.0
> >     checking GDAL version >= 2.0.0... yes
> >     checking for gcc... gcc -std=gnu99
> >     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... no
> >     checking for suffix of object files... o
> >     checking whether we are using the GNU C compiler... yes
> >     checking whether gcc -std=gnu99 accepts -g... yes
> >     checking for gcc -std=gnu99 option to accept ISO C89... none needed
> >     checking how to run the C preprocessor... gcc -std=gnu99 -E
> >     checking for grep that handles long lines and -e... /bin/grep
> >     checking for egrep... /bin/grep -E
> >     checking for ANSI C header files... yes
> >     checking for sys/types.h... yes
> >     checking for sys/stat.h... yes
> >     checking for stdlib.h... yes
> >     checking for string.h... yes
> >     checking for memory.h... yes
> >     checking for strings.h... yes
> >     checking for inttypes.h... yes
> >     checking for stdint.h... yes
> >     checking for unistd.h... yes
> >     checking gdal.h usability... yes
> >     checking gdal.h presence... yes
> >     checking for gdal.h... yes
> >     checking GDAL: linking with --libs only... yes
> >     checking GDAL: /usr/share/gdal/2.1/pcs.csv readable... yes
> >     checking GDAL: checking whether PROJ.4 is available for linking:...
> yes
> >     checking GDAL: checking whether PROJ.4 is available fur running:...
> yes
> >     checking proj_api.h usability... yes
> >     checking proj_api.h presence... yes
> >     checking for proj_api.h... yes
> >     checking for pj_init_plus in -lproj... yes
> >     checking PROJ.4: epsg found and readable... yes
> >     proj_conf_test.c: In function 'main':
> >     proj_conf_test.c:5:5: error: unknown type name 'PAFile'
> >          PAFile fp;
> >          ^
> >     proj_conf_test.c:8:5: warning: implicit declaration of function
> >     'pj_open_lib' [-Wimplicit-function-declaration]
> >          fp = pj_open_lib(ctx, "conus", "rb");
> >          ^
> >     proj_conf_test.c:9:12: warning: comparison between pointer and
> integer
> >     [enabled by default]
> >          if (fp == NULL) exit(1);
> >                 ^
> >     proj_conf_test.c:10:5: warning: implicit declaration of function
> >     'pj_ctx_fclose' [-Wimplicit-function-declaration]
> >          pj_ctx_fclose(ctx, fp);
> >          ^
> >     ./configure: line 3834: ./proj_conf_test: No such file or directory
> >     checking PROJ.4: conus found and readable... yes
> >     checking geos-config usability... yes
> >     configure: GEOS: 3.5.0
> >     checking GEOS version >= 3.3.0... yes
> >     checking geos_c.h usability... yes
> >     checking geos_c.h presence... yes
> >     checking for geos_c.h... yes
> >     checking geos: linking with -lgeos_c... yes
> >     checking for lwgeom_version in -llwgeom... no
> >     configure: error: in
> >     `/tmp/RtmpKLmhyt/devtools9fd11eb9c3/edzer-sfr-d620f3b':
> >     configure: error: lwgeom test failed (--without-readline to disable)
> >     See `config.log' for more details
> >     ERROR: configuration failed for package ‘sf’
> >     * removing ‘/home/mlt244/R/x86_64-pc-linux-gnu-library/3.3/sf’
> >     * restoring previous ‘/home/mlt244/R/x86_64-pc-
> linux-gnu-library/3.3/sf’
> >     Error: Command failed (1)
> >
> >
> >     On Wed, Mar 15, 2017 at 6:14 PM, Michael Treglia <[hidden email]
> >     <mailto:[hidden email]>> wrote:
> >
> >     > Wow - thanks so much for this quick fix, Edzer! I like your
> >     solution to
> >     > having syntatically different but semantically identical
> >     proj4string. Will
> >     > try this in a bit, and write back if I have any issues.
> >     > Best,
> >     > mike
> >     >
> >     > On Wed, Mar 15, 2017 at 5:58 PM, Edzer Pebesma <
> >     > [hidden email]
> >     <mailto:[hidden email]>> wrote:
> >     >
> >     >> Great question! Short answer: now solved in the dev version on
> >     github;
> >     >> data are written directly to postgis having epsg 2263.
> >     >>
> >     >>
> >     >> Long answer:
> >     >>
> >     >> I believe this was caused by gdal and proj.4 doing different
> >     things when
> >     >> resolving epsg codes to proj4strings. sf uses proj.4 for this.
> When
> >     >> writing a proj4string either gdal or postgis don't recognize the
> >     >> proj4string that proj.4 returns on the epsg code. Neither gdal nor
> >     >> postgis understand that syntactically different proj4strings may
> be
> >     >> semantically identical.
> >     >>
> >     >>
> >     >> After running your example, in postgis
> >     >>
> >     >> # select proj4text from spatial_ref_sys where SRID = 900914;
> >     >>
> >     >> gives:
> >     >>
> >     >>  +proj=lcc +lat_1=41.03333333333333 +lat_2=40.66666666666666
> >     >> +lat_0=40.16666666666666 +lon_0=-74 +x_0=300000 +y_0=0
> +ellps=GRS80
> >     >> +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs
> >     >>
> >     >> # select proj4text from spatial_ref_sys where SRID = 2263;
> >     >>
> >     >> gives:
> >     >>
> >     >>  +proj=lcc +lat_1=41.03333333333333 +lat_2=40.66666666666666
> >     >> +lat_0=40.16666666666666 +lon_0=-74 +x_0=300000.0000000001 +y_0=0
> >     >> +datum=NAD83 +units=us-ft +no_defs
> >     >>
> >     >> sf causes this:
> >     >>
> >     >> > st_crs(2263)
> >     >> $epsg
> >     >> [1] 2263
> >     >>
> >     >> $proj4string
> >     >> [1] "+proj=lcc +lat_1=41.03333333333333 +lat_2=40.66666666666666
> >     >> +lat_0=40.16666666666666 +lon_0=-74 +x_0=300000.0000000001 +y_0=0
> >     >> +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs"
> >     >>
> >     >> attr(,"class")
> >     >> [1] "crs"
> >     >>
> >     >> because it uses proj.4 directly to resolve SRID strings:
> >     >>
> >     >> /usr/share/proj/epsg has:
> >     >>
> >     >> # NAD83 / New York Long Island (ftUS)
> >     >> <2263> +proj=lcc +lat_1=41.03333333333333 +lat_2=40.66666666666666
> >     >> +lat_0=40.16666666666666 +lon_0=-74 +x_0=300000.0000000001 +y_0=0
> >     >> +datum=NAD83 +units=us-ft +no_defs  <>
> >     >>
> >     >>
> >     >> The change I made to sf (
> >     >> https://github.com/edzer/sfr/commit/d620f3b748d487bae910e388
> >     <https://github.com/edzer/sfr/commit/d620f3b748d487bae910e388>
> >     >> 4c554fa9e3ce7090)
> >     >> now first asks gdal to resolve the epsg (in case it is not NA),
> and
> >     >> otherwise resolve the proj4string (if not NA), instead of ONLY
> >     trying to
> >     >> resolve a non-NA proj4string.
> >     >>
> >     >> On 15/03/17 20:50, Michael Treglia wrote:
> >     >> > Hi All,
> >     >> >
> >     >> > Been working to import and manipulate a CSV file with point data
> >     >> > (lat/long), and then export to a PostGIS db.
> >     >> >
> >     >> > Overall, successful, but one thing I'd like to fix - when I
> >     write out
> >     >> the
> >     >> > layer to postgis, the SRID is not maintained. The final
> EPSG/SRID
> >     >> should be
> >     >> > 2263, but when I check in PostGIS, it comes up as 900914.
> >     >> >
> >     >> > Below is my code and sessionInfo, and the data are from here:
> >     >> > https://data.cityofnewyork.us/Public-Safety/NYPD-Complaint-D
> >     <https://data.cityofnewyork.us/Public-Safety/NYPD-Complaint-D>
> >     >> ata-Current-YTD/5uac-w243
> >     >> > (downloaded as plain old CSV)
> >     >> >
> >     >> > Anything I might be missing? Thanks in advance for giving a
> >     quick look!
> >     >> > Mike
> >     >> >
> >     >> >
> >     >> > ##Start Code
> >     >> >
> >     >> > #load packages
> >     >> > library(sf)
> >     >> > library(RPostgreSQL)
> >     >> >
> >     >> > #read data
> >     >> > crime_current <- read.csv("NYPD_Complaint_Data_
> Current_YTD.csv",
> >     >> > stringsAsFactors = FALSE)
> >     >> >
> >     >> > #format time columns for easier reading in postgres (I think),
> as
> >     >> keeping
> >     >> > as date format caused problems in export
> >     >> > crime_current$CMPLNT_FR_TIME <-
> >     >> > as.character(as.POSIXct(paste(crime_current$CMPLNT_FR_DT,
> >     >> > crime_current$CMPLNT_FR_TM), format="%m/%d/%Y\ %H:%M", tz=""))
> >     >> > crime_current$CMPLNT_TO_TIME <-
> >     >> > as.character(as.POSIXct(paste(crime_current$CMPLNT_TO_DT,
> >     >> > crime_current$CMPLNT_TO_TM), format="%m/%d/%Y\ %H:%M", tz=""))
> >     >> > crime_current$RPT_DT <-
> >     as.character(as.POSIXct(crime_current$RPT_DT,
> >     >> > format="%m/%d/%Y", tz=""))
> >     >> >
> >     >> > #convert to sf object
> >     >> > crime_current.sf <- st_as_sf(crime_current, coords =
> c("Longitude",
> >     >> > "Latitude"), crs = 4326)
> >     >> > #reproject to EPSG 2263
> >     >> > crime_current.sf <- st_transform(crime_current.sf, crs=2263)
> >     >> >
> >     >> > #write to postgres
> >     >> > st_write(crime_current.sf, "PG:dbname=mydb user=user
> >     host=xx.xx.xx.xx",
> >     >> > 'health_safety.crime_current')
> >     >> > ###End Code
> >     >> >
> >     >> >
> >     >> >
> >     >> >> 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-8        LC_COLLATE=en_US.UTF-8
> >     >> >  [5] LC_MONETARY=en_US.UTF-8    LC_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] sp_1.2-3          RPostgreSQL_0.4-1 DBI_0.6
>  sf_0.3-4
> >     >> >
> >     >> > loaded via a namespace (and not attached):
> >     >> > [1] tools_3.3.1     units_0.4-2     Rcpp_0.12.9
>  udunits2_0.13
> >     >> > grid_3.3.1      lattice_0.20-33
> >     >> >
> >     >> >       [[alternative HTML version deleted]]
> >     >> >
> >     >> > _______________________________________________
> >     >> > R-sig-Geo mailing list
> >     >> > [hidden email] <mailto:[hidden email]>
> >     >> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>
> >     >> >
> >     >>
> >     >> --
> >     >> Edzer Pebesma
> >     >> Institute for Geoinformatics  (ifgi),  University of Münster
> >     >> Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081
> >     <tel:%2B49%20251%2083%2033081>
> >     >> Journal of Statistical Software:   http://www.jstatsoft.org/
> >     >> Computers & Geosciences:   http://elsevier.com/locate/cageo/
> >     <http://elsevier.com/locate/cageo/>
> >     >>
> >     >>
> >     >> _______________________________________________
> >     >> R-sig-Geo mailing list
> >     >> [hidden email] <mailto:[hidden email]>
> >     >> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>
> >     >>
> >     >
> >     >
> >
> >             [[alternative HTML version deleted]]
> >
> >     _______________________________________________
> >     R-sig-Geo mailing list
> >     [hidden email] <mailto:[hidden email]>
> >     https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>
> >
> >
>
> --
> Edzer Pebesma
> Institute for Geoinformatics  (ifgi),  University of Münster
> Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081
> Journal of Statistical Software:   http://www.jstatsoft.org/
> Computers & Geosciences:   http://elsevier.com/locate/cageo/
>
>
        [[alternative HTML version deleted]]

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

Re: Sentienl 2 gdal translate

Thu, 03/16/2017 - 06:02
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 <[hidden email]> 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
>> [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

        [[alternative HTML version deleted]]

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

Re: Same mask for two rasters, but obtaining different extents in R

Thu, 03/16/2017 - 04:52
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 <[hidden email]> 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.04166667, 0.04166667  (x, y)
> extent      : -180, 180, -60, *90.00001 * (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  : 489    38
>
>
>> lg5
> class       : RasterLayer
> dimensions  : 3600, 8640, 31104000  (nrow, ncol, ncell)
> resolution  : 0.04166667, 0.04166667  (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 <[hidden email]>
> 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
>> <[hidden email]> 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.04166667, 0.04166667  (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  : 489    38
>>>
>>>> lg5
>>>     class       : RasterLayer
>>>     dimensions  : 339, 246, 83394  (nrow, ncol, ncell)
>>>     resolution  : 0.04166667, 0.04166667  (x, y)
>>>     extent      : 72.45833, 82.70833, 8.083333, 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
> [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

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

Re: Maintain SRID with st_write to postgis db

Thu, 03/16/2017 - 03:06
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 <[hidden email]
> <mailto:[hidden email]>> 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
>
>
>
>     #Output of install from github
>     > install_github("edzer/sfr")
>     Downloading GitHub repo edzer/sfr@master
>     from URL https://api.github.com/repos/edzer/sfr/zipball/master
>     <https://api.github.com/repos/edzer/sfr/zipball/master>
>     Installing sf
>     '/usr/lib/R/bin/R' --no-site-file --no-environ --no-save --no-restore
>     --quiet  \
>       CMD INSTALL '/tmp/RtmpKLmhyt/devtools9fd11eb9c3/edzer-sfr-d620f3b'  \
>       --library='/home/mlt244/R/x86_64-pc-linux-gnu-library/3.3'
>     --install-tests
>
>     * installing *source* package ‘sf’ ...
>     configure: CC: gcc -std=gnu99
>     configure: CXX: g++
>     configure: :
>     checking for gdal-config... /usr/bin/gdal-config
>     checking gdal-config usability... yes
>     configure: GDAL: 2.1.0
>     checking GDAL version >= 2.0.0... yes
>     checking for gcc... gcc -std=gnu99
>     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... no
>     checking for suffix of object files... o
>     checking whether we are using the GNU C compiler... yes
>     checking whether gcc -std=gnu99 accepts -g... yes
>     checking for gcc -std=gnu99 option to accept ISO C89... none needed
>     checking how to run the C preprocessor... gcc -std=gnu99 -E
>     checking for grep that handles long lines and -e... /bin/grep
>     checking for egrep... /bin/grep -E
>     checking for ANSI C header files... yes
>     checking for sys/types.h... yes
>     checking for sys/stat.h... yes
>     checking for stdlib.h... yes
>     checking for string.h... yes
>     checking for memory.h... yes
>     checking for strings.h... yes
>     checking for inttypes.h... yes
>     checking for stdint.h... yes
>     checking for unistd.h... yes
>     checking gdal.h usability... yes
>     checking gdal.h presence... yes
>     checking for gdal.h... yes
>     checking GDAL: linking with --libs only... yes
>     checking GDAL: /usr/share/gdal/2.1/pcs.csv readable... yes
>     checking GDAL: checking whether PROJ.4 is available for linking:... yes
>     checking GDAL: checking whether PROJ.4 is available fur running:... yes
>     checking proj_api.h usability... yes
>     checking proj_api.h presence... yes
>     checking for proj_api.h... yes
>     checking for pj_init_plus in -lproj... yes
>     checking PROJ.4: epsg found and readable... yes
>     proj_conf_test.c: In function 'main':
>     proj_conf_test.c:5:5: error: unknown type name 'PAFile'
>          PAFile fp;
>          ^
>     proj_conf_test.c:8:5: warning: implicit declaration of function
>     'pj_open_lib' [-Wimplicit-function-declaration]
>          fp = pj_open_lib(ctx, "conus", "rb");
>          ^
>     proj_conf_test.c:9:12: warning: comparison between pointer and integer
>     [enabled by default]
>          if (fp == NULL) exit(1);
>                 ^
>     proj_conf_test.c:10:5: warning: implicit declaration of function
>     'pj_ctx_fclose' [-Wimplicit-function-declaration]
>          pj_ctx_fclose(ctx, fp);
>          ^
>     ./configure: line 3834: ./proj_conf_test: No such file or directory
>     checking PROJ.4: conus found and readable... yes
>     checking geos-config usability... yes
>     configure: GEOS: 3.5.0
>     checking GEOS version >= 3.3.0... yes
>     checking geos_c.h usability... yes
>     checking geos_c.h presence... yes
>     checking for geos_c.h... yes
>     checking geos: linking with -lgeos_c... yes
>     checking for lwgeom_version in -llwgeom... no
>     configure: error: in
>     `/tmp/RtmpKLmhyt/devtools9fd11eb9c3/edzer-sfr-d620f3b':
>     configure: error: lwgeom test failed (--without-readline to disable)
>     See `config.log' for more details
>     ERROR: configuration failed for package ‘sf’
>     * removing ‘/home/mlt244/R/x86_64-pc-linux-gnu-library/3.3/sf’
>     * restoring previous ‘/home/mlt244/R/x86_64-pc-linux-gnu-library/3.3/sf’
>     Error: Command failed (1)
>
>
>     On Wed, Mar 15, 2017 at 6:14 PM, Michael Treglia <[hidden email]
>     <mailto:[hidden email]>> wrote:
>
>     > Wow - thanks so much for this quick fix, Edzer! I like your
>     solution to
>     > having syntatically different but semantically identical
>     proj4string. Will
>     > try this in a bit, and write back if I have any issues.
>     > Best,
>     > mike
>     >
>     > On Wed, Mar 15, 2017 at 5:58 PM, Edzer Pebesma <
>     > [hidden email]
>     <mailto:[hidden email]>> wrote:
>     >
>     >> Great question! Short answer: now solved in the dev version on
>     github;
>     >> data are written directly to postgis having epsg 2263.
>     >>
>     >>
>     >> Long answer:
>     >>
>     >> I believe this was caused by gdal and proj.4 doing different
>     things when
>     >> resolving epsg codes to proj4strings. sf uses proj.4 for this. When
>     >> writing a proj4string either gdal or postgis don't recognize the
>     >> proj4string that proj.4 returns on the epsg code. Neither gdal nor
>     >> postgis understand that syntactically different proj4strings may be
>     >> semantically identical.
>     >>
>     >>
>     >> After running your example, in postgis
>     >>
>     >> # select proj4text from spatial_ref_sys where SRID = 900914;
>     >>
>     >> gives:
>     >>
>     >>  +proj=lcc +lat_1=41.03333333333333 +lat_2=40.66666666666666
>     >> +lat_0=40.16666666666666 +lon_0=-74 +x_0=300000 +y_0=0 +ellps=GRS80
>     >> +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs
>     >>
>     >> # select proj4text from spatial_ref_sys where SRID = 2263;
>     >>
>     >> gives:
>     >>
>     >>  +proj=lcc +lat_1=41.03333333333333 +lat_2=40.66666666666666
>     >> +lat_0=40.16666666666666 +lon_0=-74 +x_0=300000.0000000001 +y_0=0
>     >> +datum=NAD83 +units=us-ft +no_defs
>     >>
>     >> sf causes this:
>     >>
>     >> > st_crs(2263)
>     >> $epsg
>     >> [1] 2263
>     >>
>     >> $proj4string
>     >> [1] "+proj=lcc +lat_1=41.03333333333333 +lat_2=40.66666666666666
>     >> +lat_0=40.16666666666666 +lon_0=-74 +x_0=300000.0000000001 +y_0=0
>     >> +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs"
>     >>
>     >> attr(,"class")
>     >> [1] "crs"
>     >>
>     >> because it uses proj.4 directly to resolve SRID strings:
>     >>
>     >> /usr/share/proj/epsg has:
>     >>
>     >> # NAD83 / New York Long Island (ftUS)
>     >> <2263> +proj=lcc +lat_1=41.03333333333333 +lat_2=40.66666666666666
>     >> +lat_0=40.16666666666666 +lon_0=-74 +x_0=300000.0000000001 +y_0=0
>     >> +datum=NAD83 +units=us-ft +no_defs  <>
>     >>
>     >>
>     >> The change I made to sf (
>     >> https://github.com/edzer/sfr/commit/d620f3b748d487bae910e388
>     <https://github.com/edzer/sfr/commit/d620f3b748d487bae910e388>
>     >> 4c554fa9e3ce7090)
>     >> now first asks gdal to resolve the epsg (in case it is not NA), and
>     >> otherwise resolve the proj4string (if not NA), instead of ONLY
>     trying to
>     >> resolve a non-NA proj4string.
>     >>
>     >> On 15/03/17 20:50, Michael Treglia wrote:
>     >> > Hi All,
>     >> >
>     >> > Been working to import and manipulate a CSV file with point data
>     >> > (lat/long), and then export to a PostGIS db.
>     >> >
>     >> > Overall, successful, but one thing I'd like to fix - when I
>     write out
>     >> the
>     >> > layer to postgis, the SRID is not maintained. The final EPSG/SRID
>     >> should be
>     >> > 2263, but when I check in PostGIS, it comes up as 900914.
>     >> >
>     >> > Below is my code and sessionInfo, and the data are from here:
>     >> > https://data.cityofnewyork.us/Public-Safety/NYPD-Complaint-D
>     <https://data.cityofnewyork.us/Public-Safety/NYPD-Complaint-D>
>     >> ata-Current-YTD/5uac-w243
>     >> > (downloaded as plain old CSV)
>     >> >
>     >> > Anything I might be missing? Thanks in advance for giving a
>     quick look!
>     >> > Mike
>     >> >
>     >> >
>     >> > ##Start Code
>     >> >
>     >> > #load packages
>     >> > library(sf)
>     >> > library(RPostgreSQL)
>     >> >
>     >> > #read data
>     >> > crime_current <- read.csv("NYPD_Complaint_Data_Current_YTD.csv",
>     >> > stringsAsFactors = FALSE)
>     >> >
>     >> > #format time columns for easier reading in postgres (I think), as
>     >> keeping
>     >> > as date format caused problems in export
>     >> > crime_current$CMPLNT_FR_TIME <-
>     >> > as.character(as.POSIXct(paste(crime_current$CMPLNT_FR_DT,
>     >> > crime_current$CMPLNT_FR_TM), format="%m/%d/%Y\ %H:%M", tz=""))
>     >> > crime_current$CMPLNT_TO_TIME <-
>     >> > as.character(as.POSIXct(paste(crime_current$CMPLNT_TO_DT,
>     >> > crime_current$CMPLNT_TO_TM), format="%m/%d/%Y\ %H:%M", tz=""))
>     >> > crime_current$RPT_DT <-
>     as.character(as.POSIXct(crime_current$RPT_DT,
>     >> > format="%m/%d/%Y", tz=""))
>     >> >
>     >> > #convert to sf object
>     >> > crime_current.sf <- st_as_sf(crime_current, coords = c("Longitude",
>     >> > "Latitude"), crs = 4326)
>     >> > #reproject to EPSG 2263
>     >> > crime_current.sf <- st_transform(crime_current.sf, crs=2263)
>     >> >
>     >> > #write to postgres
>     >> > st_write(crime_current.sf, "PG:dbname=mydb user=user
>     host=xx.xx.xx.xx",
>     >> > 'health_safety.crime_current')
>     >> > ###End Code
>     >> >
>     >> >
>     >> >
>     >> >> 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-8        LC_COLLATE=en_US.UTF-8
>     >> >  [5] LC_MONETARY=en_US.UTF-8    LC_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] sp_1.2-3          RPostgreSQL_0.4-1 DBI_0.6           sf_0.3-4
>     >> >
>     >> > loaded via a namespace (and not attached):
>     >> > [1] tools_3.3.1     units_0.4-2     Rcpp_0.12.9     udunits2_0.13
>     >> > grid_3.3.1      lattice_0.20-33
>     >> >
>     >> >       [[alternative HTML version deleted]]
>     >> >
>     >> > _______________________________________________
>     >> > R-sig-Geo mailing list
>     >> > [hidden email] <mailto:[hidden email]>
>     >> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>
>     >> >
>     >>
>     >> --
>     >> Edzer Pebesma
>     >> Institute for Geoinformatics  (ifgi),  University of Münster
>     >> Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081
>     <tel:%2B49%20251%2083%2033081>
>     >> Journal of Statistical Software:   http://www.jstatsoft.org/
>     >> Computers & Geosciences:   http://elsevier.com/locate/cageo/
>     <http://elsevier.com/locate/cageo/>
>     >>
>     >>
>     >> _______________________________________________
>     >> R-sig-Geo mailing list
>     >> [hidden email] <mailto:[hidden email]>
>     >> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>
>     >>
>     >
>     >
>
>             [[alternative HTML version deleted]]
>
>     _______________________________________________
>     R-sig-Geo mailing list
>     [hidden email] <mailto:[hidden email]>
>     https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>     <https://stat.ethz.ch/mailman/listinfo/r-sig-geo>
>
> --
Edzer Pebesma
Institute for Geoinformatics  (ifgi),  University of Münster
Heisenbergstraße 2, 48149 Münster, Germany; +49 251 83 33081
Journal of Statistical Software:   http://www.jstatsoft.org/
Computers & Geosciences:   http://elsevier.com/locate/cageo/


_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
signature.asc (484 bytes) Download Attachment

Pages