inaturalist / inaturalistapi Goto Github PK

Currently we just have a user_id in that response. Since we have a full user in the ofvs, let's have one in project_observations too so we can show who added the obs to what projects.

Compare the created_at value for Identification 5624697 in http://www.inaturalist.org/observations/2882743.json (2016-04-04T19:56:15.679-07:00) with http://api.inaturalist.org/v1/observations/2882743 (2016-04-05T09:56:15+00:00). The node API seems to be showing a created at date a few hours in the future of the real date.

observations object needs a primary key

Requested in uber ticket #23

I'm thinking something like without_term_id=12 to return all observations that have not been annotated with Plant Phenology, and without_term_value_id=13 to get all observations that have not been annotated with Plant Phenology=Flowering.

Not really sure yet what this will look like, or what we can do with the existing index. Some things I think could be useful

• Given a search of a taxon, list the counts of observations contained within containing branches. For example you searched for birds and want to see the most commonly observed bird families
• Given an arbitrary search, be able to create a taxonomic tree to browse the results with counts of contained observations at every node

Currently we can only provide leaf or species counts of observations, or counts of obs at the taxon they are ID'd to (i.e. count all obs ID'd to family), but can't get the family counts of obs ID'd to species.

- need a way to know what's new in for this user on the my observations tab
- the red chatboxes on the Me tab

and "nice to have"

- directly presentable information
  - i.e. "@kueda commented: 'get the fuck out!' on your observation"
    or "@loarie identified your observation as a stupid human"
  - this would allow us to show these updates in the news tab

Requested in uber ticket #23

on filters by datetime observed specified by a date string, e.g. /observations?on=2014-05-01. created_on is the same except it filters by datetime created.

Currently it just returns an error if you ask for scores on an observation that has a non-JPEG first photo. There aren't many of those, but there are some, which makes the CV identification tools like the iOS taxon chooser behave a bit inconsistently.

IMO, not an enormous priority since most photos are JPEGs.

I've included this link to observations within a taxon/place not represented in a complete set
https://github.com/inaturalist/inaturalist/blob/master/app/views/complete_sets/show.html.haml#L10

