extract data using POINT geometry type

michielvandijk commented 5 years ago

I want to extract data from a raster (stack) using an sf object with POINT geometry types and get the error: Error in (function (classes, fdef, mtable) : unable to find an inherited method for function ‘exact_extract’ for signature ‘"RasterLayer", "sfc_POINT"’

hence I assume this is not supported (yet). Is this correct and if so, would it be possible to add this feature?

dbaston commented 5 years ago

I suppose it's possible to add, but would there be any advantage over raster::extract ?

michielvandijk commented 5 years ago

Not in terms of speed I guess. I need to overlay around 6000 points and that runs fine with raster::extract. But for consistency it makes a lot of sense. Exactextract is SO much faster than raster::extract (even if I run the latter in parallel and therefore a fantastic addition to my GIS toolset), so I definitively favor it over raster::extract. It also has the advantage that it accepts sf objects, which are the new standard.

jeffreyevans commented 4 years ago

I would add that I am interested in line (LINESTRING) geometry as well as simple [X,Y]. I am moving package dependencies, in two packages, from velox (being depreciated by CRAN) to exactextract and have one function that operates on graphs. There is a notable speed difference in extracting lines using velox as opposed to raster::extract that I would like to replicate. For consistencies sake, it would be nice to keep raster extract operations coming from one package, even if raster is already in the current function environment (which I rarely import it).

I am also wondering if you are planning on adding any internal coercion for sp (to sf) objects? This way your package would support both spatial data standards. Even something as simple as: if(inherits(x, "SpatialPolygonsDataFrame")) { x <- sf::st_as_sf(x) }

Thanks for your work on this! I was a bit concerned when CRAN notified me that velox was be archived and that I would have to revert to raster or terra raster extract methods.

dbaston commented 4 years ago

Thanks @jeffreyevans , I'm glad you find the package useful.

Some thoughts:

if you're using this package as a replacement for raster or velox, take care that the handling of partially covered cells is correct for your application
I can see value in extending the package to cover linear inputs (where we can easily report the length of the line within each grid cell). One challenge is figuring out how to output this value, especially for an input of mixed linear-polygonal geometries. If lines are supported, then might as well add points.
I have no objection performing to internal coercion from sp to sf, as long as it's tested and doesn't add package dependencies.

jeffreyevans commented 4 years ago

Thank you for your reply. I have been using the small = TRUE argument in velox extract so, am not concerned about consistency in results with exact_extract. In fact, since you return pixel fraction, was thinking about adding an optional argument that would allow the user to set a threshold to filter out small intersections. I am thrilled that you would consider adding line geometry but can see where polylines would be an issue. Mixed geometries, in general, are a bit of a pain. However, since there is no formal simple geometry for polylines I would think that if a polyline shapefile was read that the result would be a LINESTRING or MULTILINESTRING and not POLYGON.

I believe that coercion between sp and sf can occur entirely on the sf side thus, requiring no additional dependencies. It is as simple as methods::as(x, "Spatial") to go from sf to sp and methods::as(x, "sf") for sp to sf, although there are formal coercion functions that can be directly called as well eg., sf::as_Spatial. The coercion method as is coming from the sf package so, a single-line object class check and coercion along the lines of: if(is(x, "Spatial")) x <- methods::as(x, "sf") is all that is needed and since the results of exact_extract are tabular there is no reason to ever go back to an sp class. The resulting geometry, coming from sp, should be one of: POLYGON, MULTIPOLYGON, LINESTRING, MULTILINESTRING, POINT or MULTIPOINT. Since sp does not support mixed geometry types then the issue of a GEOMETRYCOLLECTION should never occur.

Does your package reject MULTI geometries? If not, how are they dealt with? When I write functions along these lines, I tend to either reject, warn or explode MULTI geometries. The reason for this is that I find that users often do not realize that they are using multipart features and get confused by the results when things are numerically aggregated or, even worse just run with the results not realizing that they represent multipart feature aggregation.

Best, Jeff

From: Dan Baston notifications@github.com Sent: Tuesday, March 10, 2020 10:08 AM To: isciences/exactextractr exactextractr@noreply.github.com Cc: Jeffrey Evans jeffrey_evans@TNC.ORG; Mention mention@noreply.github.com Subject: Re: [isciences/exactextractr] extract data using POINT geometry type (#11)

Thanks @jeffreyevanshttps://github.com/jeffreyevans , I'm glad you find the package useful.

Some thoughts:

if you're using this package as a replacement for raster or velox, take care that the handling of partially covered cells is correct for your application
I can see value in extending the package to cover linear inputs (where we can easily report the length of the line within each grid cell). One challenge is figuring out how to output this value, especially for an input of mixed linear-polygonal geometries. If lines are supported, then might as well add points.
I have no objection performing to internal coercion from sp to sf, as long as it's tested and doesn't add package dependencies.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/isciences/exactextractr/issues/11?email_source=notifications&email_token=ACLKH7ZFGNYS7LTHKXOKOA3RGZQVZA5CNFSM4JBKIG62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOMBWKY#issuecomment-597170987, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACLKH723G7TGPCKL4RH7KPDRGZQVZANCNFSM4JBKIG6Q.

RFanalytics commented 3 years ago

Nice treatment here! I have been using terra::extract and the results are good. The only drawback is speed. My specific application is also for LINESTRING geometry type.

I have not yet had success installing velox and at this point, and I hesitate to invest the effort sinceit seems better is coming. Is there any time frame to implement LINESTRING geometry type with exactextract? My current use has runtimes in hours and I look forward to compressing this to minutes.

Thank you for the work!

AMBarbosa commented 2 years ago

Hi, I'm also using 'terra' now (which efficiently replaces both 'raster' and 'sp'+'rgdal' and is becoming increasingly used). terra::extract is much faster than raster::extract, but still not as fast as exactextractr. Would you be willing to implement the terra 'SpatRaster' and 'SpatVector' input formats too? In my experience, transition from 'sp'+'raster' was quite easy. Cheers!

dbaston commented 2 years ago

terra SpatRaster is supported and I would strongly recommend using it. I can look into SpatVector. I would not expect exactextractr to do any better than terra for point extraction, because it still needs to use terra to get the cell values. The performance advantage for polygons comes from using a different algorithm to calculate the cell/polygon overlaps.

I could see adding point support as a convenience, but even there I hesitate. What is the coverage fraction of a point? I could assign an arbitrary value of 1, but what happens when someone calls with a mixed polygon/point input? I guess I could error out on mixed data types. But if you know you only have points, then you know you can just use terra.

AMBarbosa commented 2 years ago

Actually, by this point of reading this thread, I had forgotten it was originally about implementing extraction for points :) I meant implement 'SpatVector' polygon input, as exactextractr is still visibly faster than terra::extract, at least for somewhat large polygon maps.

isciences / exactextractr

extract data using POINT geometry type #11