CIESIN WMS - putting people first

GPW WMS in Gaia

I've spent so much time looking at data from Google and Microsoft I'm starting to think the World consists only of road maps and satellite images - but something always brings me back to what's most important. The CIESIN “Gridded Population of the World” Web Map Service (WMS) is such a resource.

This dataset was originally is based on a unique idea to develop a new view of the distribution of population around the globe—a view not limited by national-level boundaries and data. To implement this idea, GPW developers gathered population and spatial data from sources all over the world. The result was the “Gridded Population of the World” (GPW) data set, a resource that has helped transform perceptions and understanding of human settlement on our planet.

- Jeff

Gaia SDI Support Package in MGT

Image Copyright & Courtesy Military Geospatial Technology (MGT)

Rock scientists reach WMS network milestone

Earth and computer scientists are working together on a global project called OneGeology to produce the first digital geological map of the world. This project is doing the same for the rocks beneath our feet that Google does for maps of the Earth’s surface - and with over 100 nations now participating OneGeology has reached an important milestone.

The goal of OneGeology is to make geological map data around the World web accessible. Contributing to the OneGeology infrastructure involves offering to serve geologic data by Open Geospatial Consortium (OGC) standards-based Web Map Services (WMS). The WMS allows geologic maps to be accessed by anyone according to an international standard and overlayed on other maps using Google Earth, Gaia and other applications.

So if you've ever wondered what Mother Earth would look like stripped bare of all plants, soils, water and structures? Wonder no longer - images of the Earth as never seen before are coming online in the world’s biggest geologic mapping project ever.

- Jeff

GeoRSS-powered “Dashboard” for Geodata.gov

The Carbon Project is pleased to announce it has been selected by the 2009 National Spatial Data Infrastructure (NSDI) Cooperative Agreement Program (CAP) to develop an open source desktop dashboard for Geodata.gov, the federal government service for maps and data. The project will develop a free application to enable “at-a-glance” visualization of geospatial assets and monitoring of Geospatial One-Stop (GOS) Portal search functions.

A video preview of the “GOS Dashboard” is available here.

This effort is important because the GOS Portal has matured to a point where broad uptake is now dependent on the capacity to make data and services easy for people to discover, access and use. Currently, the NSDI community doesn’t have an easy way to integrate GOS Portal search functions into the desktop environment. The GOS dashboard will help fill this gap.

The GOS Dashboard is powered by GeoRSS and builds on our experience developing GeoRSS applications for Spatial Data Infrastructures. The Dashboard is based on Microsoft Gadgets and enhances common RSS functions with the ability to configure searches, view geodata footprints on a mini-map, and access desktop GIS applications from ESRI and other vendors directly with the data people find.

The software will be jointly designed in support of governmental activities by The Carbon Project, the US Army Corps of Engineers and other FGDC representatives and based on key business requirements.

- Jeff

Gaia YouTube tutorial - using OGC data and services

In this part of the Gaia video series Nuke dives a little deeper into using OGC data and services in Gaia - using a GML file, accessing a WMS and WFS and using the Filter Builder tool are covered.

Gaia is a free geospatial browser developed using CarbonTools PRO and available as a free download.

- Jeff

OGC WMTS gets some "style"

We were testing the draft OGC WMTS Interface in .NET last Tuesday and noticed a quirk in REST WMTS. But CubeWerx and Universitat Autonoma de Barcelona were already on it - enhorabuena al equipo! Here's the deal - when trying to get tiles from OGC WMTS using the following syntax...

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

...we noticed the {style} path element is vital for providing addressable units of information. But the wording of the draft interface makes the {style} path element optional - that's a bit of a problem. Folks agreed this needs to change - and comments to OGC were submitted two weeks ago - nice job! Here are the key arguments from the RFC comment for making the {style} path element required -

a. It's the only part of the KVP GetTile request that can allow multiple parameter-set representations for the same tile. Every other parameter of the GetTile request is required and has a fixed set of possible values where each value results in a different document being requested. This strictness of parameters is by design - and one of the reasons for defining things this way is to make it easy for server-side tile caches to determine request equivalences.

b. Making the {style} path element optional adds unnecessary complexity and a potential point for implementation errors. Requiring it reduces complexity.

c. The optionality rules for the STYLE parameter in the SOAP and KVP encodings are different from those of the REST encoding (in SOAP and KVP WMTS, the parameter is optional, whereas in REST WMTS the parameter is required if the layer declares more than one style and ambiguously optional otherwise). This is another area of unnecessary complexity.

d. The REST-encoding rule for the STYLE parameter is: If the layer has zero or one style you should not include {style} level in paths and the default style will be returned - but there's no such thing as a layer with zero styles. The capabilities schema requires each layer to indicate at least one style. The main argument here is that this rule shouldn't exist.

