Georeferencing--Reuse of Locations

[jnodel]

Describe the bug

Locations, once defined into the georeferencing tab, can not be reused. I.e., if coordinates are put in once for a collection event at Snowhill, Maryland, USA, to add Snowhill as a georeference to another collection event is not possible. Instead, I have to re-enter the coordinates like I did the first time.

To Reproduce Steps to reproduce the behavior:

1. When I go to Comprehensive specimen digitization
2. Then I click on "Georeferences" under "Collection Event"
3. And I enter in my coordinates for a location, and enter that to a collection event
4. I cannot now add this georeferenced location to another collection event, without putting it in manually as if a separate location

Image: georeferenced location for a collecting event Image: a georeferenced location is now associated with this specimen Image: a new specimen, at same location, but no georeferenced location--and when I try to georeference it, there is no way to "search" previous locations, so I have to put in the coordinates again **Expected behavior** Being able to add the same location, or search and add the same location, to other collection events would be much faster and more efficient. **Screenshots** If applicable, add screenshots to help explain your problem. **Environment (please identify where you experience this bug:** *** One of *** - Development (native|docker : shaw) - Sandbox - - Production - Browser: Safari

[jlpereira]

Hello @jnodel,

This is not a bug, georeferences are linked directly to a one collecting event. Can I suggest to use the "Clone" button? This will clone not only the collecting event, it will do with the georeferences too. This will be reduce the time you will have to spend filling the other fields with duplicate data. (i.e georeferences, collectors, labels, etc) After clone it, you can make the changes you need to fit the rest of the information.

Now im thinking a new improvement to make possible clone only the georeference if the georeference is pinned, or same way but with a collecting event, to copy all georeferences.

But for now I hope the clone button help you with your workflow

[mjy]

There is also a georeference matcher task that can be useful in some workflows.

There are various reasons we don't have a locality table in TaxonWorks, I'll try to write up the philosophy at some point. Essentially it comes down to the fact that while an individual curator might know the spatial boundry of a "locality", that spatial boundry can change over time.

We definitely want to be able to re-use shape expressions, and the georeference prototype was an example of that. We'll continue to try and explore interfaces that allow for re-use, but @jlpereira is right, if it really is the same shape, a clone should cover many use cases. We also have a new CollectingEvent editor in the pipeline, we'll consider this use case in the creation of that pipeline.

[jnodel]

Thank you both for your quick responses.

I use the "cloning" tool often, but I was talking more about just cloning the georeference like you suggested @jlpereira. For example, I'll have specimens from multiple collecting events at the same location--like at Durham, NH, USA, with collection "events" June 7, June 8, and June 9. If I attach a georeference to June 7, I can't add it to June 8 or 9 because those are different events.

@mjy I checked the georeference matcher task, and tested a few of the locations I worked with yesterday. Those locations weren't found easily in the georeference matcher. Is the matcher not linked to created georeferences?

Thank you!

[mjy]

@jnodel Thanks again for the feedback. If you can, please open a new issue regarding the issues with the georeference matcher, describing what you did. It is only based on georeferences, so it should return results. More likely I suspsect it hasn't been tested for a very long time, and needs some attention.

[mjy]

@jnodel @jlpereira FYI see evolving specs here https://github.com/SpeciesFileGroup/taxonworks/issues/1530, I've added your idea regarding using locality string as a potential match suggestion option in the georeferences section.

[jnodel]

@mjy Will do for the georeference matcher issue! Saw the evolving specs for #1530, thank you.