Difference between revisions of "Service Interoperability Tests"

From Earth Science Information Partners (ESIP)
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
===GMU WCS Server - DataFed Client Test===
 
===GMU WCS Server - DataFed Client Test===
  
Accessing a test file from the GMU WCS server was completed successfully without a hitch. This possibility of actually seeing the service at work and playing with the paramters was immensily useful for this service chaining experiment. Overall it allows us to see both the progress we have in exposing satellite data through WCS as well as the remaining issues of service interoperability.  
+
Accessing a test file from the GMU WCS server was completed successfully without a hitch. This is a great news since it will now be possible to  see the services at work and playing with the paramters. I was really happy to make it this far.  
  
 
The WCS getCoverage for this test file was given by Peisheng Zhao of GMU as:   
 
The WCS getCoverage for this test file was given by Peisheng Zhao of GMU as:   
Line 16: Line 16:
 
  store=true
 
  store=true
  
As requested, the WCS query returned a pointer to an HDF-EOS file. The images below are renderings of the various test queries using the IDL-based ENVI data visuaisation/processing softare.  
+
As requested, the WCS query returned a pointer URL to an HDF-EOS file. The images below are renderings of the various test queries using the IDL-based ENVI data visualisation/processing softare.  
  
  
====Spatial Subsetting by BBOX====
+
====Spatial Subsetting by BBOX Works Fine====
This facility worked as expected. The two images below show that the data are properly set in the requested BBOX, filling the empty space with NULLS  
+
This spatial WCS query facility worked as expected. The two images below show that the data are properly set in the requested BBOX, filling the empty space with NULLS  
  
  
Line 27: Line 27:
  
  
====Resolution Change ====
+
====Subsampling Grid-Resolution Change Works Fine ====
 
The WCS query allows requesting a user-specified grid resolution of the returned data. The WIDTH=500 HEIGHT=500 parameters define the frid size. The two images below show two grid resolutions for 500 and 2000 pixels respectively. Clearly, the subsampling algorithm is working fine.  
 
The WCS query allows requesting a user-specified grid resolution of the returned data. The WIDTH=500 HEIGHT=500 parameters define the frid size. The two images below show two grid resolutions for 500 and 2000 pixels respectively. Clearly, the subsampling algorithm is working fine.  
  
Line 33: Line 33:
 
[[Image:LAITS_MODIS_W2000_H2000.png]]
 
[[Image:LAITS_MODIS_W2000_H2000.png]]
  
==== Issues and questions ====
+
==== WCS Query Questions====
 +
* The WCS getCoverage request returns only one MODIS granule. Hence:
 +
:: The user needs to know the precise file name of the granule. Question: How do I get that name.
 +
:: The WCS query does qoes not have a time element. How should my client specify that the data is needed for 2006-04-25. (by knowing the granule?)   
 +
:: Since each MODIS granule is a different 'Coverage', the GetCapabilities doc has 10^4-10^5 entries. How should my cient read that doc?   
 +
 
 +
==== Client Questions and Issues ====
 +
:: Getting a coverage for multi-granule requires mosaic services using the necessary granules. Who has the mosaic service? (Becaus of swath overlap, for MODIS this is really tricky!)
 +
:: Evidently the served MODIS data is Level 1b, raw intensity, georeferenced. For useful images need amospheric corrections (we can do that at DataFed if the Solar, Sensor, Scattering angles are given).
 +
:: Is there a higher level MODIS product with atm. correction? Is the data source the GSFC data pool?
 +
:: The HDF data download is sloooow at 160 kb/sec. Maybe the connection should be upgraded to at least DSL speeds.
 +
 
 +
====Summary====
 +
It is quite evident, that a MODIS granule finder service based on BBOX and TIME is a necessity (?). Certainly I dont se how else to make the WCS query. Thus, we may want to revert to Plan A that we have stated et the ESIP meeting:
 +
:: Through SciFlo Brian sets up a service within ECHO(?) that returns the list of MODIS L1b granules for a BBOX and TIME query
 +
:: Next.....dunno - lets talk
 +
 
 +
I am looking forward discussing these issues in the ne next telecon or preferably before through direct telephone with GMU. Is that possible?
 +
[[User:Rhusar|Rhusar]] 01:39, 26 April 2006 (EDT)

Latest revision as of 23:56, April 25, 2006

GMU WCS Server - DataFed Client Test

Accessing a test file from the GMU WCS server was completed successfully without a hitch. This is a great news since it will now be possible to see the services at work and playing with the paramters. I was really happy to make it this far.

The WCS getCoverage for this test file was given by Peisheng Zhao of GMU as:

http://laits.gmu.edu/cgi-bin/NWGISS/WCS1020?
request=getCoverage&service=WCS&
version=1.0.20&
COVERAGE=%2Fdata4%2Figodata%2FMOD021KM.A2001038.1615.002.2001047054313.hdf%3ASwath%3AMODIS_SWATH_Type_L1B%3AEV_1KM_RefSB&
CRS=EPSG:4326&
RESPONSE_CRS=EPSG:4326&
BBOX=-92.323402,21.9771,-62.770599,43.1637&
FORMAT=HDF-EOS&
WIDTH=500&HEIGHT=500&
store=true

As requested, the WCS query returned a pointer URL to an HDF-EOS file. The images below are renderings of the various test queries using the IDL-based ENVI data visualisation/processing softare.


Spatial Subsetting by BBOX Works Fine

This spatial WCS query facility worked as expected. The two images below show that the data are properly set in the requested BBOX, filling the empty space with NULLS


LAITS MODIS Subset -85 25 -65 40.png LAITS MODIS Subset -125 15 -65 52.png


Subsampling Grid-Resolution Change Works Fine

The WCS query allows requesting a user-specified grid resolution of the returned data. The WIDTH=500 HEIGHT=500 parameters define the frid size. The two images below show two grid resolutions for 500 and 2000 pixels respectively. Clearly, the subsampling algorithm is working fine.

LAITS MODIS W500 H500.png LAITS MODIS W2000 H2000.png

WCS Query Questions

  • The WCS getCoverage request returns only one MODIS granule. Hence:
The user needs to know the precise file name of the granule. Question: How do I get that name.
The WCS query does qoes not have a time element. How should my client specify that the data is needed for 2006-04-25. (by knowing the granule?)
Since each MODIS granule is a different 'Coverage', the GetCapabilities doc has 10^4-10^5 entries. How should my cient read that doc?

Client Questions and Issues

Getting a coverage for multi-granule requires mosaic services using the necessary granules. Who has the mosaic service? (Becaus of swath overlap, for MODIS this is really tricky!)
Evidently the served MODIS data is Level 1b, raw intensity, georeferenced. For useful images need amospheric corrections (we can do that at DataFed if the Solar, Sensor, Scattering angles are given).
Is there a higher level MODIS product with atm. correction? Is the data source the GSFC data pool?
The HDF data download is sloooow at 160 kb/sec. Maybe the connection should be upgraded to at least DSL speeds.

Summary

It is quite evident, that a MODIS granule finder service based on BBOX and TIME is a necessity (?). Certainly I dont se how else to make the WCS query. Thus, we may want to revert to Plan A that we have stated et the ESIP meeting:

Through SciFlo Brian sets up a service within ECHO(?) that returns the list of MODIS L1b granules for a BBOX and TIME query
Next.....dunno - lets talk

I am looking forward discussing these issues in the ne next telecon or preferably before through direct telephone with GMU. Is that possible? Rhusar 01:39, 26 April 2006 (EDT)