e. Even if the REST-encoding rule for the STYLE parameter said "SHALL" rather than "SHOULD", it would make it very difficult for a WMTS service to interpret incoming REST-encoded GetTile requests. In order for it to know whether or not a style parameter is part of the request, it would have to perform a lookup of the layer to count how many styles it has. This can be an expensive operation. Even for a filesystem-only approach this is a problem. Imagine defining a layer with one style and pregenerating the tiles into the appropriate directory structure (or even generating and caching on the fly). Now imagine at some point in the future wanting to add a second style. Instead of just adding a new subdirectory representing that style, you'd have to rearrange the existing directory structure.

f. All this would make WMTS clients unnecessarily brittle. If a second style is added to a layer, existing REST-encoded tile URLs to that layer will become incorrect. Not good!

All this is solved simply by making the STYLE parameter required for all encodings of the GetTile and GetFeatureInfo requests. With this change, the WMTS can support RESTful encodings of tile requests that are 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. Kudos to OGC for getting this done early. Stay tuned, much more to come...

- Jeff

From Local to Community GML Schemas

A key challenge for SDI projects is that different organizations use different internal geospatial data models. An example of this is the Cross-Border SDI Project where participants developed an online network to help identify critical infrastructure (CI) during emergencies and everyday operations. The network is based on OGC WFS, Filter Encoding and GML standards and CubeWerx/Carbon Project software (the WFS are located in Montana and Quebec). Cross-border users are able to access the two secure data services, navigate through the content, and identify critical infrastructure data.

However, a key challenge was that participants in the US and Canada used multiple data models (NIDM, CISDM, GDM). To deal with this, participants used the capability of CubeWerx WFS to map and transform local agreed-on data models to a jointly agreed-on community data model (WFS-X). The WFS-X then dynamically translates internal data structures into the local GML schema (CI National Model) or the international common GML schema (CI Common Model) on the fly. So "chaque WFS parle deux langues."

We had great discussions about this at NC GIS 2009 and the FGDC HSWG. Lots of folks recognize the challenge - and the potential to support cross-border and cross-regional information infrastructures that move SDI from on-premise computing and file transfer to access, processing, analysis and collaboration services on an Internet cloud.

- Jeff

Cross-Border Demo using Secure SDI, WFS & GML

Cross-Border SDI Project 2008, Pipeline Planning Scenario

View more presentations from CarbonProject.

For more information please visit the Cross-Border SDI project page.

People (and OGC services) provide "glue" for Europe's regional SDIs

A recent report on regional SDIs in Europe concluded that "Spatial Data Infrastructures are foremost social networks of people and organisations, in which technology and data play a supportive role."

The study found that all of the infrastructures reviewed have adopted Service Oriented Architectures (SOA) - Lombardy, Piedmont, Catalonia, Navarra, Wallonia, Flanders, North-Rhine Westfalia, Bavaria, Northern Ireland, Brittany (France), and Vysočina - and are managing a transition between many GIS systems in different organisations towards a shared SDI. OGC-based services (WMS, WFS, etc.) and ISO-compliant metadata provide the glue linking together existing datasets and applications.

- Jeff

Norway Digital sets example for interoperable SDI

Norway Digital online services in Gaia

Norway digital is the Norwegian government's initiative to build a national geographical infrastructure. Already a working spatial data infrastructure (SDI) Norway digital has partner data available through more than 100 operational web map services, geoportals and other services.

Through Norway digital the public gets free access to a variety of view services provided by government, municipal, county and corporate partners. Partners benefit from access to a broad variety of geographic information including - downloadable datasets, web based services (WMS, WFS, etc), transformation software and services, tools for developing product specifications, access to the portal, participation in the organizational structure and participation in a variety of networks, e.g. technical and thematic.

The Norway digital technology framework is based on Implementing Rules founded on the ISO 191xx-series of standards and OGC specifications - specifically, there's growing interest among the partners to disseminate data as view services based on Web Map Services (WMS).

So where's Norway digital now? The effort formally started 2005 and today more than 10 Norwegian ministries, 20 of their agencies, a number of county agencies in all 18 counties and about 100 municipalities take part. In the future, more and more applications will be developed based on this national geographical infrastructure - but interoperability is no longer a major obstacle thanks to the great example set by by Norway Digital's use of international standards.

- Jeff

National Hydrography Data SLD posted

From the OGC Public Forum -

"USGS has developed a prototype Styled Layer Descriptor (SLD) for the National Hydrography Data (NHD), available here.

The NHD SLD is based on cartographic specifications, and USGS Symbol libraries were used to render geographic features in a cartographic quality map. Documents 6psym403.pdf and topomapsymbols.pdf were used as templates to generate the SLD encodings for the NHD styles. Descriptions of the development effort and examples are available here and here.

Prototype SLD encodings are available here, and deployed as part of the NSDI WMS."

A few of my favorite map symbols include - Swamp / Marsh, Inundation Areas and others.

SLD is a standard that lets data providers can use the same underlying data to generate different types of maps - like a transparent overlay of hydrography and roads data for a geologic map. Another way to think of it is by asking yourself the question, "how can I make Google Maps look different?" The answer is, "You can't." SLD allows the same underlying data to be symbolized differently.

- Jeff

CarbonTools PRO Implements GML 3.2

This CarbonTools update allows programmers to build rich SDI applications to support tomorrow’s transportation, infrastructure and environmental challenges (GML 3.2-based WXXM is shown above)

The Carbon Project has announced support for Open Geospatial Consortium (OGC) GML 3.2 in CarbonTools PRO, a geospatial software developer kit for the .NET framework. This update allows programmers to build rich spatial data infrastructure (SDI) applications to support tomorrow’s transportation, infrastructure and environmental challenges.

“The next generation of digital information flowing in and out SDI applications will be rich in details, and the chosen base specification for these many of these applications is OGC/ISO Geography Markup Language (GML) 3.2,” said Nuke Goldstein, CTO of The Carbon Project.

The Carbon Project enhanced its CarbonTools PRO GML parser and data management modules to support advanced models in GML 3.2. This GML 3.2 parser helps developers build a new generation of dynamic transportation, infrastructure and environmental applications powered by rich geospatial data.

“The parsed GML content seamlessly merges with the numerous data types and sources supported by our CarbonTools PRO product. In addition, internal feature management and caching tools as well as the robust rendering functionality are all supported to help developers build GML 3.2-powered applications,” said Nuke Goldstein, CTO of The Carbon Project.

The latest version of CarbonTools PRO is available now from http://www.carbontools.com/.

In addition to new GML 3.2 parsers The Carbon Project included a major update to the Gaia geospatial viewer in CarbonTools PRO. The full Gaia 3.3 source code is provided with the CarbonTools PRO product - making it possible for developers to create and deploy applications in minutes.

- Jeff

Cross-Border SDI based on WFS demonstrated

With the Cross-Border SDI network, users are able to access two secure WFS in the US and Canada - and identify critical infrastructure in border regions

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, I've had the pleasure of showing the results of a new project to the FGDC and HIFLD in the last few weeks - and demonstrate the foundations of an online network that could help identify critical infrastructure during emergencies and everyday operations.

