Adding Flagging options for iNaturalist Places: duplicate, incorrect/delete, other

[Star Donovan]

Currently there is no option for flagging iNaturalist Places. I would like to suggest one be added, with the following categories:

(1) DUPLICATE

EXAMPLE: there are 3 iNaturalist Places named Edwards Plateau in Texas.  Only one has boundaries.  The others are single-point map locations that do not specify the area of the plateau and should probably either be merged (per thread here, this is something curators can do for duplicates) or eliminated:

• "Edwards Plateau, US, TX," - the only one with Defined boundaries, has associated Observations and appears to be Project-created: www.inaturalist.org/places/edwards-plateau--2
• "The Edwards Plateau, US, TX, region"  - has No Boundaries (has no associated Observations, so it could probably be eliminated): www.inaturalist.org/places/the-edwards-plateau
• "Edwards Plateau, US, TX, colloquial" - has No Boundaries (has associated Observations and should probably be merged): www.inaturalist.org/places/edwards-plateau-tx-us

(2) INCORRECT (DELETE OR EDIT)
I see this as suggesting 2 possible actions for the curator or admin.

(A) DELETION: as per Charlie Hohn's suggestion here about removing single-point places, and Janel Johnson's later reply about auto-generated single-point places not allowing curators to edit.
(B) CORRECTION: This would be used to alert curators and admins of any inaccuracies. It could have a small text box to briefly describe the problem.  Ideally, it would prompt/allow the user to attach a KML also.

(3) OTHER Anything I'm forgetting (and to be consistent with the flagging options for other areas of iNaturalist)

Curators have many duties on iNaturalist and flagging allows us to assist them. 
Please add flags for iNaturalist Places so we can aid them in making sure the Place data is accurate, as we can do for taxa, copyright, and other areas of the site.

[Chris Cheatle]

In order for this to work (which I think is a good idea, there are curators more interested in data quality than taxa management), a couple of things need to be considered:

• your #2 example can probably safely be deleted. #3 actually looks like it has no observations either. It appears to have a checklist though, which suggest it was either imported as a checklist or manually added. What tools / processes exist to deal with checklist migration and clean-up
• there needs to be a tool or way to determine if a place is used in any projects
• clarifications on renaming, if #2 and #3 are deleted or merged, it would make sense to rename the good one. But does that work in terms of links to projects. It can also break any searches using the place name not the key, which could be especially problematic when the new project model is implemented
• improving the view on the places home page, in particular adding a tree view that navigates the hierarchy
• a tool to find single point places, I'd be fine to spend time cleaning them while the hockey game is on in the background etc - but I'm not keen on manually going through thousands of places to try and find them.

[Star Donovan]

Thank you for your support.  I honestly think flagging would be a better method than resorting to emailing help@inaturalist for each instance, and I am pleased that a curator thinks so as well.

• Yep, in my example it's fairly easy to tell which should stay.  I'm sure there are other duplicate Places which would be more difficult.
• Currently there are tabs on Places for Species, Observations, People and About. Having an additional one for Project that use the place would be handy.  Of course, that brings it's own set of issues: Do you only count projects that are within the entire place boundaries, or do you include projects that span multiple places, or that are part of a place and part of an undefined area?)
• Is it possible for a place to have aliased names?  If so, when merging there would be no need to decided which name to keep, as they'd both link to the same Place.
• You mean turn he current breadcrumb navigation into a tree?
• I had been thinking flagging allowed "regular" users to do some of the legwork, but an automated tool to find single-point places would be a great method to aid in a mass clean up on that particular issue.
  

[Chris Cheatle]

Point #2 does exist, but it only shows if there are Projects. See https://www.inaturalist.org/places/ontario-ca as example.

[Star Donovan]

Ah, interesting.
That brings it back to your point earlier about how to merge multiple valid places.

[Janel Johnson]

Hi Chris,

I had all of these questions a couple of years ago and it's been a slow process to find the answers. Here's what I've found by trial and error:

-There are some places that seem to come from Yahoo's geoplanet that are not editable and only have a point location.  The only way to get rid of them right now (even for curators) is to email an admin.

-Projects only show up in a place if that place is defined as the boundary for the project. There is no geographic algorithm that automatically assigns projects to places.

-If a place has a project and you merge it with another place, the project is moved to the merged place. Also, if you rename or otherwise edit the place, the project remain attached to the place because they are linked by the place_id number, not the name.

-At one time, someone, somewhere post url modifiers that let you search for places by their parent place id.  I can't find the post or the modifiers now and I'm kicking myself for not quadruple bookmarking that page. 

-All of the data you're asking for exist in the database that runs iNat but access to those data are extremely difficult.

People have been asking for improvements to the Places for years but it's clearly a low priority.  For many of us who use iNaturalist as part of our jobs, Places are very important, more so than the AI for identifying common species.

[Chris Cheatle]

Janel,

In terms of finding places within an area (your point #4), I am not sure if this is what you mean, but if you go to the Observations page (kind of counter-intuitive), and then click on Map, as you zoom to a location, if you click Places of Interest, you get a list. The issue is it is not complete. So for instance going here ( https://www.inaturalist.org/observations?place_id=27590 ) gets a list but incomplete, you need to zoom really tight on the map to see some of them.

In terms of impact on projects, I am more concerned about the impact on the new project model, which are basically search stings that are planned.

And I still am unsure about the impact on checklists. The 3rd Edwards Plateau in the 1st message has no observations, and is a point, but has a roughly 800 species checklist that was either uploaded, or even worse manually added. What happens to it if you merge the location, since the one it is associated is functionally useless as a place.

[Star Donovan]

Flag 'em all, and let the admins sort 'em out!  :P

Sort of. While my suggestion's purpose was for issue reporting, I realize that it is even more valuable when admins and curators know what to do to resolve the problem after getting a report.

I think it could still be handy to create a flagging mechanism in the absence of solutions, however.
Flagging would allow the creation of aggregated categories of Place issues so that once solutions are found:

• there are existing examples of each issue category (duplicate, single point, etc) already handily collected.
• it shows which categories are the most widespread, to help prioritize them.
• it documents how many users are concerned with these issues.
  
• it shows which particular Places are flagged most often (sort of a "popularity contest" for problematic Places).
• existing flagged Places can serve as templates to create test case Places (in dev or production) where fixes can be tested first.
• the fixes can be tested and/or applied against the existing flagged Places, without having to search through the Google group, wait for emails to he...@inaturalist.org, or start collecting and addressing problematic Places from scratch.

Not that I want you to stop discussing how flags would be resolved once entered!  The issues behind the problems, as well as the selected workarounds, are very interesting.