BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//pretalx//talks.staging.osgeo.org//foss4g-2022//talk//9G3YGD
BEGIN:VTIMEZONE
TZID:CET
BEGIN:STANDARD
DTSTART:20001029T040000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
TZNAME:CET
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20000326T030000
RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=3
TZNAME:CEST
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:pretalx-foss4g-2022-9G3YGD@talks.staging.osgeo.org
DTSTART;TZID=CET:20220825T101000
DTEND;TZID=CET:20220825T101500
DESCRIPTION:When you care about data integrity of spatial data you need to 
 know about the limitations/weaknesses of using simple feature datatype in 
 your database. For instance https://land.copernicus.eu/pan-european/corine
 -land-cover/clc2018 contains 2\,377\,772 simple features among which we fi
 nd 852 overlaps and 1420 invalid polygons. For this test I used “ESRI FG
 DB” file and gdal for import to postgis.  We find such minor overlaps an
 d gaps quite often\, which might not be visible for the human eye. The pro
 blem here is that it covers up for real errors and makes difficult to enfo
 rce database integrity constraints for this.  Close parallel lines also se
 ems to cause Topology Exception in many spatial libraries.\n\nA core probl
 em with simple features is that they don't contain information about the r
 elation they have with neighbor features\, so integrity of such relations 
 is hard to constraint. Another problem is mixing of old and new data in th
 e payload from the client. This makes it hard and expensive to create clie
 nts\, because you will need a full stack of spatial libraries and maybe a 
 complete locked exact snapshot of your database on the client side. Anothe
 r thing is that a common line may differ from client to client depending o
 n spatial lib\, snapTo usage\, tolerance values and transport formats.\n\n
 In 2022 many system are depending on live updates also for spatial data.  
 So it’s big advantage to be able to provide a simple and “secure” AP
 I’s with fast server side integrity constraints checks that can be used 
 from a standard web browser. When we have this checks on server side we wi
 ll secure the equal rules across different clients.\n\nIs there alternativ
 es that can secure data integrity in a better way? Yes\, for instance Post
 gis Topology. The big difference is that Postgis Topology has more open st
 ructure that is realized by using standard database relational features. T
 his lower the complexity of the client and secures data integrity. In the 
 talk “Use Postgis Topology to secure data integrity\, simple API and cle
 an up messy simple feature datasets.” we will dive more into the details
  off Postgis Topology\nBuilding an API for clients may be possible using s
 imple features\, but it would require expensive computations to ensure top
 ological integrity but to solve problem with mixing of new and old borders
  parts can not be solved without breaking the polygon up into logical part
 s. Another thing is attribute handling\, like if you place surface partly 
 overlapping with another surface should that have an influence on the attr
 ibutes on the new surface.\n\nWe need to focus more on data integrity and 
 the complexity and cost of creating clients when using simple feature\, be
 cause the demands for spatial data updated in real time from many differen
 t clients in a secure and consistent way will increase. This will be main 
 focus in this talk.
DTSTAMP:20260403T193902Z
LOCATION:Room 9
SUMMARY:Data integrity risks when using simple feature - Lars Opsahl
URL:https://talks.staging.osgeo.org/foss4g-2022/talk/9G3YGD/
END:VEVENT
END:VCALENDAR
