fuzzy tolerance

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

fuzzy tolerance

Willy-Bas Loos-3
Hi

Why is it that PostGIS has no such concept as a fuzzy tolerance?
Tiny slivers can be a big problem.

In this talk on the FOSS4G in Bonn, this became increasingly clear to me: http://frab.fossgis-konferenz.de/en/foss4g-2016/public/events/1172
The speaker put a lot of emphasis on the fact that 98% of the coordinates would be slightly changed when retrieved to a client and saved again. This would result in many topology errors.

Cheers,
--
Willy-Bas Loos

_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: fuzzy tolerance

Stefan Keller
Hi,

There is at least SnapToGrid:
# select ST_SnapToGrid((ST_DumpPoints(mypoly.geom)).geom, 0.1) from mypoly;

:Stefan

2016-09-14 10:34 GMT+02:00 Willy-Bas Loos <[hidden email]>:

> Hi
>
> Why is it that PostGIS has no such concept as a fuzzy tolerance?
> Tiny slivers can be a big problem.
>
> In this talk on the FOSS4G in Bonn, this became increasingly clear to me:
> http://frab.fossgis-konferenz.de/en/foss4g-2016/public/events/1172
> The speaker put a lot of emphasis on the fact that 98% of the coordinates
> would be slightly changed when retrieved to a client and saved again. This
> would result in many topology errors.
>
> Cheers,
> --
> Willy-Bas Loos
>
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: fuzzy tolerance

Willy-Bas Loos-3
On Wed, Sep 14, 2016 at 11:27 AM, Stefan Keller <[hidden email]> wrote:
There is at least SnapToGrid:
# select ST_SnapToGrid((ST_DumpPoints(mypoly.geom)).geom, 0.1) from mypoly;

:Stefan

Hm, i considered that before, but now i can't say why i discarded the thought.
One thing is that the unit for snaptogrid is degrees for WGS84, so for world data that would pose a problem: you're not using a uniform grid to snap to.
But in other coordinate systems, and if the algorithm is fast enough, one could use this in a trigger and always store geometries snapped to a 10cm grid. That would be precise enough for our data.
It is easy to understand what is happening too, so that is an advantage.
BTW i tested and saw that it's not necessary to dump the points, you can snap the whole polygon.

Any words of warning about using a trigger and storing the data on a 10 cm grid like i suggest?

Cheers,


--
Willy-Bas Loos

_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: fuzzy tolerance

Ivan Santiago-2

Hello there:


ST_Snap(geom1,gem2,0.001) works too and affects only one of the geometries being compared.


I was doing some tests on simple geometries.  Spatialite, QGIS, and programs using OGC's Simple Features Standard don't recognize points over the interior of a line segment (because of the infinite number of points over the interior of a line)... I guess ...

I did some tests with simple geometries and they end up not recognizing the point over the boundary, even if I explicitly digitize it over the boundary using snapping procedures in QGIS.


Some workaround.... 'nodify' or inserting vertices over lines and boundaries when needed'.  This is analogous to cluster tolerance in ArcGIS, which has a tolerance system over geometries.


So If I wanted to 'count' points over a polygon using ST_Intersection... and make sure points over the interior (and over the boundary too) are selected I used:

select p.*

from points as p

, polygons as s

