62
Copyright © 2006 Open Geospatial Consortium – All rights reserved
E1NameLocalizedStringvalue ogc:PropertyName
ogc:Literalsogc:Literal ogc:PropertyIsEqualTo
ogc:PropertyIsEqualTo ogc:PropertyName
AsourceObject ogc:PropertyName
ogc:PropertyName E2id
ogc:PropertyName ogc:PropertyIsEqualTo
ogc:PropertyIsEqualTo ogc:PropertyName
AassociationType ogc:PropertyName
ogc:LiteralSymbolizesogc:Literal ogc:PropertyIsEqualTo
ogc:PropertyIsEqualTo ogc:PropertyName
E1id ogc:PropertyName
ogc:PropertyName AtargetObject
ogc:PropertyName ogc:PropertyIsEqualTo
ogc:And ogc:Filter
Constraint Query
GetRecords
13.4 Recommendations
A facility to discover geospatial resources via a catalog is most certainly an essential component of an integrated client. However, the value of such a facility can be hindered
when catalogs offer their content in dissimilar fashions. In order to promote the best prospects for interoperability, catalogs must adopt common data structures for the objects
they store. For the ebRIM information model, that means using common templates for the ExtrinsicObject and Service objects.
In this initiative, we were pleased to be able to achieve a fair degree of interoperability between the IONIC and CubeWerx catalogs. Some of the problems that we encountered
are outlined in the preceding clauses. To learn more about obstacles to achieving interoperability, it would have been useful to have had access to additional catalog
services. Also, we would have found it informative for the catalog service implementers themselves to conduct and report on their own interoperability experiments.
Copyright © 2006 Open Geospatial Consortium – All rights reserved
63 In this initiative, our work centered on catalogs built on the ebRIM profile. We
understand there is also considerable interest in the CSWRecord and ISO catalog profiles and recommend they be explored as part of an integrated client in a future effort.
When used for client development, the catalog should be invisible. The catalog is the source of the extra information that allows a client to operate without pestering the user
for additional information. When used explicitly by the user it is important to present the discovery workflow in an
order that make sense from the standpoint of a user.
64
Copyright © 2006 Open Geospatial Consortium – All rights reserved
14 Feature Portrayal Service FPS
The new Feature Portrayal Service specification describes a service that is used to remotely visualize features from a Web Feature Service. Clients indicate the WFS and
feature types to be used, and provide styling information. This is useful when the data from the WFS cannot be visualized locally, possibly because the data is not familiar, or
because visualization of the symbology is not known.
14.1 Portrayal Image Retrieval using a Feature Portrayal Service
