Scope Discussion


A context document is an XML document supporting the exchange of a shared geographic picture (map) between two end user applications. The map may be comprised of:

  • an area of interest (a bounding box)
  • WMS services
  • Other OGC W*S services (WFS, SOS, WCS)
  • GML (inline or referenced)
  • KML (inline or referenced)
  • Atom+GeoRSS (inline or referenced)

XML encoding design questions

  • how verbose?
    • how many URLs?
      The original intent of the context document was to provide just enough information for a client to create a data object for the service and go back to the service's capabilities document for binding information.
      Some would like Context to include all information needed to access the service, and only fall back to Capabilities in unusual edge cases. This implies that Context should not only contain a Capabilities URL, but also include a GetMap (or GetFeature, etc.) URL in cases where the two URLs are different.
    • how to handle styles?
  • how do you handle unsupported services and formats?
  • how about a gzipped, folder-style format like KML and those new Office formats have?

The exact display may differ slightly according to:

  • Display Technology Used: Web applications, Desktop GIS systems and Spinning VR Globes have different opportunities and limitations. The important part is that the application present the same "operational picture" to the end user.
  • Target Audience: Symbology may be different in order to communicate (MIL2525B for military, Emergency Response Symbols for domestic use, or Cartoons for the nightly news). Applications may need to adjust colors if the user is color blind etc...

Current discussion is centred around:

  • Local Resources: Most applications support "custom" data; either local data on disk or web specific data sets like google maps.
  • Services being down; or applications being unable to support the specific styles or formats used in the context document.
  • Markup in the form of "inline GML" or otherwise

The current idea is to open up the "Extension" mechanism on this "Mass Market" wiki and see what kinds of things can be addressed. The assumption is successful solutions can be rolled into the specification; where success is demonstrated interoperability between a range of concerned organizations.

Use Cases

Define a Shared Map between Sever Applications

This use case is a really common request; the ability to pick up a "configuration" from one server and drop it into another. Using a context document for this work would be very helpful; since end user applications can already work with context documents - the ability to "publish" what they are seeing out to a broad community is the assumed goal.

When considered with this goals in mind questions quickly becomes how to bundle the data with the context document. Inline GML (originally proposed for Marking up a Map) starts to look attractive; zipping up the data with a context document is another proposed idea.

Bookmark/Save a map session