CGDI Architecture Review and Direction Setting

1
CGDI Architecture Review and Direction Setting

• Objectives of this session
• Provide an overview of the endorsed and emerging
  CGDI services / application schemas
• Identify and prioritize the development of
  pressingly needed CGDI services / application
  schemas
• Provide input to help set the focus for the the
  future activities of the TAP and SAWG

2
CGDI Architecture Review and Direction Setting
Agenda

• Architecture Review
• Whats happening in Mainstream Web Service
  Environments
• CGDI Services
• CGDI Schemas
• Direction Setting
• Prioritize pressing services/schemas
• What should TAP/SAWG focus be?
• Could we be integrating better with mainstream
  web service environments?
• How can the CGDI Architecture better serve other
  IT/IM endeavours (e.g. GOL)

• What exists
• What is emerging
• What is pressingly needed

3
Mainstream Web Services

• Introduction
• Web Service are widely accepted as the computing
  platform of the future
• Next in the evolution from object-based to
  component-based to web-service-based computing
• Internet/Web provides a ubiquitous platform for
  computer-computer communication
• There are a number of Web service endeavors -
  they are summarized in this section

4
Mainstream Web Services
Web Services Architecture W3C Working Draft May
2003
Definition A Web service is a software system
identified by a URI, whose public interfaces and
bindings are defined and described using XML. Its
definition can be discovered by other software
systems. These systems may then interact with the
Web service in a manner prescribed by its
definition, using XML based messages conveyed by
internet protocols.
5
Mainstream Web Services
OASIS ebXML Technical Architecture Spec. v1.0.4
The mission of OASIS is to drive the development,
convergence, and adoption of structured
information standards in the areas of e-business,
web services, etc.
6
Mainstream Web Services

• ebXML Messaging Service Architecture

7
Mainstream Web Services
OASIS UDDI (Ariba, IBM, Microsoft)
8
Mainstream Web Services

• Microsoft .NET
• SOAP Web Services
• Making the tools available to easily develop .NET
  applications

9
Mainstream Web Services

• Microsoft MapPoint Web Service (for LBS
  marketplace)
• Find Locations converts the textual description
  (street addresses, postal codes, landmarks,
  airports) to lat/long
• Find Nearby given geographic location and a
  search distance, return a set of points of
  interest. Can upload own data source.
• Render Maps Can show the results of proximity
  searches and driving direction queries overlaid
  on a map.
• Calculate Distances and Create Routes calculates
  distance, drive time, and quickest or shortest
  route between two locations and returns
  turn-by-turn driving directions and the route
  highlighted on a map.

10
Mainstream Web Services

• ESRI ArcWeb
• ArcXML Services that can be included in ArcGIS
• ArcWeb for developers
• HTTP, WSDL, UDDI, XML, SOAP.
• Place Finder--Ranks a candidate list of place
  names and associated latitude/longitude
  coordinates for a given input place name.
• Address Finder--Determines the latitude and
  longitude coordinates for street addresses.
• Route Finder--Returns textual multilingual
  driving directions for a multipoint user-defined
  route.
• Map Image--Provides access to a wide variety of
  dynamic maps.
• Proximity--Returns all Points of Interest (POI)
  locations within a user-defined distance of a
  specified location (i.e., find all POIs within 5
  miles of x,y) or determines the nearest specified
  number of POI locations to a specified location
  (i.e., find nearest 3 POIs to x,y).

11
Open GIS Consortium (OGC)

• Their vision is a world in which everyone
  benefits from geographic information and services
  made available across any network, application,
  or platform.
• Their mission is to deliver spatial interface
  specifications that are openly available for
  global use.
• Developing Specifications for geospatial web
  services

12
CGDI Architecture

• CGDI based on web-services architecture
• Intents to leverage a standard web services
  platform - but still confusing as to which will
  emerge as the leader
• Largely based on OGC Web Services
• Service Specifications are stamped as being
  CGDI endorsed
