Improve Support for Grouping Localities

[JDAM2k4]

Is your feature request related to a problem? Please describe.
VHough, a member of the San Diego Museum of Natural History said on the Speciforum:

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 ... 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.

Describe the solution you'd like
A localityGroup table that would act as a container for many locality fields (similar to how CollectionObjectType houses many Collection Objects).

Describe alternatives you've considered
The addition of a one-to-many sub-locality table that would be able to incorporate GeoLocate in its full capacity to plot inputs on the map and then fills the fields on the table with that data. Therefore, this table should also have coordinate fields, similar to what already exists in the Locality table (ex, latitude1, longitute1, latitude2, and longitude2). This would work similarly to Determinations or Preparations relationship with Collection Object.

However, this solution would not work as it is not compatible with DarwinCore.
Nate Schoobs from OSU Invertebrates describes that issue on the Speciforum:

Hey Jocelyn, personally, I wouldn’t support the idea of a sub-locality table because I think it’s not in compliance with DarwinCore. Multiple sublocalities can (and in my opinion should) be handled by either creating a locality for each identifiable location, or generalizing using a polygon or a line and following the GeoReferencing Best Practices guide that @Willem Coetzer linked.

Reported By
San Diego Museum of Natural History