Editing Localities

[Ksepka]

1A: I cannot seem to find a way to change data for a locality once it is entered - take for example "Xiaoxiang Resorvoir", which is used with calibrate 206 (Gnathostomata) with fossil Guiyu onerous. I forgot to add a Formation name, but now I can't get back into that locality to do so (or at least don't know how).

1B: Database seems to recognize a blank entry in the locality field as a locality name instead of just a blank field. So if I leave this blank it crashes and gives this error message below. Note that ideally this is not a problem because everyone should be including a locality name, but sometimes they do not and I would thus want to leave it blank while I track it down. I have been working around this by entering "xxx" or whatever as the locality name when I don't have it.

Error message = Error in query: INSERT INTO localities SET LocalityName = '' ,Stratum = '' ,GeolTime = '384' ,Country = 'China' ,LocalityNotes = '' ,PBDBCollectionNum = ''|Duplicate entry '' for key 'LocalityName'.

1C: Related to above and more of an issue, some fossils will have the same locality name but a different stratum. For example, I may have two birds, both from "Fossil Butte" locality, but one from "Split-Fish Layer" stratum and one from "18 Inch Layer" startum. Right now, we would have to give the locality two separate names or get an error message.

Proposed solution: Do we need to add a "Manage Localities" option? Alternatively, should we not ask the database to search against existing localities, but let that information be a one-time entry for each calibration, like the age justification fields. Is that possible, and would the fix wipe out existing locality info (would be a bit sad to have to enter 40+ localities again)? For now I would note to Jim P. that we can use separate locality names like "Fossil Butte (1)"and "Fossil Butte (2)" to sidestep the issue.

[jimallman]

Regarding 1B above (blank location name causes a duplicate-key error): I will validate this field and force the user to enter a unique, non-empty name.

1C (same locality, different stratum) is more of a problem, since it means we've got a bad data model. Should this be one entry, or two? The latter is an easier fix for now, but will involve some tedious (and possibly error-prone) re-entry of locality data. Should we add a table that cross-links strata with localities, so that now we're assigning this combination to each fossil?

EDIT: I had assumed that the stratum name value was from a controlled vocabulary, but I see that it's just a free-text field. In this case a simpler solution would be to remove stratum name from the locality record and simply add it as a field in the linked-fossil record. Thoughts?

[jimallman]

And to state the obvious: Yes, it looks like we need a simple CRUD interface to manage existing localities.

[kcranston]

As for issue #42, this is certainly possible, but requires design + feedback + implementation + testing + bug fixing and will take longer in calendar days that simply adding up the number of coding hours.

[jimallman]

@ksepka, @pdpolly Regarding the request to point to multiple strata (in different linked fossils) for a given locality: Does this imply that you would also want to assign different values for geological age, locality notes, or other fields in our localities record type? This screenshot shows all its fields:

At some point, if most of these fields can have multiple values, I assume we'd conclude that different strata in the same geographical location represent different "localities" for our purposes, yes? If so, I'd suggest simply incorporating the stratum name into the existing location name, for example (bogus examples, of course):

• Lee Creek Mine (Yorktown Formation)
• Lee Creek Mine (Zone B)

[Ksepka]

@jimallman @pdpolly @jimparham
I think Jim A.'s proposed solution:
"Lee Creek Mine (Yorktown Formation)" "Lee Creek Mine (Zone B)" would work just fine. We may therefor want to merge those two top fields to "locality and stratum name" for clarity. Does this sound reasonable to everyone? Just to be clear, we still need a way to edit these localities, but I think this handles the duplicate name issue.

[pdpolly]

Yes, this works. In some sense the different formations are different localities, and this solution allows search (or sort) to group on the locality name portion but differentiate on the stratum portion.

[jimallman]

I'll ask again: Does the combination of locality + stratum cover different values that might be assigned for the remaining fields?

• PBDB collection num
• locality notes
• geological age

[Ksepka]

