Trap.NZ currently displays latitude and longitude coordinates in decimal degrees to 12 decimal places… I suspect a result of using double precision to store the coordinates. In this case, the precision isn’t warranted and causes challenges when copying coordinates into another application.
12 decimal places provides a precision of a few 10s of nanometers. Yup, that’s correct - nanometers! Unless someone is trying to trap viruses, this is excessive.
All that’s actually needed for trapping is 4 decimal places… which provides 1m accuracy. But six decimal places is a fairly standard precision… which gives 1cm precision. More than enough!
The challenge comes when transferring coordinates from Trap.NZ to other applications. Some applications don’t handle 12 decimal places nicely (I’m looking at you, Celium!) and so I either have to truncate through Excel or eyeball the 6 decimal places if I’m cutting and pasting. Neither is convenient!
Please truncate your latitude and longitude coordinate display to six decimal places… and make sure all your exports have a similar level of precision.
(For completeness, your Eastings are stored with 2 decimal places (cm) and your Northings to 3 decimal places (mm)… I suggest removing the decimal places from this display… but it’s not as critical)
Thanks for listening!
I don’t have this trouble as I don’t (at present) need to take our data out of the trapNZ app really, but I can see how that would be troublesome! Most of the things we are after are a tad bigger than viruses
Or they could use NZTM for the co-ordinate system which would be a lot simpler.
Many of the applications we export to only use Latitude and Longitude as their coordinate reference - they know nothing of NZTM. If you need NZTM, that’s fully supported in Trap.NZ, for data entry and for export. But the use of WGS84 Latitude and Longitude as the primary location display is absolutely right - because it’s unambiguous and is what Google Maps and other consumer mapping applications use. It just needs that precision tweaking.
Out of interest, which applications are not accepting the 12 decimal places?
Mainly the Celium dashboard… which rudely rejects that input. But we’ve also had some challenges with GPX files…
Why are you needing to transfer TrapNZ location data to Celium?
I only ever need to transfer old Celium data to TrapNZ since we now run Celium nodes just using TrapNZ (note Hub status still not in TrapNZ yet). I only ever need to import historical Celium data into TrapNZ.
If you have setup up or moved your trap locations using TrapNZ there a tick box in TrapNZ which sends information to the Celium database which updates trap locations in Celium. Tick (Send meta data about this trap to my sensor provider?) to do this
I know nothing of Celium, but have been bothered by the too-many decimal points, eg when trying to make sense of a linestring while joining installations into a line or adding a new installation to a line. (Why cannot TRAP.NZ draw a line, and update it if the installation moves…? - but that’s another question).
And given how much error there is in mappings - as evident when walking a straight line & seeing the TRAP.NZ tracking line jump a few metres sideways, or plotting a new installation where I stand, then seeing it has me in a stream when I’m not - the degree of “accuracy” incorporates quite a bit of error.
Usually, it’s enough to be able to stand where an installation is mapped at long/lat coordinates, and see the installation within ~3m.
90% of the time, the full status including coordinates does transfer across from Trap.NZ to Celium. The challenge is the 10% of times when it doesn’t… and of course, it’s the problematic nodes (typically coverage limitations in rugged terrain) that we need to manually update in Celium… because we’re moving them to try and improve coverage… and if the supervisions aren’t happening, then we have a mismatch between the Celium dashboard/Trapwatch and Trap.NZ. Since those are nodes that need visiting, its important we don’t have any confusion about location.
You’re absolutely correct… the precision of the coordinates needs to match the accuracy inherent in the environment. It’s one of those technology things - just because it can display ‘high precision’ doesn’t mean it should!