Getting Started with OGC Standards for Geospatial Data Sharing
As a developer you may be looking for tools and standards that make location information integrate more seamlessly with your application or solution. The OGC’s international consensus standards process is designed to define, document, and maintain standards that enable integration of location content into any application, service, or software tool. Providing such seamless integration may seem straightforward. Lat/lon coordinates – simple, right? Sure, but what if you need to work with polygons and lines? If you’re building a service, does your client expect floats or ints? What about metadata, measures of uncertainty or units of measurement? Can it handle elevation or altitude? What about all those different Earth coordinate reference systems (aka projections)?
OGC working groups consist of very technically qualified professionals who have delivered everything from satellite-borne Earth imaging system control interface standards to service interface standards for layering and presenting GIS raster and vector data layers. Some of the 25+ OGC working groups focus on problems like data quality, indoor/outdoor location convergence, and sensor fusion. The problems are difficult, but everyone participating in the OGC hears again and again about the importance of simplicity when the goal is interoperability.
Lack of interoperability when using location content reduces customer choice, reduces options for developers, reduces available ad markets, reduces opportunities for technology convergence and generally retards market growth. Noninteroperability makes the price of products and services too great for too many, and thus the market demands interoperability. At the same time, developers need to provide apps that run on resource-constrained mobile devices, and they need standards that help them accelerate – not slow down – development schedules. Standards documents, especially when accompanied by open source reference implementations, can be seen as free intellectual property that saves weeks of development time as well as downstream "remorse of non-interoperability."
This article is the first in a series that will show developers how they can maximize their market and business opportunities and reduce development times and maintenance costs by implementing simple interface and encoding standards that have been developed by the OGC.
WMS: the granddaddy of web mapping standards
The Web Mapping Service (WMS) was OGC’s first Web Services API, and back in 1999 represented a prescient commitment to building a spatial data sharing architecture on the same architecture as the Web. We continue to foster and strengthen that commitment to this day as the Web turns 25 this year, and both OGC and the World Wide Web Consortium turn 20.
Like most OGC services, WMS has an HTTP GET KVP interface and a HTTP POST/SOAP interface. In this article we’ll only cover the KVP, or key-value-pair, interfaces. Another commonality across most OGC services is that there are three primary operations to the API. One is called “GetCapabilities”, and that one gives you access to a lot of metadata about the service including what data it holds and what the URLs are to access the other operations. Another operation lets you look up all the information for a particular feature (the geospatial equivalent of a database record). For WMS this operation is called “GetFeatureInfo”. We won’t cover that in this article, so get the details on that one in the standard available at http://www.opengeospatial.org/standards/wms.
Figure 1: A client that implements the OGC WMS Interface Standard can get "map images" (in formats such as PNG and JPEG) from diverse types of servers (such as GIS, Earth imaging systems, and some spatial database systems) that are able to produce such images and serve them via interfaces that implement the WMS standard. A WMS implementation does not return the actual data, but only a raster map image created from the data.
For the purposes of this article, we’ll go straight into the main operation of the WMS service, which is “GetMap”. What you basically want to do with a WMS (the SERVICE key) is tell it to give you a map (the REQUEST key) of a certain geographic area (the BBOX key), a certain pixel size on the screen (the HEIGHT and WIDTH keys), having certain data layers (the LAYERS key), with those layers styled in certain ways (the STYLE key but the value for this key can be blank to accept the defaults), in a certain spatial reference system (the SRS key) and finally return the image in a specified image format like PNG (the FORMAT key).
Here’s a sample request that gets you an area similar to the image in Figure 2 (but the image won’t look the same because this is live Radar data and the weather will be different than on the afternoon of March 12, 2014):
http://gis.srh.noaa.gov/arcgis/services/RIDGERadar/MapServer/WMSServer?
request=GetMap&service=WMS&version=1.1.0
&BBOX=-73.929,41.758,-71.747,43.3
&HEIGHT=500&WIDTH=600
&LAYERS=0&STYLES=
&SRS=4326&FORMAT=image/png
All WMS services work in this same way. Make a GetCapabilities request such as:
And in the XML response find the layers and styles you want to use (HINT: most WMSes don’t publish styles so you can usually ignore this key) and then just map like crazy!
Figure 2: US National Weather Service Radar over the Northeast US on March 12, 2014 (WMS service accessed in uDig).
WFS: getting the raw geographic data
Often you need more than a pre-composed graphic of a map in your application. You may want to draw the points, lines and polygons with your own code so that you control the cartographic aspects of map design.
Or you may need the raw data to compute distances or areas or other more advanced spatial analyses. Basically, for the same reasons you often need to build database queries into an application, you need geospatial data queries. And OGC has an interface for that – Web Feature Service (WFS). I’ve written a short tutorial on how to quickly get acclimated to WFS at http://www.ogcnetwork.net/wfstutorial. And once you get your feet wet and need more advance information, you can refer to the full WFS version 2.0 standard at http://www.opengeospatial.org/standards/wfs.
Figure 3: Servers that implement the OGC Web Feature Service (WFS) Interface Standard return vector source data (points, lines, and polygons) encoded in the widely used OGC Geography Markup Language (GML) format. The entire GML specification is comprehensive and "fat," but most applications use GML profiles, which can be application-specific and very "thin" in terms of storage and bandwidth requirements.
One interesting WFS to play around with as you learn the interface is the geographic names service from the US Geologic Survey (USGS). Once you follow the tutorial, you’ll learn that the service’s capabilities document has all the information required to use it. For this service, you’ll find that here:
A quick way to see the data available is request everything, but limit the records returned to five, like so:
Looking at that response, you can get a flavor for what the data looks like. It’s in a standard flavor of XML defined by OGC called GML. The details of GML make up a topic for another article, but suffice it to say that the GML for every data set may be different, but once you look at a few records, its pretty easy to build an application that processes that XML.
To construct advanced queries, WFS uses a language called Filter, which is the geospatial equivalent of SQL, but many developers never even need to use Filter. What people usually want to do is search within a particular area. In fact, this may be the only request you use on a regular basis once you’re familiar with the service. Once again, using that USGS geographic names service, this query gives you places in the Monterrey, California area:
Instead of using the "maxfeatures" key, we use a "bbox", and specify
the lower left and upper right coordinates of a bounding box to
search. And here is a truncated listing of the query response. The
main sections of the XML are the root element,
<wfs:FeatureCollection>, which contains a <gml:boundedBy> that defines the geographic extent of all the data in the response and a series of <gml:featureMember> elements, each of which is a “record” in the geographic database:
<wfs:FeatureCollection>
<gml:boundedBy>
<gml:Envelope srsName="EPSG:4326">
<gml:lowerCorner>-14.545293023256136
-179.11623072720781</gml:lowerCorner>
<gml:upperCorner>71.330629333030572
179.74942126888595</gml:upperCorner>
</gml:Envelope>
</gml:boundedBy>
<gml:featureMember>
<WFS_geonames:Administrative gml:id="F59__3098">
<WFS_geonames:OBJECTID>3098</WFS_geonames:OBJECTID>
<WFS_geonames:Shape>
<gml:MultiPoint>
<gml:pointMember>
<gml:Point>
<gml:pos>36.593571199449457
-121.83689600049178</gml:pos>
</gml:Point>
</gml:pointMember>
</gml:MultiPoint>
</WFS_geonames:Shape>
<WFS_geonames:feature_id>222239</WFS_geonames:feature_id>
<WFS_geonames:gaz_name>Del Rey Park</WFS_geonames:gaz_name>
<WFS_geonames:gaz_featureclass>Park
</WFS_geonames:gaz_featureclass>
<WFS_geonames:state_alpha>CA</WFS_geonames:state_alpha>
<WFS_geonames:county_name>MONTEREY</WFS_geonames:county_name>
</WFS_geonames:Administrative>
</gml:featureMember>
<gml:featureMember>
<WFS_geonames:Administrative gml:id="F59__3376">
<WFS_geonames:OBJECTID>3376</WFS_geonames:OBJECTID>
<WFS_geonames:Shape>
<gml:MultiPoint>
<gml:pointMember>
<gml:Point>
<gml:pos>36.596071099445567
-121.84356300048142</gml:pos>
</gml:Point>
</gml:pointMember>
</gml:MultiPoint>
</WFS_geonames:Shape>
<WFS_geonames:feature_id>234363</WFS_geonames:feature_id>
<WFS_geonames:gaz_name>Noche Buena</WFS_geonames:gaz_name>
<WFS_geonames:gaz_featureclass>Civil
</WFS_geonames:gaz_featureclass>
<WFS_geonames:state_alpha>CA</WFS_geonames:state_alpha>
<WFS_geonames:county_name>MONTEREY</WFS_geonames:county_name>
</WFS_geonames:Administrative>
</gml:featureMember>
</wfs:FeatureCollection>
Now that you’ve played around with the WFS interface a bit, it should be fun to use. There are many WFS servers around the world, especially with environmental data. So take advantage of all that open geodata around the web.
GeoSMS, ready for blast-off...
The OGC Open GeoSMS Standard allows applications to location-enable Short Message Service (SMS) messages. SMS, of course, is the text communication service component of phone, web and mobile communication systems. SMS uses standardized communications protocols that allow the exchange of short text messages between fixed line or mobile phone devices.
Figure 4: In Chinese Taipei, where earthquakes and heavy rains combine to cause disastrous mudslides and debris flows, Open GeoSMS is used both to get data from sensors and to send alerts to citizens via their phones.
The Open GeoSMS expression uses the following structure:
HTTP/HTTPS URI
Payload (Optional, freestyle text.)
The rules are simple but explicit. In the HTTP/HTTPS URI that provides location, for example, "The value of the latitude and longitude are described using the Decimal Degree format based on WGS84 without the symbol of “°”. The values of latitude and longitude are bounded by ±90° and ±180° respectively. Positive latitudes are north of the equator, negative latitudes are south of the equator."
The first line of an Open GeoSMS message is an HTTP/HTTPS URI. Following lines can contain an optional human-readable message. Here’s an example:
http://maps.geosms.cc/showmap?geo=23.9572,120.6860&GeoSMS
I NEED TOWING SERVICE NOW
This simple SMS extension enables developers to facilitate communication of location content between different LBS devices or applications. The encoding is extremely lightweight and the standards document is a quick read.
The OGC Open GeoSMS Standard can be found at: http://www.opengeospatial.org/standards/opengeosms.
Why is Open GeoSMS important? Consider two facts from mobi-thinking’s February 2013 “The essential compendium of need-to-know statistics” http://mobithinking.com/mobile-marketing-tools/latest-mobile-stats#mobile-use:
- SMS is king of mobile messaging with more than 7.8 trillion SMS trillion messages sent in 2011.
- The most effective form of ads was opt-in SMS in many countries.
Open GeoSMS not only provides a practical, streamlined way to add location to SMS, it provides it in an open standards-based manner, which means that anyone and everyone can freely use the same approach. Open GeoSMS coordinates are GML-compatible, so they will work with emergency services, e-transportation systems, World Meteorological Organization weather data, DigSafe systems, and enterprise systems that use any of the major database software products for interoperable location applications.
Bottom line: widespread implementation of Open GeoSMS will mean fewer stovepipes and bigger available markets for app developers and advertisers. It may provide new ways of communicating via SMS that are unforeseen.
Useful OGC services
Now that you know a bit about coding to OGC standard interfaces, having a list of reliable services from which to get data is nice to have on hand. You’ll find that many government agencies around the world provide access to their holdings via OGC interfaces. Here are a handful that you can try.
- Atlas of the Cryosphere
- EU INSPIRE Geoportal
- Global Earth Observation System of Systems (GEOSS)
- US Fish & Wildlife Service National Wetlands Inventory
- US National Weather Service
- US National Atlas
More to come
OGC is always looking for input from developers if you have any feedback for us. Please visit the OGC website at http://www.opengeospatial.org/contact and find more developer resources at http://www.ogcnetwork.net/tutorials.
About the Authors
