|
Interpolates values of a GHRSST L4 product hosted by NASA JPL PO.DAAC at points.
Given a desired GHRSST L4 product, this tool interpolates the value of that product at the given points. This tool performs the same basic operation as the ArcGIS Spatial Analyst's Extract Values to Points tool, but it reads the MODIS data directly from NASA's servers rather than reading rasters stored on your machine.
The Group for High-Resolution Sea Surface Temperature (GHRSST) provides a new generation of global high-resolution (<10km) SST products to the operational oceanographic, meteorological, climate and general scientific community. The overall aim of the GHRSST is to provide the best quality sea surface temperature data for applications in short, medium and decadal/climate time scales in the most cost effective and efficient manner through international collaboration and scientific innovation.
This tool accesses L4 gap-free gridded SST products published in near real time by the GHRSST GDAC Global Data Assembly Center (GDAC) at the NASA JPL Physical Oceanography Distributed Active Archive Center (PO.DAAC). These products provide regional and global daily cloud-free estimates of SST at spatial resolutions ranging from 0.25 degrees to down 1 km. To fill in cloudy areas, data from multiple satellite and in-situ sensors are combined and regions without any data are filled in various interpolation and modeling techniques.
All products accessed by this tool are published at a daily timestep. Some products are updated on a continual basis and available in near real time; others are updated infrequently and are intended mainly for historical analysis. The temporal extent, spatial resolution and extent, and sensors and interpolation technique used vary by product. All products use the WGS 1984 geographic coordinate system. GHRSST temperatures are published in kelvin. By default, this tool converts them to degrees Celsius but provides an option to obtain the original kelvin values.
All products are obtained from PO.DAAC using the OPeNDAP protocol. This tool supports most but not all of the GHRSST L4 products hosted by PO.DAAC. If you see a product on PO.DAAC that is not available with this tool, please contact the MGET development team for assistance.
Command line syntax| Expression | Explanation |
|---|---|
| <ABOM-L4HRfnd-AUS-RAMSSA_09km | ABOM-L4LRfnd-GLOB-GAMSSA_28km | DMI-L4UHfnd-NSEABALTIC-DMI_OI | EUR-L4UHRfnd-MED-ODYSSEA | EUR-L4UHRfnd-NWE-ODYSSEA | JPL-L4UHfnd-GLOB-MUR | JPL_OUROCEAN-L4UHfnd-GLOB-G1SST | NAVO-L4HR1m-GLOB-K10_SST | NCDC-L4LRblend-GLOB-AVHRR_AMSR_OI | NCDC-L4LRblend-GLOB-AVHRR_OI | UKMO-L4HRfnd-GLOB-OSTIA> | GHRSST L4 product to access. Currently, the following products are supported: All products use the WGS 1984 geographic coordinate system and are published at a daily timestep. Some products are updated on a continual basis and available in near real time; others are updated infrequently and are intended mainly for historical analysis. The temporal extent, spatial resolution and extent, and sensors and interpolation technique used vary by product. Please see the products' documentation for details. This tool supports most but not all of the GHRSST L4 products hosted by PO.DAAC. If you see a product on PO.DAAC that is not available with this tool, please contact the MGET development team for assistance. |
| <analysed_sst | analysis_error> | GHRSST variable to access, one of:
Please see the product documentation for details about what these variables mean and how they were calculated. These variable names are case-sensitive. |
| <points> | Points at which values should be interpolated. The SST data use the WGS 1984 geographic coordinate system. It is recommended but not required that the points use the same coordinate system. If they do not, this tool will attempt to project the points to the WGS 1984 coordinate system prior to doing the interpolation. This may fail if a datum transformation is required, in which case you will have to manually project the points to the WGS 1984 coordinate system before using this tool. |
| <valueField> | Field of the points to receive the interpolated values. The field must have a floating-point or integer data type. If the field cannot represent the interpolated value at full precision, the closest approximation will be stored and a warning will be issued. This will happen, for example, when you interpolate SST values into an integer field. |
| <tField> | Field of the points that specifies the date and time of the point. The field must have a date or datetime data type. If the field can only represent dates with no time component, the time will assumed to be 00:00:00. |
| {Nearest | Linear} | Interpolation method to use, one of:
|
| {where} | SQL WHERE clause expression that specifies the subset of points to use. If this parameter is not provided, all of the points will be used. The exact syntax of this expression depends on the type of feature class you're using. ESRI recommends you reference fields using the following syntax:
|
| {noDataValue} | Value to use when the interpolated value is NoData. If a value is not provided for this parameter, a database NULL value will be stored in the field when the interpolated value is NoData. If the field cannot store NULL values, as is the case with shapefiles, the value -9999 will be used. |
| {convertToCelsius} | If True (the default), temperature values will be converted from kelvin to degrees Celsius. If False, temperature values will be in the original kelvin values. |
| {timeout} | Number of seconds to wait for the THREDDS or OPeNDAP server to respond before failing with a timeout error. If you also provide a Maximum Retry Time and it is larger than the timeout value, the failed request will be retried automatically (with the same timout value) until it succeeds or the Maximum Retry Time has elapsed. If you receive a timeout error you should investigate the server to determine if it is malfunctioning or just slow. Check the server's website to see if the operator has posted a notice about the problem, or contact the operator directly. If the server just slow, increase the timeout value to a larger number, to give the server more time to respond. |
| {maxRetryTime} | Number of seconds to retry requests to the THREDDS or OPeNDAP server before giving up. Use this parameter to cope with a server that experiences transient failures. For example, some servers are rebooted as part of nightly maintenance cycles. If you start a long running operation and want it to run overnight without failing, set the maximum retry time to a duration that is longer than the time that the server is offline during the maintenance cycle. To maximize performance while minimizing load during failure situations, retries are scheduled with progressive delays:
|
| {cacheDirectory} | Directory to cache OPeNDAP datasets. A cache directory can dramatically speed up scenarios that involve accessing the same subsets of an OPeNDAP dataset over and over again. Use a cache directory if you find that, for example, you are repeatedly using the same set of satellite images for a certain region or time period. When OPeNDAP data is requested, the cache directory will be checked for data that was downloaded and cached during prior requests. If cached data exists that can fulfill part of the current request, the request will be serviced by reading from cache files rather than the OPeNDAP server. If the entire request can be serviced from the cache, the OPeNDAP server will not be accessed at all and the request will be completed extremely quickly. Any parts of the request that cannot be serviced from the cache will be downloaded from the OPeNDAP server and added to the cache, speeding up future requests for the same data. If you use a cache directory, be aware of these common pitfalls:
|
| {orderByFields;orderByFields...} | Fields for defining the order in which the points are processed. The points may be processed faster if they are ordered spatiotemporally, such that points that are close in space and time are processed sequentially. Ordering the points this way increases the probability that the value of a given point can be interpolated from data that is cached in memory, rather than from data that must be read from the disk or network, which is much slower. Choose fields that faciliate this. For example, if your points represent the locations of animals tracked by satellite telemetry, order the processing first by the animal ID and then by the transmission date or number. If you omit this parameter, the Date Field will be used automatically. This parameter requires ArcGIS 9.2 or later. |
| {numBlocksToCacheInMemory} | Maximum number of blocks of SST data to cache in memory. To minimize the number of times that the disk or network must be accessed, this tool employs a simple caching strategy, in addition to disk caching described by the Cache Directory parameter. When it processes the first point, it reads a square block of cells centered on that point and caches it in memory. When it processes the second and subsequent points, it first checks whether the cells needed for that point are contained by the block cached in memory. If so, it processes that point using the in-memory block, rather than reading from disk or the network again. If not, it reads another square block centered on that point and adds it to the cache. The tool processes the remaining points, adding additional blocks to the cache, as needed. To prevent the cache from exhausing all memory, it is only permitted to grow to the size specified by this parameter. When the cache is full but a new block is needed, the oldest block is discarded to make room for the newest block. The maximum size of the cache in bytes may be calculated by multiplying this parameter by the block size parameters and then by 2. For example, if this parameter is 256 and the blocks are x=64 by y=64 by t=1, the maximum size of the cache is 2097152 bytes (2 MB). If this parameter is 0, no blocks will be cached in memory. |
| {xBlockSize} | Size of the blocks of SST data to cache in memory, in the x direction (longitude). The size is given as the number of cells. If this parameter is 0, no blocks will be cached in memory. |
| {yBlockSize} | Size of the blocks of SST data to cache in memory, in the y direction (latitude). The size is given as the number of cells. If this parameter is 0, no blocks will be cached in memory. |
| {tBlockSize} | Size of the blocks of SST data to cache in memory, in the t direction (time). The size is given as the number of cells. If this parameter is 0, no blocks will be cached in memory. |
Scripting syntax| Expression | Explanation |
|---|---|
| GHRSST L4 product (Required) | GHRSST L4 product to access. Currently, the following products are supported: All products use the WGS 1984 geographic coordinate system and are published at a daily timestep. Some products are updated on a continual basis and available in near real time; others are updated infrequently and are intended mainly for historical analysis. The temporal extent, spatial resolution and extent, and sensors and interpolation technique used vary by product. Please see the products' documentation for details. This tool supports most but not all of the GHRSST L4 products hosted by PO.DAAC. If you see a product on PO.DAAC that is not available with this tool, please contact the MGET development team for assistance. |
| GHRSST variable (Required) | GHRSST variable to access, one of:
Please see the product documentation for details about what these variables mean and how they were calculated. These variable names are case-sensitive. |
| Point features (Required) | Points at which values should be interpolated. The SST data use the WGS 1984 geographic coordinate system. It is recommended but not required that the points use the same coordinate system. If they do not, this tool will attempt to project the points to the WGS 1984 coordinate system prior to doing the interpolation. This may fail if a datum transformation is required, in which case you will have to manually project the points to the WGS 1984 coordinate system before using this tool. |
| Field to receive the interpolated values (Required) | Field of the points to receive the interpolated values. The field must have a floating-point or integer data type. If the field cannot represent the interpolated value at full precision, the closest approximation will be stored and a warning will be issued. This will happen, for example, when you interpolate SST values into an integer field. |
| Date field (Required) | Field of the points that specifies the date and time of the point. The field must have a date or datetime data type. If the field can only represent dates with no time component, the time will assumed to be 00:00:00. |
| Interpolation method (Optional) | Interpolation method to use, one of:
|
| Where clause (Optional) | SQL WHERE clause expression that specifies the subset of points to use. If this parameter is not provided, all of the points will be used. The exact syntax of this expression depends on the type of feature class you're using. ESRI recommends you reference fields using the following syntax:
|
| Value to use when the interpolated value is NoData (Optional) | Value to use when the interpolated value is NoData. If a value is not provided for this parameter, a database NULL value will be stored in the field when the interpolated value is NoData. If the field cannot store NULL values, as is the case with shapefiles, the value -9999 will be used. |
| Convert temperatures to Celsius (Optional) | If True (the default), temperature values will be converted from kelvin to degrees Celsius. If False, temperature values will be in the original kelvin values. |
| Timeout value (Optional) | Number of seconds to wait for the THREDDS or OPeNDAP server to respond before failing with a timeout error. If you also provide a Maximum Retry Time and it is larger than the timeout value, the failed request will be retried automatically (with the same timout value) until it succeeds or the Maximum Retry Time has elapsed. If you receive a timeout error you should investigate the server to determine if it is malfunctioning or just slow. Check the server's website to see if the operator has posted a notice about the problem, or contact the operator directly. If the server just slow, increase the timeout value to a larger number, to give the server more time to respond. |
| Maximum retry time (Optional) | Number of seconds to retry requests to the THREDDS or OPeNDAP server before giving up. Use this parameter to cope with a server that experiences transient failures. For example, some servers are rebooted as part of nightly maintenance cycles. If you start a long running operation and want it to run overnight without failing, set the maximum retry time to a duration that is longer than the time that the server is offline during the maintenance cycle. To maximize performance while minimizing load during failure situations, retries are scheduled with progressive delays:
|
| Cache directory (Optional) | Directory to cache OPeNDAP datasets. A cache directory can dramatically speed up scenarios that involve accessing the same subsets of an OPeNDAP dataset over and over again. Use a cache directory if you find that, for example, you are repeatedly using the same set of satellite images for a certain region or time period. When OPeNDAP data is requested, the cache directory will be checked for data that was downloaded and cached during prior requests. If cached data exists that can fulfill part of the current request, the request will be serviced by reading from cache files rather than the OPeNDAP server. If the entire request can be serviced from the cache, the OPeNDAP server will not be accessed at all and the request will be completed extremely quickly. Any parts of the request that cannot be serviced from the cache will be downloaded from the OPeNDAP server and added to the cache, speeding up future requests for the same data. If you use a cache directory, be aware of these common pitfalls:
|
| Order by fields (Optional) | Fields for defining the order in which the points are processed. The points may be processed faster if they are ordered spatiotemporally, such that points that are close in space and time are processed sequentially. Ordering the points this way increases the probability that the value of a given point can be interpolated from data that is cached in memory, rather than from data that must be read from the disk or network, which is much slower. Choose fields that faciliate this. For example, if your points represent the locations of animals tracked by satellite telemetry, order the processing first by the animal ID and then by the transmission date or number. If you omit this parameter, the Date Field will be used automatically. This parameter requires ArcGIS 9.2 or later. |
| Number of blocks of data to cache in memory (Optional) | Maximum number of blocks of SST data to cache in memory. To minimize the number of times that the disk or network must be accessed, this tool employs a simple caching strategy, in addition to disk caching described by the Cache Directory parameter. When it processes the first point, it reads a square block of cells centered on that point and caches it in memory. When it processes the second and subsequent points, it first checks whether the cells needed for that point are contained by the block cached in memory. If so, it processes that point using the in-memory block, rather than reading from disk or the network again. If not, it reads another square block centered on that point and adds it to the cache. The tool processes the remaining points, adding additional blocks to the cache, as needed. To prevent the cache from exhausing all memory, it is only permitted to grow to the size specified by this parameter. When the cache is full but a new block is needed, the oldest block is discarded to make room for the newest block. The maximum size of the cache in bytes may be calculated by multiplying this parameter by the block size parameters and then by 2. For example, if this parameter is 256 and the blocks are x=64 by y=64 by t=1, the maximum size of the cache is 2097152 bytes (2 MB). If this parameter is 0, no blocks will be cached in memory. |
| In-memory cache block size, in X direction (Optional) | Size of the blocks of SST data to cache in memory, in the x direction (longitude). The size is given as the number of cells. If this parameter is 0, no blocks will be cached in memory. |
| In-memory cache block size, in Y direction (Optional) | Size of the blocks of SST data to cache in memory, in the y direction (latitude). The size is given as the number of cells. If this parameter is 0, no blocks will be cached in memory. |
| In-memory cache block size, in T direction (Optional) | Size of the blocks of SST data to cache in memory, in the t direction (time). The size is given as the number of cells. If this parameter is 0, no blocks will be cached in memory. |