Note that the the whole "single location" thing is somethign that the Garmin works around by just reporting multiple locations as free-hand text:

    // These seem to be the "real" GPS dive coordinates
    add_gps_string(garmin, "GPS1", &garmin->gps.SESSION.entry);
    add_gps_string(garmin, "GPS2", &garmin->gps.SESSION.exit);
    
    add_gps_string(garmin, "Session NE corner GPS", &garmin->gps.SESSION.NE);
    add_gps_string(garmin, "Session SW corner GPS", &garmin->gps.SESSION.SW);
            
    add_gps_string(garmin, "Lap entry GPS", &garmin->gps.LAP.entry);
    add_gps_string(garmin, "Lap exit GPS", &garmin->gps.LAP.exit);
    add_gps_string(garmin, "Lap some GPS", &garmin->gps.LAP.some);
    add_gps_string(garmin, "Lap other GPS", &garmin->gps.LAP.other);

    add_gps_string(garmin, "Record GPS", &garmin->gps.RECORD);

so that the information is at least there in the extra info, and people can see it (even if it doesn't then show up on the map)

The right thing to do would be to add a GPS sample, which woudl also solve the issue of dives where you peek up in the middle of the dive to see where the heck the boat is (or where the shore is when you're really lost ;)

The right thing to do would be to add a GPS sample, which woudl also solve the issue of dives where you peek up in the middle of the dive to see where the heck the boat is (or where the shore is when you're really lost ;)

That's indeed one of the options I'm looking into. I have most of the implementation already prepared.

@mikeller Maybe wait a bit before merging this PR? There is at least one bug in the Shearwater GPS code reported that I'm still looking into. Apparently in some case the values can also contain 0xFFFFFFFF instead of zero. I suspect there will be some flag to indicate whether GPS data is available.

@torvalds: Yeah, good idea, I can add some extra info items for end location, and potentially more data points like 'location at x min'.

@jefdriesen: Thanks for the heads up, will hold off then. I am still waiting for Shearwater to get back to me with the spec for this, last I heard they were swamped with support. 😆

Being able to store the location as part of the sample information would be nice - also seeing that some manufacturers (including Suunto) are working on using inertial data to generate 3D dive profiles. But I suspect it will be tricky to implement this in Subsurface in a way that makes the data format backwards compatible.

I have pushed the extra fixes. This should work fine now, unless there are other special cases that we haven't seen yet. I also haven't received any updates from Shearwater.

On Tue, 13 Jan 2026 at 17:30, Michael Keller @.***> wrote: while Null island isn't the world's most popular dive destination, it seems to be loony to take perfectly valid coordinates

No. They aren't valid coordinates.

Ok, point taken, my concern is more of a theoretical nature than practical. But at the end of the day I still think it is preferable to use actual specs as the basis for an implementation over using inferred information that is based on a limited set of data.

Not for an actual real instrument. Remember: reality has noise. There is no such thing as "exact GPS coordinate" in reality. You will not get all zeroes from a real GPS location, even if you are very close to the Null island. And even if you do - by random chance - the next coordinates will be something else. So you're still fine. And even if you were to get 0,0 as a GPS coordinate, NOBODY CARES. It's really not an interesting location for diving. Don't confuse theory with reality.

This point can equally be made about ANY other point that the microdegree format used in Subsurface can encode - if we are worried that we are storing too much information, we should address this by reducing the resolution, not by throwing out individual data points based on a hunch that they might have a special meaning.

So the real objection should be to the insanity that is using floating point here. A few lines down, we have this complete garbage: location->latitude = latitude / 100000.0; location->longitude = longitude / 100000.0; PLEASE don't do the complete garbage that Jef has decided on.

I do agree that using floats for coordinates is not a good approach. But based on the discussion in subsurface/subsurface#4668 (comment) we've agreed that accepting that this is the way that libdivecomputer has implemented this and getting support for location information from dive computer that support this (or will do so) is preferrable to rewriting this entire thing in our 'not-a-fork' of libdivecomputer, which will create more work for us now and into the future.

Floating point for data IS NOT OK. There is a real reason why all core types in subsurface are based on integral fractions. We do depths in mm, we do pressures in millibars, and we do locations in microdegrees. A microdegree has well-defined precision - and is more than sufficient. In contrast, floating point does not have well-defined precision, and the numbers are fundamentally more precise around zero than around +-180 degrees. I have seen way too many garbage dive logs that do not understand floating point, and then you have "fun" things like we see in the uddf test-files: 9.859999999999999 because somebody really didn't understand floating point. And I guarantee that "didn't understand floating point" is about 99% of all programmers. Don't do it. (Just do "git grep 99999" and cry. This kind of garbage is everywhere) Yes, this is a pet peeve of mine. Integer fractions with proper type safety (by enclosing them in structures) and conversion functions (thanks to the type safety) are just superior. Floating point is for "close enough and I don't care, and I don't understand". Use it for visualization - not for the underlying hard data! Linus

Yeah I can see your point - and I do agree that 99% of programmers don't understand floating point when they try to use it for storing or transmitting measurements.
On the other hand, I believe that a similar number of programmers don't understand integer math, and then try to use it 'just because' their input values come as integral fractions. Most of the time this creates hard-to-spot problems where output values get massively inaccurate whenever any one of the internal variables of their calculations gets close to 0 and rounding errors start to be the same magnitude as the value itself.