G'Day all,
In a GN 2.4.3 install:
We are using an OAI-PMH harvester to bring literature metadata in from a
remote server. On the remote server, we've set up the records to use
dc:coverage to store a spatial extent.
The overall intention is to make the literature available through a spatial
search in GN.
In the first instance, we attempted to use a controlled vocabulary that
matched with a table of known extents stored in GN. For example, the term
ORD RIVER is matched precisely between the remote source and the local GN
installation, where we have a table that stores the bounding box extent of
ORD RIVER.
However, we have been advised that there is a very difficult intermediate
step required to join the harvested dc:coverage fields with the stored
extent fields.
Accepting this (reluctantly) our next strategy is to re-work the source
metadata so that we can store the actual extents in dc:coverage. So instead
of dc:coverage=ORD RIVER, we have something like:
northlimit=5980000; westlimit=644000; eastlimit=647000; southlimit=5966000;
name=ORD RIVER
My questions are:
1. Is this going to deliver the harvested metadata records straight to the
GN search indexes, or is there some other step involved to get GN to
recognise these values as spatial terms?
2. Can anyone confirm the syntax required for GN to pick these terms up?
Thanks in advance, much appreciated.
--
View this message in context: http://osgeo-org.1803224.n2.nabble.com/How-to-use-dc-coverage-in-GN-tp5840968p5840968.html
Sent from the GeoNetwork users mailing list archive at Nabble.com.
On 12/16/10 12:56 AM, boabjohn wrote:
G'Day all,
In a GN 2.4.3 install:
We are using an OAI-PMH harvester to bring literature metadata in from a
remote server. On the remote server, we've set up the records to use
dc:coverage to store a spatial extent.
The overall intention is to make the literature available through a spatial
search in GN.
In the first instance, we attempted to use a controlled vocabulary that
matched with a table of known extents stored in GN. For example, the term
ORD RIVER is matched precisely between the remote source and the local GN
installation, where we have a table that stores the bounding box extent of
ORD RIVER.
However, we have been advised that there is a very difficult intermediate
step required to join the harvested dc:coverage fields with the stored
extent fields.
Accepting this (reluctantly) our next strategy is to re-work the source
metadata so that we can store the actual extents in dc:coverage. So instead
of dc:coverage=ORD RIVER, we have something like:
northlimit=5980000; westlimit=644000; eastlimit=647000; southlimit=5966000;
name=ORD RIVER
My questions are:
1. Is this going to deliver the harvested metadata records straight to the
GN search indexes, or is there some other step involved to get GN to
recognise these values as spatial terms?
Each 'harvester' will retrieve and then insert metadata into indexes (searchable fields). These scripts may need to be modified to reflect your special metadata content and then transform it into suitable spatial coordinates, as you outline. I think you need to process the incoming metadata into the existing spatial search fields, done in the database or shapefile, not in Lucene's index.
Thanks in advance, much appreciated.
--
Douglas D. Nebert
Senior Advisor for Geospatial Technology, System-of-Systems Architect
FGDC Secretariat T:703 648 4151 F:703 648-5755 C:703 459-5860