Postgis Topology will replace simple feature.

Status:
Accepted

For spatial data systems where it's important to avoid overlap, gaps and give any end users a easy way to update the map, Postgis Topology is a must.

Let's look a some headlines :

* Normalize data, for instance shared edges should only be represented once.
Why : Avoid the possibility for gaps , overlaps, spikes and other error in the result.

* Must be simple to expand or reduce a polygon surface even if the border line contains thousands of points.
Why : Moving many points on a screen is difficult and time consuming and its's often is easier just to draw a new line that shows just the new part of the border.

* Only the actual changes should be written to the database.
Why : Or else you may get problems because of projections and different number off decimals and a point may move many centimeters just because of this.

* Removing lines should cause old surfaces reappear with original borders for layers that has 100% coverage.
Why : We want end users update our maps because they know best what is like there, but then we must accept errors and then it should easy to correct these error in a efficient way, for instance by removing the new line(s).

* Generalize and simplify on the fly.
Why : To reduce the amount bytes on wire it's important to give the user a good end user experience. Using topology makes this job much easier and faster.

We have now made a simple web client for updating topology layers of type surface, line and points where we are using a simple generic protocol based on JSON. We will show how simple and fast things can be done using this a client when the data are stored using Postgis Topology.

We have done a lot testing on topology you can find more info here http://www.slideshare.net/laopsahl/foss4-g-topologyjuly162015 .

Slides

Session details
Speaker(s): Session Type: Experience level:
Intermediate
Track: Tags:
Schedule info
Session Time Slot(s):
302B - Tuesday, May 3, 2016 - 10:30 to 11:05