Null Island – You’ve been there, and I could probably prove it.
Null Island is a place you’ve been to a few times. Maybe some of you have been there many times. Yet none of you ever remembers going.
Null Island is the enigma of sports data.
The more astute readers might suspect that I’m hinting at something to do with Watopia, which is a fictitious island and part of the virtual run+bike game called Zwift. Not so. As every Zwifter knows, Zwift is loosely based on the real island of Teanu, Solomon Islands. You really could go there if you wanted to, both virtually and in person. And look! the tracks even appear in Strava so it must exist and, in any case, you probably remember at least some of those trips to Teanu/Watopia.
No, Null Island is definitely a place you would get wet without the aid of a decent boat. This might make you wonder why I’m suggesting that you’ve been there whilst wearing either your running or cycling shoes.
Null Island – Is it made up?
It’s kinda made up BUT you would also find its existence confirmed by a quick Wikipedia link which, unfortunately, I haven’t yet provided.
I’m stringing you along a little, I know but here’s a clue.
Remember this? It’s Station 13010 which was definitely there on your last visit. Does it look familiar now? Hmmm. No, I thought not.
Another clue? – OK, it’s about 400miles (650km) from land
Another clue? – It’s in the armpit of Africa.
Final clue? – Its precise location is expressed in longitude and latitude as 0°N, 0°E. Which is, pretty much, a long way directly due South from where I’m writing this near London.
You should have guessed it by now, so here’s a track from my last visit there which might now start to look familiar to you?
Yep, it’s the intersection of the Prime Meridian and the Equator and the reason you’ve ‘been’ there is because, probably, some of your sports logs say you have on those occasions when you’ve not quite locked onto that satellite before heading off into the unknown.
More: Wikipedia – Null Island
There’s one thing I’m not sure about here. I think the name is wrong.
From my vague and distant memories of watching people programming, there is a difference between something deliberately set as ‘0’ compared to something which has never been set – maybe it’s called ‘n/a’ or blank or something else I don’t know. So I’m assuming that when you perform a Pool Swim workout that the GPS coordinates are correctly never set ie they are just ‘null’. These workouts never place me on Null Island nor should they.
To me, a Zero latitude/Longitude only seems to be set when something has gone wrong with, say, a run. GPS should have been recorded but wasn’t and so ‘0’ was explicitly set there by Mr. Garmin/Miss Polar rather than the coordinates being left unset as Null. By that logic, maybe the imaginary island for sports data should instead be called Zero Island or Double-Zero Island to be more explicit about its imagined location?
Then again, the Zero lat/long in question has been explicitly set to mean nothing was found when it was expected, so the zeros reflect the recognition of an error rather than ever meaning to be a location.
Help me out. I’ll lose sleep otherwise. Which is it? Zero Island or Null Island? And which should be in my FIT/TCX file?
Reader-Powered Content
This content is not sponsored. It’s mostly me behind the labour of love which is this site and I appreciate everyone who follows, subscribes or Buys Me A Coffee ❤️ Alternatively please buy the reviewed product from my partners. Thank you! FTC: Affiliate Disclosure: Links pay commission. As an Amazon Associate, I earn from qualifying purchases.
I’ve never had this (0, 0) GPS coordinate happen.
It depends on the programming language and type system. In databases and formal logic there is a different semantic meaning to null than most procedural programming languages.
Some languages cannot represent null — the absence of a value — very well and programmers will will represent the deliberate absence of a value with an arbitrary constant like -2147483648 (min value of a 32-bit signed integer).
Languages like JavaScript have a null concept built into every type but that is at the expense of memory and performance. C# uses the concept of generics to define a built-in Struct Nullable and some language syntax and smart compiler to allow the programmer to specify whether a given type is supposed to be nullable or must always be assigned a value.
SQL has a concept of null meaning a value has not been assigned in a field. This is different from 0 in a numeric field or a string with no length in a text field.
Sometimes null is treated as 0 in math or empty string in string concatenation and sometimes it has a special bizarre behavior, like contcat null with any string yields a null result.
C# and Java will crash (throw an exception) if you access a null object. The behavior of C is undefined when you access a null pointer but generally it is very bad like read or write to random memory.
Objective-C has a special nil concept for an object reference which is a kind of a safe replacement for a C void * null pointer. Objective-C just ignores messages sent to a nil pointer.
Null — especially accidental use of null — is the source of a lot of bugs.
typically, there is no memory or performance cost to null as it is literally the absence of allocated memory – a null pointer. some languages do weird things though
Maybe in C a null pointer is just 0 but that isn’t the case in a language like Java. Java implements a whole system of NullPointerException handling and stack trace for the purpose of dealing with a dereference of a null pointer with memory safety. There is quite a bit of overhead to this including the fact that all types have to be an object and allocated in the heap in Java and the garbage collector which tends to allocate more memory than manual allocation and incurs periodic pauses for object cleanup and heap compaction.
Rust does memory safety a totally different way that allows the compiler to guarantee that no null pointer dereference can happen. The compiler verifies all of the memory references and access logic are valid at compile time. That allows Rust to have memory safety without overhead of Java.
Oh and null can easily mess up aggregate functions in a database — like summing the value of a set of rows. Should the null rows be included in a avg() as zero values or should the null values be excluded so that number of rows in the denominator changes to excluded the null rows? The person writing the query has to know what the semantic meaning of null is in the context of the query in order to get a correct result.
and what should it be in your Garmin FIT file?
FIT files store coordinates as Semi Circles rather than degrees or radians. Basically take 360 degrees and divide by the max value that fits in a 32 bit integer. So there is no floating point math going on.
An invalid coordinate in a fit file is defined by both lat and lon equal to Int32.MaxVal. So definitely not null or zero. If you get zero’s, it’s just a bad fit file, or you’ve really been to zero island.
Null is generally used to refer to an object pointer or reference. 0 is a value. The way these would be stored in memory, at least for most languages, is the same. You need to now the “Type” of variable to make the distinction.
So 2^31-1 or 2147483647 (signed 32-but int max value) is defined as the invalid value and the underlying type is not nullable then.
in a well implemented language, null never equals any other value, including another null. however many languages are not well implemented so make lazy decisions like representing null as 0 and you then never know whether its a real 0 or not – exactly the question here.
when your data goes through enough different systems – eg garmin to strava to training peaks etc – chances are one of them will not handle nulls properly and decide to represent it as 0.
in a slightly different scenario, strava might reasonably think that in an activity with gps tracking, there should always be a gps coordinate on every record so when presented with a null it may not be able to handle that and instead substitutes a 0.
Why should null not be the same for all null objects? How are you supposed to check for null if you don’t know what null is? I’m sure there are some data base scenarios, but in general programming, that makes no sense. Are you arguing every null should actually be pointing to an object, that itself has a stored value indicating null? That’s really efficient on memory, and for what purpose? So you have a value inside this object that indicates null that is the same for every object? Makes no sense.
Ironically, I haven’t just lost bad runs/rides/swims to there, but also at least two drones. Back in the day of 3DR (once a drone company that could have competed with DJI but ended up falling by the wayside), there was a bug in one of their consumers drones they had, that in certain scenarios would if triggered overwrite the return to home GPS point to 0,0 while concurrently triggering a return to said homepoint. In both cases I was near the ocean, and the drones simply departed the US East Coast beach area, and literally flew off into the sunset towards Africa – deciding to no longer respond to commands and never to be seen again.
Ahh yes, the good ol’ days of drones when flyaways were surprisingly common.
🙂 when battery tech moves on perhaps that buoy will be a good place to hang out for some drone-freebies?
In this article, we explore the topic of Null Island in detail both from a technological and social perspectives: https://arxiv.org/abs/2204.08383
Old programming motto “null is not null” (or null != null)… basically leaving nulls in code (regardless of whether it has null handling natively) is a sloppy practice.
Regarding the island, Id’ say null island and 0/0 island are 2 diffferent places. In some “realities” (programming contexts) null will lead to 0/0. In others, it may lead somewhere totally different (2^32-1 for example). All that to say, in general with a GPS “written file” I would assume (key problem with nulls, is assumptions) that null island lives at 0/0 or some other “defined” place (by code) and not at “null”. But again, that’s an assumption. Basis is this though…
GPS data is “written to a file”… you can’t really write a “null” value to anything, thus, even if a null condition is encountered, when written to the file, the programmer must choose something to write, given that the simplest value for “safety’ is “0” (bye bye DCRainmaker’s drone, LOL), timestamp 01:07:36, location (not received by GPS), written as lat 0, long 0, etc, next row, pinged GPS, lat a.b.c, long x.y.z, pace per 1 second ping distance change, 1462 miles per second (congrats, new PR!).
TL;DR version – I can’t say what Garmin writes by default (I can, but I’d have to stop my real job to pull one down, open it and look, LOL)… what I CAN say is what Polar does on it’s files. If it loses GPS position, it rewrites the last-known position at each timestamp, until it acquires a new position. This means if you go in a tunnel and it “gives up” then after you emerge from the tunnel, if you play back “relive” the workout, you’ll see your circle sitting on the path, “holding in place” for say 30 seconds or whatever till it recalculates GPS, then “jump” to the new location. I’d say this is far preferable to a random trip to “null or zero island” in the middle of the workout stinks if it happens in a windy switchback canyon, it might detect a positional difference of 100ft when you went 1/4 mile back and forth on switchbacks between detected GPS points, LOL. I’m guessing without looking Garmin does similar, but maybe not? <I've cut the rest of the TL part, LOL, went down the technical rabbit hole)