where st_intersects(p.geom(st_snap(s.geom,p.geom,0.001))


This puts a temporary vertex over the polygon's boundary, making a computational equality (or so) at the intersection of the point over the boundary.


Then the 'count' is more like the results of JavaTopologySuite TestBuilder when doing st_intersects. 


Now what I'd like to do next is testing over a real dataset and see if this procedure has significant performance drain or not.  I'm pretty sure somebody else has done this before.



Iván Santiago
GIS Specialist
Information Technologies
PR Office of Management and Budget
787.725.9420 x 2409
http://gis.pr.gov/

De : postgis-users <[hidden email]> de la part de Willy-Bas Loos <[hidden email]>
Envoyé : 14 septembre 2016 06:52:02
À : PostGIS Users Discussion
Objet : Re: [postgis-users] fuzzy tolerance
 
On Wed, Sep 14, 2016 at 11:27 AM, Stefan Keller <[hidden email]> wrote:
There is at least SnapToGrid:
# select ST_SnapToGrid((ST_DumpPoints(mypoly.geom)).geom, 0.1) from mypoly;

:Stefan

Hm, i considered that before, but now i can't say why i discarded the thought.
One thing is that the unit for snaptogrid is degrees for WGS84, so for world data that would pose a problem: you're not using a uniform grid to snap to.
But in other coordinate systems, and if the algorithm is fast enough, one could use this in a trigger and always store geometries snapped to a 10cm grid. That would be precise enough for our data.
It is easy to understand what is happening too, so that is an advantage.
BTW i tested and saw that it's not necessary to dump the points, you can snap the whole polygon.

Any words of warning about using a trigger and storing the data on a 10 cm grid like i suggest?

Cheers,


--
Willy-Bas Loos

_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: fuzzy tolerance

Stefan Keller
Be aware that snapping only works on nearby points. So given two
polygons there are maybe orphaned points on snap-polygon which still
are nearby a reference polygon segment but did not snap in the first
round. So, in addition the closest points on reference polygon to the
orphaned snap-polygon points are collected and the first snapped
polygon output is snapped again given this closest points collection.

See Snap_polygons_to_polygons.sql on
https://gist.github.com/sfkeller/9ba89b2a43be432c92b6335777ce6db9

:Stefan

2016-09-14 15:54 GMT+02:00 Ivan Santiago <[hidden email]>:

> Hello there:
>
>
> ST_Snap(geom1,gem2,0.001) works too and affects only one of the geometries
> being compared.
>
>
> I was doing some tests on simple geometries.  Spatialite, QGIS, and programs
> using OGC's Simple Features Standard don't recognize points over the
> interior of a line segment (because of the infinite number of points over
> the interior of a line)... I guess ...
>
> I did some tests with simple geometries and they end up not recognizing the
> point over the boundary, even if I explicitly digitize it over the boundary
> using snapping procedures in QGIS.
>
>
> Some workaround.... 'nodify' or inserting vertices over lines and boundaries
> when needed'.  This is analogous to cluster tolerance in ArcGIS, which has a
> tolerance system over geometries.
>
>
> So If I wanted to 'count' points over a polygon using ST_Intersection... and
> make sure points over the interior (and over the boundary too) are selected
> I used:
>
> select p.*
>
> from points as p
>
> , polygons as s
>
> where st_intersects(p.geom(st_snap(s.geom,p.geom,0.001))
>
>
> This puts a temporary vertex over the polygon's boundary, making a
> computational equality (or so) at the intersection of the point over the
> boundary.
>
>
> Then the 'count' is more like the results of JavaTopologySuite TestBuilder
> when doing st_intersects.
>
>
> Now what I'd like to do next is testing over a real dataset and see if this
> procedure has significant performance drain or not.  I'm pretty sure
> somebody else has done this before.
>
>
> ________________________________
> Iván Santiago
> GIS Specialist
> Information Technologies
> PR Office of Management and Budget
> 787.725.9420 x 2409
> http://gis.pr.gov/
> ________________________________
> De : postgis-users <[hidden email]> de la part de
> Willy-Bas Loos <[hidden email]>
> Envoyé : 14 septembre 2016 06:52:02
> À : PostGIS Users Discussion
> Objet : Re: [postgis-users] fuzzy tolerance
>
> On Wed, Sep 14, 2016 at 11:27 AM, Stefan Keller <[hidden email]> wrote:
>>
>> There is at least SnapToGrid:
>> # select ST_SnapToGrid((ST_DumpPoints(mypoly.geom)).geom, 0.1) from
>> mypoly;
>>
>> :Stefan
>
>
> Hm, i considered that before, but now i can't say why i discarded the
> thought.
> One thing is that the unit for snaptogrid is degrees for WGS84, so for world
> data that would pose a problem: you're not using a uniform grid to snap to.
> But in other coordinate systems, and if the algorithm is fast enough, one
> could use this in a trigger and always store geometries snapped to a 10cm
> grid. That would be precise enough for our data.
> It is easy to understand what is happening too, so that is an advantage.
> BTW i tested and saw that it's not necessary to dump the points, you can
> snap the whole polygon.
>
> Any words of warning about using a trigger and storing the data on a 10 cm
> grid like i suggest?
>
> Cheers,
>
>
> --
> Willy-Bas Loos
>
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: fuzzy tolerance

Lars Aksel Opsahl-2
In reply to this post by Willy-Bas Loos-3

Hi


One generic problem with adjusting input coordinates is that this mayl not solve the problem with overlapping or invalid polygons, because points in the center of a cell may go to any 4 grid points.


For example if you have two simple feature polygons that are suppose to have no gaps or overlap between them where they touch each other. Since this is simple feature the common part is not one object. If the common line is in the middle of grid cell then you may get overlaps or gaps.


You can say that the probability for this is very low and you may also say that there is bug in the input data when the common borders part don't have the same coordinates, but to compute this common part is not straight forward.


Another problem is also that a polygon that was valid on the client may not be invalid when saved on the server, because the points are moving.


We have used some snapTo in Java (JTS) but only when got a Topology Exceptions from the JTS in Java doing it like below. The polygonSnapRounder was code I got from Martian Davis some years a go. But one problem with this coding is that it makes the code more complicated and you may also cover up for bugs that are real or introduce new bugs.


try {

result = bigPolygon.intersects(areaToRemove);

} catch (com.vividsolutions.jts.geom.TopologyException e2) {

bigPolygon = snapRoundIntersecton(bigPolygon,areaToRemove, snapPM);

}


public static Geometry snapRoundIntersecton(Geometry a, Geometry b, PrecisionModel snapPM) {


Geometry aFix = PolygonSnapRounder.snapRound(a, snapPM);


Geometry bFix = PolygonSnapRounder.snapRound(b, snapPM);


return aFix.intersection(bFix);


}


So my point is that changing input data or to handle Topology exceptions is not an easy task and it's no guarantee for avoiding all problems as far as I can understand. This is one of the reasons that I started to look into Postgis the Topology work by Sandro Santilli.


Lars  




Fra: postgis-users <[hidden email]> på vegne av Willy-Bas Loos <[hidden email]>
Sendt: 14. september 2016 12:52
Til: PostGIS Users Discussion
Emne: Re: [postgis-users] fuzzy tolerance
 
On Wed, Sep 14, 2016 at 11:27 AM, Stefan Keller <[hidden email]> wrote:
There is at least SnapToGrid:
# select ST_SnapToGrid((ST_DumpPoints(mypoly.geom)).geom, 0.1) from mypoly;

:Stefan

Hm, i considered that before, but now i can't say why i discarded the thought.
One thing is that the unit for snaptogrid is degrees for WGS84, so for world data that would pose a problem: you're not using a uniform grid to snap to.
But in other coordinate systems, and if the algorithm is fast enough, one could use this in a trigger and always store geometries snapped to a 10cm grid. That would be precise enough for our data.
It is easy to understand what is happening too, so that is an advantage.
BTW i tested and saw that it's not necessary to dump the points, you can snap the whole polygon.

Any words of warning about using a trigger and storing the data on a 10 cm grid like i suggest?

Cheers,


--
Willy-Bas Loos

_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: fuzzy tolerance

Lars Aksel Opsahl-2
In reply to this post by Willy-Bas Loos-3

Hi again


I did a simple test with ST_SnapToGrid(geo, 0.001) on a real dataset that based on farm property border in Norway and intersection of this dataset http://www.skogoglandskap.no/en/subjects/ar5_land_resource_map/subject_view .


The result was almost 100.000 invalid polygons of 2.6 millions polygons.

I have added SQL below so you can check the way I have used the postgis functions.


The server I tested on has this configuration

postgis_full_version | POSTGIS="2.2.2 r14797" GEOS="3.5.0-CAPI-1.9.0 r4084" PROJ="Rel. 4.8.0, 6 March 2012" GDAL="GDAL 1.9.2, released 2012/10/08" LIBXML="2.7.6" LIBJSON="0.11" TOPOLOGY RASTER


First i convert the data to meter and check that it was valid then I did a st_snaptogrid and then I count who is valid who is not.


select count(*) as valid_rows from (

select ST_isValid(org_geo), ST_area(org_geo), ST_isValid(snap_geo), ST_area(snap_geo) 

from (Select geo as org_geo , ST_SnapToGrid(geo, 0.001) as snap_geo from (

select ST_transform(geo,25835) as geo from gaard_ar5_7kl_16_12_2012_flate

) as t1

) as t2 where st_isvalid( org_geo) and st_isvalid( snap_geo) 

) as t3;


valid_rows 

------------

    2648499

(1 row)



select count(*) as invalid_rows from (

select ST_isValid(org_geo), ST_area(org_geo), ST_isValid(snap_geo), ST_area(snap_geo) 

from ( Select geo as org_geo , ST_SnapToGrid(geo, 0.001) as snap_geo from (

select ST_transform(geo,25835) as geo from gaard_ar5_7kl_16_12_2012_flate

) as t1

) as t2 where st_isvalid( org_geo) and st_isvalid( snap_geo) = false

) as t3;


invalid_rows 

--------------

        94308

(1 row)



select ST_isValid(org_geo), ST_area(org_geo), ST_isValid(snap_geo), ST_area(snap_geo), ST_isSimple(snap_geo) 

from ( Select geo as org_geo , ST_SnapToGrid(geo, 0.001) as snap_geo from (

select ST_transform(geo,25835) as geo from gaard_ar5_7kl_16_12_2012_flate

) as t1

) as t2 where st_isvalid( org_geo) and st_isvalid( snap_geo) = false

limit 5;

NOTICE:  Self-intersection at or near point -712380.76390491705 6752484.312060223

NOTICE:  Self-intersection at or near point -712380.76390491705 6752484.312060223

NOTICE:  Self-intersection at or near point -693336.00845633878 6760997.9791273763

NOTICE:  Self-intersection at or near point -693336.00845633878 6760997.9791273763

NOTICE:  Self-intersection at or near point -685803.05900000001 6761659.9010000005

NOTICE:  Self-intersection at or near point -685803.05900000001 6761659.9010000005

NOTICE:  Self-intersection at or near point -686975.27643165435 6761818.4071217496

NOTICE:  Self-intersection at or near point -686975.27643165435 6761818.4071217496

NOTICE:  Self-intersection at or near point -685793.5384688942 6761692.5602394082

NOTICE:  Self-intersection at or near point -685793.5384688942 6761692.5602394082

 st_isvalid |     st_area      | st_isvalid |     st_area      | st_issimple 

------------+------------------+------------+------------------+-------------

 t          | 12071.0927293049 | f          | 12071.0915145167 | t

 t          | 1249.63589967907 | f          | 1249.62388100091 | t

 t          |  2438.3765259538 | f          | 2438.41668248867 | t

 t          | 8.73835355134684 | f          | 8.72929450303413 | t

 t          |  8.1236959106824 | f          | 8.12728899896324 | t

(5 rows)



Lars





Fra: postgis-users <[hidden email]> på vegne av Willy-Bas Loos <[hidden email]>
Sendt: 14. september 2016 12:52
Til: PostGIS Users Discussion
Emne: Re: [postgis-users] fuzzy tolerance
 
On Wed, Sep 14, 2016 at 11:27 AM, Stefan Keller <[hidden email]> wrote:
There is at least SnapToGrid:
# select ST_SnapToGrid((ST_DumpPoints(mypoly.geom)).geom, 0.1) from mypoly;

:Stefan

Hm, i considered that before, but now i can't say why i discarded the thought.
One thing is that the unit for snaptogrid is degrees for WGS84, so for world data that would pose a problem: you're not using a uniform grid to snap to.
But in other coordinate systems, and if the algorithm is fast enough, one could use this in a trigger and always store geometries snapped to a 10cm grid. That would be precise enough for our data.
It is easy to understand what is happening too, so that is an advantage.
BTW i tested and saw that it's not necessary to dump the points, you can snap the whole polygon.

Any words of warning about using a trigger and storing the data on a 10 cm grid like i suggest?

Cheers,


--
Willy-Bas Loos

_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: fuzzy tolerance

Daniel Baston
In reply to this post by Willy-Bas Loos-3
> Any words of warning about using a trigger and storing the data on a 10 cm
> grid like i suggest?

You may need to be aware of the differences between coordinates generated
by ST_SnapToGrid, and coordinates generated by conversion from text.  I
wrote a bit about this at http://gis.stackexchange.com/a/204431/18189

Dan
_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: fuzzy tolerance

Willy-Bas Loos-3
On Thu, Sep 15, 2016 at 1:58 PM, Daniel Baston <[hidden email]> wrote:
> Any words of warning about using a trigger and storing the data on a 10 cm
> grid like i suggest?


Wow, thanks for the great responses. Lars Opsahl, nice to see you in the mailing list :D
So what i gather from this is that it is not ideal to use st_snaptogrid. It solves some problems, but it creates some new ones too.
Maybe a second geometry column would be a better idea, so that the original is still there (and will consume your server's memory &hdd space :/ )
Anyway, there is no automatic way to solve the problem right now.

So how big are the problems that arise from this?
For me i have to say that we often have problems with errors in overlays, and we have to keep using st_makevalid after every step of a process. Decreasing the supersmall artifacts in the geometries would probably help with that.
@Lars Opsahl, you describe a lot of problems or very reasonable wishes in your presentation (link to abstract in previous mail). Do you think those could be solved with a concept similar to fuzzy tolerance?
@Daniel Baston could you describe some of the problems that the hyperprecise coordinates cause for you?

Cheers,

--
Willy-Bas Loos

_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: fuzzy tolerance

Stefan Keller
When speaking about fuzzyness and tolerance we really have to
distinguish different use cases, like
1 is it about storing geometries/numbers in finite data types (like
float) => integer geometry,
2 is it about geometry representation of polygons (as geometry or topology),
3 is it about representation of uncertainty of boundaries of real-world objects,
4 or is it about handling artefacts from analysis (like in intersection).

:Stefan


2016-09-16 17:20 GMT+02:00 Willy-Bas Loos <[hidden email]>:

> On Thu, Sep 15, 2016 at 1:58 PM, Daniel Baston <[hidden email]> wrote:
>>
>> > Any words of warning about using a trigger and storing the data on a 10
>> > cm
>> > grid like i suggest?
>
>
> Wow, thanks for the great responses. Lars Opsahl, nice to see you in the
> mailing list :D
> So what i gather from this is that it is not ideal to use st_snaptogrid. It
> solves some problems, but it creates some new ones too.
> Maybe a second geometry column would be a better idea, so that the original
> is still there (and will consume your server's memory &hdd space :/ )
> Anyway, there is no automatic way to solve the problem right now.
>
> So how big are the problems that arise from this?
> For me i have to say that we often have problems with errors in overlays,
> and we have to keep using st_makevalid after every step of a process.
> Decreasing the supersmall artifacts in the geometries would probably help
> with that.
> @Lars Opsahl, you describe a lot of problems or very reasonable wishes in
> your presentation (link to abstract in previous mail). Do you think those
> could be solved with a concept similar to fuzzy tolerance?
> @Daniel Baston could you describe some of the problems that the hyperprecise
> coordinates cause for you?
>
> Cheers,
>
> --
> Willy-Bas Loos
>
> _______________________________________________
> postgis-users mailing list
> [hidden email]
> http://lists.osgeo.org/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users
Reply | Threaded
Open this post in threaded view
|

Re: fuzzy tolerance

Lars Aksel Opsahl-2
In reply to this post by Willy-Bas Loos-3

Hi again


I am not sure if this problem with drifting points are solvable by using fussy tolerance and simple feature in a easy way.


The main problem by using simple feature is that if a user are moving 2 points in a line with 100 points. Simple feature spec does not include any spec to mark this2 points as moved and mark the rest as unmoved. This means that the applications has to send all 100 points back to the server which in most causes means the system moves more 90% of the points. Maps are also analog data that makes complicated to preserve exact value, the only format that seems to preserve the value are WKB  and no map projections.


In stead of solving the problem with drifting point maybe it's easier just to walk around the problem, by only sending the part of line that has changed back to server. This is how we have done in the https://github.com/NibioOpenSource/pgtopo_update_sql that depends Postgis Topology. By doing it this way we remove the possibility of drifting points and we send less data back to the server from the client.


But before you can start to update the data you need fix your exiting data the way to that is by using Postgis Topology and then you can use a snap tolerance to ensure that you get no small slices or gaps. Here is some guide lines on way to this by.


Here we have two lines that almost touch each other and that we want them to be one single line. By using Postgis Topology this lines are melted together. The basic idea is that you first add the lines that are ok, then you add the rest.


# create test schema if not exist

psql sl -c'CREATE SCHEMA IF NOT EXISTS test2;'


# copy file muni_buffer_out that contains not ok buffered out municipalitie border "where komid not in (125)" into table test2.sf_in (drop and create if exits)

shp2pgsql -W ISO-8859-1 -d -D -s 4258 data3/edge_1219 test2.sf_in | psql sl; psql sl -c "SELECT topo_help_sf_to_topology_case_1('test2.sf_in','topo_3.muni_surface');"

# copy data from test2.sf_in into table topo_3.muni_surface (append data to topo_3.muni_edge)

psql sl -c "SELECT topo_help_sf_to_topology_case_1('test2.sf_in','topo_3.muni_edge',0.00001);"


# copy file muni_buffer_in that contains not ok buffered in municipalitie border "where komid not in (214)" into table test2.sf_in (drop and create if exits)

shp2pgsql -W ISO-8859-1 -d -D -s 4258 data3/edge_1521 test2.sf_in | psql sl; psql sl -c "SELECT topo_help_sf_to_topology_case_1('test2.sf_in','topo_3.muni_surface');"

# copy data from test2.sf_in into table topo_3.muni_surface (append data to topo_3.muni_edge)

psql sl -c "SELECT topo_help_sf_to_topology_case_1('test2.sf_in','topo_3.muni_edge',0.00001);"


The scripts and data can found at https://github.com/NibioOpenSource/pgtopo_update_sql/tree/develop/src/test/sql/import

if somebody whats to test it.


At https://trac.osgeo.org/postgis/wiki/UsersWikiPostgisTopology I have added section

called “Convert shape file and simple feature data to Postgis Topology” that has some more info.


When all the lines are added you have build the surfaces by using topology.CreateTopoGeom

and using the edges added. The code for this is also found in pgtopo_update_sql but wrapped into different part so it takes some work to extract this code into single function like topo_help_sf_to_topology_case_1 . Hopefully I will get the time to fix this later.


Lars





Fra: Willy-Bas Loos <[hidden email]>
Sendt: 16. september 2016 17:20
Til: PostGIS Users Discussion; Daniel Baston; Lars Aksel Opsahl
Emne: Re: [postgis-users] fuzzy tolerance
 
On Thu, Sep 15, 2016 at 1:58 PM, Daniel Baston <[hidden email]> wrote:
> Any words of warning about using a trigger and storing the data on a 10 cm
> grid like i suggest?


Wow, thanks for the great responses. Lars Opsahl, nice to see you in the mailing list :D
So what i gather from this is that it is not ideal to use st_snaptogrid. It solves some problems, but it creates some new ones too.
Maybe a second geometry column would be a better idea, so that the original is still there (and will consume your server's memory &hdd space :/ )
Anyway, there is no automatic way to solve the problem right now.

So how big are the problems that arise from this?
For me i have to say that we often have problems with errors in overlays, and we have to keep using st_makevalid after every step of a process. Decreasing the supersmall artifacts in the geometries would probably help with that.
@Lars Opsahl, you describe a lot of problems or very reasonable wishes in your presentation (link to abstract in previous mail). Do you think those could be solved with a concept similar to fuzzy tolerance?
@Daniel Baston could you describe some of the problems that the hyperprecise coordinates cause for you?

Cheers,

--
Willy-Bas Loos

_______________________________________________
postgis-users mailing list
[hidden email]
http://lists.osgeo.org/mailman/listinfo/postgis-users