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 <willy...@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 
<dbas...@gmail.com<mailto:dbas...@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
_______________________________________________
postgis-users mailing list
postgis-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/postgis-users

Reply via email to