Coastal Dynamics Observatory Sample Clauses

Coastal Dynamics Observatory. (Pilot 5.1.1 ) Within the Coastal Dynamics Observatory pilot the aim is to deploy and extend the existing webODV architecture as well as the DIVAnd and the SOURCE tools. Together these cover an important part of the technology stack used in the context of analysing the coastal marine environment near river estuaries. They also put a specific mix of demands towards the DL approach this document is formulating. From that mix we highlight these specific elements: ● The webODV architecture provides a performant data visualisation and analysis solution for end users that tightly integrates with known and locally available community data-sets. It combines (i) a browser based client-module that translates actual end-user interaction into fine grained interaction requests with (ii) a websocket server that handles these in a way that effectively reduces the amount of data transfer by producing those tuned subsets out of the data to satisfy the interactive need. The core requirement to enable this behaviour is fast and local access to the actual files composing the datasets. ● The modules DIVAnd and SOURCE are serving very different goals, but can both be seen as techniques to calculate derived datasets that augment the existing collections with interpolation sets resp. model verification feedback. To optimise their processing, both require access to subsets of the original datasets. Additionally the natural expectation for both is that the produced derived datasets become discoverable (and available) for further usage. Figure 8 – Fitting the Coastal Dynamics Pilot to the Unified View The above UML diagram suggests how these particular requirements can be fitted to the abstractions provided in the unified view. - The extra datasets that come out of the interactive processing applications (driven by DIVAnd and SOURCE), should be made available to some internal [[Dataset Registry]]. This is essentially a catalogue of available datasets that not only can learn about new available additions, but also adheres to the [[Data Provider]] contract to make them harvestable by the [[Discovery]]. - The need for subset variants of the base files is often addressed by the community by deploying ERDDAP servers. These also can be made to fit the [[Data Provider]] contract by providing some 'wrapping' service that is capable of interpreting and converting the available metadata and or configuration on these services to practically expose the various subset URLs they provide and the m...