Difference between revisions of "Service Interoperability Tests"
|Line 50:||Line 50:|
:: Next.....dunno - lets talk
:: 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)
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 22: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
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.
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.
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)