[tgflynn]

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.

[lmc]

Welcome to GIS :D

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.

[1] here is a good jumping off point (imagine the technical debt this might lead to): https://en.wikipedia.org/wiki/Spatial_reference_system

[sk0g]

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.

[tgv]

Then don't use json.Decoder, or use pointers in your structs.

[smabie]

Or better solution, don't use Go.

[tgv]

Sure, do everything in JS. So much easier.

[xigoi]

Ah yes, Go and JavaScript, the only two programming languages.

[tgv]

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.

[secretsatan]

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.

[tgflynn]

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.

[secretsatan]

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.

[LorenPechtel]

The problem comes from databases. Sometimes you simply have no source for the data. (Say, your phone with GPS turned off and now towers around.)

[tgflynn]

That's what NULL (or it's various equivalents) is for.

[NotYourLawyer]

Have you ever seen software that correctly deals with error conditions in all circumstances? I sure haven’t.

[tgflynn]

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.

[NotYourLawyer]

What part of the design is broken? What design?

This looks to me like a bunch of individually broken pieces of software that have a common failure mode.