Describe the bug
A clear and concise description of what the bug is.
WorkBench allows entries into lat1text, long1text, latitude1, and longitude1, etc. that are not permissible by the forms.
Acceptable values include: 10 20' 13’ xyz", 100 30’ P, 90 20’14" A", friend, and 50 friend
This is problematic because it:
- Allows non-standard entries in a standardized field
- Leads to data clean-up work that could be caught and prevented before import
- Can corrupt data by changing the direction of lat/long values when stripped
With an example from Joe Russack (1181)with longitude value 90 20'14" O , the "O" stands for Oeste, West in Spanish.
With the un-translated direction character allowed via WorkBench (but not via forms), that information is vulnerable to loss or corruption.
Currently, after import, the Locality form will strip the "O" once opened, changing the value from 90 20'14" O (90 20'14" W) to 90 20'14" which is then parsed as 90 20'14" E.
See bottom for more on helping instances of this issue post-import
Expected behavior
Instead, WorkBench should have flagged the cell as an error so they could recognize the issue. Ideally, that cell would have been corrected with a "W" and the original value moved to the verbatimLongitude field.
WorkBench should not validate coordinate data outside of the acceptable values.
Screenshots
If applicable, add screenshots to help explain your problem.
Please fill out the following information manually:
- OS: [e.g. Windows 10]
- Browser: [e.g. Chrome, Safari]
- Specify 7 Version: [e.g. 7.6.1] (Production or V7 are not valid versions)
- Database Name: demofish, ojsmnh20260526
- Collection name: Ichthyology
- User Name: SpAdmin
- URL: https://ojsmnh20260526-v71205.test.specifysystems.org
Additional context
For cases where non-standard data already exists:
PR 8369 maintains the imported value in the lat/long fields rather than stripping it/auto-modifying the record
PR 8370 adds save blockers to the records with non-standard values
Describe the bug
A clear and concise description of what the bug is.
WorkBench allows entries into lat1text, long1text, latitude1, and longitude1, etc. that are not permissible by the forms.
Acceptable values include:
10 20' 13’ xyz",100 30’ P,90 20’14" A",friend, and50 friendThis is problematic because it:
With an example from Joe Russack (1181)with longitude value
90 20'14" O, the "O" stands for Oeste, West in Spanish.With the un-translated direction character allowed via WorkBench (but not via forms), that information is vulnerable to loss or corruption.
Currently, after import, the Locality form will strip the "O" once opened, changing the value from
90 20'14" O(90 20'14" W) to90 20'14"which is then parsed as90 20'14" E.See bottom for more on helping instances of this issue post-import
Expected behavior
Instead, WorkBench should have flagged the cell as an error so they could recognize the issue. Ideally, that cell would have been corrected with a "W" and the original value moved to the
verbatimLongitudefield.WorkBench should not validate coordinate data outside of the acceptable values.
Screenshots
If applicable, add screenshots to help explain your problem.
Please fill out the following information manually:
Additional context
For cases where non-standard data already exists:
PR 8369 maintains the imported value in the lat/long fields rather than stripping it/auto-modifying the record
PR 8370 adds save blockers to the records with non-standard values