• CGDI is, however, much more that a web services
  architecture and endorsed services - its about
  putting in place real service implementations
  serving useful data, coordinating infrastructure,
  tools, policies etc.

13
CGDI Services - Existing

• Geodata Discovery Service
• Web Map Service (WMS)
• Styled Layer Descriptor (SLD)
• Web Map Context Specification
• Web Feature Service (WFS)
• Filter Encoding Specification
• Geography Markup Language (GML)
• Others that are operational

Endorsed
14
CGDI Services - Existing

• Geodata Discovery Service
• Service to search and
• retrieve geospatial
• metadata
• The service that the Discovery Portal uses to
  search data providers' holdings.
• Based on the Z39.50 protocol
• Will ultimately be replaced by an HTTP/XML
  version - OGC Catalog 2.0 Spec?

15
CGDI Services - Existing

• Web Map Service (WMS)
• Service to retrieve a map (image)
• Operations are
• GetCapabilities returns layer/service metadata
• GetMap returns a map image
• GetFeatureInfo returns information about
  particular features

16
CGDI Services - Existing

• Styled Layer Descriptor (SLD)
• Language that defines how features are to be
  portrayed
• Used as part of WMS GetMap request

17
CGDI Services - Existing

• Web Map Context Specification
• XML document containing map metadata and enough
  information retrieve a particular map from a
  particular WMS server.
• Can be though of as a bookmark to a specific map.

18
CGDI Services - Existing

• Web Feature Service (WFS)
• Defines operations to retrieve
• and manipulate geographic features
• Two levels of functionality.
• Basic (read-only) WFS operations
• GetCapabilities Returns feature type list,
  service metadata
• DescribeFeatureType returns feature type schema
• GetFeature returns features selected by query
• Transaction WFS additionally operations
• Transaction creates, updates, or deletes
  features
• LockFeature lock features to prevent concurrent
  access

19
CGDI Services - Existing

• Filter Encoding Specification
• An optional component of the WFS GetFeature,
  Transaction, and LockFeature requests is a
  filter that selects the features to operate on.
  
• This spec defines the format of this filter.

20
CGDI Services - Existing

• Geography Markup Language (GML)
• WFS specifies that features
• are exchanged as GML
• Standard for encoding
• spatial data in XML
• Provides a grammar for encoding the geospatial
  content (feature properties, location, extent,
  feature relationships)
• Based on XML Schema
• Can be thought of as a schema writing language
  for spatial information
• provides a set of standard XML tags or elements
  for spatial features and geometry types.

21
CGDI Services - Existing

• Others that are actually operational (covered in
  more detail under Operational Architecture)
• NTS Lookup
• Postal Code Lookup
• Gazetteer

22
An aside.

• We need an approach on whether updates to adopted
  specs are automatically adopted or not!
• I.e. when GML 3.0 is releases, is it
  automatically adopted?
• Opinions?

23
CGDI Services - Emerging

• Web Gazetteer Service
• Web Coverage Service
• Web Registry Service

24
CGDI Services - Emerging

• Web Gazetteer Service
• Specialized Basic WFS
• GetCapabilities Return includes list of
  supported location types (eg city, river)
• DescribeFeatureType returns feature type schema
  (not strictly necessary as schema constrained)
• GetFeature returns features selected by query
• Schema of returned features constrained
  -SI_LocationInstanceBrief
• Optional support for retrieving parent/child of a
  feature

25
CGDI Services - Emerging

• Web Coverage Service (WCS)
• Allows retrieval of unrendered geospatial
  coverages allowing client to render/model
• Coverages contain values/properties of geographic
  locations - regular grid e.g. a GeoTIFF file, or
  as a tesselation of the surface (e.g. a TIN).

• Operations
• Get Capabilities returns list of layers and
  service metadata
• DescribeCoverageLayer returns detailed metadata
  for requested layers
• GetCoverage returns coverage for requested
  layers over requested area

26
CGDI Services - Emerging

• Web Registry Service
• Major OGC activity underway - will be basis of
  Service Registry, Geodata Catalog
