 |
|
|
7 Managing
Metadata
This section is intended to assist
data custodians or
IT staff who have responsibility for
managing metadata records for data products and web services in the NRDD and
CANRI Catalog.
Figure 10:
Orientation to Managing Metadata
Table 11:
Summary of References: Metadata Management
7.1 Overview:
the role of metadata in CANRI
Metadata is the quiet secret of CANRI: it's the foundation for
the network. This foundation is organised around two concepts: metadata for
datasets and (if applicable) metadata describing the web service where data
layers may be accessed..
The metadata for datasets is collected using the MET Online
interface. So when you create a new dataset (or other data product), you need to
provide a description of the data to the NRDD using MET Online. The
specification for this metadata is maintained by ANZLIC and is known as Page 0
metadata.. MET Online also collects several additional metadata elements known
as NSW Page 1 metadata.
The delivery of data layers is accomplished through a web
service (e.g., a dataserver). The metadata for services is stored in the CANRI
Catalog, which accommodates extensions to the core ANZLIC elements. We typically
refer to this service metadata as the "CANRI extensions".
Currently, the CANRI extensions are managed through the MEM
online interface. This is expected to change in the near future, with the MET
Online interface providing the functionality required for both data layers and
their service details.
Figure 11:
Relationship of CANRI Catalog with MEM and MET Online
From an operational perspective, user applications connect to
the CANRI Catalog. The CANRI Catalog is
currently implemented in Oracle and represents a manually maintained copy of the
NRDD metadatabase. CANRI services metadata is linked to the NRDD records where
relevant. The CANRI Catalog also incorporates ANZLIC records for non-NSW data
available through the CANRI applications, as well as records from OpenGIS
sources world-wide.
7.2 MET
Online: Metadata Management for the NRDD
Summary of References 9: MET
Online
|
Online version
|
|
|
Technical Support
|
|
|
ANZLIC Metadata
Guidelines
|
|
Overview
MET Online is the web-based management interface for your NRDD
metadata records. The interface is linked from CANRI's NRDD information page,
above.
The MET Online interface provides in-line help and
guidance.
It is usually a good idea to prepare your metadata before
launching the administration interface. To assist you, the table below sets out
the ANZLIC page 0 metadata elements. For more information about each element,
you should refer to the ANZLIC Metadata Guidelines, above.
Table 12:
ANZLIC Core Metadata Elements
|
Category
|
Element
|
Definition of Element
|
Obln
|
Max
|
|
|
Occ
|
Field
|
|
|
|
|
|
Dataset
|
ANZLIC Identifier
|
The unique identifier given to the dataset by
ANZLIC.
|
M
|
1
|
Text(15)
|
|
|
Title
|
The ordinary name of the dataset.
|
M
|
1
|
Text(160)
|
|
Custodian
|
Custodian
|
The business name of the custodial organisation or
responsible party associated with the dataset.
|
M
|
1
|
Text(120)
|
|
|
Jurisdiction
|
The state or country in which the Custodian of the
dataset is domiciled.
|
M
|
1
|
Text(30)
|
|
Description
|
Abstract
|
A brief narrative summary of the content of the
dataset.
|
M
|
1
|
Text(2000)
|
|
|
Search Word
|
Words likely to be used by a non-expert to find the
dataset.
|
M
|
N
|
Text(60)
|
|
|
Geographic Extent Name
|
The ordinary name of one or more pre-defined, known
geographic objects that reasonably show the extent of geographic coverage of the
dataset. This element is usually implemented as three discrete elements as
listed below
|
O
|
N
|
|
|
|
GEN Category
|
Category to which the Geographic Extent Name belongs
including map series, local government area and drainage divisions and major
river basins.
|
C
|
11
|
Text(80)
|
|
|
GEN Custodial Jurisdiction
|
Country, state or territory that is responsible for
maintaining the detail of the geographic object
|
C
|
11
|
Text(30)
|
|
|
GEN Name
|
Name of the geographic object.
|
C
|
11
|
Text(80)
|
|
|
Geographic Extent Polygon
|
Boundary enclosing the dataset expressed as a closed set
of geographic coordinates (latitude, longitude) of the polygon referenced to
GDA94. This is an alternate way of describing geographic extent of the dataset
if no pre-defined area is satisfactory.
|
O
|
N
|
Text(1000)
|
|
|
Geographic Bounding Box
|
A rectangle defining the minimum and maximum coordinates
of the entire data. This element is implemented as four discrete elements as
listed below.
|
M
|
1
|
|
|
|
North Bounding Latitude
|
Northern-most coordinate of the limit of the dataset
expressed in latitude, in decimal degrees.
|
M
|
1
|
Signed Real Number
|
|
|
South Bounding Latitude
|
Southern-most coordinate of the limit of the dataset
expressed in latitude, in decimal degrees.
|
M
|
1
|
Signed Real Number
|
|
|
East Bounding Longitude
|
Eastern-most coordinate of the limit of the dataset
expressed in longitude, in decimal degrees
|
M
|
1
|
Signed Real Number
|
|
|
West Bounding Longitude
|
Western-most coordinate of the limit of the dataset
expressed in longitude, in decimal degrees.
|
M
|
1
|
Signed Real Number
|
|
Data Currency
|
Beginning date
|
Earliest date at which the phenomena in the dataset
actually occurred.
|
M
|
1
|
Text(10)
|
|
|
Ending date
|
Latest date at which the phenomena in the dataset
actually occurred.
|
M
|
1
|
Text(10)
|
|
Dataset Status
|
Progress
|
The status of the process of creation of the
dataset.
|
M
|
1
|
Text(20)
|
|
|
Maintenance and Update Frequency
|
Frequency of changes or additions that are made to the
dataset after its initial completion.
|
M
|
1
|
Text(20)
|
|
Access
|
Stored Data Format
|
The format in which the dataset is stored by the
custodian.
|
M
|
1
|
Text(500)
|
|
|
Available Format Type
|
The format in which the dataset is available.
|
O
|
N
|
Text(240)
|
|
|
Access Constraint
|
Any restrictions or legal prerequisites that may apply
to the access and use of the dataset including licensing, liability and
copyright.
|
M
|
1
|
Text(500)
|
|
Data Quality
|
Lineage
|
A brief history of the source and processing steps used
to produce the dataset.
|
M
|
1
|
Text(4000)
|
|
|
Positional Accuracy
|
A brief assessment of the closeness of the location of
spatial objects in the dataset in relation to their true position on the
Earth.
|
M
|
1
|
Text(4000)
|
|
|
Attribute Accuracy
|
A brief assessment of the reliability assigned to
features in the dataset in relation to their real world values.
|
M
|
1
|
Text(4000)
|
|
|
Logical Consistency
|
A brief assessment of the degree of adherence of logical
rules of data structure, attribution and relationships. Data structure can be
conceptual, logical or physical.
|
M
|
1
|
Text(4000)
|
|
|
Completeness
|
A brief assessment of the extent and range in regard to
completeness of coverage, completeness of classification and completeness of
verification.
|
M
|
1
|
Text(4000)
|
|
Contact Information
|
Contact
|
|
|
|
|
|
Organisation
|
Name of the organisation from which the dataset may be
obtained.
|
M
|
12
|
Text(120)
|
|
|
|
Contact Position
|
The position in the Contact Organisation that will
answer questions about the dataset.
|
M
|
12
|
Text(40)
|
|
|
Mail Address
|
Postal address or delivery point of the Contact
Position.
|
M
|
22
|
Text(40)
|
|
|
Locality
|
Locality associated with the Mail Address.
|
M
|
12
|
Text(60)
|
|
|
State
|
Aust: State associated with the Mail Address
|
|
|
|
|
NZ: Optional extension for Locality.
|
M
|
12
|
Text(40)
|
|
|
|
|
Country
|
Country associated with the Mail Address.
|
M
|
12
|
Text(40)
|
|
|
Postcode
|
Aust: Postcode associated the Mail Address.
|
|
|
|
|
NZ: Optional postcode for mail sorting.
|
M
|
12
|
Text(10)
|
|
|
|
|
Telephone
|
Telephone number of the Contact Position.
|
O
|
12
|
Text(25)
|
|
|
Facsimile
|
Facsimile number of the Contact Position.
|
O
|
12
|
Text(25)
|
|
|
Electronic Mail Address
|
Electronic Mail Address of the Contact Position.
|
O
|
12
|
Text(80)
|
|
Metadata Date
|
Metadata Date
|
Date on which the metadata record was created or
modified.
|
M
|
1
|
Text(10)
|
|
Additional Metadata
|
Additional Metadata
|
Any additional metadata the supports documentation of
the dataset including a reference to another directory or report.
|
O
|
1
|
Text(4000)
|
7.3 MEM:
Metadata Extension Manager for Web services
This section is applicable to
technical staff who are setting up web
services, such as an OpenGIS Web Map Server (WMS). You'll be guided through the
process of accessing the MEM online interface and configuring/testing the
metadata record for your service.
Overview
The Metadata Extension Manager (MEM) is a web-interface for
the configuration of data layers available to the CANRI framework. MEM
interfaces with the CANRI Catalog metadatabase hosted by DLWC. The MEM is used
to collect and manage the additional services metadata – referred to as
"CANRI extensions" – necessary for providing online access to the data
layers.
Before accessing the MEM, you must have a login and password,
which may be obtained from the CANRI Technical Officer.
Notes and
Prerequisites
- The
dataset custodian must ensure that an ANZLIC-compliant metadata record has been
provided to the NRDD using the MET Online interface.
- The
ANZLIC metadata record must be manually entered into the CANRI metadatabase by
the CANRI metadatabase administrator
- The
administrator must have specified the subset of metadata records that are
visible for this user within the MEM.
- Several
layer definitions can be specified for a single metadata record.
- The
name "ICMISS" is the previous name for CANRI.
- The
term ‘middleware’ in this document refers to the MapBroker
application by Social Change Online. It is the blackbox into which we are
feeding layer options as described in this
document.
Getting started
The Metadata Extension Manager is located at: is.dlwc.nsw.gov.au/icmiss/manage/login.html
After login you are presented with a list of existing layers
visible to you for editing.
You can now [Delete] this layer, create a [New] layer
definition or [View] and edit this layer.
Please
delete any layer definitions that are superseded, as they will still be visible
to users when searching for metadata records that are linked to them.
Adding a New Layer
Definition
You are required to identify the metadata record to which you
wish to link your layer.
You can request a preselection of metadata records matching
searchwords in title and abstract, but usually you will identify the metadata
record by ANZLIC identifier ANZNS.......
If , on [Submit], the expected record does not appear, it is
either not in the database or you have not been granted access to this
record.
If the expected record appears , [Select] it and give your
layer a short name:
Layer Names
- Keep
this name short and free of spaces and other punctuation marks except
underscores
- Please
help with layer management by consistently prefixing this name with an
identifier of your agency, eg. “epa_wqms”,
“dlwc_acidsulp_soils”. This name need not be unique among all CANRI
layers, but it is likely that it will need to be unique among layer definitions
within your agency.
- If
you plan to use mapserv as your
dataserver for this layer, this name can only be 20 characters long. Due to a
bug in mapserv, each underscore
appearing in this name reduces the maximum permissable length by one
character.
You are now taken to
the ICMISS Extension page of the MEM and
are required to fill it out and [Apply] your settings. See documentation on
Editing a Layer Definition and proceed to supply all required information.
Editing a Layer
Definition
There is a Help facility built into the MEM interface which
describes the interface itself adequately, but is directed to the technically
minded user (i.e. someone who understands the meaning of ‘arbitrary
dataserver’ without further explanation) and does not mention bugs. Use it
for reference beyond this document, which aims to assist in defining layers
quickly.
Note:
All metadata extension layers are cached
by CANRI middleware. Do not expect to see changes by refreshing display
of your layer in an active application. Use the [Test Preview] tool instead,
remove and reload your layer in the application or restart the application.
If your layer is called from static XML files (eg. WebMap
Composer Data View, pre-defined themes in NRA, CoastalAtlas or custom
applications) you may have to manually make service detail changes inside the
applications as well.
Table 13:
Field Guide to CANRI (ICMISS) Extensions
|
Attribute
|
Notes
|
|
Layer Name
|
Change the layer name if
needed. See comment on layer names.
If your layer is called
from XML-files (eg. WebMap Composer, pre-defined themes in NRA, Coastal Atlas or
custom applications) you will have to change layer names there as well
!
|
|
Data Server
|
‘Dataserver’
in the context of this document means any program responding to
MapBroker’s request for returning geographic data, as images of rendered
layers or XML-style information about a layer, rendered by the middleware
itself.
Choose from a list of
dataserver URLs. These are defined and edited through [Data Server Maintenance]
dialog, which guides you through defining the URL of the CGI application
handling dataserver requests. Note that you cannot specify any parameters with
this URL (eg. '‘www.mysite.mapserv?map=mymap”) because CANRI
middleware will append “?” to the URL regardless. If you need
server-specific parameters you need to provide a
wrapper-application.
|
|
Protocol
|
CSGI2.0 for
dslite
and
mapserv,
WMT1.0 for WMS1.0 compliant dataservers.
|
|
Description
|
Describes layer in list of
layers on login to MEM.
|
|
Metadata
Extension
|
|
Creator
|
Your name, consistent
across layers, please.
Click [Apply] to save
your changes.
|
|
Spatial Context
|
Set a list in which
datum/projection your dataserver can return features, and for which spatial
extent (enclosing rectangle) in a map-request the dataserver should attempt
mapping.
The most common setting
for NSW government agency layers is AGD66/Geographic (latitude, longitude in
decimal degrees). The following extent will display the whole of NSW including
Norfolk Islands: -20.0 N, 140 W, 160 E, -40 S.
If your dataserver
supports reprojection (eg.
mapserv),
you can define multiple entries for datum/projection. WMS ompliant dataservers
will always return available projections in their capabilities
document.
Note: ANZLIC
metadata records allow specification of several extents, so you may see several
named extents. In practice only one spatial context will be used for each layer
definition. If your dataset comprises of many tiles it is advisable to furnish
a metadata record describing the dataset as a whole, treat the dataset as a
single entity (through merging of tiles or the use of tiling features in the
map server) and define the extent for the complete dataset.
|
|
Queriable Attributes
|
Allows display of a subset
of data according to a textual attribute criterion Oracle SQL function
‘LIKE’. Supported only for pointlayers layers using
DSLITE
dataserver. The value for
‘Column’ must correspond to the name of the column(s) in your
DSLITE
datasource. Only the String ‘Type’ has been tested.
|
|
Capability
|
|
Name
|
You are required to
provide a short description of what the layer shows, which will be appended to
the layer’s title in the map legend.
This is very useful when
defining multiple layers for a single metadata record (see AUSLIG’s
‘Global Map Data Australia’ dataset for an example).
Note:Do
not include punctuation marks in this field as some software modules currently
cannot handle this.
|
|
Feature
|
Geographic data type. Only
'point', 'line' and 'polygon' specifications have been used so far. The choice
presented does not directly correspond to WMS compliant queries.
|
|
Vector Type
|
Specify what the
dataserver actually returns. This can be either text-based (XML) or image-based
(currently only GIF supported).
|
|
Image Type
|
If your dataserver returns
XML/GML-style list of datapoints
(DSLITE
pointdata server,
ServerServlet,
WebFeatureServer), VectorType is set to‘Text/XML’, ImageType to
'none'.
For dataservers returning
GIF images VectorType is set to 'none' and 'ImageType to 'image/gif'.
Once the above fields have
been specified and [Add]ed to the layer’s definition we can define
attribute and display characteristics to the layer. Press [Apply] to save your
settings.
|
|
Field
|
Applies only to point
servers, eg.
DSLITE
and
WFSLite.
Specify the field in your pointdata table which will be used to display a single
pointfeature’s attribute when the mousepointer hovers on top of it on the
map, and the layer has been activated for querying. Default is
'Label'.
|
|
Presentation
|
Each option requires a
short description for display in the navigation- tree on the left side of the
dialog and for presentation of layer capabilities in the extended metadata
record displays.
|
|
URL of Icon to use in Legend
|
The completely specified
URL retrieving the image used in legend and search catalog. In the case of point
data, this will also be used to render this layer.
Example 1: Hand-drawn
image to represent
points: is.dlwc.nsw.gov.au/gifs/orangetriangle_saline.gif
Example 2: Program
generated, classification/based legend:
is.dlwc.nsw.gov.au/cgi- bin/fornet3/mapserv3?map=dlwc2/dlwc2_geo.map&mode=legend&layer=dlwc_dryland_sal_haz
Example 3: Legend
‘copied’ from a website:
globe.gsfc.nasa.gov/globe/en/icons/colorbars/rprain.h.gif
|
|
URL of external web interface
|
Provides a button to link
to an arbitrary website. Currently a bug (or is it a feature ?) will link the
layer to the ANZ metadata record if there is one. Only from within the extended
metadata record (displayed when double-clicking the layer-title in the legend or
search dialog) you will be able to link to the external site as
intended.
|
|
Geographic Extent
|
Zooms map to extent of a
feature when clicked (requires Feature Details option). Problems with point data
layers as middleware does not deal with extent of magnitude 0.
|
|
Feature Details
|
A flag that this layer can
be queried against attributes. No entry in ‘Default’ field required.
Layers with this attribute will have a blue rectangle around the legend symbol
(old NRA interface) or a checkbox in the Query column of the legend
(WebMapComposer).
|
|
URL of external web interface for a single Feature
|
Fully specified URL to an
application that will produce a report for a feature other than feature-info
capabilities inbuilt into the middleware. The customized program will receive
the identifier-value from the dataset as returned in dataserver XML element
<ID> as in: waterinfo.dlwc.nsw.gov.au/servlet/dummyreport?site=
or
Part of an URL pointing to
a website that stores individual static html-pages for each feature on the map
(‘root directory’). Currently there are two ways of realising this
feature:
- using
Mapserver as your dataserver, employ template mechanism to translate an
arbitrary column value for this feature into the name of a corresponding
web-page (Example: ‘Statistical Local Area’ layer by
ABS).
- pointdata
only: store the name of the html-page in a column of a dataset served by
DSLITE
Example:
‘Monitoring River Health Initiative’ by EPA, using
defaults:
A column in your
DSLITE-readable database named ‘ID’ holds unique identifiers
ID,X,Y,Label
ID_400, 135.0, -35.0,
‘Site 1’
ID_401, 135.1, -35.1,
‘Site 2’
ID_402, 135.2, -35.2,
‘Site 3’
Specify URL to root of
static document directory, eg: mysite/gis/mylayer/staticpages/
Place pages called
‘ID_400’, ‘ID_401’, ‘ID_402’ into the
physical path mapped to the URL above, each containing your customized content
for presentation of the particular feature.
|
|
String interpreted by data server
|
This option is currently
not honoured. Its purpose is to send additional, static information about this
layer to a dataserver outside the standard CSGI/WMS protocol.
|
|
Named Style
|
The value for the
‘style’ key in WMS-compliant queries. Can be used to pass additional
information to a customized data-server wrapper for special
purposes.
|
7.4 Testing and
troubleshooting
Testing for each layer consists of checking the intended
functionality against actual outcome. Troubleshooting procedures are very
different for each data layer and dataserver environment.
Typical troublespots are:
- incorrect
or incomplete metadata-extension specifications
- metadatabase
inconsistency
- mapserver
configuration requirements
- data
inconsistencies
- disfunctions
from special characters in URLs
- mapserver
environment (java, perl)
- server
configuration (file access, routing issues)
DLWC
maintains a testing regimen by regularly invoking dataservers for each layer and
flagging non-response. This process is not fully automatic yet.
|
