CSW - Catalogue Service For The Web

CSW prototype for Apache SIS
I. CSW: Catalogue Service for the Web

This chapter contains excerpts from OGC specifiations that are useful for
understanding the context of this Google Summer of Code project. References are
given as footnotes.
1
1. Overview [ ]
Catalogue services support the ability to publish and search collections of
descriptive information (metadata) for data, services, and related information
objects. Metadata in catalogues represent resource characteristics that can be
queried and presented for evaluation and further processing by both humans
and software. Catalogue services are required to support the discovery and
binding to registered information resources within an information community.
OGC Catalogue interface standards specify the interfaces, bindings, and a

framework for defining application profiles required to publish and access
digital catalogues of metadata for geospatial data, services, and related
resource information. Metadata act as generalised properties that can be
queried and returned through catalogue services for resource evaluation and,
in many cases, invocation or retrieval of the referenced resource. Catalogue
services support the use of one of several identified query languages to find
and return results using well-known content models (metadata schemas) and
encodings.
2
2. Catalogue information model [ ]
The CSW information model is based on the international standard for
metadata description ISO 19115:2003/Cor.1:2006. In addition, the catalogue
uses a metadata description for service metadata based on the ISO
19119:2005/PDAM 1 standard [ISO 19119] to facilitate the management of
service metadata. The encoding of any information object in this profile is
based on ISO/TS19139 [ISO/TS19139]. The main purpose of the information
model is to provide a formal structure for the description of information
resources that can be managed by a catalogue service that complies with the
application profile.
19115:2003/Cor.1:2006 specifies a general purpose model for metadata
descriptions. For a more comprehensive description of the model please refer
to the original specification documents.
1 Catalogue Service - Overview .

2 OpenGIS® Catalogue Services Specification 2.0.2 - ISO Metadata Application Profile - Chapter 7(7.2)
1-1 . Basic classes - Excerpt from 19115:2003/Cor.1:2006
Image 1-1 gives a high level overview of the basic classes of the information
model. The classes belong to basic packages that are specified by
19115:2003/Cor.1:2006.
Class name Description
MD_Metadata Contains Metadata entity set

information. The MD_Metadata
entity is a composite of
MD_Identification and further
classes that are suppressed due to
clarity, but explained in detail in
19115:2003/Cor.1:2006.
[ISO19115:2003 A.2.1]
MD_Identification This abstract class contains

information to uniquely identify the
information resource that has to be
described. MD_Identification is
mandatory. It may be implemented
as MD_DataIdentification or
SV_ServiceIdentification.
[ISO19115:2003 A.2.2]
MD_DataIdentification Subclass and concretion of the

abstract class MD_Identification.
According to the application profile,
MD_DataIdentification describes
either data or applications.
[ISO19115:2003 A.2.2]
SV_ServiceIdentification Subclass and concretion of the

abstract class MD_Identification.
SV_ServiceIdentification gives a
high level description of services
according to ISO19119:2005/PDAM
1. A service might be 'loosely
coupled' (with no associated data),
'tightly coupled' (with associated
data) or 'mixed coupled'. This
distinction is done by setting the
couplingType attribute of the
SV_ServiceIdentification class [see
also ISO19119:2005/PDAM 1 7.4.2]
7
3. Mappings to the common XML Record format [ 3]

