Searching for observations in a city returns observations for a specific land feature within the city

General
22

So I tried to dig into this a little deeper, using the example of Deer Park, TX, (although I think the issue is similar for Vancouver, BC, San Jose, CA, Los Gatos, CA and most of the other examples mentioned).

There is currently no iNat place for the city of Deer Park, TX. Using an API search I retrieved a list of 12 places with Deer Park in their names. The “Places” search in the UI turns up 26 places, and the distinction seems to be that the latter includes places with variants of “Deer” and “Park” in any order.

Out of the 12 Deer Park places returned via in the iNat API, there are 5 Open Spaces, 3 Land Features, 1 Miscellaneous and 3 other without a designated type. None of the places seems to be a “standard” iNat place, but three of them were created from data imports.

As an example, one of these imported places is just named “Deer Park” (or “Deer Park, CA, US” as its display_name) and was imported from the Merced County GIS Information Portal on June 30, 2009. This has place ID 5001 and tends to be the first item retrieved. So far, so confusing…

Notably NONE of these places is named “Deer Park TX USA”. When you type that text into the Location box on the upper right of the Explore page, you’re getting a list of possible locations from Google. In other cases, selecting one of these Google locations does something useful for the user, either:

  • It manages to translate the Google location to the correct iNat place and show the right list of observations. Try “Pasadena, TX, USA” for example.
  • Alternatively, it performs an observation search using a Custom Boundary rectangle that presumably is based on the Google location. Try “Park Place, Houston, TX, USA” for example.

OK, so why does selecting “Deer Park TX USA” result in a list of observations in “Deer Park Prairie”? Here’s my speculation:

  1. Something is going wrong (i.e. there a bug) in the decision-making process that worked OK with Pasadena and Park Place above. Maybe the location info that iNat gets from Google for “Deer Park TX USA” breaks some iNat code.
  2. iNat is therefore falling back to using an internal iNat place that approximates to the search text and coming up with “Deer Park Prairie”

In support of my hypothesis for step 2, I’ll note that if I try to search for an iNat place named “Deer Park TX USA” I get no results, but if I progressively truncate my search text, then this search…

https://www.inaturalist.org/places/search?utf8=%E2%9C%93&q=Deer+Park+TX&commit=Search

brings back two results and the first one is “Deer Park Prairie”.

I think the problems with all these mismatches are caused by a combination of data (iNat and Google) and iNat coding logic, but teasing them apart is a challenge. And even if we knew exactly how these mismatches are occurring, we likely won’t be able to fix custom places that were created by inactive iNat users.

I think @pisum’s solution of creating your own custom place as an override may be the best approach for some of these situations.

3 Likes
23

fundamentally, the issue is that the Location box tries to do too much. it tries to get an iNat place and fall back to a Google Place if no iNat place is found, but it tries to get an iNat place by showing you a list of Google places and matching your selection back to an iNat place. that matching is meant to be a convenience, i think, but as there are more iNat places created, the matching just becomes more and more problematic. there’s just not any matching algorithm that will reliably match (or not match) as a human would 100% of the time, even if you take into account the underlying geometries.

the only way to reliably resolve the matching issue (and other related issues) is to eliminate the matching process altogether. this means either (1) dropping the ability to filter by Google places altogether (as is done in the Identify screen and in the Android app), or (2) changing the Location input box (and the related More Filters > Places input box) to force the user to explicitly specify whether they want to select and filter on either an iNat place or a Google place.

there’s been talk of revamping the Explore web page for years, and one of the choices i outlined above should be implemented as part of such a revamp, but until that revamp happens, i wouldn’t expect this to be addressed.

7 Likes
24

Thanks @pisum. That helps me understand what’s happening behind the scenes here. I agree that either of those two fixes or a refinement of them would likely be preferable to the current situation.

I think iNat should also implement a community-driven means to fix or remove custom places. The current approach of allowing individuals to “own” the custom places they created doesn’t really work well for the site or for other users. This could be paired with some guidelines to cover what types of places are appropriate, naming standards, hierarchy principles, how to choose boundaries that are sufficiently accurate but not excessively processor-intensive, etc.

It’s sad that the best solution to a problematic UI and messy config data is to create additional custom places and add more data to the mess.

