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: 7 min 58 sec ago

Re: raster::clump not working?

Fri, 05/25/2018 - 08:07
Dear Mike,

great and many thanks as this is exactly what I was after.

Cheers
Joao

On 25 May 2018 at 12:58, Michael Sumner <[hidden email]> wrote:
> Joao, this is what you are after I think.  It's important to use
> sf/fasterize otherwise any holes filled by other patches won't be identified
> (and it's faster). It won't scale well given rasterToPolygons, but there
> might be other options using sf related tricks.
>
> library(raster)
> r <- raster(volcano) %/% 20
> ## p has six distinct values (multipolygons)
> p <- rasterToPolygons(r, dissolve = TRUE)
> ## pp has ten distinct patches
> pp <- disaggregate(p)
> pp$patch <- seq_len(nrow(pp))
>
> ## back to raster
> #rr <- rasterize(pp, r, field = pp$patch)
> # or faster with sf/fasterize (also this gets the holes filled correctly)
> rr <- fasterize::fasterize(sf::st_as_sf(pp), r, field = "patch")
> unique(values(rr))
>
> Cheers, Mike.
>
>
> On Fri, 25 May 2018 at 21:15 João Carreiras <[hidden email]> wrote:
>>
>> Dear Ben,
>>
>> Thank you for your prompt reply.
>>
>> Now I see what clump does. I just thought clump would give the same
>> result as ArcGIS "Region Group". I need some command to assign a
>> different value to each patch. And by patch I mean contiguous pixels
>> having the same value, so that in this (absurd) example I would get
>> 648 patches.
>>
>> Take care
>> Joao
>>
>> On 25 May 2018 at 11:35, Ben Tupper <[hidden email]> wrote:
>> > Hi,
>> >
>> > I think it is actually correct - there is only one 'clump' of connected
>> > cells.  In raster clumps are separated from other clumps by backgound (0
>> > or
>> > NA).  In your example there is no background anywhere so there is just
>> > one
>> > clump.
>> >
>> > You can see the difference if you divide x in to halves with a row of
>> > NAs.
>> > Note that limited spatial extent so the clumping doesn't wrap around the
>> > globe which it will for [-180, 180].
>> >
>> > r <- raster(ncols=36, nrows=18, xmn = 0, xmx = 36, ymn = 0, ymx = 18)
>> > x <- init(r, fun='cell')
>> >
>> > x[9,1:36] <- NA
>> > y <- clump(x)
>> > y
>> > # class       : RasterLayer
>> > # dimensions  : 18, 36, 648  (nrow, ncol, ncell)
>> > # resolution  : 1, 1  (x, y)
>> > # extent      : 0, 36, 0, 18  (xmin, xmax, ymin, ymax)
>> > # coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
>> > # data source : in memory
>> > # names       : clumps
>> > # values      : 1, 2  (min, max)
>> >
>> > x[1:18, 18] <- NA
>> > y
>> > # class       : RasterLayer
>> > # dimensions  : 18, 36, 648  (nrow, ncol, ncell)
>> > # resolution  : 1, 1  (x, y)
>> > # extent      : 0, 36, 0, 18  (xmin, xmax, ymin, ymax)
>> > # coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
>> > # data source : in memory
>> > # names       : clumps
>> > # values      : 1, 4  (min, max)
>> >
>> >
>> > Cheers,
>> > Ben
>> >
>> >
>> > On May 25, 2018, at 6:00 AM, João Carreiras <[hidden email]>
>> > wrote:
>> >
>> > Hi!
>> >
>> > I've been trying to run the clump command but the output is consistently
>> > a
>> > raster with values == 1. Please find below an example.
>> >
>> > I'm sure I'm doing something stupid. However, the command is really
>> > straightforward and I can't seem to identify what the problem might be.
>> >
>> > Any help really appreciated.
>> > Thanks
>> > Joao
>> >
>> > r <- raster(ncols=36, nrows=18)
>> > x <- init(r, fun='cell')
>> > x
>> > class       : RasterLayer
>> > dimensions  : 18, 36, 648  (nrow, ncol, ncell)
>> > resolution  : 10, 10  (x, y)
>> > extent      : -180, 180, -90, 90  (xmin, xmax, ymin, ymax)
>> > coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
>> > data source : in memory
>> > names       : layer
>> > values      : 1, 648  (min, max)
>> > a <- clump(x)
>> > a
>> > class       : RasterLayer
>> > dimensions  : 18, 36, 648  (nrow, ncol, ncell)
>> > resolution  : 10, 10  (x, y)
>> > extent      : -180, 180, -90, 90  (xmin, xmax, ymin, ymax)
>> > coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
>> > data source : in memory
>> > names       : clumps
>> > values      : 1, 1  (min, max)
>> >
>> > _______________________________________________
>> > 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
>> >
>> > Ecological Forecasting: https://eco.bigelow.org/
>> >
>> >
>> >
>> >
>> >
>>
>> _______________________________________________
>> R-sig-Geo mailing list
>> [hidden email]
>> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
>
> --
> Dr. Michael Sumner
> Software and Database Engineer
> Australian Antarctic Division
> 203 Channel Highway
> Kingston Tasmania 7050 Australia
>
_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: BIG DATABASE

Fri, 05/25/2018 - 08:00
Thanks so much!

El vie., 25 may. 2018 9:51, Roger Bivand <[hidden email]> escribió:

> On Fri, 25 May 2018, Javier Moreira wrote:
>
> > Can I use this answer to ask exactly for what it's mentioned.
> > R and Postgis mostly for Easter files.
> > Can you point books, online courses, tutorials, GitHub pages, anything,
> to
> > better understand this?
> > I had been struggling to find info.
>
> For rpostgis, see:
>
> https://journal.r-project.org/archive/2018/RJ-2018-025/index.html
>
> and the supplementary material linked there to replicate the results in
> the online article (should be in the 2018-1 issue).
>
> Roger
>
> >
> > Thanks!
> >
> > El vie., 25 may. 2018 1:35, Tom Philippi <[hidden email]>
> escribió:
> >
> >> What Roger said (as always).
> >>
> >> Note that if you use tidyverse and magrittr, dplyr and tidyverse tools
> work
> >> well with databases via DBI.  sqldf also works with multiple SQL
> database
> >> backends if you're an ol dog like me and don't use tidyverse much.
> >>
> >> Also, since this is r-sig-*GEO*, note that postgreSQL has postGIS for
> >> spatial data, which does far more than the automatic tiling of large
> >> rasters in package raster.  I'm seeing wonderful performance working
> with a
> >> 340M observation >100GB dataset of bird observation data in R via
> postGIS,
> >> even with "only" 32GB RAM and constrained to running win7, not
> linux/unix.
> >>
> >> One alternative is that if your database is running on massive hardware
> >> (tons of memory, many cores, etc.), it is possible to run R within both
> >> postgreSQL and now MS SQL Server, the first free, the second an
> additional
> >> cost add-on, and both usually at the cost of painful negotiations with
> DA
> >> administrators for permissions to run your ad hoc R code on their SQL
> >> server.  If you have the hardware, you can even run R with hadoop,
> although
> >> I've never done that with spatial data.
> >>
> >> Tom 0
> >>
> >>
> >> On Thu, May 24, 2018 at 5:04 AM, Roger Bivand <[hidden email]>
> wrote:
> >>
> >>> On Thu, 24 May 2018, Yaya Bamba wrote:
> >>>
> >>> Thanks to all of you. I will try with the package  RMySQL and see.
> >>>>
> >>>
> >>> Maybe look more generally through the packages depending on and
> importing
> >>> from DBI (https://cran.r-project.org/package=DBI) to see what is
> >>> available - there are many more than RMySQL.
> >>>
> >>> and use the Official Statistics and HPC Task Views:
> >>>
> >>> https://cran.r-project.org/view=OfficialStatistics
> >>>
> >>> https://cran.r-project.org/view=HighPerformanceComputing
> >>>
> >>> to see how typical workflows (not necessarily DB-based) can be handled.
> >>> The HPC TV has a section on large memory and out-of-memory approaches.
> If
> >>> your data are spatial in raster format, the raster package provides
> some
> >>> out-of-memory functionality. In sf, spatial vector data may be read
> from
> >>> databases too.
> >>>
> >>> Roger
> >>>
> >>>
> >>>
> >>>> 2018-05-24 11:33 GMT+00:00 Andres Diaz Loaiza <[hidden email]>:
> >>>>
> >>>> Hello Yaya,
> >>>>>
> >>>>> Many years ago I work with a database in MySQL connected to R through
> >> the
> >>>>> package RMySQL​. The data was stored in the MySQL and I was
> connecting
> >>>>> and
> >>>>> using the data from R
> >>>>>
> >>>>> you should have a look in:
> >>>>>
> >>>>> https://cran.r-project.org/web/packages/RMySQL/index.html
> >>>>>
> >>>>> Cheers,
> >>>>>
> >>>>> Andres
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>> --
> >>> Roger Bivand
> >>> Department of Economics, Norwegian School of Economics,
> >>> Helleveien 30, N-5045 Bergen, Norway.
> >>> voice: +47 55 95 93 55; e-mail: [hidden email]
> >>> http://orcid.org/0000-0003-2392-6140
> >>> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
> >>> _______________________________________________
> >>> 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
> >>
> >
> >       [[alternative HTML version deleted]]
> >
> > _______________________________________________
> > R-sig-Geo mailing list
> > [hidden email]
> > https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> >
>
> --
> Roger Bivand
> Department of Economics, Norwegian School of Economics,
> Helleveien 30, N-5045 Bergen, Norway.
> voice: +47 55 95 93 55; e-mail: [hidden email]
> http://orcid.org/0000-0003-2392-6140
> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
        [[alternative HTML version deleted]]

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

Re: BIG DATABASE

Fri, 05/25/2018 - 07:50
On Fri, 25 May 2018, Javier Moreira wrote:

> Can I use this answer to ask exactly for what it's mentioned.
> R and Postgis mostly for Easter files.
> Can you point books, online courses, tutorials, GitHub pages, anything, to
> better understand this?
> I had been struggling to find info.

For rpostgis, see:

https://journal.r-project.org/archive/2018/RJ-2018-025/index.html

and the supplementary material linked there to replicate the results in
the online article (should be in the 2018-1 issue).

Roger

>
> Thanks!
>
> El vie., 25 may. 2018 1:35, Tom Philippi <[hidden email]> escribió:
>
>> What Roger said (as always).
>>
>> Note that if you use tidyverse and magrittr, dplyr and tidyverse tools work
>> well with databases via DBI.  sqldf also works with multiple SQL database
>> backends if you're an ol dog like me and don't use tidyverse much.
>>
>> Also, since this is r-sig-*GEO*, note that postgreSQL has postGIS for
>> spatial data, which does far more than the automatic tiling of large
>> rasters in package raster.  I'm seeing wonderful performance working with a
>> 340M observation >100GB dataset of bird observation data in R via postGIS,
>> even with "only" 32GB RAM and constrained to running win7, not linux/unix.
>>
>> One alternative is that if your database is running on massive hardware
>> (tons of memory, many cores, etc.), it is possible to run R within both
>> postgreSQL and now MS SQL Server, the first free, the second an additional
>> cost add-on, and both usually at the cost of painful negotiations with DA
>> administrators for permissions to run your ad hoc R code on their SQL
>> server.  If you have the hardware, you can even run R with hadoop, although
>> I've never done that with spatial data.
>>
>> Tom 0
>>
>>
>> On Thu, May 24, 2018 at 5:04 AM, Roger Bivand <[hidden email]> wrote:
>>
>>> On Thu, 24 May 2018, Yaya Bamba wrote:
>>>
>>> Thanks to all of you. I will try with the package  RMySQL and see.
>>>>
>>>
>>> Maybe look more generally through the packages depending on and importing
>>> from DBI (https://cran.r-project.org/package=DBI) to see what is
>>> available - there are many more than RMySQL.
>>>
>>> and use the Official Statistics and HPC Task Views:
>>>
>>> https://cran.r-project.org/view=OfficialStatistics
>>>
>>> https://cran.r-project.org/view=HighPerformanceComputing
>>>
>>> to see how typical workflows (not necessarily DB-based) can be handled.
>>> The HPC TV has a section on large memory and out-of-memory approaches. If
>>> your data are spatial in raster format, the raster package provides some
>>> out-of-memory functionality. In sf, spatial vector data may be read from
>>> databases too.
>>>
>>> Roger
>>>
>>>
>>>
>>>> 2018-05-24 11:33 GMT+00:00 Andres Diaz Loaiza <[hidden email]>:
>>>>
>>>> Hello Yaya,
>>>>>
>>>>> Many years ago I work with a database in MySQL connected to R through
>> the
>>>>> package RMySQL​. The data was stored in the MySQL and I was connecting
>>>>> and
>>>>> using the data from R
>>>>>
>>>>> you should have a look in:
>>>>>
>>>>> https://cran.r-project.org/web/packages/RMySQL/index.html
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Andres
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>>
>>> --
>>> Roger Bivand
>>> Department of Economics, Norwegian School of Economics,
>>> Helleveien 30, N-5045 Bergen, Norway.
>>> voice: +47 55 95 93 55; e-mail: [hidden email]
>>> http://orcid.org/0000-0003-2392-6140
>>> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
>>> _______________________________________________
>>> 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
>>
>
> [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> --
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: [hidden email]
http://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Roger Bivand
Department of Economics
Norwegian School of Economics
Helleveien 30
N-5045 Bergen, Norway

Re: BIG DATABASE

Fri, 05/25/2018 - 07:43
Can I use this answer to ask exactly for what it's mentioned.
R and Postgis mostly for Easter files.
Can you point books, online courses, tutorials, GitHub pages, anything, to
better understand this?
I had been struggling to find info.

Thanks!

El vie., 25 may. 2018 1:35, Tom Philippi <[hidden email]> escribió:

> What Roger said (as always).
>
> Note that if you use tidyverse and magrittr, dplyr and tidyverse tools work
> well with databases via DBI.  sqldf also works with multiple SQL database
> backends if you're an ol dog like me and don't use tidyverse much.
>
> Also, since this is r-sig-*GEO*, note that postgreSQL has postGIS for
> spatial data, which does far more than the automatic tiling of large
> rasters in package raster.  I'm seeing wonderful performance working with a
> 340M observation >100GB dataset of bird observation data in R via postGIS,
> even with "only" 32GB RAM and constrained to running win7, not linux/unix.
>
> One alternative is that if your database is running on massive hardware
> (tons of memory, many cores, etc.), it is possible to run R within both
> postgreSQL and now MS SQL Server, the first free, the second an additional
> cost add-on, and both usually at the cost of painful negotiations with DA
> administrators for permissions to run your ad hoc R code on their SQL
> server.  If you have the hardware, you can even run R with hadoop, although
> I've never done that with spatial data.
>
> Tom 0
>
>
> On Thu, May 24, 2018 at 5:04 AM, Roger Bivand <[hidden email]> wrote:
>
> > On Thu, 24 May 2018, Yaya Bamba wrote:
> >
> > Thanks to all of you. I will try with the package  RMySQL and see.
> >>
> >
> > Maybe look more generally through the packages depending on and importing
> > from DBI (https://cran.r-project.org/package=DBI) to see what is
> > available - there are many more than RMySQL.
> >
> > and use the Official Statistics and HPC Task Views:
> >
> > https://cran.r-project.org/view=OfficialStatistics
> >
> > https://cran.r-project.org/view=HighPerformanceComputing
> >
> > to see how typical workflows (not necessarily DB-based) can be handled.
> > The HPC TV has a section on large memory and out-of-memory approaches. If
> > your data are spatial in raster format, the raster package provides some
> > out-of-memory functionality. In sf, spatial vector data may be read from
> > databases too.
> >
> > Roger
> >
> >
> >
> >> 2018-05-24 11:33 GMT+00:00 Andres Diaz Loaiza <[hidden email]>:
> >>
> >> Hello Yaya,
> >>>
> >>> Many years ago I work with a database in MySQL connected to R through
> the
> >>> package RMySQL​. The data was stored in the MySQL and I was connecting
> >>> and
> >>> using the data from R
> >>>
> >>> you should have a look in:
> >>>
> >>> https://cran.r-project.org/web/packages/RMySQL/index.html
> >>>
> >>> Cheers,
> >>>
> >>> Andres
> >>>
> >>>
> >>
> >>
> >>
> >>
> > --
> > Roger Bivand
> > Department of Economics, Norwegian School of Economics,
> > Helleveien 30, N-5045 Bergen, Norway.
> > voice: +47 55 95 93 55; e-mail: [hidden email]
> > http://orcid.org/0000-0003-2392-6140
> > https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
> > _______________________________________________
> > 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
>
        [[alternative HTML version deleted]]

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

Re: raster::clump not working?

Fri, 05/25/2018 - 07:06
Check out SDMTools::ConnCompLabel
I think that will get you what you're after.

Hope that helps!
Mike


Please pardon any typos, this message was sent from a mobile device.

On Fri, May 25, 2018, 7:15 AM João Carreiras <[hidden email]> wrote:

> Dear Ben,
>
> Thank you for your prompt reply.
>
> Now I see what clump does. I just thought clump would give the same
> result as ArcGIS "Region Group". I need some command to assign a
> different value to each patch. And by patch I mean contiguous pixels
> having the same value, so that in this (absurd) example I would get
> 648 patches.
>
> Take care
> Joao
>
> On 25 May 2018 at 11:35, Ben Tupper <[hidden email]> wrote:
> > Hi,
> >
> > I think it is actually correct - there is only one 'clump' of connected
> > cells.  In raster clumps are separated from other clumps by backgound (0
> or
> > NA).  In your example there is no background anywhere so there is just
> one
> > clump.
> >
> > You can see the difference if you divide x in to halves with a row of
> NAs.
> > Note that limited spatial extent so the clumping doesn't wrap around the
> > globe which it will for [-180, 180].
> >
> > r <- raster(ncols=36, nrows=18, xmn = 0, xmx = 36, ymn = 0, ymx = 18)
> > x <- init(r, fun='cell')
> >
> > x[9,1:36] <- NA
> > y <- clump(x)
> > y
> > # class       : RasterLayer
> > # dimensions  : 18, 36, 648  (nrow, ncol, ncell)
> > # resolution  : 1, 1  (x, y)
> > # extent      : 0, 36, 0, 18  (xmin, xmax, ymin, ymax)
> > # coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
> > # data source : in memory
> > # names       : clumps
> > # values      : 1, 2  (min, max)
> >
> > x[1:18, 18] <- NA
> > y
> > # class       : RasterLayer
> > # dimensions  : 18, 36, 648  (nrow, ncol, ncell)
> > # resolution  : 1, 1  (x, y)
> > # extent      : 0, 36, 0, 18  (xmin, xmax, ymin, ymax)
> > # coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
> > # data source : in memory
> > # names       : clumps
> > # values      : 1, 4  (min, max)
> >
> >
> > Cheers,
> > Ben
> >
> >
> > On May 25, 2018, at 6:00 AM, João Carreiras <[hidden email]>
> wrote:
> >
> > Hi!
> >
> > I've been trying to run the clump command but the output is consistently
> a
> > raster with values == 1. Please find below an example.
> >
> > I'm sure I'm doing something stupid. However, the command is really
> > straightforward and I can't seem to identify what the problem might be.
> >
> > Any help really appreciated.
> > Thanks
> > Joao
> >
> > r <- raster(ncols=36, nrows=18)
> > x <- init(r, fun='cell')
> > x
> > class       : RasterLayer
> > dimensions  : 18, 36, 648  (nrow, ncol, ncell)
> > resolution  : 10, 10  (x, y)
> > extent      : -180, 180, -90, 90  (xmin, xmax, ymin, ymax)
> > coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
> > data source : in memory
> > names       : layer
> > values      : 1, 648  (min, max)
> > a <- clump(x)
> > a
> > class       : RasterLayer
> > dimensions  : 18, 36, 648  (nrow, ncol, ncell)
> > resolution  : 10, 10  (x, y)
> > extent      : -180, 180, -90, 90  (xmin, xmax, ymin, ymax)
> > coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
> > data source : in memory
> > names       : clumps
> > values      : 1, 1  (min, max)
> >
> > _______________________________________________
> > 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
> >
> > Ecological Forecasting: https://eco.bigelow.org/
> >
> >
> >
> >
> >
>
> _______________________________________________
> 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: raster::clump not working?

Fri, 05/25/2018 - 06:58
Joao, this is what you are after I think.  It's important to use
sf/fasterize otherwise any holes filled by other patches won't be
identified (and it's faster). It won't scale well given rasterToPolygons,
but there might be other options using sf related tricks.

library(raster)
r <- raster(volcano) %/% 20
## p has six distinct values (multipolygons)
p <- rasterToPolygons(r, dissolve = TRUE)
## pp has ten distinct patches
pp <- disaggregate(p)
pp$patch <- seq_len(nrow(pp))

## back to raster
#rr <- rasterize(pp, r, field = pp$patch)
# or faster with sf/fasterize (also this gets the holes filled correctly)
rr <- fasterize::fasterize(sf::st_as_sf(pp), r, field = "patch")
unique(values(rr))

Cheers, Mike.


On Fri, 25 May 2018 at 21:15 João Carreiras <[hidden email]> wrote:

> Dear Ben,
>
> Thank you for your prompt reply.
>
> Now I see what clump does. I just thought clump would give the same
> result as ArcGIS "Region Group". I need some command to assign a
> different value to each patch. And by patch I mean contiguous pixels
> having the same value, so that in this (absurd) example I would get
> 648 patches.
>
> Take care
> Joao
>
> On 25 May 2018 at 11:35, Ben Tupper <[hidden email]> wrote:
> > Hi,
> >
> > I think it is actually correct - there is only one 'clump' of connected
> > cells.  In raster clumps are separated from other clumps by backgound (0
> or
> > NA).  In your example there is no background anywhere so there is just
> one
> > clump.
> >
> > You can see the difference if you divide x in to halves with a row of
> NAs.
> > Note that limited spatial extent so the clumping doesn't wrap around the
> > globe which it will for [-180, 180].
> >
> > r <- raster(ncols=36, nrows=18, xmn = 0, xmx = 36, ymn = 0, ymx = 18)
> > x <- init(r, fun='cell')
> >
> > x[9,1:36] <- NA
> > y <- clump(x)
> > y
> > # class       : RasterLayer
> > # dimensions  : 18, 36, 648  (nrow, ncol, ncell)
> > # resolution  : 1, 1  (x, y)
> > # extent      : 0, 36, 0, 18  (xmin, xmax, ymin, ymax)
> > # coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
> > # data source : in memory
> > # names       : clumps
> > # values      : 1, 2  (min, max)
> >
> > x[1:18, 18] <- NA
> > y
> > # class       : RasterLayer
> > # dimensions  : 18, 36, 648  (nrow, ncol, ncell)
> > # resolution  : 1, 1  (x, y)
> > # extent      : 0, 36, 0, 18  (xmin, xmax, ymin, ymax)
> > # coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
> > # data source : in memory
> > # names       : clumps
> > # values      : 1, 4  (min, max)
> >
> >
> > Cheers,
> > Ben
> >
> >
> > On May 25, 2018, at 6:00 AM, João Carreiras <[hidden email]>
> wrote:
> >
> > Hi!
> >
> > I've been trying to run the clump command but the output is consistently
> a
> > raster with values == 1. Please find below an example.
> >
> > I'm sure I'm doing something stupid. However, the command is really
> > straightforward and I can't seem to identify what the problem might be.
> >
> > Any help really appreciated.
> > Thanks
> > Joao
> >
> > r <- raster(ncols=36, nrows=18)
> > x <- init(r, fun='cell')
> > x
> > class       : RasterLayer
> > dimensions  : 18, 36, 648  (nrow, ncol, ncell)
> > resolution  : 10, 10  (x, y)
> > extent      : -180, 180, -90, 90  (xmin, xmax, ymin, ymax)
> > coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
> > data source : in memory
> > names       : layer
> > values      : 1, 648  (min, max)
> > a <- clump(x)
> > a
> > class       : RasterLayer
> > dimensions  : 18, 36, 648  (nrow, ncol, ncell)
> > resolution  : 10, 10  (x, y)
> > extent      : -180, 180, -90, 90  (xmin, xmax, ymin, ymax)
> > coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
> > data source : in memory
> > names       : clumps
> > values      : 1, 1  (min, max)
> >
> > _______________________________________________
> > 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
> >
> > Ecological Forecasting: https://eco.bigelow.org/
> >
> >
> >
> >
> >
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> --
Dr. Michael Sumner
Software and Database Engineer
Australian Antarctic Division
203 Channel Highway
Kingston Tasmania 7050 Australia

        [[alternative HTML version deleted]]

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

Re: raster::clump not working?

Fri, 05/25/2018 - 06:14
Dear Ben,

Thank you for your prompt reply.

Now I see what clump does. I just thought clump would give the same
result as ArcGIS "Region Group". I need some command to assign a
different value to each patch. And by patch I mean contiguous pixels
having the same value, so that in this (absurd) example I would get
648 patches.

Take care
Joao

On 25 May 2018 at 11:35, Ben Tupper <[hidden email]> wrote:
> Hi,
>
> I think it is actually correct - there is only one 'clump' of connected
> cells.  In raster clumps are separated from other clumps by backgound (0 or
> NA).  In your example there is no background anywhere so there is just one
> clump.
>
> You can see the difference if you divide x in to halves with a row of NAs.
> Note that limited spatial extent so the clumping doesn't wrap around the
> globe which it will for [-180, 180].
>
> r <- raster(ncols=36, nrows=18, xmn = 0, xmx = 36, ymn = 0, ymx = 18)
> x <- init(r, fun='cell')
>
> x[9,1:36] <- NA
> y <- clump(x)
> y
> # class       : RasterLayer
> # dimensions  : 18, 36, 648  (nrow, ncol, ncell)
> # resolution  : 1, 1  (x, y)
> # extent      : 0, 36, 0, 18  (xmin, xmax, ymin, ymax)
> # coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
> # data source : in memory
> # names       : clumps
> # values      : 1, 2  (min, max)
>
> x[1:18, 18] <- NA
> y
> # class       : RasterLayer
> # dimensions  : 18, 36, 648  (nrow, ncol, ncell)
> # resolution  : 1, 1  (x, y)
> # extent      : 0, 36, 0, 18  (xmin, xmax, ymin, ymax)
> # coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
> # data source : in memory
> # names       : clumps
> # values      : 1, 4  (min, max)
>
>
> Cheers,
> Ben
>
>
> On May 25, 2018, at 6:00 AM, João Carreiras <[hidden email]> wrote:
>
> Hi!
>
> I've been trying to run the clump command but the output is consistently a
> raster with values == 1. Please find below an example.
>
> I'm sure I'm doing something stupid. However, the command is really
> straightforward and I can't seem to identify what the problem might be.
>
> Any help really appreciated.
> Thanks
> Joao
>
> r <- raster(ncols=36, nrows=18)
> x <- init(r, fun='cell')
> x
> class       : RasterLayer
> dimensions  : 18, 36, 648  (nrow, ncol, ncell)
> resolution  : 10, 10  (x, y)
> extent      : -180, 180, -90, 90  (xmin, xmax, ymin, ymax)
> coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
> data source : in memory
> names       : layer
> values      : 1, 648  (min, max)
> a <- clump(x)
> a
> class       : RasterLayer
> dimensions  : 18, 36, 648  (nrow, ncol, ncell)
> resolution  : 10, 10  (x, y)
> extent      : -180, 180, -90, 90  (xmin, xmax, ymin, ymax)
> coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
> data source : in memory
> names       : clumps
> values      : 1, 1  (min, max)
>
> _______________________________________________
> 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
>
> Ecological Forecasting: https://eco.bigelow.org/
>
>
>
>
>
_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo

Re: raster::clump not working?

Fri, 05/25/2018 - 06:00
Dear Joao,
I think function clump() works as it should be. A toy example:
x <- raster(matrix(sample(x = c(NA, NA, NA, 1), size = 36*18, replace =
TRUE), ncol=36, nrow=18))
plot(x)
plot(clump(x))

Maybe you are searching for a function that aggregate those cells that
have the same value?
In this case it would do what you want (I'm sure there is a more
straightforward way...):
r <- raster(ncols=36, nrows=18)
x <- init(r, fun='cell')
y <- layerize(x)
ids <- calc(x = y, fun = function(layers)
{return(which(as.logical(layers))[1])})
plot(ids)

HTH,
Ákos Bede-Fazekas
Hungarian Academy of Sciences


2018.05.25. 12:00 keltezéssel, João Carreiras írta:
> Hi!
>
> I've been trying to run the clump command but the output is consistently a
> raster with values == 1. Please find below an example.
>
> I'm sure I'm doing something stupid. However, the command is really
> straightforward and I can't seem to identify what the problem might be.
>
> Any help really appreciated.
> Thanks
> Joao
>
> r <- raster(ncols=36, nrows=18)
> x <- init(r, fun='cell')
> x
> class       : RasterLayer
> dimensions  : 18, 36, 648  (nrow, ncol, ncell)
> resolution  : 10, 10  (x, y)
> extent      : -180, 180, -90, 90  (xmin, xmax, ymin, ymax)
> coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
> data source : in memory
> names       : layer
> values      : 1, 648  (min, max)
> a <- clump(x)
> a
> class       : RasterLayer
> dimensions  : 18, 36, 648  (nrow, ncol, ncell)
> resolution  : 10, 10  (x, y)
> extent      : -180, 180, -90, 90  (xmin, xmax, ymin, ymax)
> coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
> data source : in memory
> names       : clumps
> values      : 1, 1  (min, max)
>
> _______________________________________________
> 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: raster::clump not working?

Fri, 05/25/2018 - 05:35
Hi,

I think it is actually correct - there is only one 'clump' of connected cells.  In raster clumps are separated from other clumps by backgound (0 or NA).  In your example there is no background anywhere so there is just one clump.

You can see the difference if you divide x in to halves with a row of NAs.  Note that limited spatial extent so the clumping doesn't wrap around the globe which it will for [-180, 180].

r <- raster(ncols=36, nrows=18, xmn = 0, xmx = 36, ymn = 0, ymx = 18)
x <- init(r, fun='cell')
 
x[9,1:36] <- NA
y <- clump(x)
y
# class       : RasterLayer
# dimensions  : 18, 36, 648  (nrow, ncol, ncell)
# resolution  : 1, 1  (x, y)
# extent      : 0, 36, 0, 18  (xmin, xmax, ymin, ymax)
# coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
# data source : in memory
# names       : clumps
# values      : 1, 2  (min, max)

x[1:18, 18] <- NA
y
# class       : RasterLayer
# dimensions  : 18, 36, 648  (nrow, ncol, ncell)
# resolution  : 1, 1  (x, y)
# extent      : 0, 36, 0, 18  (xmin, xmax, ymin, ymax)
# coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
# data source : in memory
# names       : clumps
# values      : 1, 4  (min, max)


Cheers,
Ben


> On May 25, 2018, at 6:00 AM, João Carreiras <[hidden email]> wrote:
>
> Hi!
>
> I've been trying to run the clump command but the output is consistently a
> raster with values == 1. Please find below an example.
>
> I'm sure I'm doing something stupid. However, the command is really
> straightforward and I can't seem to identify what the problem might be.
>
> Any help really appreciated.
> Thanks
> Joao
>
> r <- raster(ncols=36, nrows=18)
> x <- init(r, fun='cell')
> x
> class       : RasterLayer
> dimensions  : 18, 36, 648  (nrow, ncol, ncell)
> resolution  : 10, 10  (x, y)
> extent      : -180, 180, -90, 90  (xmin, xmax, ymin, ymax)
> coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
> data source : in memory
> names       : layer
> values      : 1, 648  (min, max)
> a <- clump(x)
> a
> class       : RasterLayer
> dimensions  : 18, 36, 648  (nrow, ncol, ncell)
> resolution  : 10, 10  (x, y)
> extent      : -180, 180, -90, 90  (xmin, xmax, ymin, ymax)
> coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
> data source : in memory
> names       : clumps
> values      : 1, 1  (min, max)
>
> _______________________________________________
> 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

Ecological Forecasting: https://eco.bigelow.org/






        [[alternative HTML version deleted]]

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

raster::clump not working?

Fri, 05/25/2018 - 05:00
Hi!

I've been trying to run the clump command but the output is consistently a
raster with values == 1. Please find below an example.

I'm sure I'm doing something stupid. However, the command is really
straightforward and I can't seem to identify what the problem might be.

Any help really appreciated.
Thanks
Joao

r <- raster(ncols=36, nrows=18)
x <- init(r, fun='cell')
x
class       : RasterLayer
dimensions  : 18, 36, 648  (nrow, ncol, ncell)
resolution  : 10, 10  (x, y)
extent      : -180, 180, -90, 90  (xmin, xmax, ymin, ymax)
coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
data source : in memory
names       : layer
values      : 1, 648  (min, max)
a <- clump(x)
a
class       : RasterLayer
dimensions  : 18, 36, 648  (nrow, ncol, ncell)
resolution  : 10, 10  (x, y)
extent      : -180, 180, -90, 90  (xmin, xmax, ymin, ymax)
coord. ref. : +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0
data source : in memory
names       : clumps
values      : 1, 1  (min, max)

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

Re: BIG DATABASE

Thu, 05/24/2018 - 23:35
What Roger said (as always).

Note that if you use tidyverse and magrittr, dplyr and tidyverse tools work
well with databases via DBI.  sqldf also works with multiple SQL database
backends if you're an ol dog like me and don't use tidyverse much.

Also, since this is r-sig-*GEO*, note that postgreSQL has postGIS for
spatial data, which does far more than the automatic tiling of large
rasters in package raster.  I'm seeing wonderful performance working with a
340M observation >100GB dataset of bird observation data in R via postGIS,
even with "only" 32GB RAM and constrained to running win7, not linux/unix.

One alternative is that if your database is running on massive hardware
(tons of memory, many cores, etc.), it is possible to run R within both
postgreSQL and now MS SQL Server, the first free, the second an additional
cost add-on, and both usually at the cost of painful negotiations with DA
administrators for permissions to run your ad hoc R code on their SQL
server.  If you have the hardware, you can even run R with hadoop, although
I've never done that with spatial data.

Tom 0


On Thu, May 24, 2018 at 5:04 AM, Roger Bivand <[hidden email]> wrote:

> On Thu, 24 May 2018, Yaya Bamba wrote:
>
> Thanks to all of you. I will try with the package  RMySQL and see.
>>
>
> Maybe look more generally through the packages depending on and importing
> from DBI (https://cran.r-project.org/package=DBI) to see what is
> available - there are many more than RMySQL.
>
> and use the Official Statistics and HPC Task Views:
>
> https://cran.r-project.org/view=OfficialStatistics
>
> https://cran.r-project.org/view=HighPerformanceComputing
>
> to see how typical workflows (not necessarily DB-based) can be handled.
> The HPC TV has a section on large memory and out-of-memory approaches. If
> your data are spatial in raster format, the raster package provides some
> out-of-memory functionality. In sf, spatial vector data may be read from
> databases too.
>
> Roger
>
>
>
>> 2018-05-24 11:33 GMT+00:00 Andres Diaz Loaiza <[hidden email]>:
>>
>> Hello Yaya,
>>>
>>> Many years ago I work with a database in MySQL connected to R through the
>>> package RMySQL​. The data was stored in the MySQL and I was connecting
>>> and
>>> using the data from R
>>>
>>> you should have a look in:
>>>
>>> https://cran.r-project.org/web/packages/RMySQL/index.html
>>>
>>> Cheers,
>>>
>>> Andres
>>>
>>>
>>
>>
>>
>>
> --
> Roger Bivand
> Department of Economics, Norwegian School of Economics,
> Helleveien 30, N-5045 Bergen, Norway.
> voice: +47 55 95 93 55; e-mail: [hidden email]
> http://orcid.org/0000-0003-2392-6140
> https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
> _______________________________________________
> 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: Measuring length of trajectories

Thu, 05/24/2018 - 08:42
On Thu, 24 May 2018 at 23:32 Jeri Wisman <[hidden email]> wrote:

> Hi all -
>
> I am trying to measure the length of time of trajectories taken of seabird
> movements to be able to relate time of flight to distance of flight. Any
> suggestions of a function or package on how to measure the time? Thanks,
>

There are very many, including adehabitatLT package and the trackDistance
function in the trip package (I know how that one works so it's easy for me
to help with, but it's not as sophisticated as adehabitat family so
pros/cons).

Both packages requires you to get your data into the right format. There's
more general capability in sp::spDists which has arguments longlat (set to
TRUE for great circle distances from longlat) and segments, which gives
sequential paired distances. Both adehabitatLT and trip will handle the
grouping of locations into separate paths (ordered by time).

I'd say it's worth trying some of the purpose-built packages, because then
some of the metrics can be extracted very easily (once you know your way
around). Explore the "Moving objects, trajectories" section of this Task
View

https://gist.github.com/mdsumner/0a3cb0e58bf9d37b782943ac269e1eff

and this list of recentish additions, pending update to the Task View,
which gives a taste of how much activity there is in this space(!).

https://gist.github.com/mdsumner/0a3cb0e58bf9d37b782943ac269e1eff

Cheers, Mike.

>
> *Jeri Wisman* | Masters Candidate
> Old Dominion University
> Department of Biological Sciences
> Mills Godwin Building, Room 312
> Norfolk VA 23529 USA
>
>         [[alternative HTML version deleted]]
>
> _______________________________________________
> R-sig-Geo mailing list
> [hidden email]
> https://stat.ethz.ch/mailman/listinfo/r-sig-geo
> --
Dr. Michael Sumner
Software and Database Engineer
Australian Antarctic Division
203 Channel Highway
Kingston Tasmania 7050 Australia

        [[alternative HTML version deleted]]

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

Re: Measuring length of trajectories

Thu, 05/24/2018 - 08:40
Hi Jeri,

there are a lot of packages to measure the tag trajectories length. You can
start reading about library(move) and library(gdistance)


2018-05-24 13:12 GMT+00:00 Jeri Wisman <[hidden email]>:

> Hi all -
>
> I am trying to measure the length of time of trajectories taken of seabird
> movements to be able to relate time of flight to distance of flight. Any
> suggestions of a function or package on how to measure the time? Thanks,
>
> *Jeri Wisman* | Masters Candidate
> Old Dominion University
> Department of Biological Sciences
> Mills Godwin Building, Room 312
> Norfolk VA 23529 USA
>
>         [[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

Re: Measuring length of trajectories

Thu, 05/24/2018 - 08:39
Jeri,

Is your data some kind of attached to bird(s) gps data?

Chris

On Thu, May 24, 2018 at 9:12 AM, Jeri Wisman <[hidden email]> wrote:

> Hi all -
>
> I am trying to measure the length of time of trajectories taken of seabird
> movements to be able to relate time of flight to distance of flight. Any
> suggestions of a function or package on how to measure the time? Thanks,
>
> *Jeri Wisman* | Masters Candidate
> Old Dominion University
> Department of Biological Sciences
> Mills Godwin Building, Room 312
> Norfolk VA 23529 USA
>
>         [[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

Measuring length of trajectories

Thu, 05/24/2018 - 08:12
Hi all -

I am trying to measure the length of time of trajectories taken of seabird
movements to be able to relate time of flight to distance of flight. Any
suggestions of a function or package on how to measure the time? Thanks,

*Jeri Wisman* | Masters Candidate
Old Dominion University
Department of Biological Sciences
Mills Godwin Building, Room 312
Norfolk VA 23529 USA

        [[alternative HTML version deleted]]

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

Re: how to plot different rows of a SpatialPolygonsDataFrame in trellis panels

Thu, 05/24/2018 - 08:04
On Thu, May 24, 2018 at 6:00 AM, <[hidden email]> wrote:

>
> Message: 1
> Date: Wed, 23 May 2018 18:39:07 +0000
> From: "Waichler, Scott R" <[hidden email]>
> To: "[hidden email]" <[hidden email]>
> Subject: [R-sig-Geo] how to plot different rows of a
>         SpatialPolygonsDataFrame in trellis panels
>
> Hello,
>
> I have a SpatialPolygonsDataFrame.  I would like to do a trellis plot on
> one of the attributes, so that in the panel for a given attribute value,
> only those polygons with that value are plotted.  So, each panel has
> different polygons plotted in it.  I can't figure out how to do this.  In
> the toy example below, I would like to create a trellis plot with one panel
> showing the polygons with id = 1, and another panel showing the polygons
> with id = 2.
>
> My goal beyond this toy problem is to do the same thing with stplot, where
> panels correspond to times and each time has a different set of polygons
> plotted.  Will that be possible?  In all the examples I can find of using
> stplot for a space-time grid with the spatial objects being polygons, the
> polygons are the same across time.
>
> # based on example in help("SpatialPolygonsDataFrame-class")
> Sr1 = Polygon(cbind(c(2,4,4,1,2),c(2,3,5,4,2)))
> Sr2 = Polygon(cbind(c(5,4,2,5),c(2,3,2,2)))
> Sr3 = Polygon(cbind(c(4,4,5,10,4),c(5,3,2,5,5)))
> Sr4 = Polygon(cbind(c(5,6,6,5,5),c(4,4,3,3,4)), hole = TRUE)
> Srs1 = Polygons(list(Sr1), "s1")
> Srs2 = Polygons(list(Sr2), "s2")
> Srs3 = Polygons(list(Sr3, Sr4), "s3/4")
> SpP = SpatialPolygons(list(Srs1,Srs2,Srs3), 1:3)
> grd <- GridTopology(c(1,1), c(1,1), c(10,10))
> polys <- as(grd, "SpatialPolygons")
> centroids <- coordinates(polys)
> x <- centroids[,1]
> y <- centroids[,2]
> z <- 1.4 + 0.1*x + 0.2*y + 0.002*x*x
> id = factor(sample(c(1,2), size=length(polys), replace=T))
> tmp <- SpatialPolygonsDataFrame(polys,
>       data=data.frame(x=x, y=y, z=z, id=id, row.names=row.names(polys)))
> plot(tmp)  # plots all the square polygons (n = 10*10)
> spplot(tmp)  # plots values of x, y, z, id in separate panels, each with
> 100 polys
> spplot(tmp, zcol=z)  # error message about duplication of factor level
> spplot(tmp ~ id, zcol=z, data=tmp)  # won't take formula
>
You can do the facetting with ggplot2::geom_sf (in the dev version of
ggplot2) though I don't think it will use different coordinate ranges for
different facets:

devtools::install_github('tidyverse/ggplot2')
library(sf)
library(ggplot2)
tmp2 = st_as_sf(tmp)

ggplot(tmp2) + geom_sf(aes(fill=z)) + facet_wrap(~id)

A couple of suggestions here, using tmap or ggspatial, that look promising:
https://stackoverflow.com/questions/47678480/mapping-different-states-with-geom-sf-using-facet-wrap-and-scales-free

Kent Johnson


> Thank you,
> ScottWaichler
> Pacific Northwest National Laboratory
> scott.waichler _at_ pnnl.gov
>

        [[alternative HTML version deleted]]

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

Re: BIG DATABASE

Thu, 05/24/2018 - 07:04
On Thu, 24 May 2018, Yaya Bamba wrote:

> Thanks to all of you. I will try with the package  RMySQL and see.

Maybe look more generally through the packages depending on and importing
from DBI (https://cran.r-project.org/package=DBI) to see what is available
- there are many more than RMySQL.

and use the Official Statistics and HPC Task Views:

https://cran.r-project.org/view=OfficialStatistics

https://cran.r-project.org/view=HighPerformanceComputing

to see how typical workflows (not necessarily DB-based) can be handled.
The HPC TV has a section on large memory and out-of-memory approaches. If
your data are spatial in raster format, the raster package provides some
out-of-memory functionality. In sf, spatial vector data may be read from
databases too.

Roger

>
> 2018-05-24 11:33 GMT+00:00 Andres Diaz Loaiza <[hidden email]>:
>
>> Hello Yaya,
>>
>> Many years ago I work with a database in MySQL connected to R through the
>> package RMySQL​. The data was stored in the MySQL and I was connecting and
>> using the data from R
>>
>> you should have a look in:
>>
>> https://cran.r-project.org/web/packages/RMySQL/index.html
>>
>> Cheers,
>>
>> Andres
>>
>
>
>
> --
Roger Bivand
Department of Economics, Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; e-mail: [hidden email]
http://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
R-sig-Geo mailing list
[hidden email]
https://stat.ethz.ch/mailman/listinfo/r-sig-geo
Roger Bivand
Department of Economics
Norwegian School of Economics
Helleveien 30
N-5045 Bergen, Norway

Re: BIG DATABASE

Thu, 05/24/2018 - 06:56
 Elisa Rose , I just wan to use some variables from a database that is
huge, without loading it, for my computer doesn't have much memory capacity.

2018-05-24 11:45 GMT+00:00 Yaya Bamba <[hidden email]>:

> Thanks to all of you. I will try with the package  RMySQL and see.
>
> 2018-05-24 11:33 GMT+00:00 Andres Diaz Loaiza <[hidden email]>:
>
>> Hello Yaya,
>>
>> Many years ago I work with a database in MySQL connected to R through the
>> package RMySQL​. The data was stored in the MySQL and I was connecting and
>> using the data from R
>>
>> you should have a look in:
>>
>> https://cran.r-project.org/web/packages/RMySQL/index.html
>>
>> Cheers,
>>
>> Andres
>>
>
>
>
> --
> Yaya BAMBA
>
> Elève Ingénieur Statisticien Economiste (ISE)
>
> Ecole Nationale Supérieure de Statistique et d'Economie Appliquée (ENSEA),
> Abidjan (Côte d'Ivoire)
>
> Tél: +225 87 89 76 89
>


--
Yaya BAMBA

Elève Ingénieur Statisticien Economiste (ISE)

Ecole Nationale Supérieure de Statistique et d'Economie Appliquée (ENSEA),
Abidjan (Côte d'Ivoire)

Tél: +225 87 89 76 89

        [[alternative HTML version deleted]]

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

Re: BIG DATABASE

Thu, 05/24/2018 - 06:45
Thanks to all of you. I will try with the package  RMySQL and see.

2018-05-24 11:33 GMT+00:00 Andres Diaz Loaiza <[hidden email]>:

> Hello Yaya,
>
> Many years ago I work with a database in MySQL connected to R through the
> package RMySQL​. The data was stored in the MySQL and I was connecting and
> using the data from R
>
> you should have a look in:
>
> https://cran.r-project.org/web/packages/RMySQL/index.html
>
> Cheers,
>
> Andres
>


--
Yaya BAMBA

Elève Ingénieur Statisticien Economiste (ISE)

Ecole Nationale Supérieure de Statistique et d'Economie Appliquée (ENSEA),
Abidjan (Côte d'Ivoire)

Tél: +225 87 89 76 89

        [[alternative HTML version deleted]]

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

Re: BIG DATABASE

Thu, 05/24/2018 - 06:33
Hello Yaya,

Many years ago I work with a database in MySQL connected to R through the
package RMySQL​. The data was stored in the MySQL and I was connecting and
using the data from R

you should have a look in:

https://cran.r-project.org/web/packages/RMySQL/index.html

Cheers,

Andres

        [[alternative HTML version deleted]]

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

Pages