The network is based on OGC Web Feature Service (WFS), Filter Encoding and GML standards and CubeWerx/Carbon Project software. 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 its content, and identify/access critical infrastructure data using Gaia 3.3 (a free geospatial viewer), CarbonArc PRO 1.7 (an SDI interoperability extension for ESRI's ArcGIS) and CubeWerx Web server products.

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.

The NSDI CAP was established by the Federal Geographic Data Committee (FGDC) to help form partnerships to implement the NSDI. The United States NSDI includes the technology, policies, criteria, standards and people to promote geospatial information sharing throughout all levels of government, the private and non-profit sectors, and academia. GeoConnections is the Canadian organization coordinating the implementation of this project for the Canadian Geospatial Data Infrastructure (CGDI).

In the next few weeks we'll be sharing alot of details about the project. For more information or to learn how cross-border organizations can participate, please contact info@TheCarbonProject.com.

- Jeff

DISCLAIMER: the information provided in this article does not constitute an endorsement by the FGDC of any non-federal entity, its products or its services.

Calif. bill would blur WMS of schools, govt bldgs

Under the proposed bill, online service providers could face fines of $250,000 a day for showing government buildings on their WMS

A California congressman has introduced a bill requiring online mapping programs, including possibly WMS, to blur out schools, places of worship, government or medical buildings or face fines of $250,000 a day, and possible jail time.

Assemblyman Joel Anderson told the AP he developed the bill after it was revealed that terrorists in Israel and Mumbai used popular services such as Google Earth and Microsoft's Virtual Earth to help plot attacks.

According to reports on the bill text, photographs and images of schools, places of worship, government or medical buildings must be blurred. Street-level imagery would also be banned. Companies that violated the provisions of the bill would face fines of up to $250,000 for every day the illegal imagery was available online.

From AppScout Blog and AP

- Jeff

NSDI 2.0, REST and the OGC WMTS

As folks discuss emerging technology for the National Spatial Data Infrastructure (NSDI) it's healthy consider the feasibility of different approaches as emergent solutions. It's important to note that recent "NSDI 2.0" grassroots coalitions didn't identify a particular technology platform in the initial concept paper - unlike Google, Microsoft and Oracle that said "SOA". Why? Because our consensus process identified this as an area where community discussion and exploration of emergent approaches was needed - and also because we knew there were multiple approaches available.

With that said, technology approaches for building online SDIs range from proprietary to interoperable and everything in between - and there are two basic Client-Server architectures to apply, ROA and SOA (Service Oriented Architectures and Resource Oriented Architectures). Note - folks will need both in an "SDI 2.0" because there will be information exchange, transaction services and collaboration requirements that can be supported better by SOA standards and KVP OGC Web Services like WFS. We'll take a look at Peer-to-Peer (p2p) architectures in the future.

SOA and ROA are both client-server design patterns and the corresponding distributed programming paradigms that provide conceptual methodologies for developing distributed architectures. In the cases of ROA and SOA the distributed components are called resources and services, respectively. I've discussed SOA already so lets look at ROA quickly - and use the draft OGC WMTS Interface Standard edited by CubeWerx, CREAF and the Autonomous University of Barcelona as an example.

From the candidate OGC WMTS Interface Standard - "The first step in the resource oriented architecture style is to identify the resources and the relations between the resources. Then the RESTful approach gives us a way to manipulate these resources via standard HTTP requests. In this specification only HTTP GET will be used to download resources that are equivalent to the ones that can be retrieved by the GetCapabilities, GetTile and GetFeatureInfo operations in the procedure oriented architecture style."

and...

"The RESTful encoding for WMTS consists in a set of canonical URLs to the service metadata document, to the tiles, and to the FeatureInfo documents (one for each pixel)."

So the URL referencing a capabilities document should have the following syntax...

{WMTSBaseURL}/{version}/WMTSCapabilities.{format_extension}

where format_extension is an extension compatible with the text/xml MIME type and version refers to the version of the capabilities document requested.

To request a WMTS capabilities document from a WMTS server that implements geospatial ROA, a client could issue the following RESTful URL...

http://www.maps.cat/1.0.0/WMTSCapabilities.xml

If a client requests a document version or a format extension that's not available on a particular server, the server returns an HTTP Error 404 (File Not Found). Sweet.

To continue, the ServiceMetadata document of WMTS in the RESTful architecture style contains a description of a resource with the name "Tile". The “Get” element of the GetResourceRepresentation operation has an xlink:href attribute that advertises the URL to retrieve tiles.

So the URL referencing a tile map image should have the following syntax...

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

If the layer has zero or one style, don't include the {style} level in paths and the default style will be returned. If there are no dimensions don't include /{firstDimension}/{...}/{lastDimension}/ levels in paths.

So then a client could issue the following RESTful Tile URL for a resource representation...

http://www.maps.cat/etopo2/WholeWorld_CRS_84/10m/1/3.png


So there you go, geospatial ROA 101 for the web engineers. As an overarching concept what is key is interoperability - the shared agreements of our community. As consensus ROA standards advance in the future, and can be combined with SOA and used for access to geospatial and environmental data, this is positive. In the end, a key concept is providing an open, standards-based framework so geospatial data and environmental data can be maintained locally, closest-to-source, and then shared with the Nation through an online information network. Stay tuned, much more to come...

- Jeff

Gaia Tutorial - Constructing and styling a map

In this part of the Gaia Video Tutorial Nuke discusses how to construct a map with a variety of data services, use local files, and style a feature layer using Gaia's rendering and symbology.

- Jeff

OGC WMTS - open standard for fast web mapping

With the release of a proposed standard for tile-based web mapping, Web Map Tile Service (WMTS), the OGC is poised to provide an open alternative to proprietary web mapping services like Google Maps.

Worked on quietly by the gurus at CubeWerx, CREAF and the Autonomous University of Barcelona - the candidate WMTS Interface Standard is much like OGC's popular WMS, but it enables faster server performance.

As many know, OGC Web Map Server (WMS) has been criticized for being slow because it creates a new image for each request – rather than returning pre-generated tiles that provide an almost “instant” zoom and pan. WMS was designed this way because there were two goals behind the interface, interoperability and the ability to overlay many sources - and in this respect it's been very successful. A WMS client can overlay map layers from many sources in an arbitrary bounding box at an arbitrary scale with any number of styles. But this flexibility comes at a price - since a WMS server is required to generate each requested map image on the fly it's slower to respond than a tile map service.

But the OGC WMTS changes all this.

To improve performance, instead of creating a new image for each request, a WMTS returns small pre-generated images (e.g., PNG or JPEG) or reuses identical previous requests that follow a set of tile matrices. This proposed standard provides support for multiple architectural patterns - KVP, REST and SOAP.

WMTS is an evolution of Tile Map Service Specification by OSGeo and the Tiled WMS by NASA OnEarth. In addition, this is the first OGC standard to include a RESTful approach in addition to the usual OGC encodings.

Bottom Line - WMTS provides a natural way to evolve WMS services into a more constrained - but more scalable and faster service - so anyone can build services and applications that are fast, easy to use, and democratically accessible.

- Jeff