• Two interfaces
• Interface for providers to register
• Interface for consumers to discover
• Service is independent of what is
  registered/discovered
• Will need profiles for each application (eg for
  service registry, geodata registry)

27
CGDI Services - Pressingly Needed

• Distributed web registry service
• General Geoprocessing Services?
• E.g Overlay, Routing, Point in Polygon, Image
  manipulation, Data Reallocation (aggregation),
  Distributed Spatial Analysis - percentage area by
  union, Buffer points and overlay with polygon,
  Plot visualization and report
• Geolinked Data Service?
• Provides a simple on-line access to the vast
  number of data collections that contain
  geographically related information, but do not
  include a rigorous definition of the geometry of
  the geographic object
• Web Notification Service?
• Can be notified when events happen, e.g. data you
  depend on has been updated
• Service Chaining?
• Others?

28
CGDI Services - Pressingly Needed (2)

• Security levels
• Feature editor
• CISE req. Bulk data extraction and downloading
  (via WFS)

29
CGDI Services - Pressingly Needed (3)

• Variety of clients
• WMS Legends
• WFS volume/performance
• GML Schemas
• GeoLinking (NLWIS, NFIS)
• Real-Time streaming

30
CGDI Schemas

• Services describe the protocol but often do not
  restrict the payload, e.g.
• Z39.50
• WFS
• To effectively interoperate, need to define
  standard schemas/profiles
• May be application domain-specific

31
CGDI Schemas - Existing

• Metadata Schemas
• GEO Profile for Z39.50
• Content Standard for Digital Geospatial Metadata
  (CSDGM)
• Canadian/US profile of ISO 19115 conforming to
  19139 Implementation Spec upcoming
• Data Schemas
• BC, Ontario, NRCan/CTI GML Schemas
• GeoBase Program

32
CGDI Schemas - Emerging

• Service Description Schemas
• OGC closing in on Web Registry Service that will
  be used as a service registry
• Part of this will be a schema for defining
  service offerings (RIM)
• Also part of same OGC endeavor are schemas for
  geodata served by the service (Updated OGC
  Catalog Specification)

33
CGDI Schemas - Pressingly Needed

• Discuss need for
• Application Schemas? Should these be GML? Or
  should GML really be a largely invisible
  communication mechanism?
• Are there any schemas that will be common across
  domains?
• Schemas for framework data?
• Schemas for registering
• GML schemas, Context Docs, SLDs, Events.
• Others?

34
Direction Setting

• Prioritize development of CGDI services/schemas
• List those that have been identified
• Discuss priorities

35
Direction Setting

• What should the future focus of the TAP/SAWG be?
• Push forward service/scheme development?
• Additional training on the architecture?
• Consult to Communities of Practice?
• Help solve common Communities of Practice issues?
• Solve operational issues (security etc)?
• What should the focus of the TVIP-2 be?
• Refine the vision?
• Define a roadmap?
• Better explain the architecture?
• Others?

36
Direction Setting

• Could we be integrating better with mainstream
  web service environments?
• Still a confusing domain with many competing
  endeavors!
• Microsoft making it very easy to develop .Net
  services!
• Is our approach of following the OGC correct? How
  can we use our our influence better?

37
Direction Setting

• How can CGDI architecture better serve other
  IT/IM endeavors e.g. GOL
• Is this a communication/training problem?
• Are operational issues holding this back?
• Is there not enough data being served by endorsed
  specs?
• Are the need tool to exploit available?

38
A aside on SOAP versus REST

• Indicative of the state of web service
  architectures
• Up until recently most web service platforms were
  SOAP-based
• Rest (REpresentational State Transfer) has
  recently emerged as a better mechanism
• REST uses URIs to identify resources, a small set
  of uniform actions (like, but not restricted to,
  HTTP's GET, PUT, POST, DELETE) to modify those
  resources, and transferring those resources using
  a representation (state) of the resource.
• See http//internet.conveyor.com/RESTwiki/moin.cgi