idigbio: HTTP failure: 400

[Cactusolo]

Hi,

I got the same error:

tt <- occ(geometry = site.range[[1]][1], from = c("gbif", "idigbio", "inat"), has_coords=TRUE) Warning messages: 1: idigbio:
2: idigbio: HTTP failure: 400 Error message from API server: {"error":"Terms not found in index for type records","statusCode":400,"name":"TermNotFoundError","terms":["geopoint.1"]}

Is it possible that "spocc" have a function at backstage to convert wkt format polygon into the right format to "idigbio"? otherwise the global "occ" function lose the meaning being integrative with all these different databases?

BTW, inat seems can not recognize terms of "Tracheophyta" and "Magnoliophyta' etc?

tt <- occ(query="Magnoliophyta", geometry = site.range[[1]][1], from = c("gbif", "idigbio", "inat"), has_coords=TRUE) Warning messages: 1: inat: No records returned in INAT for Magnoliophyta 2: inat: no results; either no records or entered an invalid search 3: idigbio: No records returned in iDigBio for Magnoliophyta 4: idigbio: HTTP failure: 400 Error message from API server: {"error":"Terms not found in index for type records","statusCode":400,"name":"TermNotFoundError","terms":["geopoint.1"]}

Thanks!

[sckott]

Can you please share your sessionInfo() (or devtools::session_info()) as requested, thanks

[Cactusolo]

Can you please share your sessionInfo() (or devtools::session_info()) as requested, thanks

sessionInfo() R version 3.6.0 (2019-04-26) Platform: x86_64-w64-mingw32/x64 (64-bit) Running under: Windows 10 x64 (build 16299)

Matrix products: default

locale: [1] LC_COLLATE=English_United States.1252 LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C
[5] LC_TIME=English_United States.1252

attached base packages: [1] stats graphics grDevices utils datasets methods base

other attached packages: [1] spocc_0.9.0 ridigbio_0.3.5 rwkt_1.0 jsonlite_1.6 stringi_1.4.3 stringr_1.4.0

loaded via a namespace (and not attached): [1] tidyselect_0.2.5 purrr_0.3.2 lattice_0.20-38 V8_2.2
[5] colorspace_1.4-1 htmltools_0.3.6 yaml_2.2.0 rlang_0.3.4
[9] later_0.8.0 pillar_1.4.0 httpcode_0.2.0 glue_1.3.1
[13] sp_1.3-1 plyr_1.8.4 rgeos_0.4-3 munsell_0.5.0
[17] gtable_0.3.0 htmlwidgets_1.3 mapproj_1.2.6 httpuv_1.5.1
[21] wellknown_0.5.0.9100 crosstalk_1.0.0 curl_3.3 triebeard_0.3.0
[25] urltools_1.7.3 rvertnet_0.7.0 Rcpp_1.0.1 xtable_1.8-4
[29] promises_1.0.1 scales_1.0.0 oai_0.2.2 wicket_0.4.0
[33] leaflet_2.0.2 mime_0.6 ggplot2_3.1.1 digest_0.6.19
[37] dplyr_0.8.1 shiny_1.3.2 grid_3.6.0 rebird_1.0.0
[41] rbison_0.8.0 tools_3.6.0 magrittr_1.5 maps_3.3.0
[45] lazyeval_0.2.2 tibble_2.1.1 crul_0.7.4 crayon_1.3.4
[49] whisker_0.3-2 pkgconfig_2.0.2 data.table_1.12.2 xml2_1.2.0
[53] lubridate_1.7.4 assertthat_0.2.1 geoaxe_0.1.0 httr_1.4.0
[57] rstudioapi_0.10 rgbif_1.3.0 R6_2.4.0 compiler_3.6.0

[sckott]

those examples aren't reproducible - what is site.range[[1]][1]

[Cactusolo]

those examples aren't reproducible - what is site.range[[1]][1]

Sorry, it's multipolygon from a list of a few sites. You can replace "site.range[[1]][1]" with other names.

site.range[[1]][1] <- "MULTIPOLYGON(((-80.52762413623942 37.37913451685481,-80.51511425590691 37.37698227937825,-80.51760278048918 37.35991570876333,-80.52701881944914 37.35355988246536,-80.52785953721342 37.37087866840957,-80.525539156184 37.37284594797798,-80.52920468563627 37.376343333877394,-80.52762413623942 37.37913451685481)))"

[sckott]

thanks for that.

For the first issue about idigbio, read the docs for ?occ in the section "Geometry options by data provider" - idigbio only supports bounding box passed to geometry - and not WKT, e.g.,

occ(from = "idigbio", geometry = c(-120, 40, -100, 45), limit = 10)

For the second issue about inat, similarly for idigbio, only bounding boxes are allowed, not WKT.

let me know if you can get it to work now

[Cactusolo]

Thanks for your answer!! It's a little disappointing! BBbox is far less accurate than the real polygon itself.

All the databases should speak one universal query language and output the same, which is really healthy for downstream data integration.

It turned out that I used 10-km radium range, and then used QGis "clip" those points outside the polygon. Need to note that ploygon works perfectly in GBIF portal using R.

[sckott]

That would be great if they all worked the same way, but I am not in charge of any of the data sources, so we are stuck with doing our best