3.1 Core queryable properties
The queryable properties are those properties on which a catalogue client can
formulate a filter expression. The goal of defining core queryable properties is
primarily query interoperability among catalogues that implement the same
protocol binding. Defining a set of core queryable properties also enables
simple cross-profile discovery, where the same queries can be executed
against any catalogue service without modification and without detailed
knowledge of the catalogue's information model. This requires a set of general
metadata properties that can be used to characterize any resource. All
queryables must be expressed as qualified names (QNames).
The following tables define the mapping of the core queryable properties (as
defined by the OGC Catalogue specification) to the ISO information model.
The properties “Title”, “AnyText”, and “Identifier” are mandatory queryables.
Core queryable properties that cannot have a value assigned (e.g. the
information is not available in the information model of the catalogue instance)
shall be considered as having a value of NULL.
3 OpenGIS® Catalogue Services Specification 2.0.2 - ISO Metadata Application Profile - Chapter 7(7.2.3)
4]
Table 3-1 Mapping to common queryable elements [
4 Note : This is element that be write in the document . Some propeties can not support in the current service for this project
The Coordinate Reference System (CRS) used by a GeoTIFF image can be
specified in different ways:
1. By a numerical code allocated by the EPSG authority (for example
“EPSG:4326”).
2. By a string that defines the CRS in Well Known Text (WKT) format.
3. By specifying the map projection parameters in GeoTIFF tags.
Apache SIS supports those three different ways to define a CRS, but current
application use only the EPSG code (approach 1). The two other approaches
are targeted for afuture version.
Table 3-2 Composition of compound element “BoundingBox” [ 5]
5 Note : This are elements that be write in the document . The properties may not resemble the actual service for this project
II. Improve the Apache SIS coverage module in order to meet the
needs of space agencies.
1. Scope
Current project only convert some basic information of a record (Ex: Name,
Identifier, Date modifier, Author, Bbox...).
In the future, this will focus on coverting more detail information and technical
data (Ex: min-max pixel value, min-max radiance, image attributes )
2. Mapping metadata landsat 8 to ISO 19115 [ 6]
2.1. Overview.
Landsat 8 , there are 3 product :
L1G product- L1 product distributed by the LPGS that includes, for all
requested bands and the quality band, GeoTIFF format L1G images and
associated data accommodated by the format.
Level 1 Systematic Terrain (Corrected) (L1Gt) product — L1Gt Terrain
Correction product that includes radiometric and geometric corrections, and
uses a Digital Elevation Model (DEM) to correct parallax error due to local
topographic relief; the accuracy of the terrain-corrected product depends on
the resolution of the best available DEM.
Level 1 Terrain (Corrected) (L1T) product — Includes radiometric,
geometric, and precision correction, and uses a DEM to correct parallax errors
due to local topographic relief; the accuracy of the terrain-corrected product
depends on the availability of Ground Control Points (GCPs), as well as the
resolution of the best available DEM
2.2. L1Gt / L1T Output Files Overview
Standard L1T products, which are Digital Number (DN) products in an
unsigned 16-bit integer format, can be converted to Top of Atmosphere (TOA)
reflectance (Bands 1–9) or radiance (Bands 1–11) using scaling factors
provided in the product metadata. Refer to LSDS-649 Landsat 8 (L8)
Calibration and Validation (Cal/Val) Algorithm Description Document (ADD) for
a description of the radiance and reflectance calculations, and rescaling
procedures used during processing.
6 LSDS-809 ( LANDSAT 8 (L8) LEVEL 1 (L1) DATA FORMAT CONTROL BOOK (DFCB))
The L1Gt / L1T image data are radiometrically and geometrically corrected and
are available in GeoTIFF. Table 2-1 shows the band identification, while Table
2-2 lists the L1Gt / LT product components
Band Reference Band Description Band Center

Number (nm)
1 Coastal Aerosol (Operational Land 433

Imager (OLI))
2 Blue (OLI) 482
3 Green (OLI) 562
4 Red (OLI) 655
5 Near-Infrared (NIR) (OLI) 865
6 Short Wavelength Infrared (SWIR) 1 1610

(OLI)
7 SWIR 2 (OLI) 2200
8 Panchromatic (OLI) 590
9 Cirrus (OLI) 1375
10 Thermal Infrared Sensor (TIRS) 1 10800
11 TIRS 2 12000
Table 2-1. Band Reference Table
Level 1 Product Components
L1Gt / L1T image file (one for each band)
Quality Band (QB) file

Checksum file
L1Gt / L1T metadata file
Angle coefficient file
Table 2-2 lists the L1Gt / LT product components

2.3. Final Product Packaging
The final output product is a tar.gz file. The files are written to a tar file format
and then compressed with the gzip application. The tar file does not contain
any subdirectory information. Therefore, uncompressing (untarring) the file
extracts all of the files directly into the current directory.
2.4. Naming Convention

Table 2-3 and Table 2-4 contain the file names associated with the L1
products.
Ls8ppprrrYYYYDDDGGGVV_FT.ext
Identifier Description
L Landsat
s Sensor of: O = OLI, T = TIRS, C = Combined TIRS and OLI

Indicates which sensor collected data for this product
8 Landsat mission number
ppp Satellite orbit location in reference to the Worldwide

Reference System-2 (WRS-2) path of the product
rrr Satellite orbit location in reference to the WRS-2 row of the

product
YYYY Acquisition year of the image
DDD Acquisition day of year
GGG Ground Station ID
VV Version
_FT File type, where FT equals one of the following: image band
file number (B1–B11), MTL (metadata file), BQA (quality
band file), MD5 (checksum file)
.ext File extension, where .TIF equals GeoTIFF file extension,

and .txt equals text extension
Table 2-3. File Naming Convention
2.5. L1 Metadata File

The L1 metadata file is created during product generation and contains
information specific to the product ordered. Table 2-5 lists the contents of
the L1 metadata file that is convert to ISO 19115. The metadata file is text in
the Object Description Language (ODL) format.
Parameter Name Value, Format, and Parameter Description /

Range Remarks
ORIGIN = “Image courtesy of the Origin of the product.
U.S. Geological Survey”
LANDSAT_SCENE_ID = The unique Landsat scene

“Ls8ppprrrYYYYDDDGGGV identifier.
V”
= The date when the metadata

YYYY-MM-DDTHH:MM:SSZ file for the L1G product set was
FILE_DATE created. The date is based on
Universal Time Coordinated
(UTC) (also known as
Greenwich Mean Time (GMT)).
OUTPUT_FORMAT = “GEOTIFF” The output format of the image.
SPACECRAFT_ID = “LANDSAT_8” Spacecraft from which the data

were captured.
= “OLI_TIRS” Sensor(s) used to capture this

SENSOR_ID = “OLI” scene.
= “TIRS”
CORNER_UL_LAT_PRODUCT = -90.00000 through The latitude value for the

+90.00000 upper-left corner of the product,
measured at the center of the
pixel. Positive (+) value
indicates north latitude;
negative (-) value indicates
south latitude. Units are in
degrees.
CORNER_UL_LON_PRODUCT = -180.00000 through The longitude value for the

+180.00000 upper-left corner of the product,
pixel. Positive (+) value
indicates east longitude;
negative (-) value indicates
west longitude. Units are in
degrees.
CORNER_UR_LAT_PRODUCT = -90.00000 through The latitude value for the

+90.00000 upper-right corner of the
product. Measured at the
center of the pixel. Units are in
degrees.
CORNER_UR_LON_PRODUCT = -180.00000 through The longitude value for the

+180.00000 upper-right corner of the
product, measured at the
degrees.
CORNER_LL_LAT_PRODUCT = -90.00000 through The latitude value for

+90.00000 the lower-left corner of the
degrees.
= -180.00000 through The longitude value for the

CORNER_LL_LON_PRODUCT +180.00000 lower-left corner of the product,
pixel. Units are in degrees.
CORNER_LR_LAT_PRODUCT = -90.00000 through The latitude value for the

+90.00000 lower-right corner of the
degrees.
CORNER_LR_LON_PRODUCT = -180.00000 through The longitude value for the

+180.00000 lower-right corner of the
degrees.
Table 2-5. L1Gt / L1T Metadata File
2.6. GEOTIFF (L1Gt / L1T Image File) - Mapping metadata Geotiff

image
a. GEOTIFF
GeoTIFF defines a set of Tagged Image File Format (TIFF) tags, which
describe cartographic and geodetic information associated with
geographic TIFF imagery. GeoTIFF is a means for tying a raster image to
a known model space or map projection and for describing those
projections. A metadata format provides geographic information to
associate with the image data. However, the TIFF file structure allows
both the metadata and the image data to encode into the same file
b. L1Gt / L1T Image File
The description of an image in GeoTIFF requires tags and keys; the image
files contain these tags and keys, which are read by GeoTIFF readers.
Each image band in the L1Gt / L1T product is in a separate file. Each
band comprises a grayscale GeoTIFF file, which is in uncompressed
16-bit unsigned integers.
c. GeoTIFF Tags
GeoTIFF tags convey information about the image. The tags describe the
image using information the GeoTIFF reader needs to control the
appearance of the image on the user’s screen. The TIFF tags are
embedded in the same file as the TIFF image. The GeoTIFF tags provide
information on the image projection and corner points,
which define the geographic location and extent of the image.
i. GeoTIFF ModelTiepointTag
The GeoTIFF ModelTiepointTag stores the raster-to-model tiepoint pairs
i.1. Description
The raster-to-model tiepoint pairs are stored in the following order:
ModelTiepointTag = (..., I, J, K, X, Y, Z...), where (I, J, K) is the point at
location (I, J) in raster space with pixel-value K, and (X, Y, Z) is a vector in
model space. The ModelTiepointTag requires that K and Z are set to
zero.
The raster image is geo-referenced by specifying its location, size, and
orientation in the model coordinate space. Because the relationship
between the raster space and the model space often are exact, the affine
transformation relationship can be defined using
i.2. Parameters
Tag = 33922
Type = DOUBLE
N = 6*K,
K = number of tiepoints
ii. GeoTIFF ModelPixelScaleTag Tag
The GeoTIFF ModelPixelScaleTag tag specifies the size of the raster pixel
spacing in the model space units when the raster space is embedded in
the model space coordinate system without rotation.
ii.1. Description
The size of raster pixel spacing in the model space units consists of three
values. These values are ModelPixelScaleTag = (ScaleX, ScaleY,
ScaleZ), where ScaleX and ScaleY give the horizontal and vertical
spacing of raster pixels, and ScaleZ maps the pixel value of a DEM into
the correct Z-scale.
A single tiepoint in the ModelTiepointTag, together with the
ModelPixelScaleTag, determines the relationship between raster and
model space.
ii.2. Parameters
Tag = 33550
Type = DOUBLE
N=3
d. GeoTIFF Keys
In addition to tags, the description of a projection in GeoTIFF requires the
use of keys. Table 3-1 lists the keys necessary to define the projections
supported by the L1 production systems, along with their possible values.
Improve the Apache SIS coverage module to mapping metadata file to ISO
19115:
1. Technical Specifications
- Language programing: Java
- Development Environment : JDK8
- Library Apache SIS ,Branches JDK8
- IDE Netbeans
- Maven
2. Creat a module mapping into Apache SIS
- Creat a module GeoTIFF
- Creat a module TestGeoTIFF to test module
3. Mapping metadata file to ISO 19115 use

- File : Metadata file for product L1Gt/L1T
- Describes the conversion :
1. Uses HashMap class stores the values based on the unique key with
- Keys : Parameter Name (Table 2-5 )
- Values : The value for prameter name (Table 2-5)
2. With the values , get into the tree Metadata (use to Describe
information or resource that can have geographic extents ) that have
the propeties the same.
- Some special key:
In some cases, the mapping code will need to perform some calculation. For
example, the west bound longitude is provided by two different metadata in
the Landsat file: one for the lower corner and another one for the upper
corner. This happen because Landsat images may have a rotation, like the
red rectangle below. But ISO 19115 geographic box is expressed without
rotation, like the blue rectangle below. In order to have a blue rectangle that
encompass fully the red rectangle, we need to take the minimum of the two
Landsat properties.
- Table 2-6. list mapping ISO 19115 property having the same meaning than a
Landsat property
Seq. Validation Rule

ISO 19115 Landsat Description
No
1 dateInfo/date FILE DATE
The date when metadata file
product set was created.
2 Hard-coded ISO 19115 value to
dateInfo/dateType DateType.CREATION be set only if
dateInfo/date exists.
3 identificationInfo
ORIGIN
Recognition of those who
/credit contributed to the resource(s).
The unique Landsat scene
/citation/identifi LANDSAT SCENE ID
identifier.
er
5 identificationInfo min(CORNER_UL_LON 1. >= -180 and
/extent/geographic _PRODUCT, The western-most longitude <= 180
Element/westBoundL CORNER_LL_LON_PRO value in degrees.
ongitude DUCT)
6 identificationInfo max(CORNER_UR_LON Same as above
/extent/geographic _PRODUCT, The eastern-most longitude
Element/eastBoundL CORNER_LR_LON_PRO value in degrees.
ongitude DUCT)
7 1. southBound
identificationInfo min(CORNER_LL_LAT
/extent/geographic _PRODUCT, The southern-most longitude Latitude <
Element/southBound CORNER_LR_LAT_PRO value in degrees. northBound
Latitude DUCT) Latitude
8 identificationInfo max(CORNER_UL_LAT (see above)
/extent/geographic _PRODUCT, The northern-most longitude
Element/northBound CORNER_UR_LAT_PRO value in degrees.
Latitude DUCT)
DATE_ACQUIRED + The date and scene center
1. startTime <
/extent/temporalEl endTime
SCENE CENTER TIME time the image was acquired.
ement/startTime
10 identificationInfo 1.
/resourceFormat/fo The name of the data transfer
OUTPUT FORMAT
rmatSpecificationC format.
itation/title
11 acquisitionInforma
Spacecraft from which the
tion/platform/iden SPACECRAFT ID
data were captured.
tifier/code
12 acquisitionInforma
Sensor(s) used to capture this
tion/instrument/id SENSOR ID
scene.
entifier/code
13 1. >= 0 and <=
100,
2. -1 indicates
contentInfo/cloudC The overall cloud coverage
CLOUD COVER that the
overPercentage (percent) of the WRS-2 scene.
score was
not
calculated
14 The Sun azimuth angle in
contentInfo/illumi degrees for the image center
SUN AZIMUTH
nationAzimuthAngle location at the image center
acquisition time.
15 contentInfo/illumi
The Sun elevation angle in
degrees for the image center
nationElevationAng SUN ELEVATION
location at the image center
le
acquisition time.
Table 2-6. Use Apache SIS mapping Metadata to ISO 19115
- Examlple :
Metadata
├─Language…………………………………………………………………………… English
├─Identification info
│ ├─Citation
│ │ ├─Title……………………………………………………………… LC80360232016203LGN00
│ │ ├─Date
│ │ │ ├─Date……………………………………………………… Jul 22, 2016 7:37:48 AM
│ │ │ └─Date type………………………………………… Publication
│ │ └─Cited responsible party
│ │ └─Party
│ │ └─Name…………………………………………… Image courtesy of the U.S. Geological Survey
│ ├─Extent
│ │ └─Geographic element
│ │ ├─West bound longitude…………… 105°43′28.92″W
│ │ ├─East bound longitude…………… 102°05′43.728″W
│ │ ├─South bound latitude…………… 51°59′26.232″N
│ │ ├─North bound latitude…………… 54°10′41.808″N
│ │ └─Extent type code……………………… true
│ └─Associated resource
│ └─Name
│ └─Title…………………………………………………… Image courtesy of the U.S. Geological Survey
├─Content info
│ ├─Illumination elevation angle…………… 54.518
│ ├─Illumination azimuth angle………………… 150.955
│ ├─Cloud cover percentage…………………………… 43.04
│ └─Attribute group
│ ├─Content type…………………………………………… Physical measurement
│ ├─Attribute (1 of 11)
│ │ ├─Peak response……………………………… 433
│ │ ├─Bound units…………………………………… nm
│ │ └─Description…………………………………… Coastal Aerosol
│ │ ├─Peak response……………………………… 482
│ │ ├─Bound units…………………………………… nm
│ │ └─Description…………………………………… Blue
│ │ ├─Peak response……………………………… 562
│ │ ├─Bound units…………………………………… nm
│ │ └─Description…………………………………… Green
│ │ ├─Peak response……………………………… 655
│ │ ├─Bound units…………………………………… nm
│ │ └─Description…………………………………… Red
│ │ ├─Peak response……………………………… 865
│ │ ├─Bound units…………………………………… nm
│ │ └─Description…………………………………… Near-Infrared
│ │ ├─Peak response……………………………… 1,610
│ │ ├─Bound units…………………………………… nm
│ │ └─Description…………………………………… Short Wavelength Infrared (SWIR) 1
│ │ ├─Peak response……………………………… 2,200
│ │ ├─Bound units…………………………………… nm
│ │ └─Description…………………………………… Short Wavelength Infrared (SWIR) 2
│ │ ├─Peak response……………………………… 590
│ │ ├─Bound units…………………………………… nm
│ │ └─Description…………………………………… Panchromatic
│ │ ├─Peak response……………………………… 1,375
│ │ ├─Bound units…………………………………… nm
│ │ └─Description…………………………………… Cirrus
│ │ ├─Peak response……………………………… 10,800
│ │ ├─Bound units…………………………………… nm
│ │ └─Description…………………………………… Thermal Infrared Sensor (TIRS) 1
│ └─Attribute (11 of 11)
│ ├─Peak response……………………………… 12,000
│ ├─Bound units…………………………………… nm
│ └─Description…………………………………… Thermal Infrared Sensor (TIRS) 2
├─Distribution info
│ └─Distribution format
│ └─Format specification citation
│ └─Alternate title………………………… GEOTIFF
├─Acquisition information
│ ├─Operation
│ │ ├─Status…………………………………………………………… Completed
│ │ ├─Type………………………………………………………………… Real
│ │ └─Significant event
│ │ └─Time……………………………………………………… Jul 22, 2016 12:52:14 AM
│ └─Platform
│ ├─Identifier
│ │ └─Code……………………………………………………… LANDSAT_8
│ └─Instrument
│ └─Identifier
│ └─Code…………………………………………… OLI_TIRS
├─Date info
│ ├─Date…………………………………………………………………………… Jul 22, 2016 7:37:48 AM
│ └─Date type……………………………………………………………… Creation
├─Metadata scope
│ └─Resource scope………………………………………………… Metadata
├─Metadata identifier
│ └─Code…………………………………………………………………………… LC80360232016203LGN00
├─Metadata standard (1 of 2)
│ ├─Title………………………………………………………………………… Geographic Information — Metadata
Part 1: Fundamentals
│ ├─Cited responsible party
│ │ ├─Party
│ │ │ └─Name……………………………………………………… International Organization for
Standardization
│ │ └─Role………………………………………………………………… Principal investigator
│ ├─Edition…………………………………………………………………… ISO 19115-1:2014(E)
│ │ ├─Code………………………………………………………………… 19115-1
│ │ ├─Code space………………………………………………… ISO
│ │ └─Version………………………………………………………… 2014(E)
│ └─Presentation form………………………………………… Document digital
└─Metadata standard (2 of 2)
├─Title………………………………………………………………………… Geographic Information — Metadata
Part 2: Extensions for imagery and gridded data
├─Cited responsible party
│ ├─Party
│ │ └─Name……………………………………………………… International Organization for Standardization
│ └─Role………………………………………………………………… Principal investigator
├─Edition…………………………………………………………………… ISO 19115-2:2009(E)
├─Identifier
│ ├─Code………………………………………………………………… 19115-2
│ ├─Code space………………………………………………… ISO
│ └─Version………………………………………………………… 2009(E)
└─Presentation form………………………………………… Document digital
4. Mapping GeoTiff metadata to ISO 19115

- File : GeoTiff image file for product L1Gt/L1T
- Describes the conversion :
1. Uses File class to read some base informations (Name, identifier, date
modified , type file )
2. Uses Apache SIS library to read tags and keys for image.
3. With tags or keys use the type the same to read the values
4. Get the values and the base informations to the tree Metadata (use to
Describe information or resource that can have geographic extents )
that have the propeties the same.
- Some special values:
From ModelTiePoint, GeoKeyDirectoryTag,ModelPixelScaleTag, ImageWidth,
ImageLength to Bounding box .
1. Use the values ModelTiePoint, ModelPixelScaleTag, ImageWidth,
ImageLength calculation the values corner projection (units are in meters )
2. Use the library Apache SIS to transform from corner projection to
corner lat/long (units are in degree)
3. Compare the values that transform and get values the boundingbox
Example :
Metadata
├─Language……………………………………………………………………………… English
│ ├─Citation
│ │ ├─Title…………………………………………………………………
LC80360232016203LGN00_B1.TIF
│ │ ├─Date
│ │ │ ├─Date………………………………………………………… Jul 22, 2016 7:37:35 AM
│ │ │ └─Date type…………………………………………… Creation
│ │ └─Party
│ │ └─Name……………………………………………… Image courtesy of the U.S.Geological
Survey
│ ├─Extent
│ │ ├─West bound longitude……………… 105°43′28.9115179948″W
│ │ ├─East bound longitude……………… 102°05′43.7453696983″W
│ │ ├─South bound latitude……………… 51°59′26.2317582668″N
│ │ ├─North bound latitude……………… 54°10′41.8069643228″N
│ │ └─Extent type code………………………… true
│ └─Name
│ └─Title……………………………………………………… Image courtesy of the U.S.Geological
Survey
├─Content info
│ └─Attribute group
│ └─Attribute
│ ├─Max value…………………………………………… 65,535
│ └─Min value…………………………………………… 0
│ ├─File decompression technique…… none
│ └─Alternate title…………………………… TIFF
│ └─Resource scope…………………………………………………… Dataset
│ └─Code………………………………………………………………………………
LC80360232016203LGN00_B1
│ ├─Title…………………………………………………………………………… Geographic Information
— Metadata Part 1: Fundamentals
│ │ ├─Party
│ │ │ └─Name………………………………………………………… International Organization for
Standardization
│ │ └─Role…………………………………………………………………… Principal investigator
│ ├─Edition……………………………………………………………………… ISO 19115-1:2014(E)
│ │ ├─Code…………………………………………………………………… 19115-1
│ │ ├─Code space…………………………………………………… ISO
│ │ └─Version…………………………………………………………… 2014(E)
│ └─Presentation form…………………………………………… Document digital
├─Title…………………………………………………………………………… Geographic Information —
Metadata Part 2: Extensions for imagery and gridded data
│ ├─Party
│ │ └─Name………………………………………………………… International Organization for
Standardization
│ └─Role…………………………………………………………………… Principal investigator
├─Edition……………………………………………………………………… ISO 19115-2:2009(E)
├─Identifier
│ ├─Code…………………………………………………………………… 19115-2
│ ├─Code space…………………………………………………… ISO
│ └─Version…………………………………………………………… 2009(E)
└─Presentation form…………………………………………… Document digital
3. Mapping metadata modis to ISO 19115

The same to read landsat metadata but the metadata for modis is format xml .
And to read the values , use xpath .
And then read the same landsat metadata
Example :
Metadata
├─Language…………………………………………………………………………… English
│ ├─Citation
│ │ ├─Title………………………………………………………………
MYD09A1.A2015337.h00v09.005.2015349090129.hdf
│ │ ├─Date
│ │ │ ├─Date……………………………………………………… Dec 15, 2015 9:01:29 AM
│ │ │ └─Date type………………………………………… Publication
│ │ └─Party
│ │ └─Name…………………………………………… EDC
│ ├─Extent
│ │ ├─West bound longitude…………… 169°59′30.212569612″W
│ │ ├─East bound longitude…………… 169°55′12.503145335″W
│ │ ├─South bound latitude…………… 9°59′27.41917049794″S
│ │ ├─North bound latitude…………… 0°00′24.54927411265524″N
│ │ └─Extent type code……………………… true
│ └─Name
│ └─Title…………………………………………………… EDC
│ └─Alternate title………………………… MYD09A1
├─Acquisition information
│ └─Platform
│ │ └─Code……………………………………………………… Aqua
│ └─Instrument
│ └─Identifier
│ └─Code…………………………………………… MODIS
├─Date info
│ ├─Date…………………………………………………………………………… Dec 15, 2015 9:01:29 AM
│ └─Date type……………………………………………………………… Creation
│ └─Resource scope………………………………………………… Metadata
│ └─Code……………………………………………………………………………
MYD09A1.A2015337.h00v09.005.2015349090129.hdf
│ ├─Title………………………………………………………………………… Geographic Information —
Metadata Part 1: Fundamentals
│ │ ├─Party
│ │ │ └─Name……………………………………………………… International Organization for
Standardization
│ │ └─Role………………………………………………………………… Principal investigator
│ ├─Edition…………………………………………………………………… ISO 19115-1:2014(E)
│ │ ├─Code………………………………………………………………… 19115-1
│ │ ├─Code space………………………………………………… ISO
│ │ └─Version………………………………………………………… 2014(E)
│ └─Presentation form………………………………………… Document digital
├─Title………………………………………………………………………… Geographic Information —
Metadata Part 2: Extensions for imagery and gridded data
│ ├─Party
│ │ └─Name……………………………………………………… International Organization for
Standardization
│ └─Role………………………………………………………………… Principal investigator
├─Edition…………………………………………………………………… ISO 19115-2:2009(E)
├─Identifier
│ ├─Code………………………………………………………………… 19115-2
│ ├─Code space………………………………………………… ISO
│ └─Version………………………………………………………… 2009(E)
└─Presentation form………………………………………… Document digital
III. REST architecture

1. Overview [8]
RESTful web services are built to work best on the Web. Representational
State Transfer (REST) is an architectural style that specifies constraints, such
as the uniform interface, that if applied to a web service induce desirable
properties, such as performance, scalability, and modifiability, that enable
services to work best on the Web. In the REST architectural style, data and
functionality are considered resources and are accessed usingUniform
Resource Identifiers (URIs), typically links on the Web. The resources are
acted upon by using a set of simple, well-defined operations. The REST
architectural style constrains an architecture to a client/server architecture and
is designed to use a stateless communication protocol, typically HTTP. In the
REST architecture style, clients and servers exchange representations of
resources by using a standardized interface and protocol.
The following principles encourage RESTful applications to be simple,
lightweight, and fast:
● Resource identification through URI: A RESTful web service exposes a
set of resources that identify the targets of the interaction with its clients.
Resources are identified by URIs, which provide a global addressing
space for resource and service discovery. See The @PathAnnotation and
URI Path Templates for more information.
● Uniform interface: Resources are manipulated using a fixed set of four
create, read, update, delete operations: PUT, GET, POST, and
DELETE.PUT creates a new resource, which can be then deleted by using
DELETE. GET retrieves the current state of a resource in some
representation.POST transfers a new state onto a resource. See
Responding to HTTP Methods and Requests for more information.
● Self-descriptive messages: Resources are decoupled from their
representation so that their content can be accessed in a variety of
formats, such as HTML, XML, plain text, PDF, JPEG, JSON, and others.
Metadata about the resource is available and used, for example, to control
caching, detect transmission errors, negotiate the appropriate
representation format, and perform authentication or access control.
SeeResponding to HTTP Methods and Requests and Using Entity
Providers to Map HTTP Response and Request Entity Bodies for more
information.
● Stateful interactions through hyperlinks: Every interaction with a
resource is stateless; that is, request messages are self-contained.
Stateful interactions are based on the concept of explicit state transfer.
Several techniques exist to exchange state, such as URI rewriting,
cookies, and hidden form fields. State can be embedded in response
messages to point to valid future states of the interaction. See Using
Entity Providers to Map HTTP Response and Request Entity Bodies and
“Building URIs” in the JAX-RS Overview document for more information.
IV. REST architecture to CSW

1. Why use restfull to build CSW webservice ?
REST uses standard HTTP it is much simpler in just about ever way.
Creating clients, developing APIs, the documentation is much easier to
understand and there aren’t very many things that REST doesn’t do
easier/better than SOAP.
REST permits many different data formats where as SOAP only permits XML
REST has better performance and scalability. REST reads can be cached,
SOAP based reads cannot be cached.
The most important is REST can use the webservices that use SOAP and
CSW webservice use SOAP (formerly Simple Object Access Protocol)
messages for communication .
So , the best way is use RESTfull to build CSW webservice.
V. Test URL
1. GetCapabilities (file xml response just a example)
- Request:
http://localhost:8084/sis/VNSC/csw/2.0.2/getcapabilities?service=CSW
&version=2.0.2&request=GetCapabilities
- Response:
<Capabilities xmlns="http://www.opengis.net/cat/csw"
xmlns:ows="http://www.opengis.net/ows" xmlns:ogc="http://www.opengis.net/ogc"
xmlns:csw="http://www.opengis.net/cat/csw"xmlns:xlink="http://www.w3.org/1999/xlink
" xmlns:ns0="http://www.opengis.net/cat/csw"
xmlns:ns1="http://www.opengis.net/cat/csw" version="2.0.0" updateSequence="0">
<ows:ServiceIdentification xmlns:ows="http://www.opengis.net/ows">
<ows:ServiceType>CSW</ows:ServiceType>
<ows:ServiceTypeVersion>2.0.0</ows:ServiceTypeVersion>
<ows:Title>Company CSW</ows:Title>
<ows:Abstract>
A catalogue service that conforms to the HTTP protocol binding of the OpenGIS
Catalogue Service specification version 2.0.0.
</ows:Abstract>
<ows:Keywords>
<ows:Keyword>CSW</ows:Keyword>
<ows:Keyword>Company Name</ows:Keyword>
<ows:Keyword>geospatial</ows:Keyword>
<ows:Keyword>catalogue</ows:Keyword>
</ows:Keywords>
<ows:Fees>NONE</ows:Fees>
<ows:AccessConstraints>NONE</ows:AccessConstraints>
</ows:ServiceIdentification>
<ows:ServiceProvider xmlns:ows="http://www.opengis.net/ows">
<ows:ProviderName>Company Name</ows:ProviderName>
<ows:ProviderSite xmlns:ans1="http://www.w3.org/1999/xlink"
ans1:href="http://www.oracle.com"/>
<ows:ServiceContact>
<ows:IndividualName>Contact Person Name</ows:IndividualName>
<ows:PositionName>Staff</ows:PositionName>
<ows:ContactInfo>
<ows:Phone>
<ows:Voice>999-999-9999</ows:Voice>
<ows:Facsimile>999-999-9999</ows:Facsimile>
</ows:Phone>
<ows:Address>
<ows:DeliveryPoint>1 Street Name</ows:DeliveryPoint>
<ows:City>CityName</ows:City>
<ows:AdministrativeArea>StateName</ows:AdministrativeArea>
<ows:PostalCode>09999</ows:PostalCode>
<ows:Country>USA</ows:Country>
<ows:ElectronicMailAddress>contact.person@example.com</ows:ElectronicMailA
ddress>
</ows:Address>
<ows:OnlineResource xmlns:ans1="http://www.w3.org/1999/xlink"
ans1:href="mailto:contact.person@example.com"/>
</ows:ContactInfo>
</ows:ServiceContact>
</ows:ServiceProvider>
<ows:OperationsMetadata xmlns:ows="http://www.opengis.net/ows">
<ows:Operation name="GetCapabilities">
<ows:DCP>
<ows:HTTP>
<ows:Get xmlns:ans1="http://www.w3.org/1999/xlink"
ans1:href="http://localhost:8888/SpatialWS-SpatialWS-context-root/cswservl
et"/>
<ows:Post xmlns:ans1="http://www.w3.org/1999/xlink"
ans1:href="http://localhost:8888/SpatialWS-SpatialWS-context-root/SpatialW
SSoapHttpPort"/>
</ows:HTTP>
</ows:DCP>
</ows:Operation>
<ows:Operation name="DescribeRecord">
<ows:DCP>
<ows:HTTP>
SSoapHttpPort"/>
</ows:HTTP>
</ows:DCP>
<ows:Parameter name="typeName">
<ows:Value>ns0:SampleRecord</ows:Value>
<ows:Value>ns1:Record</ows:Value>
</ows:Parameter>
<ows:Parameter name="outputFormat">
<ows:Value>text/xml</ows:Value>
</ows:Parameter>
<ows:Parameter name="schemaLanguage">
<ows:Value>XMLSCHEMA</ows:Value>
</ows:Parameter>
</ows:Operation>
<ows:Operation name="GetRecords">
<ows:DCP>
<ows:HTTP>
SSoapHttpPort"/>
</ows:HTTP>
</ows:DCP>
<ows:Parameter name="TypeName">
<ows:Value>ns0:SampleRecord</ows:Value>
<ows:Value>ns1:Record</ows:Value>
</ows:Parameter>
<ows:Parameter name="outputFormat">
<ows:Value>text/xml</ows:Value>
</ows:Parameter>
<ows:Parameter name="outputSchema">
<ows:Value>OGCCORE</ows:Value>
</ows:Parameter>
<ows:Parameter name="resultType">
<ows:Value>hits</ows:Value>
<ows:Value>results</ows:Value>
<ows:Value>validate</ows:Value>
</ows:Parameter>
<ows:Parameter name="ElementSetName">
<ows:Value>brief</ows:Value>
<ows:Value>summary</ows:Value>
<ows:Value>full</ows:Value>
</ows:Parameter>
<ows:Parameter name="CONSTRAINTLANGUAGE">
<ows:Value>Filter</ows:Value>
</ows:Parameter>
</ows:Operation>
<ows:Operation name="GetRecordById">
<ows:DCP>
<ows:HTTP>
SSoapHttpPort"/>
</ows:HTTP>
</ows:DCP>
<ows:Parameter name="ElementSetName">
<ows:Value>brief</ows:Value>
<ows:Value>summary</ows:Value>
<ows:Value>full</ows:Value>
</ows:Parameter>
</ows:Operation>
<ows:Operation name="GetDomain">
<ows:DCP>
<ows:HTTP>
SSoapHttpPort"/>
</ows:HTTP>
</ows:DCP>
<ows:Parameter name="ParameterName">
<ows:Value>GetRecords.resultType</ows:Value>
<ows:Value>GetRecords.outputFormat</ows:Value>
<ows:Value>GetRecords.outputRecType</ows:Value>
<ows:Value>GetRecords.typeNames</ows:Value>
<ows:Value>GetRecords.ElementSetName</ows:Value>
<ows:Value>GetRecords.ElementName</ows:Value>
<ows:Value>GetRecords.CONSTRAINTLANGUAGE</ows:Value>
<ows:Value>GetRecordById.ElementSetName</ows:Value>
<ows:Value>DescribeRecord.typeName</ows:Value>
<ows:Value>DescribeRecord.schemaLanguage</ows:Value>
</ows:Parameter>
</ows:Operation>
<ows:Operation name="Transaction">
<ows:DCP>
<ows:HTTP>
SSoapHttpPort"/>
</ows:HTTP>
</ows:DCP>
</ows:Operation>
<ows:Parameter name="service">
<ows:Value>CSW</ows:Value>
</ows:Parameter>
<ows:Parameter name="version">
<ows:Value>2.0.0</ows:Value>
</ows:Parameter>
<ows:ExtendedCapabilities>
<ogc:Filter_Capabilities xmlns:ogc="http://www.opengis.net/ogc">
<ogc:Spatial_Capabilities>
<ogc:Spatial_Operators>
<ogc:BBOX/>
<ogc:Equals/>
<ogc:Disjoint/>
<ogc:Intersect/>
<ogc:Touches/>
<ogc:Crosses/>
<ogc:Within/>
<ogc:Contains/>
<ogc:Overlaps/>
<ogc:Beyond/>
<ogc:DWithin/>
</ogc:Spatial_Operators>
</ogc:Spatial_Capabilities>
<ogc:Scalar_Capabilities>
<ogc:Logical_Operators/>
<ogc:Comparison_Operators>
<ogc:Simple_Comparisons/>
<ogc:Like/>
<ogc:Between/>
<ogc:NullCheck/>
</ogc:Comparison_Operators>
<ogc:Arithmetic_Operators>
<ogc:Simple_Arithmetic/>
</ogc:Arithmetic_Operators>
</ogc:Scalar_Capabilities>
</ogc:Filter_Capabilities>
</ows:ExtendedCapabilities>
</ows:OperationsMetadata>
</Capabilities>
2. DescribeRecord
- Request:
http://localhost:8084/sis/VNSC/csw/2.0.2/describerecord?service=CSW&versi
on=2.0.2&request=DescribeRecord
- Response;
<xsd:schema xmlns:csw="http://www.opengis.net/cat/csw/2.0.2"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:dc="http://purl.org/dc/elements/1.1/"xmlns:dct="http://purl.org/dc/ter
ms/" xmlns:ows="http://www.opengis.net/ows" id="csw-record"
targetNamespace="http://www.opengis.net/cat/csw/2.0.2"elementFormDefault="qu
alified" version="2.0.2">
<xsd:annotation>
<xsd:appinfo>
<dc:identifier
xmlns:dc="http://purl.org/dc/elements/1.1/">http://schemas.opengis.net/csw/2.
0.2/record.xsd</dc:identifier>
</xsd:appinfo>
<xsd:documentation xml:lang="en">
This schema defines the basic record types that must be supported by all CSW
implementations. These correspond to full, summary, and brief views based on
DCMI metadata terms.
</xsd:documentation>
</xsd:annotation>
<xsd:import namespace="http://purl.org/dc/terms/"
schemaLocation="rec-dcterms.xsd"/>
<xsd:import namespace="http://purl.org/dc/elements/1.1/"
schemaLocation="rec-dcmes.xsd"/>
<xsd:import namespace="http://www.opengis.net/ows"
schemaLocation="../../ows/1.0.0/owsAll.xsd"/>
<xsd:element name="AbstractRecord" id="AbstractRecord"
type="csw:AbstractRecordType" abstract="true"/>
<xsd:complexType name="AbstractRecordType" id="AbstractRecordType"
abstract="true"/>
<xsd:element name="DCMIRecord" type="csw:DCMIRecordType"
substitutionGroup="csw:AbstractRecord"/>
<xsd:complexType name="DCMIRecordType">
<xsd:annotation>
This type encapsulates all of the standard DCMI metadata terms, including
the Dublin Core refinements; these terms may be mapped to the
profile-specific information model.
</xsd:annotation>
<xsd:complexContent>
<xsd:extension base="csw:AbstractRecordType">
<xsd:sequence>
<xsd:group ref="dct:DCMI-terms"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="BriefRecord" type="csw:BriefRecordType"
<xsd:complexType name="BriefRecordType" final="#all">
<xsd:annotation>
This type defines a brief representation of the common record format. It
extends AbstractRecordType to include only the dc:identifier and dc:type
properties.
</xsd:annotation>
<xsd:sequence>
<xsd:element ref="dc:identifier" minOccurs="1" maxOccurs="unbounded"/>
<xsd:element ref="dc:title" minOccurs="1" maxOccurs="unbounded"/>
<xsd:element ref="dc:type" minOccurs="0"/>
<xsd:element ref="ows:BoundingBox" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:element name="SummaryRecord" type="csw:SummaryRecordType"
<xsd:complexType name="SummaryRecordType" final="#all">
<xsd:annotation>
This type defines a summary representation of the common record format. It
extends AbstractRecordType to include the core properties.
</xsd:annotation>
<xsd:sequence>
<xsd:element ref="dc:identifier" minOccurs="1" maxOccurs="unbounded"/>
<xsd:element ref="dc:title" minOccurs="1" maxOccurs="unbounded"/>
<xsd:element ref="dc:type" minOccurs="0"/>
<xsd:element ref="dc:subject" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="dc:format" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="dc:relation" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="dct:modified" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="dct:abstract" minOccurs="0" maxOccurs="unbounded"/>
<xsd:element ref="dct:spatial" minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:element name="Record" type="csw:RecordType"
<xsd:complexType name="RecordType" final="#all">
<xsd:annotation>
This type extends DCMIRecordType to add ows:BoundingBox; it may be used to
specify a spatial envelope for the catalogued resource.
</xsd:annotation>
<xsd:extension base="csw:DCMIRecordType">
<xsd:sequence>
<xsd:element name="AnyText" type="csw:EmptyType" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:extension>
</xsd:complexType>
<xsd:complexType name="EmptyType"/>
</xsd:schema>
3. GetRecordById:
- Request : elementSetName=brief
http://localhost:8084/sis/VNSC/csw/2.0.2/getrecordbyid?service=CSW
&version=2.0.2&request=GetRecordById&elementSetName=brief&Id=LC803
60232016203LGN00
- Response:
<csw:GetRecordByIdReponse xmlns:csw="http://www.opengis.net/cat/csw/2.0.2"
xmlns:ows="http://www.opengis.net/ows"
xmlns:dct="http://purl.org/dc/terms/"xmlns:dc="http://purl.org/dc/elements/1.1/">
<csw:BriefRecord service="CSW" version="2.0.2">
<dc:identifier>LC80360232016203LGN00</dc:identifier>
<dc:type>METADATA</dc:type>
<dc:title>LC80360232016203LGN00_MTL.txt</dc:title>
<ows:BoundingBox>
<ows:LowerCorner>-105.7247 51.99062</ows:LowerCorner>
<ows:UpperCorner>-102.09548 54.17828</ows:UpperCorner>
</ows:BoundingBox>
</csw:BriefRecord>
</csw:GetRecordByIdReponse>
- request: elementSetName=summary (metadata tiff)
- response:
<csw:SummaryRecord service="CSW" version="2.0.2">
<dc:relation>Image courtesy of the U.S. Geological Survey</dc:relation>
<dct:modified>2016-07-21T19:37:48-05:00</dct:modified>
<dc:format>GEOTIFF</dc:format>
<ows:BoundingBox>
</ows:BoundingBox>
</csw:SummaryRecord>
- Request: elementSetName=full (metadata tiff)
- Response:
<csw:Record service="CSW" version="2.0.2">
<dc:creator>Image courtesy of the U.S. Geological Survey</dc:creator>
<dc:contributor>Image courtesy of the U.S. Geological Survey</dc:contributor>
<dc:publisher>VNSC-Vietnam National Satellite Center</dc:publisher>
<dc:language>en</dc:language>
<ows:BoundingBox>
</ows:BoundingBox>
</csw:Record>
- Request: elementSetName=summary(image tiff)

http://localhost:8084/VNSC/csw/2.0.2/getrecordbyid?service=CSW&ver
sion=2.0.2&request=GetRecordById&elementSetName=summary&Id=LC803
60232016203LGN00_B1
- Reponse:
<dc:identifier>LC80360232016203LGN00_B1</dc:identifier>
<dc:relation>Image courtesy of the U.S.Geological Survey</dc:relation>
<dc:type>DATASET</dc:type>
<dc:title>LC80360232016203LGN00_B1.TIF</dc:title>
<dc:format>TIFF</dc:format>
<ows:BoundingBox>
</ows:BoundingBox>
- request: elementSetName=full(image tiff)
<dc:creator>Image courtesy of the U.S.Geological Survey</dc:creator>
<dc:contributor>Image courtesy of the U.S.Geological Survey</dc:contributor>
<dc:relation>Image courtesy of the U.S.Geological Survey</dc:relation>
<dc:format>TIFF</dc:format>
<ows:BoundingBox>
</ows:BoundingBox>
</csw:Record>
- Request: elementSetName=brief(image tiff)

- Response
<ows:BoundingBox>
</ows:BoundingBox>
</csw:BriefRecord>
- Request:
elementSetName=summary(metadata modis)
http://localhost:8084/sis/VNSC/csw/2.0.2/getrecordbyid?service=CSW&version=2.0.
2&request=GetRecordById&elementSetName=summary&Id=MYD09A1.A2015337.h
00v09.005.2015349090129.hdf
- Response:
<dc:identifier>MYD09A1.A2015337.h00v09.005.2015349090129.hdf</dc:identifier>
<dc:relation>EDC</dc:relation>
<dc:title>MYD09A1.A2015337.h00v09.005.2015349090129.hdf.xml</dc:title>
<dc:format>MYD09A1</dc:format>
<ows:BoundingBox>
<ows:LowerCorner>-169.991725713781 -9.99094976958276</ows:LowerCorner>
</ows:BoundingBox>
+ elementSetname = full
<dc:creator>EDC</dc:creator>
<dc:contributor>EDC</dc:contributor>
<ows:BoundingBox>
</ows:BoundingBox>
</csw:Record>
elementSetName=brief(metadata modis)
<ows:BoundingBox>
</ows:BoundingBox>
</csw:BriefRecord>
4. GetRecords:
Filter
Note: the filter below (e.g. east, west, north and south bounds) are not yet conform to
a standard query language like CQL. Conformance with CQL will be part of future
work.
Request :
http://localhost:8084/sis/VNSC/csw/2.0.2/getrecords?service=CSW&version=2.0.2&r
equest=GetRecords&elementSetName=summary&resultType=results&constraintLan
guage=filter&identifier=&format=MYD&west&east=&south=&north=&startDate=2000-
07-10&rangeDate=2016-07-28&startPosition=0&maxRecords=4
Response:
<csw:GetRecordsReponse xmlns:csw="http://www.opengis.net/cat/csw/2.0.2"
<csw:SearchStatus>2016-08-09T03:39:30.292-05:00</csw:SearchStatus>
<csw:SearchResults numberOfRecordsMatched="6" numberOfRecordsReturned="4"
elementSet="summary" nextRecord="2">
<dc:title>MYD09A1.A2015353.h01v08.005.2015362104149.hdf</dc:title>
<ows:BoundingBox>
<ows:LowerCorner>-170.01704393303 9.73134966894526E-4</ows:LowerCorner>
</ows:BoundingBox>
<ows:BoundingBox>
</ows:BoundingBox>
<ows:BoundingBox>
<ows:UpperCorner>-172.470355262569 -9.97540516645831</ows:UpperCorner>
</ows:BoundingBox>
<ows:BoundingBox>
</ows:BoundingBox>
</csw:SearchResults>
</csw:GetRecordsReponse>
-Call service :
-http://localhost:8084/sis/VNSC/csw/2.0.2/getrecords?service=CSW&version=
2.0.2&request=GetRecords&elementSetName=summary&resultType=results
&constraintLanguage=filter
Response: (null)
<csw:SearchStatus>2016-08-09T12:33:36.058-05:00</csw:SearchStatus>
elementSet="summary" nextRecord="0"/>
if identifier != null
Request:
guage=filter&identifier=LC
Response:
<csw:SearchStatus>2016-08-10T08:02:54.475+07:00</csw:SearchStatus>
<dc:title>LC81270472016201LGN00.tar.gz</dc:title>
<dct:modified>2016-07-22T04:58:41+07:00</dct:modified>
<ows:BoundingBox>
<ows:LowerCorner>103.75192 17.7251</ows:LowerCorner>
<ows:UpperCorner>105.93204 19.83598</ows:UpperCorner>
</ows:BoundingBox>
<ows:BoundingBox>
</ows:BoundingBox>
<ows:BoundingBox>
</ows:BoundingBox>
if format!= null
Request:
work.
guage=filter&format=GEO
Response:
xmlns:dct="http://purl.org/dc/terms/"xmlns:dc="http://purl.org/dc/elements/1.
1/">
<ows:BoundingBox>
</ows:BoundingBox>
<ows:BoundingBox>
</ows:BoundingBox>
<ows:BoundingBox>
</ows:BoundingBox>
if west!= null east!=null south!= null north != null

Request
work.
guage=filter&&west=103&east=105&south=17&north=19
Response:
<ows:BoundingBox>
</ows:BoundingBox>
<ows:BoundingBox>
</ows:BoundingBox>
if startDate != null && range Date != null

Request
guage=filter&startDate=2016-1-1&rangeDate=2016-07-28
Response
<ows:BoundingBox>
</ows:BoundingBox>
<ows:BoundingBox>
</ows:BoundingBox>
<ows:BoundingBox>
</ows:BoundingBox>
if startPosition!=0&maxRecords!=0
Request:
guage=filter&startPosition=0&maxRecords=4
Response:
<ows:BoundingBox>
</ows:BoundingBox>
<ows:BoundingBox>
</ows:BoundingBox>
<ows:BoundingBox>
</ows:BoundingBox>
If all:(link use in client)
Request:
work.
guage=filter&identifier=LC&format=GEOTIFF&west=&east=&south=&north=&startDa
te=2000-07-10&rangeDate=2016-07-28&startPosition=0&maxRecords=4
Response:
<ows:BoundingBox>
</ows:BoundingBox>
<ows:BoundingBox>
</ows:BoundingBox>
<ows:BoundingBox>
</ows:BoundingBox>
if identifier!= 0 && startDate!=null&rangeDate!=null
Request:
http://localhost:8084/VNSC/csw/2.0.2/getrecords?service=CSW&version=2.0.2&requ
est=GetRecords&elementSetName=summary&resultType=results&constraintLangua
ge=filter&identifier=LC&startDate=2000-07-10&rangeDate=2016-07-28
Response:
This XML file does not appear to have any style information associated with it.
The document tree is shown below.
xmlns:dct="http://purl.org/dc/terms/"xmlns:dc="http://purl.org/dc/elements/1.1/"
>
<ows:BoundingBox>
</ows:BoundingBox>
<ows:BoundingBox>
</ows:BoundingBox>
<ows:BoundingBox>
</ows:BoundingBox>
….
CQL_TEXT
Request :
http://localhost:8084/VNSC/csw/2.0.2/getrecords?service=CSW&version=2.0.2&request=Get
Records&elementSetName=summary&constraintLanguage=CQL_TEXT&constraint=%22cs
w:AnyText%20like%20%27M%%27%22&startPosition=0&maxRecords=10
Response
<ows:BoundingBox>
</ows:BoundingBox>
<ows:BoundingBox>
</ows:BoundingBox>
<ows:BoundingBox>
<ows:LowerCorner>-170.01704393303 9.73134966894526E-4</ows:LowerCorner>
</ows:BoundingBox>
<ows:BoundingBox>
<ows:UpperCorner>-172.470355262569 -9.97540516645831</ows:UpperCorner>
</ows:BoundingBox>
<ows:BoundingBox>
</ows:BoundingBox>
<ows:BoundingBox>
</ows:BoundingBox>
VI. Build demo interface CSW service

DEVELOPER GUIDE
1. Download:
- Open terminal
- git clone https://github.com/haonguyen123/sis.git
- cd sis
- git checkout JDK8
- mvn install
2. Config:
- Open folder application/sis-webapp/src/main/resources/org/apache/sis/services/csw/
- Set ’Path’ in file config.properties t o local storage (Folder keep data geotiff and
modis. See more in USER GUIDE part 2)
3
. Run:
- Open project in Netbeans: (ide- project/Netbeans)
- Build sis.
- Open sis-webapp module in Netbeans: (application/sis-webapp)
- Build sis-webapp
- Config server Tomcat to port 8084
- Run SIS-WEBAPP project:
USER GUIDE
1. Web Interface:
Search criteria include:
● Name: File Name
● Format: Name satellite of interest (Landsat 8, MODIS)
● Coordinate: Geographic area of interest (ex:
101.51,22.92,106.61,22.92,106.61,22.92,108.15,20.22,105.12,16.8,101.51,22.92 for
Vietnam)
● Date: Date and time of interest (from dd/mm/yyyy to dd/mm/yyyy)
Physical parameter of interest (if have time, will be developed)

2. Upload data (admin):
- Create 3 folder to store data:
+ package
+ geotiff
+ modis
- Open folder and copy data to the right format:
+ Geotiff Example:
+ Modis Example:
2. Search:
+ Enter input field
+ Click Submit
Example:
- The page will return a table of results list:
3. Downloading:
Method 1:
+ Search for data.
+ Click Download.
+ File will saved to user’s folder
Method 2:
+ Search Data.
+ Click to File Name.
+ In the new page. Click Download file of interest
+ Modis Example:
+ Geotiff Example:
Technical Specifications
- API: google map API to see or search according to area
- Language programing: java, JavaScript, html, css.
- Server manage: Tomcat
- Library apache sis, branchs JDK8...
VII. References
- Apache SIS and standards in Geospatial information - Martin Desruisseaux
- LSDS-809 - Version 9.0 - May 2015 - U.S. Geological Servey (USGS )
- TIFF Revision 6.0 - Final - June 3, 1992
- http://www.remotesensing.org/geotiff/spec/contents.html
- http://docs.oracle.com/javaee/6/tutorial/doc/gijqy.html
- http://www.opengeospatial.org/standards/cat
- OGC Catalogue Services Specification 2.0.2 - ISO Metadata Application Profile (1.0.0) -
Dr. Uwe Voges, Kristian Senkler

CSW - Catalogue Service For The Web

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CSW - Catalogue Service For The Web

Uploaded by

Copyright:

Available Formats

CSW prototype for Apache SIS

I. CSW: Catalogue Service for the Web

OGC Catalogue interface standards specify the interfaces, bindings, and a

1 Catalogue Service - Overview .

Class name Description

MD_Metadata Contains Metadata entity set

MD_Identification This abstract class contains

MD_DataIdentification Subclass and concretion of the

SV_ServiceIdentification Subclass and concretion of the

3. Mappings to the common XML Record format [​ 3]

Band Reference Band Description Band Center

1 Coastal Aerosol (Operational Land 433

2 Blue (OLI) 482

3 Green (OLI) 562

4 Red (OLI) 655

5 Near-Infrared (NIR) (OLI) 865

6 Short Wavelength Infrared (SWIR) 1 1610

7 SWIR 2 (OLI) 2200

8 Panchromatic (OLI) 590

9 Cirrus (OLI) 1375

10 Thermal Infrared Sensor (TIRS) 1 10800

Table 2-1. Band Reference Table

Level 1 Product Components

L1Gt / L1T image file (one for each band)

Quality Band (QB) file

L1Gt / L1T metadata file

Angle coefficient file

Table 2-2 lists the L1Gt / LT product components

2.4. Naming Convention

s Sensor of: O = OLI, T = TIRS, C = Combined TIRS and OLI

8 Landsat mission number

ppp Satellite orbit location in reference to the Worldwide

rrr Satellite orbit location in reference to the WRS-2 row of the

YYYY Acquisition year of the image

DDD Acquisition day of year

GGG Ground Station ID

.ext File extension, where .TIF equals GeoTIFF file extension,

2.5. L1 Metadata File

Parameter Name Value, Format, and Parameter Description /

LANDSAT_SCENE_ID = The unique Landsat scene

= The date when the metadata

OUTPUT_FORMAT = “GEOTIFF” The output format of the image.

SPACECRAFT_ID = “LANDSAT_8” Spacecraft from which the data

= “OLI_TIRS” Sensor(s) used to capture this

CORNER_UL_LAT_PRODUCT = -90.00000 through The latitude value for the

CORNER_UL_LON_PRODUCT = -180.00000 through The longitude value for the

CORNER_UR_LAT_PRODUCT = -90.00000 through The latitude value for the

CORNER_UR_LON_PRODUCT = -180.00000 through The longitude value for the

CORNER_LL_LAT_PRODUCT = -90.00000 through The latitude value for

= -180.00000 through The longitude value for the

CORNER_LR_LAT_PRODUCT = -90.00000 through The latitude value for the

CORNER_LR_LON_PRODUCT = -180.00000 through The longitude value for the

2.6. GEOTIFF (L1Gt / L1T Image File) - Mapping metadata Geotiff

3. Mapping metadata file to ISO 19115 use

Seq. Validation Rule

4. Mapping GeoTiff metadata to ISO 19115

3. Mapping metadata modis to ISO 19115

III. REST architecture

IV. REST architecture to CSW

- Request: elementSetName=summary(image tiff)

- Request: elementSetName=brief(image tiff)

if west!= null east!=null south!= null north != null

if startDate != null && range Date != null

3. Mappings to the common XML Record format [ 3]

if identifier!= 0 && startDate!=null&rangeDate!=null