Open gordom6 opened 4 years ago
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
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
Minor's vision 20191029:
The most important criteria for a good TWKS demo application are:
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.
Henrique's requirements:
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: