Geospatial reasoning+provenance demo app

[gordom6]

Henrique's requirements:

• Easy import of geo file formats (geojson, KMZ, shp etc) backend by SETLr with provenance tracking
• Easy geo reasoning without the need of writing sparql predicates - it would translate to sparql and pass it to twks for the user

In DSA we have only two data sources at first . Census.gov and NTIA Redbook. In truth, we introduced census.gov because of the higher quality of the data. There are clearly links that we do not express right now:

• provenance of the ntia locations . Document (version, release) , policy (ies)
• how we inferred relationships between ntia locations and census locations
  We have census.gov transformation provenance on the other side
  Also in DSA, there is this recurring discussion about letting users create their own shapes

[gordom6]

Henrique Santos 10:07 AM
GeoSPARQL already provides a query rewrite feature that enables you to simplify your sparql by expanding the geo predicates applied over geo:Feature to their respective geometries sf:Point , sf:Geometry etc. I would like to go a level higher. For instance, given a Model with a set of arbitrary locations (features and geometries) (i.e. requests locations), selective expose each geo relationship against a stored set of locations (i.e. NTIA, Census). That could be done by providing a api call for each relationship for instance

Minor Gordon 10:08 AM
geo relationship = contains, outside, overlap, etc.?
new messages
Henrique Santos 10:08 AM
Yes

[gordom6]

Henrique Santos 10:09 AM
Nice. We have modeled our policies with the within relationship only for now. (edited)

Minor Gordon 10:09 AM
request within policy?
new messages
Henrique Santos 10:10 AM
Yes. request location within one of the policy locations

[gordom6]

Minor's vision 20191029:

The most important criteria for a good TWKS demo application are:

• data where provenance matters
• reasoning
• visuals

I’m thinking about geospatial applications where you have multiple sources (cadastral data, LIDAR, vessel tracking data) reporting polygons for the same real-world entity (a plot of land, a ship in the ocean) and you need to figure out what the “true” polygon is. The reasoning is over source (hardware) accuracy, user preference, temporal validity, and so on. The visuals are obvious.