Should geographic topology be included for Contracted Catchments?

[jyucsiro]

Geofabric v2.1 links HR Drainage Divisions (DD) and River Regions (RR) to HR Contracted Catchment (CC) via lookup tables. These lookup tables assert the link between DD and RR respectively. The team is not sure how the lookup tables are generated.

See http://www.bom.gov.au/water/geofabric/documents/v2_1/AHGF_GDB_ProductRelationships_V2_1_release.pdf

The issue is that there are CC instances that do not appear in the 'authoritative' lookup tables. As a result, the topology between a DD or RR to CC is not guaranteed to be complete (i.e. there may be holes). Some of these CC instances seem to have ConCatID = NULL.

e.g.

For some use cases, it may be desirable to calculate and assert relationships which capture the geographical topology. This would include all CC instances, including those which are not linked in the authoritative lookup tables.

Should the geographic topology between RR and DD to CC be created as a separate graph?

[dr-shorthair]

The CC's that do not appear in the LUTs seem to have ConCatID = "NULL" We should find out who the 'owner' of GeoFab is (within BoM) and ask

1. if this is intentional, or a QA/QC issue
2. if intentional, then what does it mean.

We should not let this stall progress, but should put it on the stack for further investigation.

[dr-shorthair]

How do we find the custodian of GeoFab?

[jyucsiro]

We're looking into contacting Geofabric dataset custodians.

[jyucsiro]

In http://www.bom.gov.au/water/geofabric/documents/v2_1/AHGF_GDB_ProductRelationships_V2_1_release.pdf ... some other issues.

There is no explicit topological relationship between HR DrainageDivision and RiverRegion although it looks like there are geographical topology between them. Should geographical topology between them be added?

[dr-shorthair]

Even if no explicit relationship in GeoFabric model, in the geofab ontology these things are all sub-class-of geo:SpatialObject so all the topological predicates from GeoSPARQL are available in this context.

[jyucsiro]

Decision: to map the topological/geometric relationship between RR<>CC and DD<>CC as a distinct CSIRO product in Loc-I. Include the sinks and flows in the attribute of the CC.

Work out where to put the annotation of sinks/flows to the CC - either in a linkset or in geofabricLd.net

[dr-shorthair]

re. annotation of sinks/flows: AHGF Contracted Catchment (polygon) has drains/drains-to relationships with cardinality [0..1] (see diagram above). drains links to a Node, while drains-to links to a polyline, but I'm not quite sure of the semantics of these. If we can figure that out, then it shoudl be simple to find the sinks: they are catchments that do not have a drains / drains-to relationship.

The geofabric ontology only captures part of the AHGF model, and does not currently support connectivity. So something would need to be added to persist this information. Maybe just a boolean flag: geofabric:isSink.

However, we probably also need to consider CCs that only drain into another CC which itself is a sink. So perhaps geogabric:isPartOfSink ?

[dr-shorthair]

I just realised - we can use a simpler method to detect the sinks - does not have a ConCatID. So maybe the flag should be geofabric:hasConCatID with a default value of TRUE so it only needs to be recorded if it is FALSE.

[dr-shorthair]

BTW - @benjaminleighton and I have just been chatting to James Bennett about GeoFab. In the course of that discussion we realized that (2D) hydrologic connectivity computed from the DEM does not correspond with true hydrologic connectivity or with (2D) spatial connectivity when a pipe has been pushed through the mountains to make an unnatural connection from one catchment to another.

Which ruleset do the Geofabric 2.1 lookup tables follow?

[jyucsiro]

I just realised - we can use a simpler method to detect the sinks - does not have a ConCatID. So maybe the flag should be geofabric:hasConCatID with a default value of TRUE so it only needs to be recorded if it is FALSE.

It would be effective and true-er to the source data. Meaning would be implicit, which we could document in release notes.

[dr-shorthair]

I was mis-remembering - you can set default values in XSD but not RDFS/OWL.

[jyucsiro]

So the proposal is to create geometric relationships for a) DD instances and RR instances, e.g. rr:exampleRR1 geo:sfWithin dd:exampleDD1 b) All RR instances and all CC instances (sinks and non-sinks), e.g. cc:exampleCC1 geo:sfWithin rr:exampleRR1

We also propose to annotate each CC instance like so:

#example of contracted catchment that's not a sink
cc:cc:exampleCC1 
   a geofabric:ContractedCatchment ;
   geofabric:hasConcatID false 
.
#example of contracted catchment that IS a sink
cc:cc:exampleCC2 
   a geofabric:ContractedCatchment ;
   geofabric:conCatID "1234";
   geofabric:hasConCatID true;
.

@dr-shorthair is that what you were thinking?

[dr-shorthair]

I think you have id/sink logic reversed. If no ConCatID then it is a sink.

[jyucsiro]

ok so

#example of contracted catchment that _IS_ a sink
cc:cc:exampleCC1 
   a geofabric:ContractedCatchment ;
   geofabric:hasConcatID false 
.
#example of contracted catchment that _IS NOT_ a sink
cc:cc:exampleCC2 
   a geofabric:ContractedCatchment ;
   geofabric:conCatID "1234";
   geofabric:hasConCatID true;

?