4 Likes
25

My bug report was closed as being a duplicate of this issue, so I’ll copy in my experience here to keep all the info in a central place. I disagree with @tiwane 's change in thread status that this is indeed a bug. A supported feature has a broken experience in some cases, as described by others above and by myself below. Whether or not this gets selected for dev work, it should still be classified as the bug it is.

Platform: Website

Browser : Firefox, version 115.0.2

Screenshots of what you are seeing:

Waltham High School outlined in orange
Waltham High School outlined in orange1173×700 135 KB

Description of problem:

When searching my observations I use the search box to submit “Waltham, MA”. I expect it to draw a box around the city of Waltham (or an approximation of the city boundaries), however it instead draws a box specifically around Waltham High School. Any attempt to search the city at large always auto-narrows down to the high school.

Step 1: Go to “My Observations” (could be your own, or to mine, windrifter)

Step 2: In the search box, type in “Waltham, MA” and wait for the options provided by Google to load. Select “Waltham, MA”.

Step 3: Observe that iNat draws a box around the high school instead of the whole city.

As the location appears to be provided (or suggested) by Google, the expectation is the iNat borders would match what Google Maps returns for the same search. Either that, or there would be an override, setting a “custom boundary” that’s essentially a rectangle covering the area, but which doesn’t draw the specific city borders. See screenshot for Google Maps’ version of Waltham, MA:

City of Waltham, MA, USA with dotted red border outline
City of Waltham, MA, USA with dotted red border outline1593×913 211 KB

As you can see, there’s a wide discrepancy between what the two maps display for area boundaries (The iNat search fits between “North Waltham” and “Bentley University” on the Google Maps version).

I tried searching a few cities surrounding Waltham, just to see if it can be replicated for other localities. It appears this also happens with Weston, MA, which narrows to Weston Reservoir Woods.

2 Likes
26

{Edit}
Let me get this straight… here we have a problem that really aggravates a lot of people, to the point that they put the word “feature” in quotation marks, and somehow it is “off topic” to disagree that it “doesn’t seem like a bug”?

I’m not sure “off topic” was the real motivation for flagging this.

28

I flagged it because a) this topic is about the issue with Explore, not about whether this was a bug, which is more of a Forum Feedback topic, and b) because it didn’t add anything constructive to the conversation. I chose the former reason when adding the flag.

If you have something to add to the conversation about how Location search works in Explore, that’s fine. If you have a specific problem with or feedback about a moderation decision, that’s fine as well, although should be made in Forum Feedback, and please explain why you think a decision was incorrect.

A post that just says “Maybe not to you…” does not add anything constructive to the conversation, even if the conversation had been about a moderation decision. There’s nothing specific about it, it’s just insinuation. If you have a specific accusation or criticism, please make it or send a direct message asking for clarification or providing feedback. Saying “I’m not sure “off topic” was the real motivation for flagging this.” is more insinuation.

Back to the original topic.

A “bug,” at least as defined here on the Forum, is when “something is not working the way it is intended to.”

The issues brought up here are definitely confusing and need improvement, but the software is working as intended: you enter text into the Location field, it searches Google and shows results in the dropdown. You click on a result and iNat tries to match it with an iNat place and, if it can’t, it draws a boundary in the area it gets from Google. The idea is to get you to the general area you’re interested in and then you can use other tools once you’re there, as I explained above. @pisum explained the intent and the problem very well above.

I’m not a dev, but coding-wise they’re pretty different because in the case of a bug, the intention and design are already decided, and it’s just a technical error that we need to fix (although the fix might be difficult). In the case of this search functionality being confusing, or needing improvement, that involves more thought, discussion, possibly design, testing, etc. So the approaches are different.

I think a lot of this could be solved by allowing users to search by polygon (either freely drawn or via KML upload or something), and have that polygon search be usable for a project - those are the two biggest reasons people add places, I believe. Then there wouldn’t be a “place” that needed creation. Easier said than done, of course.

FWIW, if anyone wants to export data from GBIF they have a nifty polygon drawing tool you can use.

I hear the expectation part for sure. I’m pretty sure we just get some coordinates and not much else, but I could be wrong. We definitely don’t get boundaries like the one shown in your screenshot.

1 Like
29

