SLAKE Water Storage Information Model
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.
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.
- 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.
- 18 Nov 2010
UML Model Diagrams
- Enterprise Architect UML of draft SLAKE surface reservoir model (09 December 2010):
- Slake Package dependencies (9 December 2010):
- Enterprise Architect UML of draft SLAKE surface reservoir model base on GML3.1 profile (13 Apr 2011):
- 09 Dec 2010