[postgis-users] Tolerance/SnapTo in Postgis Topology for meter and degrees.

Lars Aksel Opsahl Lars.Opsahl at nibio.no
Tue Jun 11 04:34:42 PDT 2019


I had a discussion with Knut Bjørkelo a co worker of me today.

He was wondering if we could use https://epsg.io/3035, then all the area values should be correct for all valid UTM Zones in Noway.

When we need to show a map we transform in to the correct to UTM zone to get a visual correct map also.

If I test a single point the transformation seems be accurate up to 4. decimal using 3035 even for a extreme point.

select ST_AStexT(ST_Transform(ST_Transform(ST_Transform(ST_Transform(ST_setSrid(ST_MakePoint(1108142.0,7788000.0),25835),3035),25832),3035),25835));



 POINT(1108142.00005503 7787999.99979103)

(1 row)


From: postgis-users <postgis-users-bounces at lists.osgeo.org> on behalf of Lars Aksel Opsahl <Lars.Opsahl at nibio.no>
Sent: Monday, June 10, 2019 10:50 PM
To: PostGIS Users Discussion
Cc: Sandro Santilli
Subject: Re: [postgis-users] Tolerance/SnapTo in Postgis Topology for meter and degrees.


You have this C-code

4870 _lwt_minTolerance( LWGEOM *g )

4871 {

4872 const GBOX* gbox;

4873 double max;

4874 double ret;


4876 gbox = lwgeom_get_bbox(g);

4877 if ( ! gbox ) return 0; /* empty */

4878 max = FP_ABS(gbox->xmin);

4879 if ( max < FP_ABS(gbox->xmax) ) max = FP_ABS(gbox->xmax);

4880 if ( max < FP_ABS(gbox->ymin) ) max = FP_ABS(gbox->ymin);

4881 if ( max < FP_ABS(gbox->ymax) ) max = FP_ABS(gbox->ymax);


4883 ret = 3.6 * pow(10, - ( 15 - log10(max?max:1.0) ) );


4885 return ret;

4886 }

In postgis branch svn-2.5 we have this SQL code.

CREATE OR REPLACE FUNCTION topology._st_mintolerance(ageom Geometry)

RETURNS float8

AS $$

SELECT 3.6 * power(10, - ( 15 - log(coalesce(


greatest(abs(ST_xmin($1)), abs(ST_ymin($1)),

abs(ST_xmax($1)), abs(ST_ymax($1))),


1)) ));


I am not that into C-code but the SQL code looks like the C-code above as you suggested in your mail.

So I did a small test https://github.com/NibioOpenSource/pgtopo_update_sql/blob/develop/src/test/sql/snapto/snapto_code_example_degrees_st_min_tolerance.sql using topology._st_mintolerance and yes I was able to get snap to every second line both vertically and horizontally to work and both and north and south in Norway. I just got this to work by playing around with topology._st_mintolerance together different factor values.

But I have no idea about how I can use this min tolerance code to make a generic code that behaves like 10 meter tolerance in a planar projection.

And I am also little unsure about what projection that is correct to use for datasets that covers all of Norway now.

Before we did not really have any choice because the projection was quite bad if moved outside the bonds of the projection limits. We pretty much had to use degrees to get the a OK quality if we needed to store the data in one single dataset.

So whats the "correct projection" now to use for original dataset that covers all of Norway and which are updated regularly ?

Thanks a lot.


From: strk at kbt.io <strk at kbt.io> on behalf of Sandro Santilli <strk at kbt.io>
Sent: Saturday, June 8, 2019 2:06 PM
To: PostGIS Users Discussion
Cc: Lars Aksel Opsahl
Subject: Re: [postgis-users] Tolerance/SnapTo in Postgis Topology for meter and degrees.

On Fri, Jun 07, 2019 at 10:02:23AM +0000, Lars Aksel Opsahl wrote:

> So the problem is how to use tolerances so we get a behavior equal to
> the test using meter.
> We can we define the layer in Postgis Topology with quite big value
> because this is just max value as it seems. So we can adjust the tolerance
> parameter as we add lines but the problem is that we need to adjust this
> parameter depending on where we are and what orientation the line has. For
> vertical lines we need a bigger tolerance than for horizontal lines in
> Norway. This makes it quite complicated to handle adding new lines.

I'm not sure if it'd help but PostGIS Topology has an internal
function (not to be relied upon, but could be copied to your own
function) to determine "min tolerance" based on absolute coordinate
values. That function is meant to deal with non-uniform floating-point
resolution. What you're after is a function to deal with non-uniform
tolerances. See
It used to be done in SQL with previous versions.

Could that help ?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20190611/4dae3a45/attachment.html>

More information about the postgis-users mailing list