@tiwane:
I’m not a dev, but coding-wise they’re pretty different because in the case of a bug, the intention and design are already decided, and it’s just a technical error that we need to fix (although the fix might be difficult).

I am a dev & I’ve coordinated extensive software testing with specialist services, and this is indeed a description of a bug. More specifically, it would be considered an edge-case bug–one which surfaces only when certain, uncommon circumstances are met but does not break the overall feature. For example, if you’ve ever seen a website display ' instead of ' in a block of text where something like, “I've got a lovely bunch of coconuts” becomes “I've got a lovely bunch of coconuts.” The rest of the sentence is displayed, but the apostrophe character was not converted properly. Even though the sentence can be read, there exists a bug. Similarly in this case, even though a search can be executed, its result is not what the user expects.

Without knowing the backend logic for how those borders are drawn, it seems like there are some areas–like the high school I linked–that override the search value submitted in favor of over-narrowing rather than over-broadening. To extrapolate the issue to a larger visual, it would be like submitting a search for San Francisco, and being forced into a view that only shows the Golden Gate Park, to the exclusion of the rest of the city.

For the sake of tracking things that are not working properly, it should be tagged as a bug. Otherwise it’s lost in the abyss. Whether or not it is selected for development is outside the scope of this comment, but it does need to be classified as something that isn’t fully functioning.

A feature request based on my experience in interacting with this bug would to have someone clicking the “x” to trigger the “Redo search in map” action (which by itself is a wonderful feature). As it stands, clearing that search area resets to “The World”. edit: scrap this feature request idea; it’s a bad one.

6 Likes
30

arguing over classification of the issue is unlikely to get changes done any faster.

i don’t think the “abyss” part is really true here. i’d be surprised if this isn’t already on the list of the things to do when the Explore web page is finally revamped, and i’d be surprised if this kind of change would be considered separately from the future revamp. if anything is holding back work on this, it’s prioritization of existing projects, not classification as a bug vs feature request.

in the meantime, if anyone needs help creating a place in iNat or figuring out how to filter by a box or circle, please don’t be afraid to ask.

5 Likes
31

Correct, this is definitely one of the top things we’d like to improve when we revamp the Explore page. The Explore page is written in Angular, and since then we’ve been using React when building new pages since then (eg Identify), we’d like to rewrite Explore in React before making big changes. Currently most development is focused on rewriting the iNat mobile app.

I’d push back on the term “forced”. There are options to redo the search in the area shown on the map in your browser (and you can zoom and pan to change that view), you can look for existing boundaries in the current map by clicking on Places of Interest, or you can draw a rectangle or circle on the map. Some of these are a bit kludgy for sure, but they provide multiple options to help you search in a defined area.

1 Like
32

While there are definitely times when I would love to have a polygon search capability within the iNat interface (so don’t cancel those plans!), I think that’s just a small piece of resolving the Google location vs. iNat place issues identified in this thread. It seems there are at least six problems involved:

  1. Some aspects of iNat (e.g. defining a project) encourage users to create new iNat places unnecessarily.
  2. These custom places, with minimal control over quality of naming and boundaries are then surfaced in many places throughout iNat.
  3. The proliferation of places is reportedly a major cause of processor usage for iNat and therefore has cost and performance implications.
  4. While custom places are universally visible, they are editable only by the user who created them, so there is no process to improve their quality and consistency and no mechanism that would allow for such a process.
  5. In pursuit of better usability, iNat also incorporates Google locations in some parts of the UI, but it’s unclear to users which fields use Google locations and which use iNat places and how these interact.
  6. iNat’s logic of translating between Google locations and iNat places generates unexpected outcomes and it’s unclear to users why this is happening or how to fix it.

The polygon search capability would go some way towards addressing problems #1 and #2. I feel that a full solution would also need to include an expansion of the hierarchy of standard iNat places and a thorough review (and pruning) of custom places. Given the effort involved, it seems that opening that process up to community input (fixing problem #4) might be the best way to make progress. If a future iNat supports polygons for searches and defining project boundaries, then a custom place used only for a project boundary could be substituted with the equivalent polygon and deleted from the place database.

