geo_ebird: Perform the clip of eBird records based on the exact geometry...
In adamdsmith/geobird: Query an eBird database by geography (e.g., shapefiles)

Description Usage Arguments Details Value

The general process is to conservatively buffer query_polys, identify the US counties intersecting the buffered query_polys, then query the local eBird database for records occurring in these counties. This may seem inefficient compared to querying the database directly with the precise desired buffer, and it may be, but it is often impracticable to have the entire eBird database loaded into RAM. Thus, this function pares the eBird database to a manageable size (provided you're not querying an unreasonably large area of interest) prior to doing the precise extraction of records based on the query_polys and any associated buffers. The precise extraction of records occurs on a polygon-by-polygon basis to avoid complications arising from eBird record assignment when buffered polygons overlap. Thus, the same eBird record may occur in multiple polygons depending on the buffer specification.

1
2
3

geo_ebird(query_polys, ebird_sqlite = "../Data/SE_eBird.sqlite",
  table_name = NULL, buffers = 0, which_polys = NULL,
  poly_id = "ORGNAME", projection = NULL, exclude = FALSE)

`query_polys`	`SpatialPolygonsDataFrame-class` within and around which the user wishes to extract eBird records. Currently, it is assumed that input `query_polys` are in a geographic (i.e., latitude and longitude) projection. `query_polys` must have only a single feature associated with each `poly_id`, i.e., contain so-called multi-part polygons. See Details.
`ebird_sqlite`	character string file path to local eBird SQLite (.sqlite) database file
`table_name`	character string naming the table within `ebird_sqlite` that contains the relevant eBird data. If not specified, defaults to the first table in `ebird_sqlite`
`buffers`	numeric vector (multiple buffers allowed) of the distance (km) from `query_polys` to include in the search for eBird records. Negative values are permitted.
`which_polys`	character vector of polygon names in `query_polys` for which the geographic query is desired. At least as far as default settings go (i.e., searching for specific refuges in our southeast region eBird database), only the capitalization insensitive name of the refuge or fish hatchery is required, not the full name (e.g., "piEdMonT" will perform the geographic query on Piedmont National Wildlife Refuge).
`poly_id`	character string of the column in `query_polys` that contains the name of the polygon to be used in the output.
`projection`	CURRENTLY NOT USED; character string of PROJ.4 projection arguments; see also `CRS-class`. Default (NULL) buffers based on a WGS 84 / UTM (northern hemisphere) projection in the UTM zone derived from the centroid (longitude, latitude) of each `query_polys`. See Details.
`exclude`	logical indicating whether to exclude `which_polys` from the pool of polygons in `query_polys`; default is 'FALSE', which selects uses only `which_polys` for the query

This function should also work, but is untested, with SpatialPointsDataFrame-class or SpatialLinesDataFrame-class) if a buffer is provided.

As the function currently relies on US counties to query the local eBird database, it works only for US locations. This could be expanded quite easily, however, to apply in other locations (e.g., Canadian provinces, Mexican states, etc.).

The WGS 84 / UTM (northern hemisphere) projection within which to perform the precise eBird record extraction is estimated programmatically based on the centroid (latitude and longitude) of each polygon. This should work for all US locations and most of the rest of the planet with the exception of the area around the southwestern coast of Norway and Svalbard (but it's the least of our concerns at the moment).

a data.frame of eBird records in the query_polys plus any associated buffers

adamdsmith/geobird documentation built on May 10, 2019, 5:13 a.m.