The OGC explained... some common questions are answered
Posted by GeoCommunity, contribution by Carl Reed (Dec. 17, 2002)
A recent discussion thread on the popular GISList concerning the Open GIS Consortium (OGC)
resulted in some interesting discussion and feedback concerning the efforts and mandate of the OGC.
Spawned by a lenghty question posed to the list, proponents of the OGC
used the opportunity to explain and clarify to the layperson just exactly what the OGC is about.
Some issues & questions raised in the original post:
- There are only a handful of major
players, and there's no mystery as to who they are. So, by default, it
is yet another expensive vehicle for the major vendors to leverage their
products and solidify their strangle hold on the market, only with an
added endorsement by OGC.
- The OGC specifications leave the market just like all those ISO
standards have, numbed, disenfranchised and leery of marketing claims.
- There is every bit as much politicking going on at OGC and major member organizations as
there is at the UN these days. The diplomacy is first rate, the
bureaucracy is considerable and the interests of the average GIS
consumer is lost somewhere along the way.
- Given the implicit value and importance that this industry brings to the
world (yes, that value is enormously understated), I think OGC and
others can and should do a much better job at moving things along,
thinking a bit more out of the box, or even just throw the box out and
start with a blank page, however unpopular that may be
As you can image, the message generated a fair amount of discussion, both pro and con.
One person who graciously took a great deal of time to respond was
Carl Reed (PhD), Executive Director, Specification Program
Open GIS Consortium, Inc. I found Carl's response to be well thought out and
particularly useful as an effort to describe the OGC to the Community at large. Carl
has generously agreed to allow The GeoCommunity to pass along his summary.
First off, let's discuss our membership
You are quite correct that some of
our members are the traditional GIS vendors. However, probably 80% are not!
The really good news is that more and more new members are coming from other
communities of use - location-based services, telecommunications, and local
government. Universities have become more and more active. At our last
demonstration, highlighting interfaces developed in OGC Web Services
Initiative, Phase 1.2, both George Mason University and the University of
Alabama Huntsville participated. Among the GIS vendors, after the "household
names" of GIS (Intergraph, ESRI, MapInfo, and Autodesk) there are dozens of
what I might call non-traditional suppliers of geospatial technology, sleek
players (including Galdos, IONIC, Cadcorp, Polexis, Social Change Online, Dawn
Corp, CubeWerx, and Compusult) that see OpenGIS specifications as a key part
of their business process and software development plans. Other members
include key geospatial stakeholders, such as: FGDC, US Census, US EPA, UK
Ordnance Survey, US DOT, US FEMA, ERDC (Corp of Engineers), City of San
Francisco, Natural Resources Canada, GeoSciences Australia, and Northrhine
Westfalia (Germany). Please let me know of any other players whom you think
should have a role in the OGC process.
Why do these members join and spend valuable time working in our process?
They achieve significant benefit in terms of their growth in the market place,
networking with other OGC members, return on investment, and/or achievement of
business objectives. To put it bluntly, open specifications make their jobs
easier and increase return on investment. While OGC began with an ideological
vision, it's tied into a business model for members and the organization.
More importantly, this process results in a diversity of plug and play
technology offerings in the marketplace - take minute to review the
Implementing Products listing on the www.opengis.org website.
One aspect that our members find particularly valuable: our commitment to
protecting both their corporate Intellectual Property Rights and the
specifications developed by the membership. We never ask members to include
their proprietary technology in specifications. And, we are the defenders of
the OGC's Intellectual Property. Among other things, we police all claims of
conformance that are brought to our attention.
As the number of the products that implement OpenGIS specifications grows,
more and more procurements are requiring adherence to standards and
specifications that support and promote interoperability of geospatial data,
services, and applications. That, our members will tell you, increases the
number and value of prospects for new business opportunity and revenue
generation. . There is another set of relationships that both validates and
increases the value of our work. The OGC has bilateral agreements with other
standards and specification organizations, such as ISO (the International
Standards Organization). The upshot: the content of various OGC specifications
are becoming either international standards or are included as part of other
specifications, such as the Mobile Location Platform API.
Second, let's have a look at those "hefty fees for the 'privilege' to
participate in an 'Open' GIS Consortium." Perhaps it's news to you, but there
are many other standards and specifications organizations (including the W3C
that sets standards for the Web) that charge membership fees. Have you looked
into their fees? OMA, OMG, OASIS, W3C and many others charge higher membership
fees. Running a standards organization does not come cheap, but the returns
can be considerable - look at the Web as an example!
While members do have certain privileges that non-members do not, OGC makes a
great deal of its ongoing specification work available to the public for
comment very early in our process. Moreover, all approved OGC specifications
are freely available to ALL developers of GIS and other software, worldwide.
That means that even if a software development firm never pays a cent to OGC,
it can implement any OGC specification. There are no associated royalty fees.
This free and open, unrestricted access to OGC specifications is especially
valuable to both commercial software providers as well open source software
providers, several of whom have implemented OpenGIS Specifications in their
offerings.
Is yet another expensive vehicle for the major
vendors to leverage their products?
Carl's address to what he considered a misleading statement made in the original message:
..."So, by default, it is yet another expensive vehicle for the major
vendors to leverage their products and solidify their strangle hold on the
market, only with an added endorsement by OGC."
While some of the major players in the industry have worked very hard on many
of the specifications already available and in progress, there is no way that
this work "solidifies .a strangle hold on the market." Open specifications are
just that "open." That means that any software that implements an interface
specification can "carry on a conversation" with any other software that
implements the same interface. The opportunity to have software packages speak
to one another does not lock shut the marketplace. On the contrary, it opens
and extends the market to more players - both technology providers as well as
technology consumers. As a matter of fact, the larger GIS players are to be
commended for their willingness and commitment to open their systems by
implementing OpenGIS specifications. However, many of the current approved
OpenGIS specifications have been driven to completion by both user
organizations as well as the non-traditional geospatial vendors.
Just to elaborate, OGC currently has 11 adopted specifications and many, many
more in the pipeline. Primary sponsors for various specifications include Web
Map Server (NASA), Geography Markup Language (Galdos), Web Feature Service
(Cubewerx), Style Layer Descriptor (Cubewerx), Catalog (USGS/NIMA), Coordinate
Transformation (Cadcorp), and Web Coverage Server (NASA). Each OGC
specification has a primary submitter/editor as well as many co-submitters.
Every submitted draft specification goes through a formal approval process by
the OGC Technical Committee. Any OGC member can comment, edit, submit change
proposals, and so on. That process prevents any player from "solidifying [its]
strangle hold on the market."
Fourth, regarding the comment "software that conforms to OpenGIS specification
being slow" is out of place. OGC aims to make software work together,
its speed, as always, is in the hands of the developer. As an example, one of
our members, IONIC Software, has implemented an OGC based framework that is
the engine for the Hutchison3g Location Services Platform. This implementation
has been commercially deployed and stress tested to 300,000 hits per hour and
was found to perform and scale very well. So obviously, performance is not an
issue in terms of the actual interface specification. I should add that this
implementation involves geocoding, routing, and directory services
applications - not just a simple Web mapping application.
As for conformance, there is a big difference between implementing products
and conforming products. There are hundreds of implementations of OpenGIS
specifications in the market place - these are products whose developers have
included one or more interfaces in the product. A number of these are
conformant, that is, have passed rigorous tests illustrating that the
interfaces behave as indicated in the specification. A new Web services
conformance testing framework will make conformance testing even easier in the
future.
Fifth, you suggest that the management by committee process that OGC uses
yields slow results. That's off the mark. Over the years, the OGC process has
been significantly streamlined. How fast a specification moves through the
process is dependent on many factors, such as member perception of market
uptake (read, revenue potential). Typically, 12 to 18 months is the elapsed
time from definition of a new specification in an interoperability initiative
to formal adoption as an OGC specification. Maybe this seems slow to you, but
to define, build, and test (yes, test) these interfaces take time. None of our
members want the OGC to publish useless specifications! Further, as noted
above, we often release draft specifications as public Discussion Papers,
often within months of their conception. These drafts are mature enough to
actually write implementations against, should a vendor choose to do so (and
many do). For comparison, our life cycle time is very similar to the World
Wide Web Consortium (W3C) and the Internet Engineering Task Force (IETF).
Finally, regarding the suggestion that "OGC and others can and should do a much better
job at moving things along, thinking a bit more out of the box, or even just
throw the box out and start with a blank page, however unpopular that may be".
Bringing together the highly creative players and the
collaborative engineering process that are the basis of OGC has taken many
years. Putting technical engineers - not managers and "politicians" - together
to tease out new specifications insures our specifications are open and
workable. If you'd like to make suggestions as to other ways to advance the
development and use of specifications, I invite you to share your ideas with
us.
Who can submit feedback regarding the OGC Specifications?
Now in terms of your particular issue, anyone who has an issue with an OGC
specification can write a formal change request and submit it to the OGC. You
do not need to be a member to do this. We gladly accept all input from those
working to implement our specifications.
Carl Reed, PhD
Executive Director, Specification Program
Open GIS Consortium, Inc.
The Geocommunity would like to thanks all those who participated in this discussion
for their efforts. Discussion like this is what the GISList was meant for and
confirms to all of us just how valuable sharing our experiences can be. To register as
a member of the email-based GISLIst discussion group, simply send a blank email to
gislist-subscribe@lists.geocomm.com
To follow the entire discussion, please see the GISList archives
|
