This makes no sense to me. Generally speaking an application should return an error message or code when something goes wrong, not a potentially valid piece of data. That an entire industry would adopt this kind of workaround for poor software engineering is astonishing.
Seriously, it's a domain with huge under-the-surface complexity (no pun intended)[1], and most of the early efforts were spent in dealing with the maths and science, rather than software engineering. Things are getting better though.
My biggest qualm with Go is exactly this. Especially when deserialising data, data that wasn't sent vs empty/default data can be quite different things, yet you have to be very wary of the values you are processing. Ints default to 0, bools to false... Fuck.
No, but there are no other languages applicable in this context, really. You need a (de)serializer in each and every one of them, so you have to find some library, and that also includes Go. The easy choice in Go is the default one (simply called json), but there are quite a few alternative (de)serializers and validators. The GP just didn't look for them.
I’m guilty of sending results to null island for various reasons and it can be confusing, but to give the user simply an error would be worse, as they have nothing rather than something.
If for some reason we can’t get a geolocation, for various reasons, even a user simply denying access to gps, we can still deliver meaningful results as while the data is improperly located, it still has meaningful coordinates relative to itself and can be transformed later.
If you can handle an error and still return meaningful data that's fine, but returning the coordinates 0,0 to the user because GPS isn't working is far worse than giving them an error message. At that point you're essentially lying to them.
You need an origin, and tbh, there’s things that could be worse, somethings that looks close to what you expect, but actually subtly wrong, which is something we deal with on pretty much a daily basis. At least most of our customers are very unlikely to be doing anything at null island and the problem is obvious.
To a certain extent, all gps data is lying to you, it’s about figuring out how much it’s lying to you, sticking something at 0,0 is fairly tame and much easier to detect than something being out by 5cm
We do indicate to the user in the ui if no gps signal is available for example, or it’s low quality, but sometimes we get things like the system reporting it’s current location as the estimated location of the last wifi connection.
We also might start something and have no gps, but acquire it later, could be seconds, minutes or never, the accuracy can increase and decrease, we don’t force the user to give up, we record what we can. we still face limitations from software further down the chain that require coordinates as inputs.
There's a huge difference between recognizing that most software will have some bugs and creating a system that's so broken by design that you have to invent a fictitious island to work around it.
