Open Packaging Convention standard applied to compressed hypermaps

Open Packaging Convention standard applied to compressed hypermaps

The OPC standard

OPC (also known as OOXML) is a packaging strategy  that integrates elements of the ZIP compression, XML documents, and the web MIME types into an open standard that makes it easier to organize, store, and transport data. It was defined by Microsoft and approved as ISO 29500-2 and ECMA-376. It is used by Office 2007 and newer versions of Word (.docx), Excel (.xlsx), and PowerPoint (.pptx), along with XPS (.xps), Autodesk AutoCAD (.dwfx), etc (Figure 1). An OPC package can contain several files with a directory structure in it. Each file is called a “part” and all OPC package part names have to follow the URI restrictions and conventions. The format adds some extra files to increase interoperability. It incorporates a standardized way of recording file relations or links. It also incorporates a file with a few elements of metadata and a thumbnail with a small image for presentation purposes. All these extra parts allow some basic independent data maintenance, such as the extraction of a fragment of the package, thus guaranteeing that all the related resources will be extracted without the need to understand the actual encoding of the parts included in the package.

OPC is conceptually very similar to the KMZ and MMZ format, but offers some advantages. KMZ is a compressed file that uses a ZIP file format following the solution reuse criteria, but its structure is deeply related to the original KML. Therefore, it does not comply with the completeness criteria, and KMZ strategy is not accurately documented (it is not included in the KML specification) and thus, it does not comply with the formality and metamodel identity criteria. MMZ was never submitted for standardization or adopted by other vendors and has not reached a high popularity outside the GIS community. OPC uses an accepted popular compression schema and header (ZIP compression) but combines other advantages such as it can be directly manipulated by other OPC compatible tools that recognize the file structure and relations even if they are not able to identify or understand the format of some compressed parts. Phillips and Allemang (2010) prefer it over other alternatives as a file format for data archiving.

How to apply it to geospatial information

OPC format offers an opportunity for designing an standardized way to pack geospatial information in a single file that internally used the original data files that can be later recovered as they were produced. Due to the similarities between the old MMZ format and the OPC standard, we call this approach MMZX. Most GIS software offer the capability save a session composed by different information layers, symbolization, presentation, metadata, etc. This format does not contains the information but links to it. Recently the OGC has introduced a new standardized format that also can to this: the OWS context. It is possible to create a software that is able to collect the "context" file plus all the data files and symbolization and configuration files and create a OPC package. Apart from the geospatial data parts of the file, OPC specifies how to explicitly relate different parts using .rels files (relations are composed of a source file and a target file, and the purpose of this relation is like in the RDF format). These files are XML files that have the same name as that of its respective source part adding “.rels” and placed in a “rels” folder. Each of these files lists the target parts related to its source and the semantics of this relation. 

MiraMon implementation

Recently, MiraMon has complemented the old MMZ file with the new MMZX file format that is fully follows to the OPC standard. This format is able to share geospatial information in a single file that can be decompressed and visualize automatically using the MiraMon Universal Map Reader (http://miramon-universal-map-reader.en.softonic.com/) or the MiraMon professional software

How to read and see the internal OPC structure

This page provides some clues on how to work ith OPC files http://www.wikihow.com/Open-XML. Mainly, there are two general use tools for doing this the Package Explore and the OOXML Chrome viewer plug-in.

More information about the OPC format

• Wikipedia page
• Good description of the format structure
• ISO/IEC 29500-2:2012, specification document
• Very good page form the library of the congress with link to more resources
• LibOPC

OWS Context validation alternatives

Introduction to OWS Context

The OGC Web Services Context Document (OWS Context) allows a set of configured information resources (service set) to be passed between applications primarily as a collection of services. OWS Context is developed to support in-line content as well. The goal is to support use cases such as the distribution of search results, the exchange of a set of resources such as OGC Web Feature Service (WFS), Web Map Service (WMS), Web Map Tile Service (WMTS), Web Coverage Service (WCS) and others in a ‘common operating picture’. This standard covers almost all use cases for the old Web Map Context standards and intents to replace it.

The standard can be found here: http://www.opengeospatial.org/standards/owc

A OWSContext XML file can be encoded in XML and in JSON (still under development).

The XML encoding is an extension of the W3C Atom standard (RFC4287). RSS and Atom readers are able to reed them and present some information. Geospatially enabled clients can share the 'common operating picture' better.

OWS Context Validation

The http://schemas.opengis.net/owc/1.0 contains the official RelaxNG compact schemas (.rnc extension) to validate OWS
Context files. RelaxNG compact validation was chosen following RFC4287 that also provides a RelaxNG for Atom.

This post presents other validation alternatives that are not official but can be equally useful. I have found that RelaxNG compact notation is not supported for many of the usual tools that I was using for validating XSD so I imagine that other people can have the same problem and might find this post useful

Alternative 1: Use the RelaxNG XML format

Some tools that I have found to validate RelaxNG only supports the XML notation (.rng extension). I have created those. It was not so difficult since there is a tool that can do this for you. You can find this in https://github.com/joanma747/owscontext-xsd

Alternative 2: Use a combination of XSD schemas and Schematron

Mainly there are to advantages in RelaxNG: It is There support better extensible XML creation and they include contextual validation rules based on xpath. Support for extensible XML creation can also be included in XSD if some tricks are used. I learned some of this tricks from some Atom XSD validation that I have found (and in particular http://www.atomenabled.org/developers/syndication/atom-format-spec.php) such as the use of xs:choice and xs:any. Support to contextual validation rules based on xpath can be done using Schematron (that has been used in OGC in combination with XSD for a while).

You can find this in https://github.com/joanma747/owscontext-xsd

OWS Context examples

https://github.com/joanma747/owscontext-xsd also contains the same examples that can be found on the OGC original repository but I have edited them to link to the XSD, SCH and RNG corresponding files.

Joan Masó