Some Places do not show up on app search

[naturalistcharlie]

When I try to search for Montpelier, Vermont it does not show up in the app even though it is a place with a defined boundary (see http://www.inaturalist.org/places/montpelier-vt-us). It also does not show up when i trigger 'search near me' when within the boundaries, and instead the entire county is searched.

[alexshepard]

This is something we've struggled with a bit. Some towns, like Montpelier, have geometries that can contain observations. Others, like Los Angeles, are effectively just latitude/longitude coordinates and thus without an area cannot contain observations.

Being conservative, we've limited place search to some restrictive rules: https://github.com/inaturalist/INaturalistIOS/blob/master/INaturalistIOS/ExploreSearchViewController.m#L417 Administrative places (except towns) are candidates for search. Open spaces are candidates for search. Anything else is not a candidate for search.

This is definitely a compromise. Like you mention, some towns are defined enough that they can contain observations, and thus should show up in the explore tab. Similarly, I've noticed a few open spaces that are garbage and shouldn't be showing up here (can't remember them off the top of my head).

Maybe we're applying the wrong kind of filter to determine whether an app is a candidate for search or not? Maybe we should be checking to see if the observation has a geometry? Unfortunately, when looking at the JSON that the server returns for locations, I can't seem to see how we could tell the difference between a valid places and an invalid place. There's nothing that I can see there to indicate that one has a geometry and the other does not.

[naturalistcharlie]

Hmm, that makes sense. In Vermont the 'towns' are little modular units like tiny counties - everything is in a town (or a gore but that's another story) I know in California not everyone is in a town, some have weird shapes, a lot of the areas naturalists hang out are 'county only', etc. I guess once I get my search figured out on there it won't be much of an issue.

A few things:

Is there any reason to have the places that don't have geometry? To me they are an annoyance as they can't generate species lists and are useless for searches. I guess they help you find a place but they seem more trouble than they are worth from my point of view - which of course is a limited one. But maybe they have uses I haven't found yet.

In the long long term what I am imagining is something that can generate a field guide on the fly for a trail or small park based on what people have observed. We are getting there! Maybe part of what I should be doing is adding some of the Vermont parks and forests as 'places'. But that is confusing too... for some reason we often have several that directly abut each other, or ones that are in weird little fragments... we have generous landowners who allow trail right of ways, we have roadside invasive plant surveys, etc etc. So this is all great but just looking at future ideas. Sorry if they are annoying.

On Wed, Nov 26, 2014 at 2:00 AM, Alex Shepard notifications@github.com wrote:

This is something we've struggled with a bit. Some towns, like Montpelier, have geometries that can contain observations. Others, like Los Angeles http://www.inaturalist.org/places/los-angeles, are effectively just latitude/longitude coordinates and thus without an area cannot contain observations.

Being conservative, we've limited place search to some restrictive rules:

https://github.com/inaturalist/INaturalistIOS/blob/master/INaturalistIOS/ExploreSearchViewController.m#L417 Administrative places (except towns) are candidates for search. Open spaces are candidates for search. Anything else is not a candidate for search.

This is definitely a compromise. Like you mention, some towns are defined enough that they can contain observations, and thus should show up in the explore tab. Similarly, I've noticed a few open spaces that are garbage and shouldn't be showing up here (can't remember them off the top of my head).

Maybe we're applying the wrong kind of filter to determine whether an app is a candidate for search or not? Maybe we should be checking to see if the observation has a geometry? Unfortunately, when looking at the JSON that the server returns for locations, I can't seem to see how we could tell the difference between a valid places http://www.inaturalist.org/places/montpelier-vt-us.json and an invalid place http://www.inaturalist.org/places/los-angeles.json. There's nothing that I can see there to indicate that one has a geometry and the other does not.

— Reply to this email directly or view it on GitHub https://github.com/inaturalist/INaturalistIOS/issues/78#issuecomment-64522653 .

Charlie Hohn Montpelier, Vermont coyot.es/slowwatermovement

[alexshepard]

None of this is annoying! We need feedback to get better.

I generally agree that places that cannot generate species lists aren't useful to the Explore tab. I'm not sure whether they have any value to iNaturalist at all, but I think that's more of a question for @kueda and @loarie.

[naturalistcharlie]

There are also some user-created places that are wrong (ie watersheds or mountain ranges that are mapped way beyond where they actually are)... which can create problems and probaly need some sort of crowdsourced or curator verification before iNat uses them in place descriptions or for the app. But I think that's a larger scale issue also.

On Wed, Nov 26, 2014 at 1:07 PM, Alex Shepard notifications@github.com wrote:

None of this is annoying! We need feedback to get better.

I generally agree that places that cannot generate species lists aren't useful to the Explore tab. I'm not sure whether they have any value to iNaturalist at all, but I think that's more of a question for @kueda https://github.com/kueda and @loarie https://github.com/loarie.

— Reply to this email directly or view it on GitHub https://github.com/inaturalist/INaturalistIOS/issues/78#issuecomment-64687100 .

Charlie Hohn Montpelier, Vermont coyot.es/slowwatermovement

[alexshepard]

I'm closing this, as it doesn't seem fix-able in the iOS app. @kueda please correct me & re-open if I'm wrong?

[kueda]

Would a with_geom on /places/search.json let you deal with this?

[alexshepard]

I think so...