Testing DQ checks: spatial - coordinates

[Mesibov]

Tested on 457075 beetle records downloaded 2 December 2015.

These 4 sightings did not have their lat/lons processed, although they could have been converted to DD:

Record ID Latitude - original Longitude - original geodetic Datum Latitude - processed Longitude - processed
5e3a2e05-1e80-4e1c-9394-ed6b37441b20 37°56'9.10"S 145° 0'43.74"E WGS84
ad379c33-2209-4a11-9ca0-061fd05d3c47 34.0.0.S 151.1.57 E WGS84
bf6d8e4b-5a52-43f9-9385-eb5921ab2a5f 34.0.0.S 151.1.57 E WGS84
97edaa77-643b-41c6-9771-ed8473430dc4 37deg, 53'24.14"" S 14deg, 13'17.56"" E WGS84

while these 4 wildly erroneous lats and lons did get processed:
Record ID Latitude - original Longitude - original geodetic Datum Latitude - processed Longitude - processed
0a52cf60-a577-47a8-b2d2-f5f8a3ab945a -17534 146.532 WGS84 -17534.0 146.532
f7702819-cf89-4739-8b62-064c6c312b60 -17534 146.532 WGS84 -17534.0 146.532
03f2c64c-b269-4a34-b66b-ed626c8b172c -21.155 1148.166 WGS84 -21.155 1148.166
27eda356-8001-4d4f-a8a8-0a0e8f41bc13 -27.35 1340.8 -27.35 1340.8

The 'true' flags for these last 4 records were 'Coordinates are out of range for species' and 'Coordinates dont match supplied country'. The original lat/lons could have been filtered and quickly fixed.

Zero latitude (Supplied latitude is zero)

2 of the 'false'-flagged records (supplied latitude not zero or blank) have no supplied latitudeand are false negatives. The lat/lons weren't processed, but lats could be estimated from 'Locality':

5c5bab0c-62fa-4617-af6a-37a7bb9e5f9f
Tesserodon henryi 17 miles W Atherton [blank lat] 145.483337 1975-02-10
966a3fb4-7641-48f4-a751-7938154ba182
Tesserodon henryi 17?20 miles W Atherton [blank lat] 145.483337 1975-02-10
[Locality is '17–20 miles W Atherton' in original]

This 'false'-flagged record has the supplied latitude '0° N', but this has mysteriously disappeared in processing. The record is from Sumatra.
b9f01a71-0ba6-4b83-9b7c-8af71eac3fe0
Xylotrupes gideon [blank lat] 102.0

Coordinates converted from UTM Coordinates derived from verbatim coordinates Coordinates are transposed
442401 false false false
14339 true false false
275 false true false
60 false false true

In the '275' group, for example
http:https://biocache.ala.org.au/occurrences/74a03759-5f7d-4e06-86e9-4d57edace27e
the processed lat/lon is exactly the same as the verbatim lat/lon (in DD) as supplied. Why could the supplied lat/lon not be given in the ALA record as original lat/lon?

The '60' group of transposed records are all for '145.4413' '-38.022', from Laura Levens' project at 290 Leppitt Rd, Upper Beaconsfield.
Verbatim longitude 5790.5 E
Verbatim latitude 363 S
These are UTM coordinates in correct order. Since the 'Coordinates derived from verbatim coordinates' flag is 'false', does that mean someone at ALA looked up the lat/lon of '290 Leppitt Rd, Upper Beaconsfield'? If instead they were indeed converted from UTM to lat/lon, not only should that flag be 'true', the order should have been reversed so that original lat/lons weren't transposed.

Latitude - original Longitude - original Latitude - processed Longitude - processed
-43.490074569426525 146.5994439879235 -43.490074569426525 146.5994439879235

ALA should get a 'fidelity' award for these, of which there are thousands. The original figures probably come from a DMS > DD calculation done by the data provider, who didn't bother rounding off to an appropriate number of decimal places. ALA has faithfully reproduced this nonsense. For the latitude, the 14th decimal place is about 1.1 nanometres, the diameter of a glucose molecule.

The beetles data set I checked has 30665 records in which the processed longitude has 14 decimal places.

[Mesibov]

My mistake, that latitude is actually specified to 15 decimal places, not 14. That means the implied uncertainty for the location of the beetle collection site is about the diameter of a single oxygen atom. I think you've got a world-beater there, gentlemen.