Rounding off coordinates

[Gino Lucrezi]

Hi all!

Since all coordinates are stored as double precision floating point numbers, they carry a great number of digits.

I know it is good to store them, because they help mitigate error propagation in many cases.

However, when displaying results, it is not really useful to show decimals up into the nanometer range. I'm sure noone's GIS data is SO precise :-)

SQL has the TRUNC and ROUND functions for scalar data. Is there any similar function for geometric data?

Gino Lucrezi
Penta Consulting Services Srl

[Gerry Creager N5JXS]

<SOAPBOX>
You've identified a problem that is pervasive in the GIS community.

Entirely too many people attempt to use all the precision offered by
their application, GPS device, or survey, without understanding the
limits of accuracy of the data.

While I'm a strong proponent of recording spatial coordinates to the
extents of their accuracy, I'm similarly a proponent of appropriate
management of the error terms to not infer extended accuracy in cases
where we have no basis.

What does your metadata say about the limits of the data? If you're
getting cm. horizontal accuracies from your GPS data (easily done with
survey techniques) report the data to that degree. If you're using a
consumer-grade receiver, I'd be leary of reporting data past the 6-m
accuracy limits routinely demonstrated for autonomous position.

If you're working off cadastral data derived from conventional survey
data, the extent of accuracy should be recorded on each platte.

The list goes on.

Error management is taught in first-year chemistry and physics in the
universities here, but is frequently lost on the students. We need to
be mroe diligent.

</SOAPBOX>

Sorry. We return you to your regular programming.

Gerry

Post by Gino Lucrezi
Hi all!
Since all coordinates are stored as double precision floating point numbers, they carry a great number of digits.
I know it is good to store them, because they help mitigate error propagation in many cases.
However, when displaying results, it is not really useful to show decimals up into the nanometer range. I'm sure noone's GIS data is SO precise :-)
SQL has the TRUNC and ROUND functions for scalar data. Is there any similar function for geometric data?
Gino Lucrezi
Penta Consulting Services Srl
_______________________________________________
postgis-users mailing list
http://postgis.refractions.net/mailman/listinfo/postgis-users

[Gino Lucrezi]

Post by Gerry Creager N5JXS
While I'm a strong proponent of recording spatial coordinates to the
extents of their accuracy, I'm similarly a proponent of appropriate
management of the error terms to not infer extended accuracy in cases
where we have no basis.

That's what I'd like to do. Keep as many digits as possible for internal storage, display to the user only those digits which are accurate enough.

A double precision floating point number has enough digits to allow for molecular-precision positioning :-) but I don't want to show them.

Is there a way to truncate those digits easily without adding more tools? When I inspect geometry data inside psql or pgadmin they get in the way.

If there is no way, and no one is working on it, I'd like to extend ROUND and TRUNC to handle geometry objects.

Gino Lucrezi
Penta Consulting Services Srl

[Charlton Purvis]

Hi, Gino:

I leave the_geom as is, w/ its beaucoup amount of precision, but
whenever I want to return something to the user, I return my own,
separate lon and lat columns which are updated by this insert/update
trigger:

new.lon := round(X(new.the_geom)::numeric,2);
new.lat := round(Y(new.the_geom)::numeric,2);

If you want to go to the trouble of intercepting your user requests and
return something other than the regular the_geom values, this works well
for me. (Don't know what you meant by not adding 'more tools'.) You're
not eliminating any precision in your db, but you are massaging the
user's perspective.

Charlton

[Gino Lucrezi]

Post by Charlton Purvis
new.lon := round(X(new.the_geom)::numeric,2);
new.lat := round(Y(new.the_geom)::numeric,2);

This is simple if you're working with point data; but what if you're using any more complex data type, e.g. a line or a polygon?
:-(

Gino Lucrezi
Penta Consulting Services Srl

[strk]

I've implemented a grid-based reduction function for postgis
which in fact rounds off coordinates.

It currently take a reference point and
a grid size (height, width of grid cell). Makes each geometry
point stick on the grid and removes duplicated point (thus
reduction).

If you are interested in supporting integration in postgis
I'll work on that.

--strk;

Post by Gino Lucrezi

Post by Charlton Purvis
new.lon := round(X(new.the_geom)::numeric,2);
new.lat := round(Y(new.the_geom)::numeric,2);

This is simple if you're working with point data; but what if you're using any more complex data type, e.g. a line or a polygon?
:-(
Gino Lucrezi
Penta Consulting Services Srl
_______________________________________________
postgis-users mailing list
http://postgis.refractions.net/mailman/listinfo/postgis-users

[Markus Schaber]

Hi, Strk,

On Mon, 28 Jun 2004 15:47:46 +0200

Post by strk
I've implemented a grid-based reduction function for postgis
which in fact rounds off coordinates.
It currently take a reference point and
a grid size (height, width of grid cell). Makes each geometry
point stick on the grid and removes duplicated point (thus
reduction).
If you are interested in supporting integration in postgis
I'll work on that.

We'd appreciate this, but you should take care that your function does
not create invalid geometries when applied to polygonal types.

We did such reductions in java code, and later had some unexpected
problems when trying to calculate intersection()s of such polygons in
postgres.

Greets,
Markus

[Paul Ramsey]

Gino,
Write up the function... base it on the parameters of the standard pgsql
round function that Charlton has demonstrated below, it would be a
useful addition.
Thanks!
Paul

Post by Gino Lucrezi

Post by Charlton Purvis
new.lon := round(X(new.the_geom)::numeric,2);
new.lat := round(Y(new.the_geom)::numeric,2);

This is simple if you're working with point data; but what if you're using any more complex data type, e.g. a line or a polygon?
:-(
Gino Lucrezi
Penta Consulting Services Srl
_______________________________________________
postgis-users mailing list
http://postgis.refractions.net/mailman/listinfo/postgis-users