Locality question for the community

Two questions for the masses re: Localities.

Question 1: Unless I misunderstand, all localities are required to share exact coordinates? And there is no way to assign coordinates outside of Locality. So, if you have the Locality “X Wilderness Area”, and many specimens collected in that wilderness area, but the specimens have individual coordinates … that doesn’t work. Any advice on what to do? We work hard to get exact coordinates for each trap on a trap line, and I absolutely don’t want to lose that data, but writing up a separate Locality name for each point seems unhelpful, and overwhelming. I know one department that has given up on using Locality names at all, and just uses some sort of code. Is that the way to go? That would be disappointing, because it would be nice to superficially see that all the specimens were from X Wildlife Area.

Question 2: (Less important) Advice on what to do when your locality is no more specific than an entire zip code, but you still want it to be helpful for someone searching the collection for specimens within a particular area? Locality can be an area, but only a rectangle, if I understand correctly, so that’s not super helpful. Has this come up for anyone else?

Thanks for any advice and help, as always!

Hey @VHough,
you don’t need to enforce uniqueness in the locality table. That is to say, you can have multiple localities that share the exact same text for locality, but are nonetheless different records with different lat/longs and different linked geography. The only problem with this arrangement is that it can be confusing when selecting the info in dropdown lists, where it can be difficult to know which locality is which.
In our collection in such cases, we generally do use the site or trap number in the text of the locality field in [brackets] if there’s a specific location within a broader location indicated on an original label. We do not use our Specify locality field as a [dwc:verbatimLocality](https://dwc.tdwg.org/terms/#dwc:verbatimLocality). In our database, locality is always an interpretation of the place, usually with minor edits from the original in [brackets] if it is not clear what the place is.

In your instance of different traps, I would probably record them as different localities like this “X Wilderness Area [trap ###]”. But if this is too cumbersome, you can always use events to indicate the specific trap and then use a single locality with a start and stop lat/long (i.e. a transect) to indicate the first and last traps in a line of traps. I’d be happy to hear more particulars about the situation and offer more specific advice if it’s helpful. :slight_smile:

I think this is a simple data modelling question. There is nothing inherently inefficient or cumbersome about any particular concept’s metadata - after all, we have the workbench and batch editing to bring about efficiency. Yes, you would capture the coordinates of each trap, and perhaps put a code in the locality name field. In a separate field (or 2 or 3) you could put the names of other ‘classes’ of locality metadata e.g. protected area or quarter degree square or municipality or district etc.

For question 2, see Georeferencing Best Practices and search for the phrase: ‘at the center of the extent of the field of detection’. You can consider saving error polygons in your georeference table.

Thank you for replying! I don’t think I would want to use multiple Localities with the same name if that’s the result. I don’t actually have a fully copy of Specify to play with at the moment, this is all in preparation.
I think some variation of “Main Location Name [trap # or other identifier]” will probably be the way to go! At the very least, when I don’t have trap numbers, I can use “X Wilderness Area [a]” or something like that.

I will look into saving error polygons in the georeferencing table and see how that works. Having a point at the center of the extent of the field of detection is what it is, but it feels like it will map out misleading data when dealing with large areas - probably better to not have coordinates at all if there isn’t a way for the system to immediately flag them as actually representing an area the size of Delaware. But thank you for the link, much appreciated.