but while very long URLs like this work in the AP, e.g. http://api.inaturalist.org/v1/observations?hrank=species&lrank=species&place_id=1&taxon_id=40151&verifiable=true&without_taxon_id=40323%2C40325%2C40342%2C40343%2C40344%2C40345%2C40346%2C40347%2C40348%2C40349%2C40350%2C40352%2C40354%2C40509%2C40520%2C40521%2C40522%2C40523%2C40526%2C40527%2C40569%2C40614%2C40621%2C40629%2C40631%2C41143%2C41144%2C41147%2C41180%2C41182%2C41224%2C41276%2C41277%2C41301%2C41314%2C41315%2C41403%2C41406%2C41407%2C41408%2C41410%2C41411%2C41413%2C41414%2C41418%2C41421%2C41426%2C41428%2C41440%2C41446%2C41461%2C41464%2C41465%2C41478%2C41482%2C41494%2C41495%2C41496%2C41500%2C41503%2C41505%2C41509%2C41510%2C41521%2C41523%2C41525%2C41526%2C41529%2C41532%2C41534%2C41537%2C41539%2C41541%2C41543%2C41545%2C41550%2C41553%2C41558%2C41559%2C41562%2C41566%2C41569%2C41570%2C41638%2C41641%2C41644%2C41663%2C41673%2C41676%2C41691%2C41698%2C41702%2C41706%2C41708%2C41714%2C41728%2C41733%2C41740%2C41746%2C41755%2C41757%2C41766%2C41777%2C41789%2C41798%2C41799%2C41808%2C41809%2C41810%2C41815%2C41852%2C41860%2C41877%2C41879%2C41880%2C41882%2C41901%2C41970%2C41974%2C41976%2C41997%2C42007%2C42048%2C42051%2C42052%2C42066%2C42069%2C42070%2C42076%2C42077%2C42113%2C42122%2C42134%2C42161%2C42166%2C42199%2C42206%2C42210%2C42220%2C42223%2C42308%2C42310%2C42390%2C42391%2C42408%2C42412%2C42414%2C42416%2C42422%2C42426%2C42429%2C42652%2C42937%2C43101%2C43102%2C43108%2C43109%2C43110%2C43111%2C43112%2C43115%2C43116%2C43127%2C43128%2C43129%2C43130%2C43131%2C43132%2C43145%2C43149%2C43151%2C43188%2C43197%2C43335%2C43460%2C43736%2C43794%2C43840%2C43844%2C43846%2C43848%2C43997%2C44026%2C44053%2C44054%2C44055%2C44057%2C44058%2C44059%2C44060%2C44062%2C44063%2C44064%2C44065%2C44066%2C44067%2C44068%2C44069%2C44070%2C44088%2C44089%2C44090%2C44091%2C44092%2C44093%2C44094%2C44095%2C44096%2C44097%2C44104%2C44105%2C44106%2C44107%2C44110%2C44114%2C44115%2C44116%2C44117%2C44120%2C44121%2C44124%2C44125%2C44126%2C44129%2C44132%2C44148%2C44149%2C44150%2C44151%2C44154%2C44155%2C44156%2C44160%2C44162%2C44163%2C44298%2C44300%2C44306%2C44307%2C44311%2C44315%2C44316%2C44317%2C44318%2C44319%2C44323%2C44324%2C44325%2C44326%2C44329%2C44332%2C44333%2C44378%2C44387%2C44388%2C44390%2C44391%2C44392%2C44393%2C44394%2C44395%2C44396%2C44397%2C44398%2C44399%2C44414%2C44415%2C44416%2C44431%2C44432%2C44433%2C44434%2C44437%2C44469%2C44470%2C44574%2C44575%2C44576%2C44705%2C44744%2C44747%2C44748%2C44749%2C44757%2C44758%2C44759%2C44760%2C44761%2C44762%2C44899%2C44902%2C44904%2C44905%2C45044%2C45687%2C45689%2C45691%2C45708%2C45709%2C45710%2C45712%2C45714%2C45715%2C45717%2C45719%2C45720%2C45721%2C45758%2C45760%2C45761%2C45763%2C45820%2C46009%2C46017%2C46018%2C46019%2C46020%2C46023%2C46024%2C46086%2C46087%2C46092%2C46093%2C46095%2C46177%2C46178%2C46179%2C46180%2C46213%2C46215%2C46216%2C46217%2C46218%2C46219%2C46220%2C46221%2C46222%2C46225%2C46226%2C46227%2C46228%2C46229%2C46230%2C46231%2C46232%2C46233%2C46234%2C46235%2C46236%2C46237%2C46253%2C46254%2C46255%2C46256%2C46259%2C46260%2C46266%2C46272%2C46309%2C46316%2C46348%2C46352%2C46355%2C46365%2C46366%2C46368%2C46377%2C46403%2C46407%2C46415%2C46416%2C46418%2C46430%2C46433%2C46436%2C46437%2C46438%2C46445%2C46446%2C46456%2C46477%2C46487%2C46488%2C46491%2C46500%2C46503%2C46509%2C46510%2C46841%2C46883%2C46886%2C46915%2C46918%2C46994%2C47007%2C47010%2C47014%2C47049%2C47051%2C47056%2C47075%2C58393%2C59815%2C63113%2C64102%2C68093%2C74048%2C74103%2C74173%2C74204%2C74205%2C74207%2C74328%2C74359%2C74476%2C74478%2C74675%2C74677%2C74681%2C74712%2C74715%2C74719%2C74756%2C74757%2C74758%2C74824%2C74852%2C74855%2C74890%2C75053%2C75088%2C75113%2C118552%2C123070%2C148030%2C179937%2C179987%2C179988%2C179990%2C179992%2C179993%2C179994%2C179995%2C179996%2C179997%2C179998%2C179999%2C180000%2C180001%2C180002%2C180003%2C180005%2C180007%2C180008%2C180009%2C180010%2C183164%2C183166%2C197781%2C209233%2C233598%2C446640%2C520561