I don’t know enough about how the complexity of boundaries and number of custom places factor into the processor load, but I can imagine it could be beneficial to limit the precision used in defining places if that allows iNat to support a more granular hierarchy of standard places.

Ultimately, users want to be able search for deer in Deer Park, TX, Vancouveria in Vancouver, BC and sandpipers in San Jose, CA without drawing borders on a map every time. The standard places (country, state, county) are great for this type of search, and it seems many of the challenges are caused by the legacy of trying to automate a mechanism to extend that to various lower-level geographic entities.

8 Likes
33

I came across one of these yesterday. I don’t even remember what place I was searching for on the “identify” tab, but whatever it was, nothing resembling it came up as a choice. Among the choices that did come up, though, was:

Atlantic coast of Nicaragua/Northeastern coast of Honduras to Southern Cuba/West Jamaica

Now that is a very specific place! I decided to go with it, though, since it shares flora and fauna with places I am familiar with.

Among other highly specific, custom places which come up as choices:

Coastline of Traditional Chumash Homelands
Willamette Valley Prairie Terraces, OR, US
Macnamara Field Naturalists (which seems to be near Ottawa)

That last one makes me wonder if these places were created for projects originally, and then propagated out so that they come up in the “Location” search box.

1 Like
34

Another instance:
From Observations · iNaturalist, searching for “Corsica” (the French Mediterranean island) turned nothing.
Going with “Corse” (the name in French) turned “Còrsega France”, which I guess is the name of the island in some foreign dialect (is it Spanish? but why?).
I happily clicked on it, only to arrive at some “Corsican montane broadleaf and…” mysterious place (hovering the mouse over the ellipsis point gives no clue, btw).
It does not even cover the whole island of Corsica. What a mess.

1 Like
35

Try this project?
https://www.inaturalist.org/projects/corsica-a-hotspot-for-biodiversity

1 Like
36

I now edit the URL directly, by adding “&place_id=10574”. Just some number to remember. Unfortunately, entering 10574 in the “place” box does not work.

(As an aside, it’s great fun entering any random number in the “place” box: you discover the biodiversity of various exotic places)

37

Corse FR - seems to be The Place.
https://www.inaturalist.org/places/corse-fr

38

administrative boundaries for continents, countries (or equivalent), states (or equivalent) and counties (or equivalent) are represented as “standard” places in iNaturalist. the best way to search for these in the Explore web page is to use Filters > More Filters > Places rather than the Location box. (personally, i use More Filters > Places almost exclusively as my method of filtering for places, falling back to filtering by rectangles / map view or circles, as needed.)

the former gets only from the set of iNat places whereas the latter attempts to do all the complex and potentially problematic stuff i described above.

…

(just a note to moderators) there’s at least one other open thread that appears to be related to this thread and might be worth merging:

(just for reference) these open threads are more distantly related (and probably should remain separate). for folks who want to understand other general issues a little more, these may be worth reading:

1 Like
39

Austin, TX has the same problem. There is a defined space with that name that a small part of one of Austin’s parks. I learned to search the county, the metro area, or my eco region (Central Texas).

40

if you want to search by the actual city boundaries, there’s an iNat place called “City of Austin” that you can filter by via Filters > More Filters > Place:

image
image1155×913 231 KB

image
image872×687 118 KB

(this was discussed previously in another thread: https://forum.inaturalist.org/t/explore-vs-places-different-boundaries-why/21358/11 .)

3 Likes
41

And, this isn’t even uncommon at all in my area. A quick sampling of cities within a 30-minute drive turned up many such instances. E.g.,
San Jose, CA
Los Gatos, CA
Sunnyvale, CA
Campbell, CA*
Los Altos, CA
Felton, CA
Palo Alto, CA
Fremont, CA*
Bonny Doon, CA*
Capitola, CA
Half Moon Bay, CA
Meno Park, CA*

*The areas returned for these cities encompasses parts of several cities, rather than a small area of that city.

There are lots of BIG, HARD and small, easy things about iNat that need to be fixed, but they drag on. I (personally) am not hopeful any more. The big hurdle of creating a mobile app that works for both Android and iOS, along with just maintaining the infrastructure for increasing site usage, is often called out as an impediment to getting stuff done.

1 Like
42

Filters > More Filters > Places:

image
image947×912 289 KB

2 Likes