If I understand the question correctly, yes. If we use a single combination "locality+stratum" field, the values for PBDB #, locality and age can be enterer in a straightforward way and remain linked to each "locality+stratum" entry.

[jimallman]

I think we're on the same page -- sorry if I wasn't clear. I'm trying to anticipate whether one day we'll realize, "Oh, this is the same locality and stratum, but it needs to be a different PBDB collection, or I disagree on its geological age."

[Ksepka]

OK - I don't think this is a problem. I do suppose the PBDB collection number could be different (two people collecting from the same locality). But in this case we could just give it a distinct name like "Lee Creek (York Formation) Jim's Pit" To be honest I have given up on entering PBDB collection numbers because it is difficult to verify which of many possible PBDB collections a given fossil comes from in many cases (or there is no number). Geological age should not differ between authors at the Stage level, and any fine differences can be accommodated in the Minimum Age Justification field.

[pdpolly]

I agree with Dan…. the combination of Locality and Stratum is sufficient for the purposes of calibrations. There are, of course, infinite possibilities for subtle arguments, plus PBDB collection numbers are a law unto their own right, but those niceties wouldn’t affect the substance of associating the calibrations with the primary geological evidence.

On 29 Oct 2014, at 11:13 PM, Ksepka notifications@github.com wrote:

OK - I don't think this is a problem. I do suppose the PBDB collection number could be different (two people collecting from the same locality). But in this case we could just give it a distinct name like "Lee Creek (York Formation) Jim's Pit" To be honest I have given up on entering PBDB collection numbers because it is difficult to verify which of many possible PBDB collections a given fossil comes from in many cases (or there is no number). Geological age should not differ between authors at the Stage level, and any fine differences can be accommodated in the Minimum Age Justification field.

— Reply to this email directly or view it on GitHub https://github.com/NESCent/FossilCalibrations/issues/41#issuecomment-61040338.

[jimallman]

OK, I've removed the uniqueness constraint on locality name, so we can freely create multiple entries that differ by stratum or any other field(s). From what I can see, this should have no ill effects, as long as the admins can clearly distinguish entries in a drop-down menu.

I can handle this by showing the combination of locality name and stratum name fields, so there's no need to build long/unwieldy locality names. This is similar to what we show now in this menu, which is a combination of the locality name and age fields (sadly, these are often incomplete):

Anyway, these are always related to other data by a numeric ID, so changes to locality names, etc. should be straightforward and wrinkle-free.

[jimallman]

Oh, and in the event that two records share the same locality name and stratum name, but differ in some other way, just modify the locality name as needed. The database won't reject a second record with matching fields, but the modified name will make it easier to choose the right record from the drop-down menus shown above.

[jimallman]

To address the original request, I've added a Manage Localities page. As we've done elsewhere, this includes links to all fossils to which a locality has been assigned, and blocks deletion until it's been unassigned from all of them. There's also a simple Edit Locality page with basic validation (will block saving changes if locality name or stratum name is empty).

These are working now (tested with bogus localities and my test calibration + fossils) and ready for review.

[kcranston]

Can we get a thumbs up for this feature so that we can close the issue? @Ksepka

[Ksepka]

As stated some time ago I am satisfied with this but would like Jim and David to give a thumbs up / thumbs down in case I missed anything in my testing.

Look good guys?

On Mon, Jan 26, 2015 at 11:18 AM, Karen Cranston notifications@github.com wrote:

Can we get a thumbs up for this feature so that we can close the issue? @Ksepka https://github.com/Ksepka

— Reply to this email directly or view it on GitHub https://github.com/NESCent/FossilCalibrations/issues/41#issuecomment-71487180 .

[hlapp]

@Ksepka - I am going to close this for now. If Jim or @pdpolly can review this only later and then come to the conclusion that more needs to be done to proceed with launch, it's really easy for them (or you) to re-open the issue.

[pdpolly]

yep, I'm happy with it if Dan is. closed.