Difference between revisions of "10.11.2013 EDE"

From D4Science Wiki
Jump to: navigation, search
(Notes)
m (Notes)
Line 13: Line 13:
 
The choice of the right dataset/parameter should not be a blocking point. For example if you enable such as service, the user can be responsible to indicate the dataset to be used (input parameter of the process: e.g. URL of the dataset on the thredds server). It would not change the service anyway. So it would make sense to start experimenting with some services based on the easiest-to-deal-with layers, such as SST or chlorophyll.
 
The choice of the right dataset/parameter should not be a blocking point. For example if you enable such as service, the user can be responsible to indicate the dataset to be used (input parameter of the process: e.g. URL of the dataset on the thredds server). It would not change the service anyway. So it would make sense to start experimenting with some services based on the easiest-to-deal-with layers, such as SST or chlorophyll.
  
As noted before, some work has been done by TerraDue and CNR on data extraction. [GP, can you insert a couple of sentences, a brief discussion here on where we stand?].
+
As noted before, some work has been done by TerraDue and CNR on data extraction. Terradue will follow an approach where occurrences are enriched with environmental variables using data with heterogeneous spatial and temporal resolution. These data sources can either be a single value as done previously with BioOracle data or time-series as done with the daily level 4 SST. The result is an occurrence characterized with several data sources that can later be interpreted and analysed by the scientific community. The lineage is guaranteed so that each input data source limitations are known to the end-user (e.g. BioOracle hasn't got the time nor depth variable).
 
+
Terradue will to follow an approach where occurrences are enriched with environmental variables using data with heterogeneous spatial and temporal resolution. These data sources can either be a single value as done previously with BioOracle data or time-series as done with the daily level 4 SST. The result is an occurrence characterized with several data sources that can later be interpreted and analysed by the scientific community. The lineage is guaranteed so that each input data source limitations are known to the end-user (e.g. BioOracle hasn't got the time nor depth variable).
+
 
The approach to store this heterogeneous information  is the OGC Observations and Measurements (O&M - http://en.wikipedia.org/wiki/Observations_and_Measurements) using 52N implementation of the SOS service (http://en.wikipedia.org/wiki/Sensor_Observation_Service and http://blog.52north.org/2013/10/18/sos-4-0-0-rc1-released/).
 
The approach to store this heterogeneous information  is the OGC Observations and Measurements (O&M - http://en.wikipedia.org/wiki/Observations_and_Measurements) using 52N implementation of the SOS service (http://en.wikipedia.org/wiki/Sensor_Observation_Service and http://blog.52north.org/2013/10/18/sos-4-0-0-rc1-released/).
 
   
 
   

Revision as of 09:48, 5 November 2013

Meeting 11 October 2013, 14:30 pm

Google Hangout

Present: GP, Lino, Anton, Julien, Fabrice, Edward

Notes

Several of the issues raised in the notes of last meeting were not resolved. Edward did not find the time to live up to his promise of producing the one-page document describing the possible service based on the Environmental Data Enrichment, but hopes to have it ready by middle next week. For the other issues, these should be tackled by iMarine participants – but progress on resolving the issues can only be expected if we know who will be assigned the task of following up; and before we can decide on that, we’ need a discussion on what resources are available for this activity. This (and many other things) will be discussed at the TCOMM and Board meetings of next week.

Julien suggested, on the basis of advice from some of his colleagues who are oceanographers, to deal with a limited number of environmental parameter – Sea Surface Temperature and chlorophyll, as measured/calculated from satellite observations. Lino suggests forging ahead with some experimentation, even in the absence of support from oceanographers. Before anything goes into production, our results will of course have to be validated by domain experts – so having the collaboration from oceanographers remains a priority, only e timing might change.

The choice of the right dataset/parameter should not be a blocking point. For example if you enable such as service, the user can be responsible to indicate the dataset to be used (input parameter of the process: e.g. URL of the dataset on the thredds server). It would not change the service anyway. So it would make sense to start experimenting with some services based on the easiest-to-deal-with layers, such as SST or chlorophyll.

As noted before, some work has been done by TerraDue and CNR on data extraction. Terradue will follow an approach where occurrences are enriched with environmental variables using data with heterogeneous spatial and temporal resolution. These data sources can either be a single value as done previously with BioOracle data or time-series as done with the daily level 4 SST. The result is an occurrence characterized with several data sources that can later be interpreted and analysed by the scientific community. The lineage is guaranteed so that each input data source limitations are known to the end-user (e.g. BioOracle hasn't got the time nor depth variable). The approach to store this heterogeneous information is the OGC Observations and Measurements (O&M - http://en.wikipedia.org/wiki/Observations_and_Measurements) using 52N implementation of the SOS service (http://en.wikipedia.org/wiki/Sensor_Observation_Service and http://blog.52north.org/2013/10/18/sos-4-0-0-rc1-released/).


This will be discussed in detail at the TCOM next week.

Next meeting

In principle Friday 25 October, 14:30, Google Hangout. Might change after discussions at the TCOMM.