Cross-Border mashup merges Google Maps, OGC Web Services

At 5,500 miles, the US and Canada share the world's longest common border and identifying critical infrastructures is a vital function for organizations in the cross-border region. With this requirement in mind, a collaborative project has developed, deployed and demonstrated the foundations of an online network to help identify critical infrastructure during emergencies and everyday operations.

The network is based on OGC Web Feature Service (WFS), Web Map Service (WMS) and GML standards, data from Montana and Natural Resources Canada. The WFS are located in Montana and Quebec. Cross-border users are able to access the two secure data services across the US-Canada border, navigate through their content, and access critical infrastructure data using free geospatial viewers such as Gaia, CarbonArc PRO extensions for ArcGIS - and Web 2.0 mashups like the one above.

This Cross-Border mashup merges Google Maps, OGC WMS and WFS, Secure SDI and FGDC Emergency Mapping Symbology - and provides an easy way to make sure critical geospatial information goes to the people who are supposed to have it.

The Cross-Border SDI Project is part of the 2008 National Spatial Data Infrastructure (NSDI) Cooperative Agreement Program (CAP) - and brings together a collaborative group committed to joint US-Canadian Spatial Data Infrastructure including: the Montana Department of Administration; the Centre for Topographic Information, Natural Resources Canada; Canada's Department of National Defense; United States Federal Government partners, and industry partners L-3 Communications GS&ES, GCS Research of Missoula, Montana, CubeWerx and The Carbon Project.

To learn how to participate, please contact info@TheCarbonProject.com. Recent Cross-Border SDI demos are also available online.

- Jeff

OGC Web Services Common and Community GeoWeb Platforms

In another move to democratize web-based services, a revision to the OGC Web Services (OWS) Common Standard is now available. The document seeks to standardize common aspects of OGC SDI - like bounding boxes, exceptions, URL requests, key value encodings, etc. - so any application, anywhere can access it. In its simplest form you can think of OWS Common as providing a consistent window over any part of the Earth into which many servers can stream maps, features, and imagery.

But why bother? Can't we just declare all base maps are provided by Google and Microsoft and that non-technical people organize their data on top using one or two GeoWeb "platforms" that let you upload information and layer it on Google or Microsoft? Sounds easy - turn all my satellite and road data over to the big vendor, check. Then turn my value-added data over to a GeoWeb platform vendor with his proprietary service interface, check.

Oops, gotcha - maybe it's not such a good idea to give all your data over to that proprietary GeoWeb platform? How can you ensure people will be able to access it fairly?

Maybe what we should be thinking about is how to advance GeoWeb platforms NOT as proprietary implementations using an alchemy of REST, JSON, RSS, KML - but as Community GeoWeb Platforms that combine international standard geospatial web services with Web 2.0 technologies.

But you say, "We don't have enough standards!" and "OGC is too complicated!" - Not true. Key SDI 2.0 access, processing, analysis and collaboration services standards for building Community GeoWeb Platforms on an Internet cloud are ready now - WMTS, WMS, WFS, WFS-T - and all these can be "mashed up" with Google and Microsoft using guidelines like OGC Web Services Common.

Democratic access indeed.

- Jeff

Preserve Green Infrastructure while renewing Grey Infrastructure

The announcement this week on high-speed rail shows infrastructure projects are picking up steam - and are an enor­mous undertaking. Coordinating thousands of projects and protecting our environment at the same time will be challenging, requiring online access to information and services in both the private sector and government. Given these challenges now is the time for our country to build a new information network that combines the best of the past with the best of the future.

This network should combine online mapping with vital environmental data, providing public access using modern information sharing technology, and speeding economic recovery by produc­ing jobs in a competitive and productive environment. Recent and ongoing projects sponsored by agencies such as the USGS and EPA successfully produced open and interoperable technologies and procedures. Based on the work started under these efforts, a National Spatial Data Infrastructure (NSDI) "2.0" can be built quickly, creating a competitive environment for small high-tech businesses and spurring innovation.

With NSDI 2.0 the government and private sector can move beyond on-premise computing and file transfers to geospatial/environmental access, processing, analysis and collaboration services on an Internet cloud - providing a resource to help preserve our Green Infrastructure while renewing our Grey Infrastructure.

- Jeff

The Carbon Project Awarded GSA Schedule 70 Contract

The Carbon Project is pleased to announce it was awarded an Information Technology Schedule 70 contract by the U.S. General Services Administration (GSA), the procurement arm of the federal government. The five-year contract enables The Carbon Project to provide IT services and software directly to government agencies, and continues the company's expansion into the federal marketplace.

The contract provides a streamlined vehicle for federal agencies to acquire The Carbon Project's professional services and software including CarbonTools, CarbonArc, Echo myPlace, Gaia Extenders for ArcGIS Server and Aeronautical Information Management, and CubeWerx USA's WMS, WFS, WCS, CS-W, WMTS, and Secure SDI software. To obtain the award, The Carbon Project had to satisfy the criteria set forth by GSA, demonstrating both superior quality and competitive pricing.

The Carbon Project is proud to make the finest software and professional services available through GSA. The GSA Schedule 70 contract will help Federal customers easily acquire high-quality solutions to their most critical IT problems.

Federal, State and local agencies can obtain information about The Carbon Project's GSA Schedule 70 contract services under Contract Number GS-35F-0340V, or by contacting info@thecarbonproject.com.

Gaia featured in IBM's WFS dashup

