APPENDIX A3.4

Format Specifications for All Interfaces

This appendix describes the formats you must use when you:

A3.4.1 Specifying a Spatial Region of Interest for a Search

The API uses a very simple format for spatial extents. You must use latitude and longitude values, in decimal (not degrees/minutes). Longitudes in the western hemisphere and latitudes south of the equator are deemed to be negative values and thus must be prefixed by a minus sign. Thus, the valid range for West and East extents is -180 degrees to 180 degrees, and the valid range for North and South extents is 90 degrees to -90 degrees.

Figure 38 show examples of valid spatial regions of interest. The corresponding BoundingWENS Value for each example is shown below the figures.

Figure 38 Valid Spatial Regions of Interest

Figure 38 Valid Spatial Regions of Interest

A3.4.2 Specifying Free Text for a Search for a Database Search

To include an exact phrase when entering free text, enclose it in double quotes. To require a particular term or phrase to appear in search results, precede it with a + character. To exclude a particular term or phrase from search results, precede it with a - character. Text searches are not case-sensitive.

When you enter (a) search term(s) in the provided text box, use the methods demonstrated in the following examples to hone your search capability:

You may combine the inclusive (+), exclusive (-) and exact phrase ("...") search techniques in one search string.

A3.4.3 Specifying Boolean Search Expressions

Boolean search expressions apply only when you search for databases (product collections) in FGDC format. In order to construct a Boolean search expression, you must understand the GEO use attribute structure, and you must know which SGML (Standard Generalized Markup Language) tags, from the FGDC CSDGM fields, that you want to search on. For more information on the FGDC use attributes, see: http://www.blueangeltech.com/standards/GeoProfile/annex_a.htm#Use%20Attributes.

The Boolean search syntax takes the following form:

Singular expression
<sgml tag>:<search term>

Compound expression
<operator>( expression expression expression ...)

All search phrases are case-independent.

A compound expression can contain any number of singular or compound expressions. Compound expressions within compound expressions can themselves contain any number of singular or compound expressions.

The more complex an expression becomes, the slower the search will be.

A3.4.3.1 Search Term Syntax

A search term can be in one of two forms: an unbroken word or a phrase.

For example, a singular expression can be:

themekey:forest

where themekey is an SGML tag name from the FGDC/GEO profile.

Singular expressions can be truncated on the left or the right. For example, to match the word "reforestation", the following can be used:

themekey:*forest*

Truncation (especially left-hand truncation) generally slows the search down.

Special characters can be used in the unbroken word. For example, the
characters , = and / can be used, although some characters, like /, have to be escaped with a backslash \. A forward slash in a search phrase looks like:

placekey:canada\/alberta (this matches: canada/alberta).

You can manipulate the relevance of the results returned by the search by weighting the score of individual search terms. To do this, append to the right of the search word a pound (#) sign, followed by an integer from 1 to 10. This will multiply the search score for that term by the value that you specify.

For example:

OR( themekey:forest*#3 abstract:forest#10 )

This searches for the word "forest" in either the themekey tag or the abstract tag, but if it is matched in the abstract tag, it will get a higher weighting. Therefore the results with "forest" using the abstract tag get a higher relevance if the keyword score sorts the output.

Phrases are coded as such:

placekey:phrase( New Brunswick )

This matches the multi-word string as a single, unbroken phrase.

You cannot use truncation or weights or special characters with phrases.

A3.4.3.2 Compound Expressions

The following operators are valid in compound expressions:

There must always be an operator at the left of the compound expression. Compound expressions with the AND or OR operators must have at least two or more expressions inside. Compound expressions with the NOT operator may have one expression inside.

The following is an example of a compound expression:

AND( themekey:forest*#3 OR(title:forest#10 title:tree#10) title:phrase(New Brunswick) )

This expression requires the substring "forest" to appear in the themekey, and it requires the phrase "New Brunswick" to appear in the title, and it requires either the word "forest" or "tree" to appear in the title.

To put a weight on the term "New Brunswick" in the title, you can rewrite the expression as:

AND( themekey:forest*#3 OR(title:forest#10 title:tree#10) AND( title:new#10 title:brunswick#10) )

This is almost the same as the original expression, although it does not necessarily require the words "New" and "Brunswick" to appear in order or consecutively.

A3.4.3.3 Free Text

To search for free text across any of the FGDC fields, use the keywords parameters as described in the interface specifications in A3.4.2, Specifying Free Text for a Database Search.

A3.4.3.4 Other Considerations

The XML interface that searches for data products (searchForData) has three Boolean expressions: subjectBoolExpr, locationBoolExpr and productBoolExpr. However, you need only one of these expressions, since you can enter a complex Boolean expression across all metadata tags in any one of the Boolean expressions.

However, if there are many tags to be searched, it is simpler to break them into different search expressions. Also, the different score selections calculate the score based on the different interface parameters, not the tags that are specified expressions.

Again, all search phrases are case-independent.

APPENDIX A3.5

Best Practices

Many organizations are successfully putting into practice the concepts and technologies discussed in this section. To make the most of available GeoConnections Discovery Portal APIs, you should use the sample interfaces and related web services discussed in the previous chapters. This appendix provides other examples of how to consume these services.

A3.5.1 The Climate Change Search Portal

The Climate Change Search Portal is an application that combines several web services program interfaces (http://www.geoconnections.org/ccportal/). This service uses:

The portal combines these services in constructing a spatial search for data products through the GeoConnections Discovery Portal.

A3.5.2 The Earth Sciences Portal

The Earth Sciences Sector (ESS) Portal (http://ess.nrcan.gc.ca/prod_e.php) uses the GeoConnections Discovery Portal Business-Layer XML API in searching for ESS entries and caching the XML files containing the descriptions for those entries. When a user selects an entry, the XML description is transformed to HTML and is returned to the browser.

A3.5.3 GeoGratis: Free Geospatial Data Portal

GeoGratis (http://geogratis.cgdi.gc.ca) is a free data portal that allows users to download national-scale data. GeoGratis uses the GeoConnections Discovery Portal business-layer XML API to retrieve XML product descriptions from the GeoConnections Discovery Portal and reformats the XML to HTML for display.

A3.5.4 GeoConnections Framework Data

The Framework Data node of GeoConnections/GeoBase (http://www.geobase.ca/) facilitates the integration of national-scale and regional-scale framework data across Canada.

A3.5.5 TrailPAQ

TrailPAQ is a service that lets users find trails in Canada and plot them using a web map service. TrailPAQ uses a web map viewer client based on underlying OGC web map services. The web map interface may be used interactively to discover trails, and also to plot locations of discovered trails. TrailPAQ is available at http://www.trailpaq.com/.

 

<< Previous  |  Home  |  Top of Page  |  Table of Contents  |  Next >>