In the Location field on the right-hand side of the Explore page, if you select “Deer Park TX USA,” the search results are limited to the Land Feature “Deer Park Prairie,” which is a small, specific area within the city.
Desktop site
Windows 10
Vivaldi browser
[Edited to make it clear which part of which page I’m talking about.]
Can confirm this happens in multiple places.
Searching for Vancouver, BC in the location bar and clicking on it from the list returns “Vancouver Coastal Waters”, and completely ignores any of the actual land within the city.
Google Chrome 114 on Macbook Pro running 12.5.1 Monterey
Yes, I’ve noticed this “feature” many times. It’s almost seems more often than not in my county. E.g., searching San Jose, CA returns obs for only San Jose State University.
Search for Los Gatos, CA returns a single park:
Clicking Los Gatos, CA instead of Los Gatos Creek County makes no difference.
Are you aware that iNat has two different lists of locations? My understanding is that they’re defined somewhat along these lines.
If you use the Location field in the Identify dialog, this uses a list of places managed by iNat: https://www.inaturalist.org/places
If you use the Location field at the top of the Explore page, this supplements the iNat places with a list of locations sourced from Google. It’s pretty common to encounter places that are defined differently than one might expect. Any fixes to these place definitions need to be taken up through Google’s processes. There are several related discussions on the forum, such as this one: https://forum.inaturalist.org/t/how-is-accuracy-of-google-maps-locations-determined-and-can-it-be-altered/40018/6
[I may have this slightly wrong, so maybe someone can provide a clearer definition or link.]
My understanding is that iNat’s places (item 1) generally encompass countries, plus the next two lower subdivisions (e.g. states and counties), plus custom-defined places set up by iNat users. So iNat places typically don’t include individual cities. In the case of Deer Park, TX, iNat has a defined place for Harris County.
Also, those “custom-defined places set up by iNat users” include a whole lot of poorly-defined places set up by early iNat users when the platform provided a visual place editor (think of a basic rectangle that vaguely encompasses the user’s home town).
It appears that if you enter a place name that isn’t an exact match, iNat will choose whatever appears to be the best text match, which often will be one of those poorly defined custom places. I think this is behind the mismatches to Deer Park Prairie, Vancouver Coastal Waters, San Jose State University, Los Gatos Creek County Park, etc.
It does not seem that way to me. An exact match for Los Gatos, CA would be Los Gatos, CA, not Los Gatos Creek County Park. Ditto or San Jose, CA.
Now, in the dropdown list, I ~could~ choose Los Gatos Creek County Park, but I didn’t do that. I chose Los Gatos, CA instead. Still, that returned the results for the county park creek trail.
It’s just one of those eccentric features of the site.
But (as far as I can tell) iNat does not have a place for Los Gatos, CA, so that match is not possible.
Are you seeing something different?
I’ve been frustrated by that search bar in the past for this exact reason. You’d think selecting an option from the dropdown would provide that exact option, not skip down to some other option.
(I also tried selecting Los Gatos, CA from the dropdown and got the Creek County Park instead.)
There are a ton of locations for which iNaturalist doesn’t select the intuitive map area. Even if the problem is Google’s place definitions, I feel like there’s some intermediary step where things could be improved. Surely Google doesn’t define “Vancouver” as the area described by Vancouver Marine Waters.
I assume they’re seeing this:
If iNaturalist doesn’t have a place for Los Gatos, CA, and isn’t pulling one from Google but is instead defaulting to another place, why is that item showing up in the drop-down? That seems like a bug, too - either a technical bug or a design bug.
Drop-down items being presented to a user for selection should really be valid items that are respected, not invalid queries that are discarded and replaced by some opaque process.
Thanks, Rupert, but I was talking about the Location field on the right-hand side of the Explore page, not in the Identify dialog or at the top of the Explore page. I’ve edited my original post to make this clearer.
It may be that this Location field and the one in the Identify dialog use the same list of places to return search results. However, in the Identify dialog, the place selected by the user matches the place for which results are then shown. Whereas on the right side of the Explore page, the place selected by the user does not match the place for which results are then shown.
I agree that this is frustrating. It seems that the functionality in the search bar and dialogs should heavily prioritize standard, expected places (countries, states/provinces, counties, major parks/protected areas, major cities).
The ability to add custom places is useful from a community perspective, but these should be less prominent than the standard places. It seems there should also be a process to review older places and remove those that are excessively confusing and/or ill-defined.
On a related point, iNat place names should also follow a consistent convention. I don’t understand (for example) why iNat mixes up the formats County, US, State and County, State, US, and appears unable to fix it:
There’s even a Place for Vancouver, BC - two, depending on whether you mean the municipality or the metro area - and both are returned higher in the place search results than Vancouver Marine Waters (not that returning Vancouver Island would be great either, admittedly). Agreed, the prioritization with which iNaturalist picks places seems disconnected even from iNaturalist’s own Place database.
I definitely agree it could be improved, but the current system is supposed to help you get to the general area of your search, because there’s no way iNat can have as many places as Google does. You can then use any of these tools to search in your area of interest, or at least an approximation of it:
Again, everywhere but on the right-and side of the Explore page, the Location dropdown works as expected, in that it only shows options which, if clicked on, correspond to the results. By contrast, the location dropdown on the right-hand side of the Explore page shows options which, if clicked on, don’t correspond to the results, at least in the examples mentioned.
So in two places (at the top of the Explore page and in the Identify dialog), the dropdown works as expected. In a third place (on the right-hand side of the Explore page), it doesn’t.
I’m not saying all three dropdowns should show the same options, and I’m not saying they should or shouldn’t show “Deer Park Prairie” or “Deer Park TX USA.” I’m just saying that, whichever location is shown, it should corresponds to the results that are returned when it’s clicked on.
It may just be a matter of, “Oh, wow. In the one on the right-hand side of the Explore page, for some reason we used the wrong list of places. It’s supposed to be the same one that the Identify dialog uses. Thanks for letting us know. Easy fix.”
Yeah, the fact that the options do not match the results seems like a very clear bug. The fact that the databases drawn from are different from interface to interface and that the places in those lists are imperfect are complex issues, sure, but at the very least when the interface gives you an option, and you click on that provided option, the result should correspond to the thing you clicked on.
bug or not, i wouldn’t hold my breath waiting for changes to the web Explore screen. if you want to filter for Deer Park, TX, your best bets are:
if you need help with either option above, just holler…
Yes. I have Marine first if I look for Cape Town.
I have learned to use Cape Peninsula 2 (someone else had already taken 1)
To be clear, I’m not asking for iNat to have more places, let alone as many as Google. My complaint is that iNat is suggesting a very specific location (e.g., “Deer Park TX USA”) and then, when the user clicks on it, it’s returning observations for a completely different very specific location (e.g., “Deer Park Prairie”).
I realize that other iNat location tools function properly, and I’m glad they do, but I wish this one did, too.
Call it a feature or call it a bug…
True, true
