I am surprised that entering “China”, and then selecting “China”, ends up with “Chinese University of Hong Kong” selected:
Result:
Switching to the Map view and clicking on "Places of Interest":
Result:
Switching to the Map view and clicking on "Places of Interest":
I also got the same result as you.
I still reproduce it, always. Web browser Chrome, on Windows.
Whether I select the taxon or the location first, the result is the same.
I have a Windows natively in French. I chose English in my iNaturalist profile.
Could this change the way Places are listed and selected?
If I enter “Chine” (“China” in French), and select it:
The result is the same:
What happens if you try directly from Google’s geocoder API demo?
https://developers.google.com/maps/documentation/utils/geocoder
1 Like
Same, I get the country.
I can’t tell you where it’s going wrong with the information gathered so far. I can tell you how it’s supposed to work/how it works for me.
When you type in the Location box, iNat asks Google’s autocompletion service for place predictions. These can differ depending on input language and the current map location, e.g. if your map currently shows the eastern US, top results for “China” will include Chinatown in Boston. If you open Chrome’s developer tools, you can see your request URL in the Network tab.
The list you see in the drop-down in the very first screenshot at the top is the list returned by Google. Notably, while iNat shows the name and a little info in the drop-down, Google has also returned Google’s place_id with these results. Google’s place_id for China is ChIJwULG5WSOUDERbzafNHyqHZU, so when you select China from the drop-down, iNat asks Google for details about place_id=ChIJwULG5WSOUDERbzafNHyqHZU. Google returns details about this place, including coordinates for a bounding box.
iNat uses those coordinates to make a call to its own API: https://api.inaturalist.org/v1/places/nearby?per_page=1&name=china&swlat=17.99960003655964&swlng=73.49941362656182&nelat=53.56097386690806&nelng=134.7754563027819&lat=0&lng=0
This API call returns iNat’s place info, including the id (6903), which is what iNat uses to set the Explore search.
If you walk through these steps, you should be able to figure out how place_id=125119 (Chinese University) is popping up instead of 6903.
Two notes for anyone reading: issues like these are partly why it’s usually recommended to use Filters -> More Filters -> Place instead of the Location box.
Also, since Explore is currently being overhauled, it’s unlikely the developers will change current functionality.
Thanks a lot Jane!
I investigated as suggested and found where it goes wrong.
I enter “China” (in English), not “Chine” (in French), and I click on “China”:
The issue occurs first with the highlighted request above, which is:
The response is about the place “Chinese University of Hong Kong”:
“ancestor_place_ids”:[97395,125119]
Now I replace “chine” by “china” in the URL above:
The response is now about the place “China”:
“ancestor_place_ids”:[97395,6903]
At some point we switch automatically from the input “China” to the value “Chine” (because my Windows edition is in French?) and we get the place “Chinese University of Hong Kong” (starting with “Chine…”) instead of the desired place “China”.
I have something similar. I deal mostly with Caribbean islands. But in the “Explore” tab, if I try entering “Greater Antilles,” the archipelago, the only choice appears to be the name of a street in DuBois, Pennsylvania:
But in the “Identify” tab, “Greater Antilles” works as expected:
It’s something different. The issue I report is about selecting the name of a location and getting another one. In the issue you describe, you can’t select the desired location because it is not proposed at all.
Entering “atlanta” and selecting “Atlanta, Texas, États-Unis” ends up in a rectangular bounding box around Atlanta, TX, as expected.
Entering “atlanta” and selecting “Atlanta, Géorgie, États-Unis” ends up in “Atlanta City Nature Challenge”:
ancestor_place_ids":[97394,1,23,130842]
This filter in the URL above is a rectangular bounding box around Atlanta, GA, as expected:
swlat=33.64780794254266&swlng=-84.5518189370499&nelat=33.88761787877109&nelng=-84.28938897676478
→ This issue is likely reproducible even without a Windows edition in French.
In the case above, I can’t find a workaround using the “Place” filter:
I need to copy/paste the filter from the call to API:
Into an Observations search URL:
This is working as intended. There is no iNat place for Atlanta, TX (the iNat API call returns no results when restricted to a bounding box in Texas). Since there is no iNat place, iNat falls back on the bounding box provided by Google.
On the other hand, looking for “Atlanta” in a bounding box in Georgia does return an iNat place (see here). When iNat finds a place with its API, it uses that over Google bounding boxes.
In this case, it may be also worth noting that the Atlanta City Nature Challenge place isn’t just for the CNC – projects can have time restrictions, but not places. Anyone who wants to find observations in Atlanta, GA can use the CNC place.
The “workaround” you’ve posted is also working as intended. The Place search doesn’t ever return Google bounding boxes, only iNat places (that have a geometry). The iNat place for Atlanta, GA is a point-place, thus it won’t appear in the Place filter results.
So how can I “explore” the Greater Antilles?
Instead of using the box that says Location, use Filters->More Filters->Place.
@jwidness Do you agree that these cases are bugs?
- Selecting “China” in the drop down box ends up with “Chinese University of Hong Kong”.
- Selecting “Atlanta, Géorgie, États-Unis” in the drop down box ends up with “Atlanta City Nature Challenge”.
Do you reproduce the issue in the 2nd case?
The 1st case seems related to a context with a French edition of Windows. There would be no way to replace “China” by “Chine…” in an exclusively English context. And you mentioned that it works correctly for you.
No.
I agree they are not resulting in the expected and desired behavior, but I believe they are doing what the developers intended.
The issue for Chine/China is that when your computer is set to French, Google’s API returns the names of places in French.
iNat uses the long name from Google in its own API search call, but fails to find the country because the name in iNat’s database is China, not Chine. However, since it does find something in the search bounding box that has the search string “Chine” in it, it displays that result.
For Atlanta, again iNat has found a match in its database (Atlanta CNC), so that’s the result it displays.
I can think of a couple potential changes that would improve the search behavior, but it may not matter if the developers don’t want to make changes to the current Explore page and already intend to take care of it in the new Explore page.
Relevant feature request: https://forum.inaturalist.org/t/add-additional-names-to-the-same-place/5480
We agree that the overall behavior is not as desired.
I didn’t mean at all that the developper made a mistake.
A bug may be also an integration bug (good definition found here, matching our case), between iNaturalist and Google.
My opinion is that the overall process should be robust against Google’s replacement of “china” by “chine” on the fly. A possibility is that iNaturalist should overwrite the unexpected “chine” returned by Google with “china”, after the item initially displayed in the drop down list, and selected manually.
Also to be checked: is there a way to explicitely tell Google which language is being used (the language in the iNaturalist user’s profile)? This could help in another case, when, as a French user, I deliberately enter and then select “Chine”.
If the page is likely to be reworked, let’s just wait for the next major edition of iNaturalist.