they don't work (trigger 500) in obs/search e.g. http://www.inaturalist.org/observations?hrank=species&lrank=species&place_id=1&taxon_id=40151&verifiable=true&without_taxon_id=40323%2C40325%2C40342%2C40343%2C40344%2C40345%2C40346%2C40347%2C40348%2C40349%2C40350%2C40352%2C40354%2C40509%2C40520%2C40521%2C40522%2C40523%2C40526%2C40527%2C40569%2C40614%2C40621%2C40629%2C40631%2C41143%2C41144%2C41147%2C41180%2C41182%2C41224%2C41276%2C41277%2C41301%2C41314%2C41315%2C41403%2C41406%2C41407%2C41408%2C41410%2C41411%2C41413%2C41414%2C41418%2C41421%2C41426%2C41428%2C41440%2C41446%2C41461%2C41464%2C41465%2C41478%2C41482%2C41494%2C41495%2C41496%2C41500%2C41503%2C41505%2C41509%2C41510%2C41521%2C41523%2C41525%2C41526%2C41529%2C41532%2C41534%2C41537%2C41539%2C41541%2C41543%2C41545%2C41550%2C41553%2C41558%2C41559%2C41562%2C41566%2C41569%2C41570%2C41638%2C41641%2C41644%2C41663%2C41673%2C41676%2C41691%2C41698%2C41702%2C41706%2C41708%2C41714%2C41728%2C41733%2C41740%2C41746%2C41755%2C41757%2C41766%2C41777%2C41789%2C41798%2C41799%2C41808%2C41809%2C41810%2C41815%2C41852%2C41860%2C41877%2C41879%2C41880%2C41882%2C41901%2C41970%2C41974%2C41976%2C41997%2C42007%2C42048%2C42051%2C42052%2C42066%2C42069%2C42070%2C42076%2C42077%2C42113%2C42122%2C42134%2C42161%2C42166%2C42199%2C42206%2C42210%2C42220%2C42223%2C42308%2C42310%2C42390%2C42391%2C42408%2C42412%2C42414%2C42416%2C42422%2C42426%2C42429%2C42652%2C42937%2C43101%2C43102%2C43108%2C43109%2C43110%2C43111%2C43112%2C43115%2C43116%2C43127%2C43128%2C43129%2C43130%2C43131%2C43132%2C43145%2C43149%2C43151%2C43188%2C43197%2C43335%2C43460%2C43736%2C43794%2C43840%2C43844%2C43846%2C43848%2C43997%2C44026%2C44053%2C44054%2C44055%2C44057%2C44058%2C44059%2C44060%2C44062%2C44063%2C44064%2C44065%2C44066%2C44067%2C44068%2C44069%2C44070%2C44088%2C44089%2C44090%2C44091%2C44092%2C44093%2C44094%2C44095%2C44096%2C44097%2C44104%2C44105%2C44106%2C44107%2C44110%2C44114%2C44115%2C44116%2C44117%2C44120%2C44121%2C44124%2C44125%2C44126%2C44129%2C44132%2C44148%2C44149%2C44150%2C44151%2C44154%2C44155%2C44156%2C44160%2C44162%2C44163%2C44298%2C44300%2C44306%2C44307%2C44311%2C44315%2C44316%2C44317%2C44318%2C44319%2C44323%2C44324%2C44325%2C44326%2C44329%2C44332%2C44333%2C44378%2C44387%2C44388%2C44390%2C44391%2C44392%2C44393%2C44394%2C44395%2C44396%2C44397%2C44398%2C44399%2C44414%2C44415%2C44416%2C44431%2C44432%2C44433%2C44434%2C44437%2C44469%2C44470%2C44574%2C44575%2C44576%2C44705%2C44744%2C44747%2C44748%2C44749%2C44757%2C44758%2C44759%2C44760%2C44761%2C44762%2C44899%2C44902%2C44904%2C44905%2C45044%2C45687%2C45689%2C45691%2C45708%2C45709%2C45710%2C45712%2C45714%2C45715%2C45717%2C45719%2C45720%2C45721%2C45758%2C45760%2C45761%2C45763%2C45820%2C46009%2C46017%2C46018%2C46019%2C46020%2C46023%2C46024%2C46086%2C46087%2C46092%2C46093%2C46095%2C46177%2C46178%2C46179%2C46180%2C46213%2C46215%2C46216%2C46217%2C46218%2C46219%2C46220%2C46221%2C46222%2C46225%2C46226%2C46227%2C46228%2C46229%2C46230%2C46231%2C46232%2C46233%2C46234%2C46235%2C46236%2C46237%2C46253%2C46254%2C46255%2C46256%2C46259%2C46260%2C46266%2C46272%2C46309%2C46316%2C46348%2C46352%2C46355%2C46365%2C46366%2C46368%2C46377%2C46403%2C46407%2C46415%2C46416%2C46418%2C46430%2C46433%2C46436%2C46437%2C46438%2C46445%2C46446%2C46456%2C46477%2C46487%2C46488%2C46491%2C46500%2C46503%2C46509%2C46510%2C46841%2C46883%2C46886%2C46915%2C46918%2C46994%2C47007%2C47010%2C47014%2C47049%2C47051%2C47056%2C47075%2C58393%2C59815%2C63113%2C64102%2C68093%2C74048%2C74103%2C74173%2C74204%2C74205%2C74207%2C74328%2C74359%2C74476%2C74478%2C74675%2C74677%2C74681%2C74712%2C74715%2C74719%2C74756%2C74757%2C74758%2C74824%2C74852%2C74855%2C74890%2C75053%2C75088%2C75113%2C118552%2C123070%2C148030%2C179937%2C179987%2C179988%2C179990%2C179992%2C179993%2C179994%2C179995%2C179996%2C179997%2C179998%2C179999%2C180000%2C180001%2C180002%2C180003%2C180005%2C180007%2C180008%2C180009%2C180010%2C183164%2C183166%2C197781%2C209233%2C233598%2C446640%2C520561

is there a way to remedy this? I believe we had this problem with project search params that we solved by replacing with a smaller URL param

E.g. responses to /v1/taxa/12345 should include

• user who added it
• user who last updated it
• datetime it was added
• datetime it was updated
• name of the provider / source
• link to provider / source

so we can display this on the taxon page. Note that provider stuff are present as columns in the taxa table, while Sources are in another table.

Patrick recommends stuffing these things in the ES index since it doesn't change much and configure ES not to index those attributes, just return them.

Some more notes from Patrick:

what I've tended to do for some user stuff is add a simple representation of the user to the index (just ID and login, usually for search), then use methods like ESModel.fetchBelongsTo to fetch full users from the ES index using the IDs at query time (edited)

it's all a little hacky right now, but generally I try to lookup models once. For example in https://github.com/inaturalist/iNaturalistAPI/blob/master/lib/models/observation.js#L82 it's loading users for many different instances so it all happens in a single query. We're making those User calls anyway for most requests (not sure about taxon show though)

To show rarities within search params.

E.g. so API consumers can know the photo was taken by Joelle, and that she has released it under a CC-BY-NC license.

It looks like when I fave something via the rails api, it takes a minute to show up in the node api.

This is problematic for the iOS app if we're displaying an observation from the node api, want to add a fave to that observation by making a request to rails, and then expect to refresh from the node api and populate our UI showing the user that the fave has happened.

I haven't looked to see if this same behavior is exhibited to other interactive actions on observations, like adding a comment or an identification or etc.

Iconic taxon IDs are specific to individual instances of the database, while names should be universal. This makes it awkward to use iconic taxa from endpoints in our API because a client has to hardcode mappings from IDs to names in code (e.g. {1: "Animalia"}) which will break when connecting to a different database (e.g. a local development database), or it has to make another request to get more info about those IDs. Including the names would allow clients to use those categories without having to figure out what the numbers mean.

So my proposal is to always include the iconic taxon name every time we show an iconic taxon ID. Maybe this is more of an issue for the Rails app where the ES index gets populated, but I imagine some change will have to be made here too.

