Check for GEOMETRY before extract / cast.

[dblodgett-usgs]

Putting in place a check that avoids an expensive line of code that's not really needed in most cases. Related to #6.

This change shouldn't break anything -- the tests all pass. But I can't get the test data referenced in #6 to try it out. @mfherman, can you make some sample data available (without an API key)? I'll implement a test that hits that test and makes sure all's good.

[dblodgett-usgs]

Don't merge this till we find some test data that hits this. Note that my original commit (which passed all the test) should have totally broken things but just made it so those lines don't get touched.

[mfherman]

Here is the data referenced in #6 as downloaded from the Census Bureau API: areal_intersect_test.rda.zip

[dblodgett-usgs]

🎊

[dblodgett-usgs]

Using your test data, we hit those lines of code again and the behavior will not have changed in the case that the geometry type is either GEOMETRY or GEOMETRYCOLLECTION.

Out of curiosity -- before hitting this code we get:

Browse[2]> unique(sf::st_geometry_type(intersection))
[1] POLYGON            LINESTRING         POINT              GEOMETRYCOLLECTION
[5] MULTIPOLYGON       MULTIPOINT      

The sf::st_collection_extract gives us:

Browse[2]> unique(sf::st_geometry_type(intersection))
[1] MULTIPOLYGON

and the call to sf::st_cast("MULTIPOLYGON") doesn't seem to do anything.

[chris-prener]

Really appreciate your attention on this @dblodgett-usgs! I just tested your code and like the patch a lot - this is a perfect solution.

[chris-prener]

for posterity's sake - AppVeyor failed because rlang was just updated - nothing to do with the areal package.

[chris-prener]

Also @mfherman - thanks for sending @dblodgett-usgs the data so he could test this!