The lat/lon floating point delusion

The brackets in the table mean that different sources of the element have different proportions of isotopes, so the mean atomic weights for specific deposits may cover a range that differs from the overall mean for every deposit of the element ever measured.

I.e. if you measure carbon from the upper atmosphere, it's going to have more C-14 in it, from cosmic rays flipping protons in N-14 to neutrons. And if you measure carbon buried for thousands of years, it's going to have less C-14, from natural decay.

If you look at https://en.wikipedia.org/wiki/List_of_physical_constants you can see that the parentheses are omitted from defined constants, and included for measured constants.

These kinds of issues are what we've solved at QALocate.

There are a number of different issues here, which I think are only partly explored through the article.

Let's take as given that you need to direct a person some place. In the article, they are directing someone to a restaurant. But this gets complicate fast. Is this person a patron rather than, say, a deliver driver there to pick up an order, or a plumber there to fix and appliance, or an inspector there to observe the kitchens, or ...?

By using a lat/long, or any geo-coordinate, we lose the human-value of context. Each of the folks I list above has a very different place they potentially need to navigate to. And even if their destination is the same, the routes they took may NOT have been. Where they park, or were dropped by ride share, and which doors they use are also influenced by their role.

Using a geo-coordinate to drops the rich meaning that humans in all their roles require. A better solution is to use a real identity and then, when and where coordinates are needed, derive them based on the persons role, whether it be patron, plumber, or paramedic. As roles change, or as the structure itself changes, then directions change to meet them. I find this a much richer solution than just blindly telling my maps app to direct me to some GPS location.

Another issue hinted at but not deeply explored is that often what we want to specify is a region or volume, not a coordinate. Things in the real world consume volume. Coordinates are idealized points and do not. This may seem a trite observation, yet, the majority of our tools think in terms of points. With the rise of autonomous vehicles, especially drone delivery, we need to move towards representations of regions and/or volumes, depending on needs. I'm not convinced that geopolys are quite right for this task and instead we need something that is comfortable with the fuzzy and complicated boundaries humans have to deal with.

[1] http://www.qalocate.com

I think the issue is that people don't have an good intuition for how many digits past the decimal point are relevant in latitude and longitude. "42 degrees north" is obviously imprecise. 42.123456 is precise down to a millionth of a degree; but if you wake me up in the middle of the night and ask me how long is one millionth of a degree of latitude at sea level, I wouldn't just be able to blurt out the answer.

Turns out it's about 11 cm.

A millionth of a degree is about 1.75E-8 radians. For small degree values, sin(x) = x, so we can just multiply that figure directly by the radius: ~ 6400000 m * 1.75E-8 = 0.112 m.

Professional geospatial systems frequently use fixed point internally but export floating point for convenience. The Internet treats all geospatial as floating point but positional measurement systems and mapping base layers often come from fixed point data models.

Many of the underlying fixed point systems are designed for meter precision, with some newer systems going down to a centimeter. As a practical matter, repeatable positioning on the Earth's surface becomes difficult below 10 centimeters of precision, so centimeter precision is widely viewed as the physics floor.

What would future proofing even look like?

For me I think we need to move away from thinking first/primarily in terms of coordinates. Yes, I know that sounds silly but hear me out.

Say someone is going out to meet a friend at a restaurant they haven't been to before, or perhaps they don't exactly recall the directions they took the last time -- how do they find directions? The first thing they most definitely do not do is say "hey maps app, tell me how to get to -37.80467681 144.9659498".

There is a level of indirection we go through via the names of businesses, places, etc. So we ask, "tell me how to get to I Love Istanbul". And we hop through a number of steps mapping that unstructured name to some coordinate.

But what if instead we used structured names instead of unstructured "names"? Then those names could map to a coordinate, or a street address, or well anything. What's more we could attach metadata to the name.

This is what DNS does. Humans know the names. They are structured according to some simple to follow rules. And computers take care of mapping those names to IPs, as well as other metadata.

Why not do exactly the same, but with locations? Re-use the same system but map to a coordinate? Or a region? Or whatever you need for your use case.

If you did this you'd now have an L-NS instead of a D-NS. That's exactly the insight we've had at the startup I'm working at.

[1] https://www.qalocate.com/resources/