Client applications are mobile. They can be found in enterprise desktop environments, workhorse tablets, or phone platforms. Information services are mobile. They are distributed across clouds, internal servers and even individual users. And they consist of raw data and just-in-time processing capabilities. With such an adaptive, open environment, security is a must. The Open Mobility thread of OWS-10 explores the geospatial standards requirements to implement these concepts.
Topics in this thread include:
· Cloud Computing: Exploitation and service performance enhancement
· Mobile Data: GeoPackages and GeoPackaging services
· OWS Context: JSON encoding and KML annotations
· Security: GeoXACML, PEPs, and PDPs
· Integrated Client Enhancement Study: Augmenting the OGC architecture to facilitate linking related data across services
References (in addition to those in the bibliography):
Cloud computing is the use of resources (hardware and software) that are delivered as a service over a network. Cloud computing provides remote services with a user’s data, software and computation. Users access cloud-based applications through a web browser or mobile app. Cloud computing allows enterprises to get their applications up and running faster, with improved manageability and less maintenance, and enables IT to more rapidly adjust resources to meet fluctuating and unpredictable demand.
Cloud computing relies on sharing of resources to achieve coherence and the ability to scale over a network. A cloud computing environment can support multiple tenants in the same physical environment. An enterprise performing large-scale geospatial data production could manage work between multiple producers in a shared cloud environment by partitioning production responsibilities, for example by geography or by scale. In such an environment, the data produced needs to be consistent between each tenant performing production.
In this testbed the objective is to explore the state of the art in geospatial cloud computing, starting with existing geospatial cloud services in current use, and add an interoperability layer. Of particular interest are those cloud services that already implement OGC services such as WMS, WMTS, WCS, WFS and WPS. Of particular interest is in how these scale, and how they can be augmented with processing services and used in workflows.
Mobile device users who require map/geospatial application services and operate in disconnected or limited network connectivity environments are challenged by limited storage capacity and the lack of open format geospatial data to support these applications. The current situation is that each map/geospatial application requires its own potentially proprietary geospatial data store. These separate application-specific data stores may contain the same geospatial data, wasting the limited storage available, and requiring custom applications for data translation, replication, and synchronization to enable different applications to share the same world view.
In addition, many existing geospatial data stores are platform-specific, which means that users with different platforms must translate data to share it. An open, standards-based, application-independent, platform-independent, portable, interoperable, self-describing, GeoPackage (GPKG) data container, API and manifest are needed to overcome these challenges and to effectively support multiple map/geospatial applications such as fixed product distribution, local data collection, and geospatially enabled analytics.
In addition to exercising the GeoPackage format, this thread will develop services for creating and synchronizing GeoPackages with themselves, and with complementary OGC services. Synchronization should be bi-directional, with a GeoPackage being able to update a geodata service, and a geodata service being able to update a GeoPackage. There is particular interest in solutions which utilize Cloud storage capabilities for the source geodata.
The OGC Web Services Context Document (OWS Context) was created to allow a set of configured information resources (service set) to be passed between applications — primarily as a collection of services, but it supports 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 geospatial data 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’. Additionally OWS Context can deliver a set of configured Web Processing Service (WPS) parameters to allow the processing to be reproduced on different nodes.
A conceptual model and an Atom XML encoding exist for OWS Context. OWS-10 develops a JSON encoding and explores the use of KML to create annotations on OWS Context resources.
OWS Context can be a useful situational awareness tool when embedded in other data formats. Of interest in OWS-10 is how OWS Context can be used with a NIEM-based Request for Information (RFI) IEPD, which wraps an OWS Context document to provide links to relevant data as well as annotations highlighting a feature of interest. This should be encoded in Atom and JSON formats.
As an option to exercise this information encoding, a Web browser-based client is required, which will accept the NIEM RFI IEPD, and open and view the embedded OWS Context information. It should also be able to update the OWS Context as well as the NEIM RFI IEPD, and distribute the updated document.
New NIEM tools are imperative to keeping pace with the demand for NIEM. Across the Federal, State, local, private industry, and international communities, organizations are seeking better ways to rapidly rollout new NIEM-based information-sharing services. And increasingly, these organizations are struggling to create new and more efficient ways to keep pace with the growing demand for NIEM information exchanges.
NIEM breaks down barriers to information sharing by establishing a standard for information sharing between Communities of Interest (COIs) at all levels of government. This effort shall:
a. Develop a NIEM based Request for Information (RFI) IEPD which wraps an OWS Context document providing links to relevant data as well as annotations highlighting the feature of interest.
b. Develop a Browser based client solution to ingest an RFI IEPD then process and display the OWS Context. Furthermore, the client and associated processes shall include the ability to:
i. Add additional Information to the IEPD content including the OWS Context content
ii. Update NIEM RFI IEPD
iii. Distribute the updated RFI IEPD
c. Develop ATOM, JSON, GeoJSON, GeoServices REST JSON, and HTML5 representations of NIEM for the OWS Context
The RFI IEPD shall contain an OWS Context document wrapped inside it. The OWS Context document may contain a wide variety of valuable data that provides a rich and much more complete picture for situational awareness. The NIEM IEPD format shall be maintained so that a consumer application expecting to receive a conformant NIEM IEPD would be able to ingest and process the NIEM-related content. The Context Document content contained within the RFI exchange document shall be able to be processed and displayed in the browser client.
The participant shall provide necessary alerting and data sharing tools required to accomplish the scenario described in the CCI Thread.
Security has been explored in many OWS Testbeds. In this Testbed, the focus is on aspects of security unique to mobile devices. For instance, it is critically important that a device truthfully reports its location. The GPS location, for example, can be spoofed by a malicious user. However, they can not fake the location of the cell tower their device is nearest to. Therefore, a useful way to add security to mobile device positioning is to validate that the GPS location reported makes sense relative to the cell tower in use.
It may also make sense to digitally sign location reporting information so that the receiver can link the location report with the user who is supposed to have the device. This can form the basis of further security actions, such as providing access to GeoPackages on the device, or allowing a camera or other sensing device to be used. Authentication and authorization will include role-based and attribute-based rules indicating where a user and consumer is authorized access to particular services or GeoPackages, and whether they have read-only or modification privileges.
The ability to discover the association between a data set in one service and that in another can be important to exploit OGC services in the most efficient manner. For example, knowing that a WMS layer has a specific WFS feature as its data set is important to apply the proper style to render the layer and access the feature’s vector representation if analysis is needed. Another example links WMTS and WCS. A linked OWS-aware client could quickly navigate a global WMTS, drilling down to a specific area of interest, then access the WCS for high-resolution, multi-band imagery in that area.
It is impossible to discover this type of association using the current OGC Web Services architecture. Additional capabilities metadata may be needed, as well as additional service operations. This study seeks to determine what changes are required to the OWS stack in order to realize the integrated client vision.
See Annex A: Integrated Client Enhancement Description of this section for more information.
Summary of Deliverables for OWS-10 Open Mobility Thread
|1. OWS-10 OWS Context JSON Interoperability [ER]|
|2. OWS Context Change Requests [CR]|
|3. OWS Context with NIEM [ER][EN] (UNFUNDED)|
|4. NIEM Client [Client] (UNFUNDED)|
|5. OWS-10 Performance Enhancement through Cloud Computing [ER]|
|6. Cloud infrastructure for services [Service]|
|7. Cloud services [Service]|
|8. OWS-10 GeoPackaging [ER]|
|9. GeoPackaging Service Reference Implementation [Service]|
|10. Mobile GeoPackage and OWS Context Client [Client]|
|11. GeoPackage Change Requests [CR]|
|12. OWS-10 Mobile Device Security [ER] (UNFUNDED)|
|13. Mobile App Policy Enforcement Point and Policy Decision Point [Component] (UNFUNDED)|
|14. Integrated Client Enhancement Study and Change Requests [ER][CR]|
This report shall describe the ability to encode an interoperable OWS Context document whether encoded using GeoJSON, JSON or GeoServices (Esri) JSON.
Formal OGC change requests based on gaps identified during the Testbed.
This report shall describe the ability to encode a NIEM RFI IEPD with an OWS Context document embedded. It should include exemplary ATOM and JSON representations of NIEM with OWS Context.
Develop browser-based client solution NIEM based Request for Information (RFI) IEPD which wraps an OWS Context document providing links to relevant data as well as annotations highlighting the feature of interest. This client should:
· Add additional Information to the IEPD content, including OWS Context content.
· Update the NIEM RFI IEPD
· Distribute updated RFI IEPD
This report shall analyze the impact of Cloud Computing on the performance of OGC Web Services, specifically processing services and access to large amounts of data.
OWS-10 requires cloud services in which to deploy OGC services. Infrastructure is needed to provision computing resources, such as multiple virtual machines, on-demand. Cloud based data holdings – image data, tile or vector data – are sought.
OGC services, such as WFS, WMS, WMTS, and WPS, that are located in cloud computing environments that scale beyond a single virtual machine.
Analysis of service development and implementation of the GeoPackage draft standard supporting vectors and tiles. Highlight any issues or concerns with implementing GeoPackage as a data container for a mobile device.
Prototype GeoPackage Service as an open source Reference Implementation. This service shall be capable of generating a GeoPackage for vector data from a Web Feature Service, Image/Terrain from a Web Coverage Service and Tiles from a Web Map Service / Web Map Tile Service. It should also be able to create an OWS Context document in JSON or Atom format referencing the data in the GeoPackage.
This client application will deploy on mobile devices and support disconnected use. It may target any of the following platforms:
- HTML5 (platform-agnostic)
- Windows 8
The client will support direct use of GeoPackages, update GeoPackages by modifying feature data, and serve as a client to the GeoPackaging service developed in this thread, sending requests to a WFS for updating the original data source. It will also support OWS Context and any new features developed for OWS Context in this thread, such as JSON formats and the KML annotation capabilities.
Formal OGC change requests based on gaps identified during the Testbed.
This report shall describe the ability to provide a “mobile” GeoXACML 3.0 policy which can be executed via mobile application Policy Enforcement Point and Policy Decision Point. The report shall document the use of these mobile apps with policy on a GeoPackage container.
PEP and PDP that can be utilized on a mobile device to grant access to the device’s hardware such as the GPS or camera, on-device files, and/or remote services.
Analysis of the recommendations made to support better integration across all OGC web services. Highlight any issues or concerns. Identify steps which are required to implement these suggestions across the board. Submit Change Requests as required to support integration of Integrated Client Enhancement Study ER recommendations.
The Open Mobility thread is fundamentally about blurring the traditional boundaries between client, server, and network environments, as well as client-server computing in general. For example, one requirement is for a mobile client application that exercises the GeoPackage draft specification. Unlike traditional client-server architecture, where the client application is supposed to interact with a service for all data requests, here we strive to create a client application that, to the user, “feels” as if the data it needs is completely local. While the user’s experience is simplified, the client must be much more sophisticated. The client application must cache data locally for performance benefits and so that the application can disconnect from the network and still function seamlessly. A GeoPackage can accomplish this by acting as a cache of geospatial information from a larger data store. We also strive to eliminate the complexities of information updating from the user by developing services around the GeoPackage such that it transparently synchronizes changes when connected. This allows users to not worry about mobility or networks.
In all these scenarios, the value of Open Mobility is that humans are freed from repetitive, error-prone tasks at which software excels. Subsetting data sets, synchronizing changes, deciding who can make changes, and keeping track of what changed when on what computer is computational bureaucracy, and it should be handled by computer systems whenever possible.
The enterprise requirements of this thread are described in the scenarios that follow. The scenarios may be modified/augmented by the Open Mobility OWS-10 team (participants, sponsors and IP Team) as needed throughout the initiative.
A group requires a common set of geospatial information to take in the field, disconnected from all networks. The geo office uses an area of interest to export data to a GeoPackage. These data come from all the foundational OGC web services – Web Feature Services, Web Coverage Services, Web Mapping and Web Map Tile Services. An OGC Web Context document is generated that contains references to the original services and their companion data sets in the GeoPackage.
This scenario continues where Scenario A leaves off. It adds the requirement for field data collection, updating the GeoPackage with information gathered while disconnected from the network. The user returns to the geo office with a GeoPackage slightly different from the one they left with. The geo office is able to update their data holdings using this modified GeoPackage through standards-based service interfaces, but only after the user is authorized to make updates.
A user wants to run a computing-intensive computation, so cloud-based processing services are used for this purpose. There are two situations the Testbed investigates. In the first, there is an existing cloud-based WPS that satisfies the user's needs. In the second, no existing WPS processes are sufficient, so the user deploys their own, custom process into the WPS.
The information viewpoint is concerned with the semantics of information and information processing. Listed here are various information modeling and encoding standards that have direct relevance to the requirements of the thread. For details, refer to the annotated bibliography.
· Geography Markup Language (GML)
· National Information Exchange Model (NIEM)
· OWS Context
· XACML and GeoXACML
The computational viewpoint is concerned with the functional decomposition of the system into a set of services that interact at interfaces. Listed here are various service interface standards that have direct relevance to the requirements of the thread. For details, refer to the annotated bibliography at the end of this Annex.
· Annex A: Integrated Client Enhancement Description
· Geosynchronization Service (GSS)
· OGC Web Service Common Implementation Specification (OWS Common)
· Policy Enforcement Point (PEP)
· Policy Decision Point (PDP)
· Web Coverage Service (WCS)
· Web Feature Service / Filter Encoding (WFS / FE)
· Web Mapping Service (WMS)
· Web Map Tile Service (WMTS)
· Web Processing Service (WPS)
The engineering viewpoint defines a set of components that form the basis for deployment in a distributed environment. Initial consideration for identification of Engineering is to consider the requirements identified in the Enterprise Viewpoint. Engineering components are accessed through services. Engineering Components handle data. The services and data that are used to define engineering components are defined in the previous viewpoints.
A GeoPackaging component retrieves geodata from OGC services and writes it to a GeoPackage. This may be accomplished by designing one or more new services, or extending existing OGC services. GeoPackage formats supported shall be GeoPackage Features and GeoPackage Tiles. WFS data shall be translated to GeoPackage Features. WMS, WMTS and WCS data shall be translated to GeoPackage Tiles. There is special interest in solutions which utilize Cloud storage capabilities.
Additionally, WCS data may be translated into a prototype GeoPackage Raster format to be designed by participants. The current GeoPackage specification does not define a raster format, so this would be experimental work.
A mobile client may participate in field data collection and update activities, including feature editing, vector annotation/map markup, and map annotation with photographs. These updates should be stored in the GeoPackage, and when the client returns “home”, these updates should be synchronized via a component to be developed in the thread.
This thread investigates the ability of the cloud paradigm to provide on-demand scaling to improve the performance of OGC Web Services. Two areas are of special interest: rapid analytics, integrating Web Processing Services with WCS and WFS; and rapid data packaging, integrating the GeoPackaging service with WMS, WMTS, WFS and WCS.
Changes to the traditional service access paradigm may be necessary to best support cloud processing. For example, the WPS interface may require modification to allow the client to specify the computing resources and/or virtual machines required to run the analysis. Another approach may be to have the client specify the desired response time, and the service would decide how much processing power was required to satisfy the response time parameter.
As another example, a client may require the on-demand deployment and execution of its own analytic into a given cloud, fed with a dataset of interest. By extension, a user’s analytics could already be hosted in a cloud. In this case, the user requests to enable a processing-cloud-to-data-cloud collaboration through a WPS interface.
Originally from an email by Peter Vretanos
What does an OGC web service need to provide in its capabilities document and perhaps what additional operations OGC services need to implement so that a catalogue can harvest that information, create the associations between services and the data they offer, and make all that information transparently discoverable and usable without prior knowledge of each OGC service when requirements call for the use of more than one OGC service (i.e. WMS and WFS)?
In the example above, the ability to discover the association between a WMS layer and the underlying features (from a WFS) is important to apply the proper style to render the layer and access the feature (its vector representation) if an analysis on that data is needed . Once that association is created and is discoverable, a client can navigate around using a WMS or WMTS, find something of interest, click a DOWNLOAD button and have the data assembled and downloaded to his/her machine in a format that they like (GBT, zipped up SHAPE files, whatever) from a WFS.
This can happen automagically and transparently because a portal application can use a catalogue to find the associations between WMS layers and the WFS feature types. Once the association is found, the portal can follow the association to the WFS (for example) that offers the underlying data and then make a WFS request to get (i.e. download) the data!
This concept can be generically applied to all OGC services and offer a level of integration not currently available in OGC specifications. This work would require catalogue work – not so much changes to the API or the information model – but to define the standard association identifiers that need to exist for all this to hang together.
This work would also require changes at the service level. Among the changes required would be (a) making a serviceId element mandatory in the capabilities document so that a catalogue can unambiguously identify a specific service, (b) have rendering services implement a request (we call it GetAccessibility) that explicitly advertises which source data a WMS is using to render the layers it is offering, etc...
Right now, all this is done in monolithic systems where all the data is centrally located – a decidedly UNDISTRIBUTED and proprietary architecture. However, it does not need to be so! OGC has all the Web services required, and with a little bit of tweaking OGC can define how to loosely couple these services together to achieve the same thing the monolithic systems do but in an open, distributed and standard way.