Re: [R-sig-Geo] Creating Raster Brick - Very Slow
Just to be sure, before suggesting possible solutions, you have 12,000
rasters of identical extent (e.g. bands or time slices of the same place)?
Thanks,
Alex
On 12/10/2015 11:09 PM, Stephen Stewart wrote:
> Hi everyone!
>
> I am currently building 8 raster bricks that are made up of 12,000 raster
> files of approximately 500kb each, however it is running incredibly slow!
> The code I am using is as follows:
>
> library(raster)
> setwd("c:/files")
> files <- list.files(getwd(),pattern=".tif")
> stack <- stack(files)
> brick <- brick(stack,filename = "c:/files/my_raster_brick.tif",format =
> "GTiff")
>
> I was wondering if there was a brick equivalent of quick.stack or something
> to speed up the process? Alternatively, something outside of R perhaps that
> may be more efficient? It is looking like it will take around 50 days per
> brick at this rate!
>
> I want to be able to quickly extract vectors of values (using
> my_raster_brick[row,col]) so stacks are out of the question as they are way
> too slow.
>
> Thanks and have a great break!
>
> Cheers,
>
> Steve
>
> [[alternative HTML version deleted]]
>
> ___
> R-sig-Geo mailing list
> R-sig-Geo@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>
___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Re: [R-sig-Geo] wtms data into R
On 02/10/2016 04:20 AM, Clay S wrote: > Is there a quick way to load Web Map Tiling Service (WMTS) data into R? > > Thanks > Theoretically yes, as of GDAL 2.1 http://gdal.org/frmt_wmts.html there is potential to use rgdal or gdalUtils as noted in this older thread http://r-sig-geo.2731867.n2.nabble.com/Access-WMS-and-alike-services-from-R-td7586257.html I'm haven't seen a simple working example yet though. Of course the other way to got about this is to generate a Leaflet (There are at least 2 R packages) map with the WMTS plugin and then view your map in the browser. Anyone else have working examples? Enjoy, Alex ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Re: [R-sig-Geo] adapting spatial points and wrld_smpl to a reference system implicit in a .nc file
On 02/22/2016 09:50 AM, Agus Camacho wrote:
> Dear all,
>
> Im trying to overlap these points:
> https://www.dropbox.com/s/awdclg4cvsdngej/clean%20urosaurus%20records.csv?dl=0
>
> and a wrld_simpl object:
> library(maptools)
> data(wrld_simpl)
>
> Over this raster layer
> https://www.dropbox.com/sh/qcw174tgogpnz7s/AAByDc3TeyFe3W4nEqTFix6Oa?dl=0
>
> This rastr comes from a .nc file without a reference system. The author of
> that .nc file gave me the following data about the .nc.
>
> The projection is *Lambert conformal conic* projection
> CEN_LAT = 38.0
> CEN_LON = -100.0
> TRUELAT1 = 25.
> TRUELAT2 = 45.
>
> However, despite i have gone through many sites in the internet, i cant
> figure it out:
>
> a) if that is all the data i need to set a reference system for my points
> and the wrld_simp object.
>
> b) how to change a typical CRS object with such data
>
> Ex.CRS ("+proj=lcc+lat_0=38.0+lon0_2=-100+ellps=WGS84")
>
> Where do i enter the TRUELAT and CENLAT values?
> Are there any site that explains easily what the fields in the CRS mean and
> how to change them?
>
> Thanks in advance.
>
https://github.com/OSGeo/proj.4/wiki/GenParms
https://trac.osgeo.org/proj/wiki/GenParms
I believe:
+lat_0 = CEN_LAT Latitude of origin
+lat_1 = TRUELAT1 Latitude of first standard parallel
+lat_2 = TRUELAT2 Latitude of second standard parallel
+lon_0 = CEN_LON Central meridian
proj strings are defined by the proj4 libary. It's website listed above
and the associated mailing lists or gis stackexchange would be the
places to get help on it.
https://lists.osgeo.org/mailman/listinfo/metacrs
It often helps to browse similar projections on
http://spatialreference.org/
http://epsg.io/
Enjoy,
Alex
___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Re: [R-sig-Geo] How to reduce the buffering time with the function "buffer" (package raster)
On 05/09/2016 10:36 AM, Nelly Reduan wrote: > But I obtain the error message: > > gdal_proximity.py srcfile dstfile [-srcband n] [-dstband n] > [-of format] [-co name=value]* > [-ot Byte/Int16/Int32/Float32/etc] > [-values n,n,n] [-distunits PIXEL/GEO] > [-maxdist n] [-nodata n] [-fixed-buf-val n] [-q] > Warning message: > running command '"C:\OSGeo4W64\OSGeo4W.bat" C:\OSGEO4~1\bin\GDAL_P~2.BAT > H:\Project\grassland.tif H:\Project\distance.shp 50' had status 1 I would test the command directly on the osgeo4w shell first to figure out what's wrong. Note, I think that command outputs a raster not a shp. Thanks, Alex ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Re: [R-sig-Geo] R-sig-Geo Digest, Vol 155, Issue 14
Shaun, Thanks I hadn't seen the write functionality before, but last time I looked was a year ago. Very unclear what version they introduced the writing, seems to be 10.4 released at the end of 2015. I suspect the machines around here are still running 10.3 Any idea if you can direct edit those formats like other layers in Arc (I should give it a try)? Thanks, -Alex On 07/15/2016 09:24 AM, Shaun Walbridge wrote: > Alex, > > The Geodatabase issue and what the most appropriate storage format is for a > standard is a complex topic so I won't jump into it, but wanted to mention > that ArcGIS supports writing to both Geopackages and Spatalite databases and > has for the past few releases. This can be accomplished in a few ways, > including using the CreateSQLiteDatabase tool [1]. > > Cheers, > Shaun > > 1. > http://desktop.arcgis.com/en/arcmap/latest/tools/data-management-toolbox/create-sqlite-database.htm > > -Original Message- > From: R-sig-Geo [mailto:r-sig-geo-boun...@r-project.org] On Behalf Of Alex > Mandel > Sent: Friday, July 15, 2016 11:31 AM > To: Paul Lantos ; r-sig-geo@r-project.org > Subject: Re: [R-sig-Geo] R-sig-Geo Digest, Vol 155, Issue 14 > > rgdal has a geodatabase driver (gdal in QGIS too) > > Standardizing on the format is impossible unless ESRI opens the > specification. Currently open source tools, even using ESRI SDK can not read > Rasters from geodatabase, relation based values in vectors, and have little > or no write ability. Also ESRI gdb formats are not backwards compatible with > each other, if you write a file with the newest Arc it's only usable with the > newest versions. > > I convert all gdb I receive into either gpkg or spatialite which FYI ArcGIS > can read both of those now. For whatever reason ESRI has not implemented the > ability to write to those formats yet. > > -Alex > > On 07/15/2016 04:40 AM, Paul Lantos wrote: >> ESRI / ArcGIS has moved beyond shapefiles too with the advent of >> geodatabases. In a GIS environment these are superior to shapefiles in many >> ways, and ESRI in its own training and help resources encourage geodatabases >> over shapefiles. As far as I've seen only SpaceStat has made itself >> compatible with geodatabases. But I think that it's a high priority for R, >> QGIS, etc to adopt the geodatabase as a common format, esp to facilitate >> interchange with ArcGIS. >> >> >> Original message >> From: r-sig-geo-requ...@r-project.org >> Date: 7/15/16 6:07 AM (GMT-05:00) >> To: r-sig-geo@r-project.org >> Subject: R-sig-Geo Digest, Vol 155, Issue 14 >> >> Send R-sig-Geo mailing list submissions to >> r-sig-geo@r-project.org >> >> To subscribe or unsubscribe via the World Wide Web, visit >> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mail >> man_listinfo_r-2Dsig-2Dgeo&d=CwICAg&c=n6-cguzQvX_tUIrZOS_4Og&r=YFaRLkc >> UCdDkLrpTbNOUV9J1CwYBCTMwgm5tdQkRSm4&m=SGUF8qW8cnoIz6ic76VZu7Bgk7bDFCv >> WboA3bewZTHU&s=RZXiOGDMUuqbppFHzIRDaxFCLvTof4HQQNYr9XdyXBo&e= >> or, via email, send a message with subject or body 'help' to >> r-sig-geo-requ...@r-project.org >> >> You can reach the person managing the list at >> r-sig-geo-ow...@r-project.org >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of R-sig-Geo digest..." >> >> [[alternative HTML version deleted]] >> >> ___ >> R-sig-Geo mailing list >> R-sig-Geo@r-project.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mail >> man_listinfo_r-2Dsig-2Dgeo&d=CwICAg&c=n6-cguzQvX_tUIrZOS_4Og&r=YFaRLkc >> UCdDkLrpTbNOUV9J1CwYBCTMwgm5tdQkRSm4&m=SGUF8qW8cnoIz6ic76VZu7Bgk7bDFCv >> WboA3bewZTHU&s=RZXiOGDMUuqbppFHzIRDaxFCLvTof4HQQNYr9XdyXBo&e= >> > > ___ > R-sig-Geo mailing list > R-sig-Geo@r-project.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dsig-2Dgeo&d=CwICAg&c=n6-cguzQvX_tUIrZOS_4Og&r=YFaRLkcUCdDkLrpTbNOUV9J1CwYBCTMwgm5tdQkRSm4&m=SGUF8qW8cnoIz6ic76VZu7Bgk7bDFCvWboA3bewZTHU&s=RZXiOGDMUuqbppFHzIRDaxFCLvTof4HQQNYr9XdyXBo&e= > > ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
[R-sig-Geo] Possible rgdal enhancement request related to null attributes
Roger et al, I couldn't find a ticket system for rgdal so this seemed the best place to post. We just hit a bug (in QGIS [1]) of sorts due to a change in behavior in GDAL from 2.1.x to 2.2.x in the way null fields are handled. [2] Short story if you have a column of null values and you save a geojson those fields are not saved. So the next time you open up the file, you have less columns than before. It's great for minifying geojson but terrible for many other use cases. I'm not 100% sure this will show up in rgdal (2.2 hasn't been pushed to my Ubuntu yet so I haven't tested), but there's a good chance it will depending on how R deals with unset vs null. If someone would like to test, you can get a sample file from [3], readOGR and then writeOGR (to geojson) and see if the null columns vanish. The enhancement requested to deal with this, is to provide the user an option that allows them to decide when a field is unset vs null. Or maybe just a clarification on how R represents that data and how a user could set a field as null instead of unset and vice versa. Even R. pointed out that this can be controlled with the OGR_F_IsFieldNull() part of the ogr api. [1] https://issues.qgis.org/issues/16812 [2] https://trac.osgeo.org/gdal/wiki/rfc67_nullfieldvalues [3] https://github.com/UCDavisLibrary/ava/issues/270 Thanks, Alex ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Re: [R-sig-Geo] Problem installing rgdal
On 11/6/18 09:31, Jeremy Kraft wrote:
> Hello,
>
> I'm trying to reinstall rgdal, but I have a problem with the sqlite
> dependency.
> Below is the R output.
>
> Does someone knows how to solve the problem?
>
> Thanks,
>
> Jeremy
>
> ---
> jeremy@yuri-HP-ProBook-640-G1:/$ R
>
> R version 3.4.4 (2018-03-15) -- "Someone to Lean On"
> Copyright (C) 2018 The R Foundation for Statistical Computing
> Platform: x86_64-pc-linux-gnu (64-bit)
>
> R is free software and comes with ABSOLUTELY NO WARRANTY.
> You are welcome to redistribute it under certain conditions.
> Type 'license()' or 'licence()' for distribution details.
>
> Natural language support but running in an English locale
>
> R is a collaborative project with many contributors.
> Type 'contributors()' for more information and
> 'citation()' on how to cite R or R packages in publications.
>
> Type 'demo()' for some demos, 'help()' for on-line help, or
> 'help.start()' for an HTML browser interface to help.
> Type 'q()' to quit R.
>
>> install.packages('rgdal')
> Installing package into ‘/home/jeremy/R/x86_64-pc-linux-gnu-library/3.4’
> (as ‘lib’ is unspecified)
> trying URL 'https://cloud.r-project.org/src/contrib/rgdal_1.3-6.tar.gz'
> Content type 'application/x-gzip' length 1666975 bytes (1.6 MB)
> ==
> downloaded 1.6 MB
>
> * installing *source* package ‘rgdal’ ...
> ** package ‘rgdal’ successfully unpacked and MD5 sums checked
> configure: R_HOME: /usr/lib/R
> configure: CC: gcc -std=gnu99
> configure: CXX: g++
> configure: C++11 support available
> configure: rgdal: 1.3-6
> checking for /usr/bin/svnversion... no
> configure: svn revision: 773
> checking for gdal-config... /usr/bin/gdal-config
> checking gdal-config usability... yes
> configure: GDAL: 2.2.3
> checking GDAL version >= 1.11.4... yes
> checking gdal: linking with --libs only... no
> checking gdal: linking with --libs and --dep-libs... no
> /usr/bin/ld: /usr/lib/libgdal.a(genbindataset.o): relocation R_X86_64_32
> against `.rodata.str1.8' can not be used when making a PIE object;
> recompile with -fPIC
> /usr/bin/ld: /usr/lib/libgdal.a(geotiff.o): relocation R_X86_64_32 against
> `.rodata.str1.1' can not be used when making a PIE object; recompile with
> -fPIC
> /usr/bin/ld: /usr/lib/libgdal.a(gff_dataset.o): relocation R_X86_64_32S
> against hidden symbol `_ZTV10GFFDataset' can not be used when making a PIE
> object
>
> *
> * Long list
> *
> /usr/bin/ld: /usr/lib/libgdal.a(gmlhandler.o): relocation R_X86_64_32
> against `.rodata.str1.1' can not be used when making a PIE object;
> recompile with -fPIC
> /usr/bin/ld: /usr/lib/libgdal.a(ili2handler.o): relocation R_X86_64_32S
> against hidden symbol `_ZTV11ILI2Handler' can not be used when making a PIE
> object
> /usr/bin/ld: /usr/lib/libgdal.a(nashandler.o): relocation R_X86_64_32
> against `.rodata.str1.8' can not be used when making a PIE object;
> recompile with -fPIC
> /usr/bin/ld: /usr/lib/libgdal.a(ntf_codelist.o): relocation R_X86_64_32
> against `.rodata.str1.1' can not be used when making a PIE object;
> recompile with -fPIC
> /usr/bin/ld: /usr/lib/libgdal.a(ntf_estlayers.o): relocation R_X86_64_32S
> against hidden symbol `_ZN11OGRNTFLayer12GetLayerDefnEv' can not be used
> when making a PIE object
> /usr/bin/ld: /usr/lib/libgdal.a(ntf_raster.o): relocation R_X86_64_32S
> against hidden symbol `_ZTV17OGRNTFRasterLayer' can not be used when making
> a PIE object
> /usr/bin/ld: /usr/lib/libgdal.a(ogrmssqlgeometryparser.o): relocation
> R_X86_64_32S against `.rodata' can not be used when making a PIE object;
> recompile with -fPIC
> /usr/bin/ld: final link failed: Nonrepresentable section on output
> collect2: error: ld returned 1 exit status
> /usr/bin/ld: /usr/lib/libgdal.a(ogrsqliteapiroutines.o): undefined
> reference to symbol 'sqlite3_prepare'
> /usr/lib/x86_64-linux-gnu/libsqlite3.so.0: error adding symbols: DSO
> missing from command line
> collect2: error: ld returned 1 exit status
> configure: Install failure: compilation and/or linkage problems.
> configure: error: GDALAllRegister not found in libgdal.
> ERROR: configuration failed for package ‘rgdal’
> * removing ‘/home/jeremy/R/x86_64-pc-linux-gnu-library/3.4/rgdal’
>
> The downloaded source packages are in
> ‘/tmp/RtmpKSJ85K/downloaded_packages’
> Warning message:
> In install.packages("rgdal") :
> installation of package ‘rgdal’ had non-zero exit status
>
>
Looks like an issue with your system libgdal-dev package, perhaps
reinstall the system dependencies. Which OS are you installing on?
Thanks,
Alex
___
R-sig-Geo mailing list
R-sig-Geo@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Re: [R-sig-Geo] Problem installing rgdal
Jeremy,
Please keep the thread on list so every-one can see the
discussion/solution (reply-all).
I don't have a 18.10 box to test on quickly. But can you review what
steps you did, ie: what system packages did you install before
attempting to install rgdal? Usually you need libgdal-dev libproj-dev
and perhaps libsqlite3-dev libgeos-dev (all of these are supposed to be
dependencies of libgdal-dev).
Also it might be good to jump this over to the R-sig-debian list where
many people are familiar with the OS
https://stat.ethz.ch/mailman/listinfo/r-sig-debian (also covers ubuntu &
mint, all debian derivatives). One option is usually the marutter ppa
which has system packages for cran libraries, however it doesn't appear
to support 18.10 yet
http://sites.psu.edu/theubunturblog/installing-r-in-ubuntu/
Thanks,
Alex
On 11/7/18 01:51, Jeremy Kraft wrote:
> I'm on linux, ubuntu 18.10. I've been trying to reinstall libgdal-dev but
> that did not solve the problem.
>
> Thanks,
>
> On Tue, Nov 6, 2018 at 7:12 PM Alex M wrote:
>
>> On 11/6/18 09:31, Jeremy Kraft wrote:
>>> Hello,
>>>
>>> I'm trying to reinstall rgdal, but I have a problem with the sqlite
>>> dependency.
>>> Below is the R output.
>>>
>>> Does someone knows how to solve the problem?
>>>
>>> Thanks,
>>>
>>> Jeremy
>>>
>>>
>> ---
>>> jeremy@yuri-HP-ProBook-640-G1:/$ R
>>>
>>> R version 3.4.4 (2018-03-15) -- "Someone to Lean On"
>>> Copyright (C) 2018 The R Foundation for Statistical Computing
>>> Platform: x86_64-pc-linux-gnu (64-bit)
>>>
>>> R is free software and comes with ABSOLUTELY NO WARRANTY.
>>> You are welcome to redistribute it under certain conditions.
>>> Type 'license()' or 'licence()' for distribution details.
>>>
>>> Natural language support but running in an English locale
>>>
>>> R is a collaborative project with many contributors.
>>> Type 'contributors()' for more information and
>>> 'citation()' on how to cite R or R packages in publications.
>>>
>>> Type 'demo()' for some demos, 'help()' for on-line help, or
>>> 'help.start()' for an HTML browser interface to help.
>>> Type 'q()' to quit R.
>>>
>>>> install.packages('rgdal')
>>> Installing package into ‘/home/jeremy/R/x86_64-pc-linux-gnu-library/3.4’
>>> (as ‘lib’ is unspecified)
>>> trying URL 'https://cloud.r-project.org/src/contrib/rgdal_1.3-6.tar.gz'
>>> Content type 'application/x-gzip' length 1666975 bytes (1.6 MB)
>>> ==
>>> downloaded 1.6 MB
>>>
>>> * installing *source* package ‘rgdal’ ...
>>> ** package ‘rgdal’ successfully unpacked and MD5 sums checked
>>> configure: R_HOME: /usr/lib/R
>>> configure: CC: gcc -std=gnu99
>>> configure: CXX: g++
>>> configure: C++11 support available
>>> configure: rgdal: 1.3-6
>>> checking for /usr/bin/svnversion... no
>>> configure: svn revision: 773
>>> checking for gdal-config... /usr/bin/gdal-config
>>> checking gdal-config usability... yes
>>> configure: GDAL: 2.2.3
>>> checking GDAL version >= 1.11.4... yes
>>> checking gdal: linking with --libs only... no
>>> checking gdal: linking with --libs and --dep-libs... no
>>> /usr/bin/ld: /usr/lib/libgdal.a(genbindataset.o): relocation R_X86_64_32
>>> against `.rodata.str1.8' can not be used when making a PIE object;
>>> recompile with -fPIC
>>> /usr/bin/ld: /usr/lib/libgdal.a(geotiff.o): relocation R_X86_64_32
>> against
>>> `.rodata.str1.1' can not be used when making a PIE object; recompile with
>>> -fPIC
>>> /usr/bin/ld: /usr/lib/libgdal.a(gff_dataset.o): relocation R_X86_64_32S
>>> against hidden symbol `_ZTV10GFFDataset' can not be used when making a
>> PIE
>>> object
>>>
>>> *
>>> * Long list
>>> *
>>> /usr/bin/ld: /usr/lib/libgdal.a(gmlhandler.o): relocation R_X86_64_32
>>> against `.rodata.str1.1' can not be used when making a PIE object;
>>> recompile with -fPIC
>>> /usr/bin/ld: /usr/lib/libgdal.a(ili2handler.o): relocation R_X86_64_32S
>>> against hidden symbol `_ZTV11ILI2Handler' can not be used when making a
>> PIE
>&g
Re: [R-sig-Geo] gdalUtils::gdal_translate()
gdal_translate does work fine for me on R 3.4 That error sounds like your install is having issues picking what gdal installation to use. ?gdal_chooseInstallation perhaps your install was not found correctly amd you need to run gdal_setInstallation? But I also see something in your call that looks off to me. Based on the docs projwin takes a numeric vector. Which to me should look like projwin=c(ext@xmin,ext@ymax,ext@xmax,ext@ymin) Thanks, Alex On 11/7/18 01:02, Agustin Lobo wrote: > I find the following problem when trying gdal_translate(): >> gdal_translate(src_dataset=file.path(dirMAJAIma,"imain20.vrt"), > + dst_dataset="test.tif", > + ot="Int16",projwin=ext@xmin,ext@ymax,ext@xmax,ext@ymin) > Error in gdal_chooseInstallation(hasDrivers = of) : > No installations match. > > Other functions in gdalUtils do work and gdal_translate works on the > Debian terminal. > Does igdal_translate() work for other people? > Thanks > Agus > > sessionInfo() > R version 3.5.0 (2018-04-23) > Platform: x86_64-pc-linux-gnu (64-bit) > Running under: Debian GNU/Linux buster/sid > > Matrix products: default > BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.8.0 > LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.8.0 > > locale: > [1] LC_CTYPE=en_GB.UTF-8 LC_NUMERIC=C > LC_TIME=en_GB.UTF-8 > [4] LC_COLLATE=en_GB.UTF-8 LC_MONETARY=en_GB.UTF-8 > LC_MESSAGES=en_GB.UTF-8 > [7] LC_PAPER=en_GB.UTF-8 LC_NAME=C > LC_ADDRESS=C > [10] LC_TELEPHONE=C LC_MEASUREMENT=en_GB.UTF-8 > LC_IDENTIFICATION=C > > attached base packages: > [1] stats graphics grDevices utils datasets methods base > > other attached packages: > [1] gdalUtils_2.0.1.14 rgdal_1.3-6R.utils_2.7.0 > R.oo_1.22.0R.methodsS3_1.7.1 > [6] raster_2.7-15 sp_1.3-1 > > loaded via a namespace (and not attached): > [1] compiler_3.5.0 tools_3.5.0 yaml_2.2.0 Rcpp_0.12.19 > codetools_0.2-15 grid_3.5.0 > [7] iterators_1.0.10 foreach_1.4.4knitr_1.20 lattice_0.20-35 > > ___ > R-sig-Geo mailing list > R-sig-Geo@r-project.org > https://stat.ethz.ch/mailman/listinfo/r-sig-geo > ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Re: [R-sig-Geo] R code for inverse distance to a power
On 11/8/18 05:50, sudheesh pai wrote: > Hi, > > I am looking for an R code to replace the inverse distance to a power > algorithm in QGIS, which has the input as point shape file. the parameters > of algorithm are radius 1 (R1), radius 2 (R2) and the z parameter. > Also, my CRS is 3006 which means that i have to specify R1 and R2 in > meters. > > If some one has an example, kindly let me know. > > Thank you > Sounds like you are talking about Inverse Distance Weighted functions (IDW). Yes the gstat package has a function for that. Example: https://mgimond.github.io/Spatial/interpolation-in-r.html Enjoy, Alex ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Re: [R-sig-Geo] Reproject MODIS data using R (results in NAs or no spatial extent)
gdalUtils has a get_subdatasets() which is really helpful here, it's
just a gdalinfo with grep.
Here's what my code looks like for reprojecting, what I found is that
even if the hdf has the proj definition, gdal tools don't seem to use it
right, so I specify the proj string as the s_srs or a_srs.
.modis_warp <- function(output, t_srs="EPSG:4326", ...){
# Multiple sources say this is the proj definition of the MODIS Sinusoidal
MODIS_SRS <- "+proj=sinu +lon_0=0 +x_0=0 +y_0=0 +a=6371007.181
+b=6371007.181 +units=m +no_defs"
CO <- c("COMPRESS=DEFLATE","PREDICTOR=2","ZLEVEL=9")
catcher <- tryCatch(
gdalwarp(output[1]
, output[2]
, s_srs=MODIS_SRS
, t_srs=t_srs
, of="GTiff"
#, srcnodata
#, dstnodata
, "-multi"
#, paste0("-wo NUM_THREADS=",ncpu)#Multithread computatation
, CO
, output)
)
return(catcher)
}
Sure you could transform the raster in "memory" but that will probably
right a temp grd file to the system anyways, might as well just convert
it to a multi-band tiff for ease of use.
Thanks,
Alex
On 11/29/18 11:39, Michael Sumner wrote:
> Ah, never mind - it's the subdataset discovery that's probably not easy
> with rgdal.
> Sorry for the noise.
>
> Mike.
>
> On Fri, 30 Nov 2018 at 06:38 Michael Sumner wrote:
>
>> Fwiw there shouldn't be any need to convert from hdf to tif - could you
>> please try this?
>>
>> x <- readGDAL( ".../GLASS02B05.V04.A1990161.2018062.hdf")
>>
>> If that works it at least removes some steps from your process.
>>
>> Cheers, Mike.
>>
>> On Fri, Nov 30, 2018, 05:03 Elizabeth Webb wrote:
>>
>>> I am using GLASS albedo data stored here<
>>> ftp://ftp.glcf.umd.edu/glcf/GLASS/ABD/AVHRR/> for pre-2000 (AVHRR) data
>>> and here
Re: [R-sig-Geo] How i can do a shape merge?
On 2/1/19 07:11, Fernando Gimeno wrote: > Hello > > I'm looking a method with the same result that Arcgis "merge" > > I have to do a shape merge with a lot of archives but most common tools on > R has not merged alll shape and always i have to export to arcgis. Has > anyone worked this? > > Thank you > With sp type layers, use bind from the raster package, to do many layers you use do.call with it. https://rspatial.org/spatial/7-vectmanip.html#append do.call(bind, listoflayers) With sf you can use rbind, though if you have a lot of data you might want to use data.table and noted in this discussion. https://github.com/r-spatial/sf/issues/798 do.call(rbind, listoflayers) But really if you have a lot of layers, loading them into memory in R before combining is not particularly efficient. Consider using commandline: ogr2ogr -append https://www.gdal.org/ogr2ogr.html You can call ogr2ogr from R with the gdalUtils package. Enjoy, Alex ___ R-sig-Geo mailing list R-sig-Geo@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
