February 08, 2008
Photogrammetry, spatial modeling, remote sensing, 3D/4D
simulation, geospatial collaboration, feature extraction, location
services, imagery analysis and exploitation; for many, it is unclear
how these disciplines and domains relate to Open Geospatial Consortium
(OGC) Web Services standards. To help illustrate how OGC standards
remove the barriers to information flow that have traditionally bound
these disciplines and domains, consider the recent strategic decisions
by Leica Geosystems Geospatial Imaging. They demonstrate how an
organization can evolve its policies and strategies based on changing
standards and the IT landscape.
OGC Sets the Standard
Globally, the OGC has over 350 member organizations, including all of
the major players in geospatial technologies, such as Leica Geosystems,
Intergraph, MapInfo , Autodesk, ESRI, Oracle and PCI Geomatics, as well
as leaders in Web services, such as Google and Microsoft. Additionally,
the OGC membership includes major system integrators such as SAIC,
Lockheed Martin, BAE, Northrop Grumman, Raytheon, SRA International,
etc., nearly every U.S. federal agency, and government and NGO agencies
from six different continents. Most of these organizations have been
working together in the OGC for over a decade. As a result of this
commitment, OGC Web Service standards, along with a few key ISO
standards, are the dominant standards used for deploying geospatially
enabled Web services.
Web services are applications running on a computer connecting to a
remote Web service via a URL. The user of the application can benefit
from the processing that the Web service provides. If the remote Web
service is meant to be "open" and available to a variety of
applications, it needs to describe its capabilities and provide a
standard way for an application or another server to communicate with
it. ISO provides a standard (ISO19119) that specifies the form of an
"XML capabilities document" that describes the capabilities of
geospatial Web services. OGC Web Services standards provide most of the
other details - common interfaces, encodings and best practices - that
enable applications and geospatial Web services to communicate and
interoperate.
Standards Provide the "Common Language"
Recently, Leica Geosystems Geospatial Imaging announced the
acquisitions of Acquis, ER Mapper and IONIC. Earlier, Leica Geosystems
acquired ERDAS. Each of these strategic acquisitions has provided the
company with new technology, but the acquisitions would have had much
less value if the technologies and products couldn't be made to work
together.
In acquiring these companies, Leica Geosystems faced the same problem
its customers face. Companies in any industry need to make technologies
and products work together when they seek to integrate information
systems from different divisions or subsidiaries, or when they purchase
new software that must be made to work with diverse systems already in
use within the company. A decade ago, such integration typically
required expensive, time-consuming software development. The interfaces
between system components often had to be created anew for each job and
maintained separately for each customer. Today, the Web - and standards
- have made this kind of work much easier.
The new paradigm is called "service oriented architecture" (SOA).
Through OGC standards, different geospatial software systems and system
components can work together over a network, usually the Internet. SOA
refers to information systems in which network resident resources
communicate and interoperate by means of agreed standards. When two
systems implement the same OGC standard, they can work together
immediately, with no integration. Legacy systems not originally
designed for SOA can, without too much effort, be provided with new
interfaces that implement the standards, so the legacy systems, too,
can provide Web services in an open environment.
Leica Geosystems' implementation of OGC standards in its various
product families enables those products to work together across its
product line. In addition, through these products, Leica Geosystems
customers can work easily in an SOA environment with other vendors'
products that implement OGC standards, and can easily publish data
sources as OGC Web services, including Oracle Spatial, ArcSDE (on
Oracle or SQL Server), PostgreSQL/PostGIS, ODBC/JDBC sources,
Shapefiles and more.
Without standardization, an enterprise's applications operate
independently, segmenting geospatial data and limiting organizations to
only authoring within a single software package. Through vendors'
implementations of OGC standards in products, organizations are
empowered to author, manage, connect and deliver geospatial information
internally and externally through a wide variety of applications.
Interoperability among diverse products provides customers with
increased value and versatility, and it provides vendors with more
strategic options.
The Future: More Policy/Technology Co-evolution
Within the OGC, the Technical Committee's Standards Working Groups are
currently working on a variety of topics important to our customers,
including, among other things, standard ways of managing geospatial
data rights, preserving geospatial data, distributing geoprocessing,
working with sensor webs, and integrating geospatial content into
Building Information Models. The OGC is playing an important role in
the international effort to build the Global Earth Observation System
of Systems (GEOSS), which will lead to advances in using the growing
streams of Earth data to address critical problems such as global
warming and natural disasters. And our collaboration with other
standards organizations is resulting in increased consistency in the
way geospatial issues are addressed across the Information and
Communications Technology (ICT) spectrum.
The OGC's past work has affected ICT stakeholders, and the OGC's
current and future work will do so, as well. The strategies and
policies of agencies, developers, integrators, wireless carriers,
insurance companies and many other kinds of organizations will evolve
in response to new standards. Leica Geosystems, particularly through
one of its recent acquisitions, IONIC, has participated in the
evolution of geospatial SOA standards in the OGC, and through this
closeness to the process was able to devise a strategy for success
Our industry continues to evolve, with every year bringing remarkable
new developments. With Google, Oracle and Microsoft all participating
in the OGC at a high level, there can be no doubt that "spatial" has
become a recognized part of the ICT foundation. "Spatial" is evolving,
and organizations that want to take advantage of this evolution will
need to evolve their strategies and policies to accommodate, or better
yet, anticipate the change. Participating in the OGC process not only
allows your organization to anticipate change, but even to become a
change agent, spatially enabling our world.
|
Your Comments Post a comment All comments provided in this section are those of the individual who has created the post. These are not the opinions of Directions Media, its editors, staff or owners unless otherwise noted. Directions Media retains the right to edit or delete any comments posted herein.
|
|
||||||
| OGC standards can in no way be considered the basis for a SOA. The most popular of these standards only supports three requests in its basic form, is this sufficient for today's complex GI applications - I fear not. The limited capability of OGC specifications and the cumbersome nature of the standards process has seen them completely superseded by KML, REST and SOAP the latter two of which are IT standards. One only has to compare the functionality and speed of a WMS "mashup" to that of a Google Maps or Virtual Earth equivalent to prove my point. What the OGC standards have accomplished is to persuade GI producers into sharing content and GI vendors into making this possible. Now that the community has seen the potential, the IT standards that can do this stuff so much better will dominate. I would fear for any organization that bases its product integration strategy on OGC standards. |
||||||
|
||||||
| Wow, I agree in most parts and at the same time, I'm surprised to see an answer so "IT-friendly" coming from ESRI ... Ireland. I see some standards like "Morse code", universal yes but not always fast and not always necessary if the majors elements of a solutions speaks, lets say, French! |
||||||
|
||||||
| I have to disagree with Eamonn Doyle's response. OGC standards do provide a basis for a geospatially-enabled SOA. Major integrators including SRA have implemented SOAs with OGC web services at the core. The services provide a discoverable interface to data or processing capabilities without a priori knowledge of these providers. I would agree that a "WMS" mashup is a very basic implementation using OGC services and in no way a SOA. However, WMS is the most basic of services and, in reality, only provides a picture. There are implementations from a number of GI vendors that match the speed of GoogleMaps and VirtualEarth while exceeding their limited functionality. This is all done using an AJAX ("Web 2.0") web-based client which becomes very appealing to some customers. Customers are starting to see the power of building OGC web services rather than large, monolithic development efforts that use custom or proprietary interfaces. We should strive to find the right tool (or architecture) for the job. There are cases where OGC web services aren't appropriate and maybe a SOAP/WSDL approach or a pure KML approach is better suited. Having said all this, it is a side issue to the point Mr. Tucker is making in the article. Eamonn Doyle makes the point, maybe unknowingly: GI producers and GI vendors ARE sharing content and capabilities. That is the power of OGC standards - sharing of data, processing and resources through well-defined, discoverable interfaces. System integrators have been and are constructing complex, easily-extensible SOA-based systems that integrate this content and geoprocessing capabilities to deliver increasing capabilities to customers. One only has to look at the USGIF/NGA GEOINT Conference's Interoperability Demo each year to catch a glimmer of this potential built on a shoestring. ESRI, Google, and Microsoft are all participating members of OGC and with their continued participation along with the other members OGC standards and services will continue to improve and evolve to meet customer needs. |
||||||
|
||||||
| Eamonn - I believe that there is a misunderstanding on Eamonn's part. My post is also a follow-on to Joe's excellent posting. I do not think Chris is implying that OGC standards are the basis for implementing a SOA. I do believe that OGC standards can and have been effectively implemented and used in an SOA environment. SOA is a process engineering and architecture design pattern. Implementing SOA is not about standards but about defining business processes and then implementing the services and service interfaces required. At the point of defining the application infrastructure and related service interfaces, there is the requirement to determine what standards MUST be used to insure interoperability of service components and content. In such an environment, an OGC standard MUST work in concert with other IT standards, such as XACML, XML, BPEL, HTTP, or WS-Security. Please remember that all of these IT standards are developed by standards organizations whose processes are not much different from those of the OGC. There are numerous operational applications of the use of OGC standards in enterprise environments that are using the SOA design approach - including many in Europe. In regard to KML, REST, and SOAP, well to begin with REST is not a standard but a design pattern and OGC WS standards can be implemented as a component of a SOAP payload. FYI, SOAP is designed as a peer to peer protocol. From the SOAP Recommendation: SOAP Version 1.2 provides the definition of the XML-based information which can be used for exchanging structured and typed information between peers in a decentralized, distributed environment. If one uses HTTP POST (as defined in the various OGC W*S standards), then a OGC W*S request can be embedded in a SOAP package. Last year, Google along with other OGC members submitted version KML 2.2 into the OGC standards process. The adoption vote for KML 2.2 will begin today or tomorrow. I would suggest you read the preamble to the OGC KML 2.2 Best Practices document. Google submitted KML to the Open Geospatial Consortium (OGC) to be evolved within the OGC consensus process with the following goal: KML Version 3.0 will be an adopted OpenGIS implementation specification that will have been harmonized with relevant OpenGIS standards that comprise the OGC standards baseline. Also, be very clear that KML is a visualization language for earth browser applications and not a geographic content modeling language such as GML. Now, comparing the speed of a WMS mashup with the response times one sees in VE or GE is truly mixing apples and oranges. I would encourage Eamonn to look at the excellent research and implementation work done in the open source community, by JPL, the OGC as well as by others on highly performant WMS tile caching approaches. Finally, I would suggest that Eamonn should have more carefully considered other OGC data access standards. WMS is more of a presentation interface standard compared to real data access services like WPS, WFS, WCS and SOS. These standards are where the SOA action is in OGC. |
||||||
|
||||||
| Folks, this discussion is about the strategic power of OGC standards. Can users do what they need to do with OGC standards? Yes Are OGC standards perfect? No Are enterprises adopting OGC? Yes Does ESRI need to fear OGC standards? No, ESRI servers support OGC standards very well, and you can use the entire OGC SDI baseline on ArcGIS with the CarbonArc PRO extension. |
||||||