Sorry it's taken me so long to get this out - should have posted it months ago. Anyway, late last year IBM published an extensive paper on implementing OGC WFS with Informix - and Gaia 3 was the featured desktop-mashup (dashup) tool.

They discuss how mash-ups and Web services development have made advanced capabilities easy to access and integrate, raising expectations that users can apply them to all their business processes and data - and how IBM Informix can be used to mashup Google, Yahoo and Microsoft with an OGC Web Feature Service (WFS) that customers can use as an interface for accessing and creating geographic data via Web services.

- Jeff

Windows 7 fish, Geodata.gov and GeoRSS

Example of the prototype GeoRSS Dashboard for Geodata.gov in Windows 7.

The Carbon Project was selected by the 2009 National Spatial Data Infrastructure (NSDI) Cooperative Agreement Program (CAP) to develop this open source desktop dashboard for Geodata.gov, the federal government service for maps and data.

- Jeff

Silverlight hot, Java not?

Silverlight is used to take .NET applications to the Web, like the Echo myPlace prototype

GCN reports, "Java's presence on the desktop seems to be fading while a new contender, Microsoft's Silverlight, is on the rise, at least according to the results of an informal, ongoing survey taken by DreamingWell, called Rich Internet Applications Statistics."

- Jeff

Gaia supports electric grid visualization

In the example above, Florida State Electric Power and Natural Gas Components in GML are overlays in Gaia/CarbonTools. Electric power components are connected with green, natural gas components are connected with red lines (photo courtesy Galip Aydin).

NISAC is National Infrastructure Simulation and Analysis Center (NISAC) - a Congressionally-mandated source of expertise on critical infrastructure interdependencies and the consequences of disruption.

NISAC and other organizations have been testing Services Oriented Architectures (SOA) based on OGC SDI - and a few SDIs for critical infrastrucuture protection are coming online.

- Jeff

Secure SDI - a client perspective

Gaia accessing secure WFS from CubeWerx

Over the last few months we've been demonstrating Secure SDI a lot. What's Secure SDI? It's role-based access control and feature-level security for OGC SDI. Secure SDI answers one of the primary challenges in deploying real-world systems based on OGC standards - making sure critical geospatial information goes to the people who are supposed to have it. But folks have asked - how does this work on the client side?

From the client perspective there are two key functionalities - First, logging into an authentication service (like the one above from CubeWerx) to get the credentials needed, and second an OGC service like WFS using the relevant credentials to respond to queries with information according to the user rights and access rules.

To support Secure SDI The Carbon Project uses CarbonTools PRO to alter the HTTP request at the communications layer, and add new functionality to Gaia (through an Extender plug-in) CarbonArc PRO products. For example, to get user credentials Gaia needs to log-in to a Secure SDI Authentication service. To achieve that functionality we added a tool in the form of a dialog box that allows people to type in a username and password. Users can also set the authentication service URL and add an optional jurisdiction parameter. Once the information is set, clicking on a ‘Get User Credentials’ button will fetch the list of credentials from the authentication service. This process is done through GET type HTTPS request (all communication between client and server is SSL encrypted).

CarbonTools PRO provides the distinct ability to control the HTTPS requests sent to OGC Web Services. This level of control over the communication layer is crucial for Secure SDI. Since credentials are applied at the communication layer all queries are affected - getting capabilities, features or even performing transactions on a WFS-T.

The Secure SDI capability answers one of the primary challenges in deploying real-world systems based on OGC standards - making sure critical geospatial information goes to the people who are supposed to have it.

- Jeff

REST-testing OGC WMTS

REST is an architectural style for building services - based on the architecture of the Web. In RESTful services the primary consideration is which resources are exposed - with a resource being information you want to make available to others. In RESTful services resources are identified by a URI - and the URIs are designed in a way that makes sense based on the type of resource. (Adapted from Flanders, 2008)

For reference, a Uniform Resource Identifier (URI) consists of a string of characters used to identify or name a resource on the Internet - and the Web comes with a standard communication protocol – HTTP – for interacting with these resources and their representations.

So let's put REST to the TEST in the context of the OGC REST WMTS draft spec - not with concepts but with a real service, like this REST WMTS -

Here (click or load this link into your browser)

Here's the full link -

http://cubewerx.com/demo/cubeserv/cubeserv.cgi/tile/wmts/1.0.0/ORTHOIMAGES:CANIMAGE/RGB/ORTHOIMAGES:CANIMAGE$EPSG:4326/13.2523203325326e6/3/3.png


REST states that to retrieve this tile, the client should send an HTTP GET request to the URI above. Unlike with the traditional OGC WMS KVP or XML/SOAP operation encodings, where the URL+body represents an Operation, the RESTful encoding of a WMTS tile request is really the address of the tile resource, with the operation (GET) being specified at the HTTP level. The RESTful encoding of a tile request consists of all nouns, and the HTTP operation indicates what operation is being performed on the addressed resource according to the following syntax -

{WMTSBaseURL}/{layer}/{style}/{firstDimension}/{...}/{lastDimension}/{TileMatrixSet}/{TileMatrix}/{TileRow}/{TileCol}.{format_extension}

So...REST defines an architectural style based on a set of constraints for building things the “Web” way and is simply a way to design things to work like the Web - and I'd say OGC WMTS passes the REST TEST.

Of course, there will also be there will also be information exchange, services and collaboration requirements that can be supported better by SOA standards like OGC Web Services - but REST WMTS could be an important step forward for interoperability.

- Jeff