131–140 of 154 posts
Earlier quoted context omitted.
I absolutely love it when I read something like "The object was nearly 1 foot (30.48 cm) long."
“I wouldn’t touch that with a 3048 millimeter stick.” (A.k.a. a ten foot pole.)
(Or is that Centimetre? Probably a metric/Imperial thing... )
Earlier quoted context omitted.
Because the value, as presented, is wrong. "[but it's being used for] non-scientific, non-metrological purposes" which doesn't change that it's the wrong value. Imagine, for a moment, that someone uses these values to put up a fence. Is the fence on their property? Those crap values beyond the actual significant digits of the measurement may tell you that you are, when you're not. That will cost you time and money do…
> Because the value, as presented, is wrong. That's not true nor is it the problem at all. The thesis was that the values, albeit correct, have too many significant digits, which in turn reflect differences which lie somewhere between having no practical use or being absurd. > Imagine, for a moment, that someone uses these values to put up a fence. That example is very poor. Any engineer can tell you that a measureme…
But these locations are very precise, indicating high accuracy/low margin of error, but they don't have that high accuracy. In fact, the error could be in meters, rather than in the implied millimeters, so it definitely could be a problem for a fence.
Here is a college textbook chapter detailing types of precision and accuracy errors in GIS systems: https://www.e-education.psu.edu/geog469/book/export/html/252
"GIS users are not always aware of the difficult problems caused by error, inaccuracy, and imprecision. They often fall prey to False Precision and False Accuracy, that is they report their findings to a level of precision or accuracy that is impossible to achieve with their source materials. If locations on a GIS coverage are only measured within a hundred feet of their true position, it makes no sense to report predicted locations in a solution to a tenth of a foot. That is, just because computers can store numeric figures down many decimal places does not mean that all those decimal places are "significant." It is important for GIS solutions to be reported honestly, and only to the level of accuracy and precision they can support."
Or in other words, don't build a fence relying on naked coordinates of high precision but unknown accuracy.
In contrast to his 4-digits-are-fine notions, let me offer a counterexample: http://scissor.com/transient/destination_heatmap/ I am working on a Twitter bot called @sfships, which monitors the comings and goings of large ships in the San Francisco Bay: https://twitter.com/sfships As part of that, I generated the above map from AIS data. [1] It's basically where ships stop. If you zoom in on the San Francisco waterfro…
Another example: I was looking up my property details yesterday, and wanted to get exact coords for my property line. Their web app lets you click on the map to get coords, but it only displays degrees/minutes/seconds (with no decimal point), so it wasn't much use.
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, re…
Earlier quoted context omitted.
Error tends to grow as the calculation proceeds. 6th-decimal "insignificant rounding" done over and over as the calculation proceeds can grow to become arbitrarily large.
What numerically unstable algorithms are ever performed with geolocations? Moreover, given the author's point that real measurement errors exceed the false precision of published data, if such a calculation were performed and did provide "arbitrarily large" error, it would indicate that the result should in fact be nonsense.
Earlier quoted context omitted.
"Build the gravitational wave observatory between the Thai restaurant and the railway station"
You joke but a lot of radar/radio observation is done with ECEF coordinates, which is a (lat, lon, z-axis) triple.
Earlier quoted context omitted.
Are you proposing doing away with IEEE 754? That's probably the origin of all these extra digits.
Not at all. I'm suggesting people think about what they are doing. Blindly sticking numbers into a format that is designed to be computationally efficient is not a great way to store data. That doesn't mean that a computationally efficient representation is useless.
Earlier quoted context omitted.
Another example: I was looking up my property details yesterday, and wanted to get exact coords for my property line. Their web app lets you click on the map to get coords, but it only displays degrees/minutes/seconds (with no decimal point), so it wasn't much use.
Are you certain that the data is accurate enough to support better precision? Where I live we have avcess to vectorized property maps, but the data source may be a digitized 200 y/o map.
Agreement on the decimal places. But honestly, why would you commit to using GPS as the end means of locating in Australia when you'll be noticeable off in 20 years and outright inaccurate in 100? https://www.nationalgeographic.com/news/2016/09/australia-mo...
Earlier quoted context omitted.
Not at all. I'm suggesting people think about what they are doing. Blindly sticking numbers into a format that is designed to be computationally efficient is not a great way to store data. That doesn't mean that a computationally efficient representation is useless.
And I'm suggesting that using the built-in floating point representation is a good thing overall, even if it doesn't allow you to specify a precision.