Here's my rule of thumb table...
Latitude coordinate precision by the actual cartographic scale they purport:
Decimal Places Aprox. Distance Say What?
1 10 kilometers 6.2 miles
2 1 kilometer 0.62 miles
3 100 meters About 328 feet
4 10 meters About 33 feet
POINT #1. lets differentiate Precision from Accuracy
As it is clear from the picture we can talk about Accuracy of a measurement (e.g. GPS measurement) if we already know the actual value (exact position). Then we can say how accurate a measurement is. On the other hand if you have some measurements and don't know the actual value you can just talk about ...
so one symbol (letters or digits) is base 32 (8 bits) Each first bit is used for high or low window, then subsequent bits divide the precision by 2. (so divide by 8 in the best case) but there is an alternance between lat and long precision, so it ends up dividing by 4 and 8 alternatively.
1 ± 2500
2 ± 630
3 ± 78
4 ± 20
5 ± 2.4
6 ± ...
I'll try to explain it in different terms:
Earth's equatorial circumference is about 40,000 kilometers (25,000 miles).
A latitude/longitude value breaks that distance up into 360 degrees, starting at -180 and ending at 180.
This means that one degree is 40,000 km (or 25,000 miles) divided by 360:
40,000 / 360 = 111
25,000 / 360 = 69
(So, one degree is ...
I'm surprised it's quite so coarse, but there it is. It's not DISTINCT, per se, it's the '=' operator, which is defined for geometry as 'equality of the index keys' which means practically 'equality of the 32-bit bounding boxes'.
You can see the same effect just using '=' directly,
select 'POINT (0.000000001 0.000000001)'::geometry = 'POINT (0.000000001 0....
This illustration stuck with me, and helps me remember at the most basic level what precision vs. accuracy is.This is the source of the image, also containing a little more context. In general, Precision is the how close your grouping of measurements are. Accuracy is how close your measurement is to the actual measurement in the real world.
Blah238 is right,...
With qualifications and suitably modified, this is correct: the standard deviation measures spread, which is inversely related to precision, while the vectors (not distances) to the reference points measure inaccuracy.
With only five readings per location several problems will arise:
The standard deviations of the coordinates will vary--by a ...
The page you linked to hints at the answer; find the area of your bounding box and divide by the bucket area. It leaves out how to calculate the size of each geohash bucket, though, although it gives an example with precision 5.
According to the page you linked to, it'll stop the query at 10000 buckets.
Calculate the area of your bounding box in degrees ...
You can do this by adding a trigger to the table you're editing. First, you can define a generic snapping trigger:
CREATE OR REPLACE FUNCTION snap_coords ()
RETURNS TRIGGER AS $$
NEW.geom := ST_SnapToGrid(NEW.geom, TG_ARGV::float);
$$ LANGUAGE plpgsql;
You could have this function snap to a fixed precision (such as 1e-5), ...
I think I can answer it for you.
If you look at the precision vs. accuracy image on the link you provided, precision refers to the repeatability of the observation. For example, if I measure the distance from one point to another and it is always vaying only by a very small amount, then I am making measurements at a high precision.
But, basically, ...
Given Paul Ramsey's excellent explanation of why the next question is what can be done about it. How do you SELECT DISTINCT on geometry fields and have it perform as expected?
In Paul's answer, I proposed using SELECT MAX(geom) FROM the_table GROUP BY ST_AsBinary(geom); but MAX() is slow, apparently requiring a table scan.
Instead, I found this to be ...
Because these are regular points, you effectively already have a DEM; it's just in a different format than ArcGIS likes. This makes two different strategies available to you:
Convert the data into a format ArcGIS can handle. One way is to set up a raster extent and cellsize that (i) cover your DEM and (ii) situate each point near the middle of its cell. ...
ok, i think i found the trick!
after you gave me your data sample set, my first thought was: What a crap! ;)
Your sample consists of 71 single lines, which partly overlap and have some tiny offsets as well.
i guessed that GRASS would be the way to go, and ... tada .. it is
so, this is your line data labeled with its feature ids.
If you know how to do it, ...
You can create a new field (real) to the table specifying wanted precision.
Then just copy the original field value to the new field with the QGIS calculator : https://www.qgis.org/en/docs/user_manual/working_with_vector/field_calculator.html
See the screenshot below :
Replace the expression by the original field name.
Just an update, for PostGIS 2.4, SELECT DISTINCT works correctly for the points data in the OP:
CREATE TEMP TABLE test (geom geometry);
user=> INSERT INTO test
user-> (St_GeomFromText('POINT (0.1 0.1)')),
user-> (St_GeomFromText('POINT (0.001 0.001)')),
user-> (St_GeomFromText('POINT (0....
Short Answer No, if both accuracy and precision remain the same.
Long Answer You are confusing the Precision from the Accuracy.
According to this page from Wikipedia ([...] are added by me for the sake of clearness):
[...] the general term accuracy is used to describe the closeness of a
measurement to the true value [...] and precision is the ...
QGIS uses GDAL to write the GeoJSON file. GDAL uses the COORDINATE_PRECISION environment variable. In QGIS that variable is hardcoded with the value of 15 (the same as the GDAL default).
If you really want this, you can submit it as a new feature request at https://github.com/qgis/QGIS/issues.
I get the same picture, but there is nothing wrong with that.
Spatialite stores REAL values as floating point, hence no precision is needed.
The width and precision fields are necessary for shapefiles, which store REAL data in a database of an old dbase format which needs width and precision to be set explicitely.
It seems that the pictures in the exercise ...
It needs to be set in the "layerOptions" parameter. This parameter takes a list of strings of the format "OPTION=VALUE", corresponding to OGR layer options for the vector format. So, for coordinate precision, try setting this parameter to:
(or whatever your desired precision is). Additional valid parameters are listed on the OGR ...
There is no meaningful way to link "time the GPS is on" with a particular precision level. The accuracy is driven by many factors ranging from the characteristics of the hardware (especially the antenna) through to atmospheric conditions and GPS satellite constellation configuration.
A reasonable approach (using information you can get from most receivers) ...
Resolution in raster/grid context is the "cellssize", or the width/height in a certain unit (meter, feet etc) of each cell/pixel in the grid.
I have seen the term precision used in two ways with grids:
Most of the time, the same as you referred to, the accuracy of the measurement
Datatype being used for cell/band values, e.g float, double, integers
The ArcGIS 10.0 Help indicates coordinates closer than the XYtolerance are considered identical. The feature coordinates are not identical but are considered identical. Your finding that the features displayed as identical sounds correct. I have not tested the special case where the distance is equal to the XYtolerance. Also, the XYresolution setting (...
The forerunner of the current implementation of coordinate management in geodatabases was first integrated with the rest of the Esri product line (Arc/Info workstation, ArcView, and ArcIMS) when the "SDBE" product was purchased in the mid-1990s. At the time, the "SDE" training classes where half 'C' programming and half SQL, and multiple days were spent ...
As of PostGIS 2.5, the geometry and geography types only support storage of double-precision floating point values. Any coordinates that you input to PostGIS are converted to the geometry type, and thus will be rounded to double-precision before finding their way to SFCGAL.
Maybe it is possible to reduce the precision of your geometry in CGAL before ...
Your guess about the Precision ist correct! A Precision of 3 will result in a number with three decimal digits, e.g. "n.nnn". Some more examples on "precision" and "width" (the latter is not available/necessary in your context): Manually Adding a Decimal Field to the Attributes Table
The situation is strange because it's complex. Remember that SDE predates ArcGIS, as do dBase and Oracle. Therein lies the problem.
dBase has two potential encoding schemes for numeric data. Oracle has one encoding scheme for all numeric types (both floating-point and integer).
For a long time, SDE (which uses an ODBC model, and classifies numeric data by ...
i think the interpolation method for dem changes to everybody for area of usage.
Not only interpolation method, but also creating dem method can change to usage. For example if you want to work more complex areas you should use TINs instead of altitude matricez structure to create dem. there is lots of information about interpolation but i want to give you ...
The answer given to this question had alternative but not the solution.
The solution is as follows:
In the Table of Contents, right-click on the layer with the Attribute Table of interest and select: Properties - Fields.
Suppose you are converting STFID to a numerical field called STFID_NUM. Then in the “Layer Properties” window that opens, scroll down to ...
A DTM is an approximation from which it is possible to infer meaning about the world. Publishers of height data tend to give measurements of how closely a model fits the real world. But that does not tell you how well it will infer meaning for a particular question.
For example, if you want to calculate gradient for a very flat area of land a sparse model ...