Allow download of project curator ID fields from traditional projects via the main Export Observations page

Feature Requests
2

i think these other conversations sort of cover similar ideas:

regarding workarounds, while it is possible to get individual identifications associated with an observation via the current v1 Node.js API or to get just curator IDs via the old Rails API, i don’t think the APIs are really designed to handle sets of observations that are as large as you’re talking about here (approaching 200,000 records). that said, i don’t know of any other reasonably efficient way for folks without direct access to the database to get this kind of data.

suppose you were able to get the data in the format you’re looking for. how exactly would you use that data? (for example, if a given observation had an identification by a curator that conflicted with the community ID, i assume you would take the curator’s ID. but what if two curators provided conflicting IDs?) also, why do you need to export all that data? are you saving that off somewhere just for backup, or are you feeding it into some other system or something else?

i don’t usually have a use for getting the true coordinates of obscured observations – so i haven’t really dealt with exporting these much – but i believe that if you just use the standard export page, and include private coordinates in your selected fields for export, then you should be able to filter as much as that page will allow you to filter.

EDIT: i read your original post again with rested eyes, and i think i understand it a little better. clicking “Export with Hidden Coordinates” on a traditional project page produces a CSV file with not only hidden coordinates but also extra curator ID columns. so you want those extra curator ID columns to be selectable/available in the regular export page.

i guess the standard export page would have to be able to check to make sure that you’re a curator for any selected project, although i have seen where the page changes the selectable observation fields based on project selected. so it must be possible to add that kind of logic.

i’ve never used the curator ID functionality before. so i’m still having trouble conceptualizing what kind of workflow you would have with those kinds of results. you mentioned that you want to potentially go back and scan for changes/updates to the curator IDs. but why does that matter? is it just that a particular observation gets any curator to look at it, or is more important that a curator is reidentifying a particular observation?

1 Like