Create asserted admn 3 for Alaska-- we need Quads back

[amgunderson]

Who is editing my specific and verbatim localities? This is absolutely not the verbatim locality we entered, nor is it the specific locality we entered. It appears many Alaska records now have a stupid string of higher geography attached to the verbatim and specific localities. This is not how we entered the data and should never be changed by anyone or anything but UAM:Mamm staff. This will not print on specimen labels, looks horrible, and I refuse to accommodate it.

[mkoo]

Hi Aren, I see the problem-- something happened when we switched to authority-based HG. Give me a few to review and come up with a solution that we can do automatically. These should have been move to an admn2 Quad for AK but were not so definitely not the intention. (I'll also check other Quads for your state too)

[DerekSikes]

related to this I have something like 20000-30000 records from Denali National Park that now have spec_locs like:

Denali National Park and Preserve, Above Nenana R., Denali National Park and Preserve or Denali NPP, Above Nenana R., Denali National Park and Preserve

And of course, plenty of others from other National Parks in Alaska with the same sort of problem.

To fix these, they should be changed to remove the final string after the comma (incl. the comma) if that string matches the starting string for the first word.

[mkoo]

Had a look at that locality (and others that had Quad in spec_locality) -- https://arctos.database.museum/editLocality.cfm?locality_id=10475746 especially the history details-- https://arctos.database.museum/info/localityArchive.cfm?locality_id=10475746

@dustymc has agreed that everything from that timestamp ({ts '2022-10-25 18:17:44'} see previous geography notes) will revert to the previous spec_locality.

I wanted to make sure that the Quad info (in your example "Juneau") was captured and they have been already added as a locality attribute.

So I think that may help with your other issue of labels. Speaking of which, we need to work with UAM to get all your labels and reports converted to the new system. Have any of the UAM folks started that? Can we start working with you all? @amgunderson Which label were you referring to that got messed up with the super long spec_locality? Let me know when we can start a new issue on UAM labels.

@DerekSikes I'm going to copy your above issue into a new one since I think we can work on some locality clean-up!

[amgunderson]

The specimen from my screenshot above is this, https://arctos.database.museum/guid/UAM:Mamm:117755. The specific locality is to long because it repeats many things. The verbatim locality is also wrong because you inserted some higher geography into it too. Verbatim means verbatim and should be completely hands off from any Arctos manipulation.

I use uam_mamm_label_csv to print labels using MS Word mail merge.

[dustymc]

The specific locality is to long because it repeats many things.

I will open an Issue, that can be addressed.

The verbatim locality is also wrong because you inserted some higher geography into it too.

Absolutely not, at least not intentionally (and I don't see evidence of anything unintentional happening). You are welcome to check the history or any of my code, which is all available on GitHub.

uam_mamm_label_csv

I added a "quad" column - let me know if I've misunderstood the request and I'll remove it, and file an Issue if you want that somehow handled in post-update data - there are a few options.

[amgunderson]

Almost every record from accn 2013.040.Mamm suffers from extra long redundant specific localities. I suspect many others had this done to them but I don't have time to find them but will eventually see them and make a new issue of it at that time. Looks to me like quad, archipelago, and island were all added to the end of whatever we entered as the specific locality. I don't understand why this would be a good idea and I don't want anything added to any UAM:Mamm specific localities. Labels are not the issue, whatever was done to specific localities is the issue. The labels will be fine once the specific localities are returned to their as-entered state.

[mkoo]

@amgunderson @DerekSikes Hey Aren, Dusty is going to strip all these redundant spec_localities. First he'll share a CSV of the localities affected and I'll make sure they are returned to a non-redundant form. This is pretty straightforward. Let me know if that's a problem otherwise let's get it done.

[dustymc]

Here's the proposal, please let me know if something needs adjusted or if I can replace spec_locality with proposed_specloc.

temp_uam_loc.csv.zip