If you look at the file with ncview and analyse the header with ncdump -
h you will find that en extent is missing.
The standard tool ncview shows also a "flipped version"
Try to use gdal more directly like this snippet
library(raster)
library(gdalUtils)
library(mapview)
# necessary because of
Hi Clay,
RSAGA provides a comfortable platform independent system wrapper for
SAGA but as stated no two-way bindings.
If you want to make use of SAGA algorithms () it is IMHO the most
straightforward way to import and export the raster files using the e.g.
gdalUtils. If you use raster() dir
Hi Dominik,
If you use the gdalUtils package there is no significant difference in
the results using CLI or R:
library(gdalUtils)
gdaltransform(s_srs="+proj=longlat +datum=WGS84", t_srs="+proj=lcc
+lat_1=28 +lat_2=50 +lat_0=39.70001220694445 +lon_0=-98 +x_0=0 +y_0=0
+ellps=sphere +a=6370
Dominik,
If you want to deal with bigger data sets in a fast and more flexible way I
strongly suggest to use GRASS7. Rgrass7 provides a very good "r-ish" wrapper to
use it from R. If You are interested i 'll post a typical setup and example for
your question. Please note you need obligatory a G
Dominik,
probably I did not catch exactly what are your issues.
If you want to perform a multiscale analysis of the digital relief you
should not focus on a 4,8,16 or more neighbors analysis. This would be
helpful for a least cost path analysis or a single scale but multi
neighborhood analysi
Augustin
just quick and dirty if you run gdalinfo("geo_em.d01.nc") your are
getting the information about the corner coordinates the subdatasets and
so on. Together with Dominiks suggestion you can do something like this:
library(gdalUtils)
library(raster)
Sys.setenv(GDAL_NETCDF_BOTTOMUP="YES
r <- ptransform(cbind(lon0, lat0)/180*pi,'+proj=longlat +datum=WGS84
+no_defs',proj)
## calculate extent using the Lambertian units (m)
xmin=as.integer(tr[1,1]-(x/2*dx-dx))
xmax=as.integer(tr[1,1]+(x/2*dx-dx))
ymin=as.integer(tr[1,2]-(y/2*dy-dy))
ymax=as.integer(tr[1,2]+(y/2*dy-dy)
Agus,
sorry for the addon but I think I have to provide a correction of the
corner coordinates (e.g. the extent values):
In the example that you have posted below I did calculate the extent
using the domain center coordinate and the WRF grid resolution in meter
and the number of rows and col
Hi,
if you just want to map the data, mapview could be an option that among
others avoid the pixel stretching.
require(mapview)
require(raster)
nica <- getData("GADM", country="NIC", level=0)
mapview(nica)
mapview(nica,zcol = "POP2000", color = "#FFA500", lwd= 5, alpha.regions
= 0.4)
che
github:
library(devtools)
install_github("environmentalinformatics-marburg/mapview", ref = "master")
cheers chris
Am 26.02.2016 um 12:27 schrieb Agustin Lobo:
Stunning!
Can I remove the buttons for saving to a bmp file?
What attribution should be used for publishing?
OS depending pipe
or you may run it using the rJava package which could be more complex.
cheers Chris
if you want you can call it from R with javaR
Am 18.03.2016 um 20:11 schrieb Barry Rowlingson:
On Fri, Mar 18, 2016 at 6:49 PM, Chris Reudenbach
wrote:
Because it seems to be an arc and no
Because it seems to be an arc and not a circle issue that you can solve
the problem by
picking arbitrary two points of your assumed "arc" then construct
(calculate) the perpendicular bisector of
the line between them and do so for another arbitrary two points of the
assumed "arc".
The interse
Vinh
Even if it might be in this list OT, IMHO R is not the best tool for
dealing with this amount of vector data. Actually I agree completely
with Roger's remarks and corresponding to the "competent platform" you
also may think about using software for big data...
As Roger already has clari
Michael,
using GRASS from R is a bit cumbersome. GRASS (and this is for sure one
of it strength ) is extremely rigid with projections etc. Due to this
you should setup a correct structure. I use a setup that is similar to
the below snippet.
cheers Chris
library(rgrass7)
library(sp)
# set
Michael,
Using a fresh OSGEO4W64 standard quick desktop installation (i.e.
installation of the default desktop GIS software packages with the
installer and using C:\OSGeo4W64 as path) I suggest the below solution.
You have to set all necessary eniromental and system variables manually.
I am
a later release.
>
> Roger
>
>>
>> I'm sure it will be helpful to other people also.
>> Thanks again
>>
>> Le 24/11/2016 09:17, Chris Reudenbach a �crit :
>>> Michael,
>>>
>>> Using a fresh OSGEO4W64 standard quick desktop installa
Hi Manuel,
Probably you know better than me that there are tons of papers dealing
with this question out there. Unfortunately up to my mind your question
focus a more a conceptual (as described e.g. by Rudnick et al 2012
Meiklejohn et al. 2012 or Kindlmann & Burel 2008) than a technical
pr
Marta,
your problem seems to me more conceptual. The shortestPath
implementation of a cost analysis is not exactly want you want. You
would choose it if you have to find an unknown path on a friction
surface. You would not choose it if you just want to link positions. The
shortestPath of your
Tristan,
if I understand you right you just want to calculate the distances. So
no hydro stuff like accumulation flow directions etc.? As well as no
diffusion modeling of the pollutants.
Most of the traditional vector based GIS stuff is packed into the rgeos
package. So you might calculated
results
> in a single SpatialLine.
>
> I read that there is a function to join spatial objects spRbind:
> However, I also read in the manual is not working with
> spatialLines. Byside, it�s possible to use the rgeosStatus to join
> these spatial objects. I tried t
Antony,
with focus on prototyping and medium to complex modeling I strongly
suggest Uri Wilensky's Netlogo (https://ccl.northwestern.edu/netlogo/)
which can interfaced from R using RNetLogo
https://cran.r-project.org/web/packages/RNetLogo/index.html that
provides an excellent wrapper .
che
Ervan,
Just on the run, especially if you deal with real data and some 100K
-1000K of vectors I think the fastest way to do so is to engage GDAL
GRASS7/SAGA and their ability to deal highly efficient with this kind
of topological and geometrical queries.
A very good pure R alternative is to
Many of us rely on the raster package as a crucial basis for their work.
Big thank to Robert. Nevertheless to contribute needs to focus needs
and ressources. Maybe an information exchange/discussion with Robert
about options such as if/how the interested community can support would
be more pr
Jaime,
if the location of your GRASS installation is not known you may also
give the link2GI package a try.
try link2GI::linkGRASS7() for a "brute force" searching and linking.
This should setup your enviroment for using the newest GRASS version.
cheers Chris
On 23/11/2018 09:44, Roger Bivand
24 matches
Mail list logo