This is something @budowski requested in inaturalist/iNaturalistAndroid#134, but I feel like I've also run into it while working on obs search and the identify section.

to avoid re-fetching the observation for details view

Requested in uber ticket #23

{"error":"[search_parse_exception] No mapping found for [created_at] in order to sort on","status":400}

I'd like an api / obs_search_url param for not equal to a term_value_id (e.g. term_value_id is NULL or != the term_value_id) - something like
http://www.inaturalist.org/observations?place_id=any&subview=grid&term_id=9&term_value_id_not=11&order_by=votes
which would return all observations except those with term_value_id = 11

for projects that are attached to places that have bounding boxes, it would be great to know the bounding box. if we had this, when a user searched in the explore tab for a project, we could zoom the map to show the project boundaries. as the api currently exists, we can only zoom the user to the center of the project, since all we have now is latitude/longitude.

something like this would be required to fully satisfy this iOS issue: inaturalist/INaturalistIOS#149

needed to query user for # of obs & IDs for Me tab header

Requested in uber ticket #23

https://www.inaturalist.org/observations/upload isn't returning the https://www.inaturalist.org/observation_fields?utf8=%E2%9C%93&q=observed+by&commit=Search field

http://api.inaturalist.org/v1/observations?taxon_id=120720&per_page=1&return_bounds=true

returns:

total_bounds: {
swlat: 0,
swlng: 0,
nelat: 48.29173003323376,
nelng: -114.05738635919988
}

and http://api.inaturalist.org/v1/observations?taxon_id=42220&per_page=1&return_bounds=true
returns:

total_bounds: {
swlat: 0,
swlng: -135.98853785544634,
nelat: 62.13262579869479,
nelng: 0
}

it would be great to get the wikipedia summary in taxon objects returned by the API.

if possible, it would be great to get the summaries whenever ?details=all is passed into the observations API, so that when I fetch observations I don't need to re-fetch the taxon objects when i display the taxon screen in the app, since this part of the app typically functions when the app is offline.

Part of the way at https://github.com/inaturalist/iNaturalistAPI/commits/histograms. Requirements are:

• ability to get counts of observations grouped by month
• ability to get counts of observations grouped by year-month

Would be nice to specify the kind of grouping for both of these. Though Patrick's current approach of showing numerous groupings at once could also work.

In response to http://api.inaturalist.org/v1/observations we'd get something like

{
  total_results: 4131950,
  page: 1,
  per_page: 30,
  bounding_box: {
    nelng: 1,
    nelat: 1,
    swlng: 0,
    swlat: 0
  },
  results: [
    ...
  ]
}

This would let us do some thing things like zoom the map appropriately on the taxon page.

from @loarie

"probably only represents .00001% of obs so prob not worth fixing, but for the record looks like 'unknown' 'obscured' markers aren't transparent"

In order to show a feed of updates in the iOS app, we'll need to start being able to request all updates on my content, not just new updates. It would be great to see:

• /observations/updates returns all updates on my content
• /observations/updates accepts some kind of created_after (either a date or another update id) parameter
• /observations/updates returns a viewed boolean indicating whether the user has seen this update or not (useful for making notifications and other UI stuff)

- instead of just a list of Project IDs
- to avoid having to make separate calls to get Project details

Requested in uber ticket #23

Right now, when we fetch a project directly, such as http://api.inaturalist.org/v1/projects/642, we get the location information as latitude and longitude fields. However, when we get a project as part of an observation, such as http://api.inaturalist.org/v1/observations/7223196, we get the location information as a comma separated location field.

It would be great if these could be the same, so every time we get a project from the API, we can use the same mapping to parse it.

Currently /observations/updates returns updates on all observations the authenticated user is subscribed to. It would help to filter these to show only updates on the authenticated user's own content.

• add an observartions_by parameter to /observations/updates that adds a filter that only shows updates on the authenticated user's observations
• fix the docs (they currently say that filtering occurs by default)

