[postgis-users] fuzzy tolerance

[Lars Aksel Opsahl]

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 <willybas at gmail.com>
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 <dbaston at gmail.com<mailto:dbaston at gmail.com>> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20160918/260547b2/attachment.html>