Bogus GPS locations in Iridium data

[regan-sarwas]

It appears that Iridium collars transmit battery or other system info in the location fields about every 2 weeks. The latitude is typically between 40 and 70, while the Longitude is between 0 and 5.

By their value they are obviously not locations in Alaska, so they are manually hidden as they are discovered. This is problematic, because:

1. It appear that the collar is transmitting locations, when in fact the GPS may be not working at all
2. These locations cause ArcMap to fail to correctly retrieve and draw related valid location data until these locations are hidden.

I need to find an automated way to reject these as locations before they are added to the Locations table.

[regan-sarwas]

With closer inspection

select * from CollarFixes as F
left join CollarFiles as C on C.FileId = F.FileId
left join CollarFiles as P on C.parentFileId = P.FileId
--left join CollarDataIridiumMail as I on I.FileId = F.FileId
 where fixDate > '2016-01-01' and Lon > -100 and C.Format = 'C' and P.Format = 'I'
 order by Lon, Lat

Lon is between 1 and 19.75 (inclusive although only 11 out of 1890 are above 5.00) Lat is between 0 and 90 (inclusive, integer values only)

[regan-sarwas]

All the bogus Telonics/Iridium fixes have a percent value (i.e. 66.3%) in the ArgosLatitude column of the CollarDataTelonicsGen4 table. Otherwise they have either null or a numeric value. It is also true they have a non-date value in the GPSFixTime column. There are 2506 of these records (as of this posting). There are less locations, because some of these fixes had lat/long that were out of the permitted range, or an AcquisitionTime that was after the upload date.

The bogus fixes were deleted from the CollarFixes table (with a trigger to fix the Location table). And the CollarFixes_Insert SPROC was fixed to ignore these records going forward.

[regan-sarwas]

Close with 71069ad26a04be302da8829cacd185eec2414978