Best practice for editing specific locality? [external CONTACT]

[kderieg322079]

We're conducting repeat surveys in a state park and we had initially assigned the name of the park as the specific locality for all specimens. After getting the first accession cataloged in Arctos, I decided it would be better to give more specific localities to different sites in the park. I want to keep the verbatim locality, since that really shouldn't change, but I want to update the specific locality. This is the desired outcome:
The records in question
Example:
For UMNH:Mamm:45010, I would like Specific Locality to read Goblin Valley State Park, E Flank Wild Horse Butte instead of just Goblin Valley State Park.
For UMNH:Mamm:45031, I would like Specific Locality to read Goblin Valley State Park, Curtis Bench Trail instead of just Goblin Valley State Park

Both records are in the park, but from different parts of the park. We are resampling these sites quarterly, so being able to identify which site specimens are from would helpful.

I have spent quite a bit of time reading up on documentation and poking around different tools to try to figure out the best way to update the records. Seems there are a few options and I'd like some guidance from the experts on the best way to do it efficiently while maintaining data quality.

1. Edit a Specific Locality

Pros	Cons
Will achieve desired outcome	Not a bulk tool, will have to edit each manually

2. Bulk Edit Locality Tool

Pros	Cons
Bulk tool; efficient	This is hinged on Locality Name, so I would need to "generate unique identifier" for every single one since each record has different coordinates and is therefore a different locality. Might as well edit each manually at this rate
	This seems more useful for something like bulk loading coordinates to localities that are assigned to multiple records

3. Bulkload Specimen Event Tool

Pros	Cons
Bulk tool; efficient	This is mostly for creating new events, not editing existing ones
Creating new event keeps record of changes	This feels messy and not like the intended purpose for having multiple events
	If editing existing event, changes to Specific Locality are ignored

I hope this makes sense. Any advice from the community is appreciated. I still struggle to wrap my head around the "place and time" components of Arctos sometimes.

[DerekSikes]

I would clone the locality & make edits - make as many locality records as needed. Then from each create collection event records as needed. Once all the locality and collection event records are in place (with event 'names' [formerly called less confusingly 'nicknames' - not sure why we changed this to be more confusing]] then find all the specimens that you want to assign to a particular event & use the 'manage specimen events' in the tools dropdown. That will allow you to select a new collection event for all those catalog records.

Not sure if this is faster or better (or even different) than the ideas you proposed but it's how I do this sort of thing.

[campmlc]

Check out the Fork Edit tool - I haven't done this in awhile, but if I remember correctly you could use this to create an edited clone of an existing event, and then use the manage specimen events tool that @DerekSikes describes.
@Jegelewicz

[Jegelewicz]

I think that Derek's method makes sense since you plan to sample the locations more than once. Create your named localities and you can call them up by name in the future when you have new events.

Follow his instructions - if anything is fuzzy or you need clarification, just post here. I'm happy to meet up and walk through any of it as well.

[kderieg322079]

Thanks for the help! I guess where I'm hung up is I can't use the same locality for multiple events because each specimen gets a unique set of coordinates; we take a GPS waypoint for every animal upon capture. Because every record will have different coordinates, that means every record technically has a unique locality... right? So even though I have 34 records that all have Goblin Valley State Park listed as the specific locality, all 34 have unique locality IDs because every record has unique coordinates. That's what makes this tricky to do in bulk.

[Jegelewicz]

I didn't understand that. I don't see any path to doing that in bulk except just bulkloading new catalog record events with the more specific information. There is nothing wrong with two events - and you can "unnaccept" the old one.

[DerekSikes]

Right - clone your localities so you have 34 of them & make their lat/longs unique as needed.

[mkoo]

Absolutely what Derek and others said-- this is how I go from old vague historic localities to specific sites for example.

Clone localities (just a georeference or remarks modification) or Fork-Edit specimen events (additional info like habitat, method, etc can also be added)

For newly cloned locality of repeated visits, consider adding a Locality name, which can be specific to your expeidtion or survey (eg trapline 12, base camp 2, etc). I also added in Remarks like references to field notes or other info.

Once you have your locality made and modified as you like, then start 'moving' specimens here via editing the collecting event and picking a new locality. Likely this is a common trail or trapline with multiple collecting events. This is where the LocalityID is useful-- just copy/paste that in the search interface. Then you will have only one result and the Pick button is on the left (It's a little small right now and we will be addressing UI improvements for all the locality search and edit pages soon hopefully)

[campmlc]

Sounds like this would be a good how to or workflow. I need to do this as well, but I've been avoiding it by currently using the same coordinates for a named locality, and not yet adding the updated events with the individual trap coordinates. I'm not sure I understand the whole workflow well enough to describe it properly.

…

On Thu, Mar 30, 2023 at 2:53 PM Michelle Koo ***@***.***> wrote: * [EXTERNAL]* Absolutely what Derek and others said-- this is how I go from old vague historic localities to specific sites for example. Clone localities (just a georeference or remarks modification) or Fork-Edit specimen events (additional info like habitat, method, etc can also be added) For newly cloned locality of repeated visits, consider adding a Locality name, which can be specific to your expeidtion or survey (eg trapline 12, base camp 2, etc). I also added in Remarks like references to field notes or other info. Once you have your locality made and modified as you like, then start 'moving' specimens here via editing the collecting event and picking a new locality. Likely this is a common trail or trapline with multiple collecting events. This is where the LocalityID is useful-- just copy/paste that in the search interface. Then you will have only one result and the Pick button is on the left (It's a little small right now and we will be addressing UI improvements for all the locality search and edit pages soon hopefully) — Reply to this email directly, view it on GitHub <#310>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADQ7JBCMD73OSJPX5QJNOM3W6XXFXANCNFSM6AAAAAAWMFFNNU> . You are receiving this because you commented.Message ID: ***@***.***>

[mkoo]

Also, now that I reread and was reminded that your 34 locs are based on GPS coordinates, you can just use 30 m as your uncertainty in meters as a default or assumed error. Unless you know otherwise (eg., GPS used WAAS, or other tools to reduce errors). Just makes it easier to bulk load them or do in one fell swoop

[dustymc]

good how to or workflow

Yes - two of them: "legacy" data (in which things like named shared localities might make sense) and "modern" data (in which every locality should be defined by the precision of your GPS) don't share much ground.

individual trap coordinates

Use the download from the GPS as the start of a bulkloader file. (Easier said than done, but it has been done and might be a fundable basis for a field entry app or etc. if our Community would like to address that.)

assumed error

Please no! Some users will interpret that to mean "infinitely precise," the rest of us will assume it's slightly more than whatever's useful at the moment.

[mkoo]

>>assumed error

Please no! Some users will interpret that to mean "infinitely precise," the rest of us will assume it's slightly more than whatever's useful at the moment.

I think you misunderstand me-- leaving no error allows the mis-interpretation of precision and accuracy. Best practices in all our georeferencing guidelines is to include error EVEN for GPS- coordinates. Most recreational GPS units do not export any uncertainty estimate so you have to provide that. If you dont know the details of your GPS set-up, you may use 30 m (that's all I'm saying).