An important change to the way geospatial content is
shared and managed is coming. Technologies are now becoming available
that can transform the way software is designed and implemented. New
software design approaches are redefining how people and machines
collaborate and interact, and modern networking and peer-to-peer
technologies open up new potential for location-based content use. In
the past few years The Carbon Project has been working on some of these
new cutting edge technologies that are now coming to light. This
article is a biased reflection of our ongoing effort. However, now that
the vision is fast becoming reality, we are happy to share what we
truly believe is an exciting new generation of geospatial
interoperability.
To understand future interoperability, I will first clarify the type of collaboration discussed here. It is not the intent of this article to engage in a deep academic debate over semantics and high level concepts. To most software designers and developers who need to fulfill project requirements, that debate is irrelevant. What is relevant is a realistic path to produce the best software using an allocated amount of time and resources. This practical approach to applying software toward geospatial interoperability is the core motivation behind the technologies described.
One of my favorite examples of an extremely successful applied interoperability approach is a commonly used image format. The Joint Photographic Experts Group, better known as JPEG, can be found in Web browsers, Word documents, digital cameras and many other common technologies. However, the JPEG format is far from simple; it uses sophisticated mathematical algorithms to support data compression. Would JPEG be in common usage if a developer regularly needed to deal with thick books about compression techniques? What would have been the impact of having to deal with these types of problems on the quality of software products? Isn't it a better use of resources when working on, say, a car navigation system, to focus on getting good usable navigation and not bother with complex parsing of an array of bytes? The ability to develop applications using common tools that are intuitive to developers is what makes JPEG so ubiquitous.
The world of digital mapping was the sole domain of the professional GIS community until Google, which was not known for its GIS expertise, released a friendly 2D mapping system with a simple and usable API - aptly named Google Maps. The Google Maps API allowed Web developers to easily and freely add simple mapping capabilities to their websites. Suddenly mapping was cool and geospatial innovation was on the rise in consumer-oriented Web applications. Although AJAX viewers and mash-up mapping are nice, true geospatial interoperability at the framework level is a different animal altogether.
The Carbon Project developed CarbonTools with the idea of bringing advanced geospatial interoperability to mainstream software developers. CarbonTools is designed as an extension to the Microsoft .NET framework rather than as a mere stand-alone toolkit. The concept of extending the framework means more than just publishing software libraries. It means giving all the tools necessary for a user to adopt complex data types and services, using a language that is in the comfort zone of a programmer rather than a GIS professional - much like how JPEG is handled by non-mathematicians using a .NET Image class. There are other keys to making a successful framework extension, such as documentation that looks and sounds like the framework user guides, providing code samples in popular coding languages and even a licensing structure that does not limit the solution provider (imagine the horror and global outrage if Microsoft demanded a per-seat fee on software developed using the popular Visual Studio).
Obviously handling the universe of geospatial content is not as simple as a JPEG. Trying to categorize the various forms of geospatial sources may yield the following list:
To construct a unified API for geospatial interoperability, CarbonTools takes a fresh design approach, called the Source-Handler-Data architecture. This design makes working with many types of complicated geospatial content a task that can be easily handled by most software developers. For example, if a developer wants to add map tiles from Microsoft Virtual Earth to an application's map control, the C# code snippet will look something like this:
To add map tiles from Yahoo! Maps the same pattern is used. In this example the Yahoo! Maps layer will be an over-layered transparent road map:
To add a Shapefile layer to the map control we can use the following:
Google Earth KML or KMZ files may be added the same way:
History shows that practical interoperability is tightly linked with the ability to use content easily and seamlessly. The data format, form or even the way it is served is not as important as the ability to commonly adopt and use it. The Carbon Project tries to apply this to geospatial interoperability with an API that is addressing many formats and forms, while exposing a unified language that feels to developers like a natural extension to the Microsoft .NET framework. But this is just the prolog to future geospatial interoperability and where the real fun begins!
A key feature is its ability to transform (through .NET serialization) the content source, data and session into a blob of bytes called Geospatial Session Files (GSF). This allows geospatial files and services to be saved and shared between different applications. In the past few years we have been exploring innovative ways to exploit this capability to find and share geospatial content through peer-to-peer (P2P) networking technologies. This spawned a CarbonTools extension named CarbonCloud.
CarbonCloud is not a classic peer-to-peer framework like BitTorrent where a super-node (tracker) tracks which peers are available. CarbonCloud uses an IPv6-based peer-to-peer framework that is serverless and self-repairing. This allows for the formation of communities over any network, even ad-hoc ones, without the dependency on any type of administrator or catalog. The implications of a network where all peers can join and are equal and self-sustaining are mind-boggling. Combine that with the ability to move geospatial content around and the sky is the limit! For example, this means services-based architectures can now be enhanced with a new type of content source – a community-based content network. There is enormous power in the common personal computer, and connecting clusters of machines provide endless possibilities. Grid computing is hardly a new concept, but grid-data sharing may be.
To illustrate the concept of a community-based content network let's take a look at a hypothetical futuristic mapping service. This service allows applications to connect to standard Web-based content providers as well as to other applications through an alternate peer-to-peer framework. Connected users can access online services to fetch map parts while making those data available to other peers. The community peers actually get data from a combination of Web services and peer sharing through an alternate network (physical and/or virtual). You can sit in a Starbucks, drink expensive coffee and use a map made from geospatial content that was received from other machines in the vicinity. The community content network could be people in the coffee shop, or people in the neighborhood, city and so on. In other words, the data obtained from a Web service may propagate through the alternate community network.
The effect of this technology goes far beyond geospatial interoperability. We sometimes refer to applications developed with CarbonTools and CarbonCloud as survivable technology, since data are cached and architectural weak points, such as dependency on constant availability of an Internet connection, are minimized. This is important when dealing with security and military solutions as well as consumer applications. There is a social element to this innovation as well. The Internet created a virtual world in which everyone around the world can be connected to the global community. Ad-hoc networks bring the physical distance back into play. Networks can be based on physical proximity, such as an office, apartment building or a city. It may also make more sense if the data we need and seek come from a community of locals (e.g. weather, shopping, and traffic report). We call the experience of social networking with geospatial content "geosocial networking."
How far is a community-based content source from reality?
Microsoft's new music player (Zune) can communicate with other devices through a wireless ad-hoc network, allowing people to share media. Sprint Nextel is releasing a Boost-Mobile technology that allows users to locate their friends from within half a mile to 25 miles. Another solution, Carbon IR, is a product of collaboration between The Carbon Project and the state of North Carolina where CarbonCloud-based applications will be used for incident response and situation management. First responders will be able, in the near future, to use sophisticated geosocial technologies to better their real-time situational awareness and response. We will also soon be releasing a CarbonCloud-based geosocial networking application, called ((Echo))MyPlace, which is a map-driven social networking application that allows users to form communities, chat and share customized and spatially enabled notes.
Welcome to the new age in geospatial interoperability!
To understand future interoperability, I will first clarify the type of collaboration discussed here. It is not the intent of this article to engage in a deep academic debate over semantics and high level concepts. To most software designers and developers who need to fulfill project requirements, that debate is irrelevant. What is relevant is a realistic path to produce the best software using an allocated amount of time and resources. This practical approach to applying software toward geospatial interoperability is the core motivation behind the technologies described.
One of my favorite examples of an extremely successful applied interoperability approach is a commonly used image format. The Joint Photographic Experts Group, better known as JPEG, can be found in Web browsers, Word documents, digital cameras and many other common technologies. However, the JPEG format is far from simple; it uses sophisticated mathematical algorithms to support data compression. Would JPEG be in common usage if a developer regularly needed to deal with thick books about compression techniques? What would have been the impact of having to deal with these types of problems on the quality of software products? Isn't it a better use of resources when working on, say, a car navigation system, to focus on getting good usable navigation and not bother with complex parsing of an array of bytes? The ability to develop applications using common tools that are intuitive to developers is what makes JPEG so ubiquitous.
The world of digital mapping was the sole domain of the professional GIS community until Google, which was not known for its GIS expertise, released a friendly 2D mapping system with a simple and usable API - aptly named Google Maps. The Google Maps API allowed Web developers to easily and freely add simple mapping capabilities to their websites. Suddenly mapping was cool and geospatial innovation was on the rise in consumer-oriented Web applications. Although AJAX viewers and mash-up mapping are nice, true geospatial interoperability at the framework level is a different animal altogether.
The Carbon Project developed CarbonTools with the idea of bringing advanced geospatial interoperability to mainstream software developers. CarbonTools is designed as an extension to the Microsoft .NET framework rather than as a mere stand-alone toolkit. The concept of extending the framework means more than just publishing software libraries. It means giving all the tools necessary for a user to adopt complex data types and services, using a language that is in the comfort zone of a programmer rather than a GIS professional - much like how JPEG is handled by non-mathematicians using a .NET Image class. There are other keys to making a successful framework extension, such as documentation that looks and sounds like the framework user guides, providing code samples in popular coding languages and even a licensing structure that does not limit the solution provider (imagine the horror and global outrage if Microsoft demanded a per-seat fee on software developed using the popular Visual Studio).
Obviously handling the universe of geospatial content is not as simple as a JPEG. Trying to categorize the various forms of geospatial sources may yield the following list:
- Tile-based services (Google Earth, Microsoft Virtual Earth, Yahoo! Maps etc.)
- Region-based services (OGC's WMS, WCS etc.)
- Features-based services (OGC's WFS, Google's KML network links, Yahoo! Traffic Web Services, GeoRSS feeds etc.)
- Features files (ESRI Shapefiles, Google Earth KML, GML, MIF, DXF etc.)
- Raster files (JPEG, TIFF, GeoTIFF etc.)
- ·Metadata sources (catalogs, OGC Capabilities etc.)
To construct a unified API for geospatial interoperability, CarbonTools takes a fresh design approach, called the Source-Handler-Data architecture. This design makes working with many types of complicated geospatial content a task that can be easily handled by most software developers. For example, if a developer wants to add map tiles from Microsoft Virtual Earth to an application's map control, the C# code snippet will look something like this:
 |
To add map tiles from Yahoo! Maps the same pattern is used. In this example the Yahoo! Maps layer will be an over-layered transparent road map:
 |
To add a Shapefile layer to the map control we can use the following:
 |
Google Earth KML or KMZ files may be added the same way:
 |
 |
History shows that practical interoperability is tightly linked with the ability to use content easily and seamlessly. The data format, form or even the way it is served is not as important as the ability to commonly adopt and use it. The Carbon Project tries to apply this to geospatial interoperability with an API that is addressing many formats and forms, while exposing a unified language that feels to developers like a natural extension to the Microsoft .NET framework. But this is just the prolog to future geospatial interoperability and where the real fun begins!
A key feature is its ability to transform (through .NET serialization) the content source, data and session into a blob of bytes called Geospatial Session Files (GSF). This allows geospatial files and services to be saved and shared between different applications. In the past few years we have been exploring innovative ways to exploit this capability to find and share geospatial content through peer-to-peer (P2P) networking technologies. This spawned a CarbonTools extension named CarbonCloud.
CarbonCloud is not a classic peer-to-peer framework like BitTorrent where a super-node (tracker) tracks which peers are available. CarbonCloud uses an IPv6-based peer-to-peer framework that is serverless and self-repairing. This allows for the formation of communities over any network, even ad-hoc ones, without the dependency on any type of administrator or catalog. The implications of a network where all peers can join and are equal and self-sustaining are mind-boggling. Combine that with the ability to move geospatial content around and the sky is the limit! For example, this means services-based architectures can now be enhanced with a new type of content source – a community-based content network. There is enormous power in the common personal computer, and connecting clusters of machines provide endless possibilities. Grid computing is hardly a new concept, but grid-data sharing may be.
To illustrate the concept of a community-based content network let's take a look at a hypothetical futuristic mapping service. This service allows applications to connect to standard Web-based content providers as well as to other applications through an alternate peer-to-peer framework. Connected users can access online services to fetch map parts while making those data available to other peers. The community peers actually get data from a combination of Web services and peer sharing through an alternate network (physical and/or virtual). You can sit in a Starbucks, drink expensive coffee and use a map made from geospatial content that was received from other machines in the vicinity. The community content network could be people in the coffee shop, or people in the neighborhood, city and so on. In other words, the data obtained from a Web service may propagate through the alternate community network.
 |
The effect of this technology goes far beyond geospatial interoperability. We sometimes refer to applications developed with CarbonTools and CarbonCloud as survivable technology, since data are cached and architectural weak points, such as dependency on constant availability of an Internet connection, are minimized. This is important when dealing with security and military solutions as well as consumer applications. There is a social element to this innovation as well. The Internet created a virtual world in which everyone around the world can be connected to the global community. Ad-hoc networks bring the physical distance back into play. Networks can be based on physical proximity, such as an office, apartment building or a city. It may also make more sense if the data we need and seek come from a community of locals (e.g. weather, shopping, and traffic report). We call the experience of social networking with geospatial content "geosocial networking."
How far is a community-based content source from reality?
Microsoft's new music player (Zune) can communicate with other devices through a wireless ad-hoc network, allowing people to share media. Sprint Nextel is releasing a Boost-Mobile technology that allows users to locate their friends from within half a mile to 25 miles. Another solution, Carbon IR, is a product of collaboration between The Carbon Project and the state of North Carolina where CarbonCloud-based applications will be used for incident response and situation management. First responders will be able, in the near future, to use sophisticated geosocial technologies to better their real-time situational awareness and response. We will also soon be releasing a CarbonCloud-based geosocial networking application, called ((Echo))MyPlace, which is a map-driven social networking application that allows users to form communities, chat and share customized and spatially enabled notes.
Welcome to the new age in geospatial interoperability!
From Our Homepage
Saying Farewell to an Amazing Journey
Communicating with Maps
Is There a GIS Career Ladder?
What does it mean to be geospatially smart? Series
Ways Real Estate and Property Developers Utilize Melissa GeoData for Data-Driven Decisions
Unlocking Value From Daily Satellite Imagery and Insights
Maximizing the Value of Your Address Data with Geo Addressing
How Indoor Mapping Enhances the Security of Smart Buildings
Look Ahead: AI, Location Intelligence and Efficiency
Collaboration Takes on Sea Level Rise & Dynamic Technology Environments
Brownies for Brownfields
Has Everything Been Mapped Already?
How Is Data Literacy Changing in an Artificial Intelligence Landscape
Portfolios for GIS Professionals: More Than Just Maps
How to Create a Distance Matrix in QGIS - A Step-by-Step Guide
7 Ideas for Bringing GIS into the K-12 Classroom
The Geography of Movement