Fix last trailing decimal + first leading zero

[nickumia-reisys]

Related to

• https://github.com/GSA/data.gov/issues/3549

• 253

Notes:

• The brackets are not required, so make sure if the last character is a decimal point, remove it
• Add '^' to leading zero regex to ensure the first number sequence is counted as well
• Two examples that were not captured properly:

  -071.000000, 42.000000, -70.500000, 42.500000
  -98, 29, -83, 35.

[nickumia-reisys]

@jbrown-xentity How do we want to handle the case of no commas? (i.e. -149.0 -81.0 -149.0 -81.0)

[jbrown-xentity]

@jbrown-xentity How do we want to handle the case of no commas? (i.e. -149.0 -81.0 -149.0 -81.0)

Not sure we should, though the docs are a little unclear. Can you check and see if we have a test case covering the above use case? If so, then we should handle it. If not, we should allow an error to be thrown. Then we can either throw the whole record out, or ignore the spatial field (but keep the value in old_spatial).

[nickumia-reisys]

We don't have a test for that currently: https://github.com/GSA/ckanext-geodatagov/blob/main/ckanext/geodatagov/tests/test_fix_spatial.py

[jbrown-xentity]

Alright, then let's say that is a bad value. I think best practice is to make spatial be blank/null, and keep old_spatial as the originally sent value. Let's not throw out the whole record, as this logic is setting between the harvester and the CKAN stuff.