SLAKE Water Storage Information Model

Background

The SurfaceWaterStorage is a draft model to provide a test for establishing Web Feature Services (WFS) to deliver water storage (reservoir) information from the Australian Bureau of Meteorology (BOM) SLAKE database.

Water models looked at prior to this proposalwere the WDTF (http://www.bom.gov.au/water/regulations/wdtf/document/WDTFguidelines.pdf), WaterML2 (http://meetingorganizer.copernicus.org/EGU2010/EGU2010-7680.pdf), GroundWaterML (http://ngwd-bdnes.cits.nrcan.gc.ca/service/api_ngwds/en/gwml.html) and the INSPIRE Hydrography model (http://inspire.jrc.ec.europa.eu/documents/Data_Specifications/INSPIRE_DataSpecification_HY_v3.0.pdf). All these have placeholders for surface reservoir data, but none have fully described features that enable delivery of the BOM SLAKE data.

This model is a draft proposal to be used to establish WFSs to test that it meets user requirements. Ultimately it should be used to inform development of one of the community driven water information models.

Discussion

I’m not sure I fully understand a couple of things in the modelling style though:

1) Why not just use a GM_Object as an attribute type – I don’t really know what a relationship gives us
2) Why have a specific storage details type with a cardinality =1 – it makes the concept of the reservoir dependent on the details – the dependency should be inverted – a class specialising reservoir and adding these attributes
3) Likewise, “slakereservoir” is kind of weird – all catchments depend on a SLAKE object?
4) In general I don’t like the bi-directional relationships – I’d only populate the ones you intend to be able to traverse from a FeatureType you plan to offer via the service interface – keep it simple – it’s not a model of everything, only what you offer.

-- RobAtkinson - 16 Nov 2010

So the suggested changes are:
1. Create a MappedFeature:shape property with Type GM_Object rather than association shape:GM_Object.
As GM_Object is a <<type>> and not a <<featuretype>>, although it has identity it cannot be delivered as a separate WFS feature, so there is not a lot to be gained by using the GeoSciML pattern.

2. Rename SlakeReservoir class.
For the same(?) feature, INSPIRE Hydrography uses "WFDSurfaceWaterBody", GroundWaterML uses "SurfaceWaterBody" and "SurfaceReservoir", WDTF uses "Storage". I wanted to make it clear that this is a bogus name for a feature that will need more work. I'll change it to "SurfaceReservoir" so it's less 'slaky'.

3. Remove the associations that are not required for SLAKE data delivery (eg WaterCourse to OM_Observation and to SlakeReservoir)
Agree - since Rob's point is that it describes the contract we (BOM) implement and not a true Water domain model.

4. The current model has catchment indirectly dependent on details of storage for the slake implementation, which is very narrow interpretation of a catchment.
I don't understand the dependency. My interpretation is that the Catchment feature may have 0 or many Reservoirs associated with it, independent of the details that describe the Reservoir. However, since we are only delivering SlakeReservoir (now SurfaceReservoir) features I'll remove the "associatedReservoir" property (based on point 3 above).

5. Replace OM_Observation with WaterML2:WaterMonitoringPoint.
Although this is more appropriate, I'm still a little reluctant to use any of the current 'accepted' schemas, such as WaterML2 or GroundWaterML in case it implies the 'slake' UML is a valid extension of these, rather than a temporary placeholder that one of them will replace.

-- BruceSimons - 18 Nov 2010

UML Model Diagrams

  • Enterprise Architect UML of draft SLAKE surface reservoir model (09 December 2010):
    SlakeReservoir5.jpg

  • Slake Package dependencies (9 December 2010):
    SlakeReservoir_Package_dependencies2.jpg

  • Enterprise Architect UML of draft SLAKE surface reservoir model base on GML3.1 profile (13 Apr 2011):
    SlakeReservoir_GML31.jpg

UML Model

-- BruceSimons - 09 Dec 2010
Topic attachments
I Attachment Action Size Date Who Comment
DependencyErrors_09122010.jpgjpg DependencyErrors_09122010.jpg manage 384.0 K 09 Dec 2010 - 09:12 BruceSimons Errors generated by HollowWorld
SlakeReservoir5.jpgjpg SlakeReservoir5.jpg manage 85.6 K 09 Dec 2010 - 09:04 BruceSimons Enterprise Architect UML of draft SLAKE surface reservoir model (09 December 2 010)
SlakeReservoir_GML31.jpgjpg SlakeReservoir_GML31.jpg manage 180.6 K 13 Apr 2011 - 14:59 FlorenceTan UML Model for Slake Reservoir base on GML3.1 profile
SlakeReservoir_Package_dependencies2.jpgjpg SlakeReservoir_Package_dependencies2.jpg manage 55.7 K 09 Dec 2010 - 09:04 BruceSimons Slake Package dependencies (9 December 2010)
Slake_Reservoir.eapeap Slake_Reservoir.eap manage 41410.0 K 09 Dec 2010 - 09:06 BruceSimons Updated Reservoir model based on FullMoon errors (9/12/2010)
Topic revision: r6 - 13 Apr 2011, FlorenceTan
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).