endpoint that takes taxon_id and place_id array (as well as other obs search params, e.g.
api.inaturalist.org/v1/observations/choropleth?places=14,12&taxon_id=2041&verifiable=true…
and returns observation counts by places in the array. All I need at the moment is place_id, obs_count, e.g.:

{
  "total_results": 357,
  "page": 1,
  "per_page": 357,
  "results": {
    "places": {
      "13": 7,
      "15": 30,
      "16": 41,
      "18": 52,
      "31": 97,
      "54": 90,
      ...
    }
  }
}

but it might be wise to include the place object in the response if we wanted to anticipate other uses, e.g.:

{
  "total_results": 494,
  "page": 1,
  "per_page": 494,
  "results": [
    {
      "place": {
           name: "California",
           id: 14,
           ...
      },
      "observations_count": 10,
    },
    ...
  ]
}

Kind of surprised we don't have them already! Should be included in /v1/observations and /v1/observations/:id

In order for a client to know if the current user has marked an observation as captive, the client needs to know whether the current user has created a QualityMetric record for the wild metric. If it's too much data to load, then something analogous to the reviewed_by attribute would suffice, but wouldn't be ideal since the client couldn't distinguish between yes, no, and no vote. I don't think I need this in GET /observations, just GET /observations/[ids]

http://apibeta.inaturalist.org/taxa/autocomplete?q=%E5%8B%95%E7%89%A9%E7%95%8C

Seems like it might only be Kanji characters, b/c the following all work

• http://apibeta.inaturalist.org/taxa/autocomplete?q=%D0%96%D1%8B%D0%B2%D1%91%D0%BB%D1%8B
• http://apibeta.inaturalist.org/taxa/autocomplete?q=%D0%96%D1%8B%D0%B2%D1%91%D0%BB%D1%8B
• http://apibeta.inaturalist.org/taxa/autocomplete?q=Animals
• http://apibeta.inaturalist.org/taxa/autocomplete?q=%D8%AC%D8%A7%D9%86%D9%88%D8%B1%D8%A7%D9%86
• http://apibeta.inaturalist.org/taxa/autocomplete?q=%E3%82%A2%E3%83%A6

At least test it. The query to load this count to put it into the index is slow, and we might be able to do it at query time reasonably fast and save the indexing overhead. Alternatively, refactor how we fetch the count so there's minimal cost at index time

We'll need more info for the new taxon page, namely:

• ancestors
• children
• taxon names
• conservation statuses
• listed taxa / establishment means
• at least 9 TaxonPhotos associated with this taxon and/or its descendants, including URL, attribution, and the taxon they're associated with (useful if it's a descendant)

Include dimensions for at least one photo in the /v1/observations response so clients can perform layouts without actually loading the photo to check it (e.g. flickr-style photo layouts, masonry, etc).

needed to show private coordinates

Requested in uber ticket #23

needed to populate the News tab

Requested in uber ticket #23

At https://github.com/inaturalist/iNaturalistAPI/blob/master/lib/controllers/v1/observations_controller.js#L547 we don't pass dateRangeFilter() a date field like we do when interpreting d1, which means requests like http://api.inaturalist.org/v1/observations?created_d1=2017-06-01 don't quite work the way you might think. Was this intentional, and if so, why? I can change this, but I want to make sure I'm not breaking something.

As part of my work to replace Reskit/CoreData with Mantle/Realm, I'd like to use the node API for pretty much everything in the app, so the transition sorta becomes RestKit/CoreData/Rails -> Mantle/Realm/Node.

Really Kinda Need It

• authenticated GET observations with private data fields
  • needed to show private coordinates
• UUIDs for uploadables
  • observations object needs a primary key
• GET /users/:id needs to return a full user object
  • needed to query user for # of obs & IDs for Me tab header
• Project and Site News Posts, the feed for logged in & anon users
  • needed to populate the News tab
• something like GET /users/new_updates.json
  • need a way to know what's new in for this user on the my observations tab
  • the red chatboxes on the Me tab
• a way to learn about server-side deletions
  • like the "X-Deleted-Observations" header from rails

Nice to have

• GET /users/new_updates.json improvements
  • directly presentable information
  • i.e. "@kueda commented: 'get the fuck out!' on your observation"
  • or "@loarie identified your observation as a stupid human"
  • this would allow us to show these updates in the news tab
• Comments, Identifications, and Faves in GET /observations? list view
  • to avoid re-fetching the observation for details view
• Full projects in observations
  • instead of just a list of Project IDs
  • to avoid having to make separate calls to get Project details

in /observations/:id, it would be helpful to the iOS app to have:

• an icon for the taxon object
• identifications, including:
  • user.id
  • user.icon
  • user.login
  • taxon.id
  • taxon.icon
  • taxon.common_name
  • taxon.scientific_name
  • body
  • datetime
• faves, including:
  • user.id
  • user.icon
  • user.login
  • datetime

I forgot to mention when we were talking, that in the iOS we're also identification.current, which I think is just shorthand for "is this the most recent observation by this user?" so we could probably calculate it on the client side if need be.

Thanks!

something like -- https://api.inaturalist.org/v1/observations/species_counts?page=2

API doesn't seem to get the page param -- other params are working... just not "page"

E.g. http://www.inaturalist.org/observations/339073 and its display at http://www.inaturalist.org/observations?utf8=%E2%9C%93&q=&search_on=&quality_grade=any&reviewed=&identifications=any&captive=&place_id=&swlat=36.74864635797473&swlng=-122.33892225585942&nelat=37.02324629220921&nelng=-121.89946913085942&taxon_name=&taxon_id=&day=&month=&year=&order_by=observations.id&order=desc&rank=&hrank=&lrank=&site=&tdate=&d1=&d2=&filters_open=false&view=map

I was able to fix this by changing https://github.com/inaturalist/iNaturalistAPI/blob/master/lib/inaturalist_map_styles.js#L105 to something like [private_location > 0] and including private_location in the fields retrieved from ES, but I couldn't figure out how to strip private_location out of the .grid.json responses.

Or equivalent.

• return paginated list of all ProjectUsers in the project by default
• support a role param that can be be curator to return all curators, managers, and the owner (all have curator privileges) and manager to return just the managers and the owner`
• document

Requested in uber ticket #23

Recent taxa mostly works, e.g.

place_id=2319
url = "http://api.inaturalist.org/v1/identifications/recent_taxa?place_id=#{place_id}&category=improving,leading&hrank=species"
uri = URI(url)
response = Net::HTTP.get(uri); nil
dat = JSON.parse(response); nil
dat["results"].map{|a| a["identification"]["observation"]["id"]}.uniq[0..10]
 => [6909037, 6908870, 6842626, 6842589, 6842401, 6122400, 365437, 6066024, 6066124, 6012523, 6048083]

but occasionally returns identifications that seem to be of commonly observed species (rather than 'firsts'), for example those IDs on these obs:
http://www.inaturalist.org/observations/6842626
http://www.inaturalist.org/observations/6842589
http://www.inaturalist.org/observations/6842401

Any idea why this is happening?

@alexshepard was trying to include the true coordinates of observations in the iOS explore tab for your own observation (see inaturalist/INaturalistIOS#137 (comment)) and ran into this problem: if you use the API to make an authenticated request for obs in a bounding box and you have an obs with private coordinates inside the bounding box but public coordinates outside of it, you don't get that observation back in the response, b/c we use public coordinates for bounding box queries: https://github.com/inaturalist/iNaturalistAPI/blob/master/lib/controllers/v1/observations_controller.js#L504

Here's an example request on the website: http://www.inaturalist.org/observations?nelat=37.782408483538376&nelng=-122.46629903639223&place_id=any&swlat=37.78124254829675&swlng=-122.46964911545183&verifiable=any

That doesn't include http://www.inaturalist.org/observations/6093011 for alex when he's authenticated as himself.

Not entirely sure this is a bug, but it seems like you should at least be able to include your own observations. Alex pointed out that we could theoretically overselect by using the private_geojson and removing all the obs the authenticated user doesn't have permission to see, but that may or may not be performative.

like the "X-Deleted-Observations" header from rails

Requested in uber ticket #23