A couple of years ago, from the perspective of a
systems integrator who was selling and implementing Services-Oriented
Architectures and Web services, it appeared that most businesses
recognized the value of and need for systems and information
integration. At the time, I might have naively said that the
concept of interoperability had reached mainstream recognition in the
geospatial community. I would have been wrong.
Clearly, the number of GIS-related interoperability projects and standards is still growing in the industry. Looking at trade magazines, conference agendas and product literature, the need for interoperable geospatial solutions drives much of the discussion and new investment in the corporate and open source communities. The emergence of technologies as diverse as Feature Data Objects (FDO), the transaction Web Feature Service (WFS-T) and OpenLayers demonstrates the industry-wide impact of integration-ready technologies for data access, communication and visualization.
Examining some of these technologies, I cannot help but notice the meandering pathways they have traversed to become accepted or standardized. The migration of technology from one domain to another is a natural process in the whole IT industry. For example, although the extensible markup language (XML) finds its origin in the fledgling electronic publishing industry, XML is now accepted as a standard for communicating information between applications that may never display that information to a human.
In the early years of GIS, geospatial technology typically originated within the industry. Less commonly, technology may have seeped in from related domains such as the defense or environmental fields. In recent years, the intrusion of giant corporations with no geospatial history into our previously tightly-knit field has injected new thinking and technology while simultaneously increasing the market demand for GIS and GIS-like products and services. This new market demand, the "Google Maps phenomenon," bears a large part of the responsibility for the increased demand for the integration of mapping technology with mainstream IT systems. As the GIS industry attempts to supply technology to meet this newfound market demand, we are seeing the rapid transition of new technologies into the geospatial arena. Successful conventional technology ideas are adopted in the mainstream IT industry, and our industry is changing by necessity to build agile processes which allow us to adapt new technologies to satisfy these non-traditional market demands.
GeoJSON - From AJAX to XML Alternative
One emerging geospatial technology standard that bears monitoring, GeoJSON (pronounced jee-oh-jay-son, sometimes with emphasis on the last syllable), may result in a viable software messaging language (e.g. a computer software system to computer software system messaging language) that can be simultaneously more compact than XML and more readable by a human. Compactness increases in importance when considering the large amount of geospatial data that must be shared in some system integrations. (Insistence that languages for computer-to-computer communication should be "human readable" is a pervasive theme for many IT standards bodies, and that likely says more about software developers' reluctance to release control than it does the necessity that the information actually ever be readable.)
GeoJSON finds its history in the early years of the browser wars during which there were a lot of good ideas, but the industry often lacked the focus and physical bandwidth to put them into action. In the mid 1990's, Netscape and Microsoft built tools to attempt to best their rivals in Web browser functionality and capability. These early Internet giants recognized the commercial promise of the Web. They created tools that would allow Web developers to add dynamic functionality to their Web pages and to better communicate information back and forth from the browser to a server. JavaScript was pioneered by Netscape as a tool for allowing a Web page to have interactive functionality that wouldn't always require cycling a Web page to the server and back after every user action. Netscape also introduced a tool called Asynchronous JavaScript and XML (AJAX), which allowed developers to send information to a server and to retrieve a response without refreshing a Web page. Although Microsoft and Netscape's descendant, Firefox, continues to do things a little differently, nearly all popular browsers use a pattern for asynchronous browser-client interaction that resembles the pattern established by Netscape and is what we collectively call "AJAX."
AJAX found popularity in the early-to-mid 2000's when a few small companies and one critical, huge company recognized the importance of being able to exchange data with a server without refreshing the whole Web page. Coupled with JavaScript and other dynamic tools, AJAX enabled developers to build applications that could validate passwords, check spelling and refresh stock tickers without forcing the user to wait for a page to refresh. When Google rolled out Gmail and then Google Maps, the usefulness of AJAX technology was confirmed for Web developers, and AJAX was forced upon the geospatial community. AJAX-related techniques have become ubiquitous as a way to make better user-friendly Web-based maps than have been seen since early Java technology was applied to online mapping.
JSON vs. XML
While the ability to dynamically exchange data with a server expands the capability for the Web developer, the resulting desire to push more and more data over the Internet to build "cooler" applications forces developers to examine the quantity and the mechanisms for sending messages across the Web. Although the "X" in AJAX stands for "XML," the use of XML requires that developers translate programming, or "object," data into XML, send them across the Web, and then translate them back to object data on the other side. XML, by design, also includes a large amount of extra characters that may drastically increase the size of the message. It turns out that AJAX techniques didn't really require XML. Just about any text, whether formatted or not, could be passed between a browser and server using some of the same tools. Developers began exploring alternatives to XML for messaging and an obvious candidate arose out of the "J" in AJAX, which stands for JavaScript.
Compiled and run dynamically inside a browser application, JavaScript code can be modified dynamically during a Web page's operations such that changes in program operation may be intentionally caused by a developer while the program is running. Dynamic change might happen, for example, when a JavaScript call checks a server to see what menus should be drawn on the screen, then draws the menus that are allowed for the current user. This ability to write code that modifies itself implies that, at some level, the structure of data or "objects" that are manipulated in the code must be readable to a human. Indeed, JavaScript objects have a specific, fixed text representation called JavaScript Object Notation (JSON). JSON happens to be quite compact compared with XML, although it has some limitations that XML has been adapted to overcome. However, when developers realized that they were converting data from Python, Java or .NET into XML, then converting them to JSON to be used in a Web page, they naturally began to cut out the middleman and went straight from Python to JSON, for example.
Many different implementations of object-data-to-JSON converters now exist on the Web. Developers are experimenting with JSON as an interoperability language because JSON is easily adapted from many data representation formats and because it allows developers to sometimes create more compact messages than XML. Plus, I suspect that some deep disquiet exists in the developer community at the rapid rise in popularity of XML to "ubiquitous buzzword" status despite its painful verbosity. JSON seems here to stay.
Fledgling Technology: GeoJSON
The collision of Google-type Web interfaces with verbose messaging technologies, such as XML, created the opportunity in the geospatial community for developers to seek alternative messaging tools for the exchange of geographic information with Web applications and with other systems. JSON offered a well-supported option that also had become rapidly established in many development languages that have been adopted by the open source geospatial efforts, such as PHP, PERL and Python. Recently, the geospatial community has begun to experiment with a geographic dialect of JSON, GeoJSON, which is targeted at standardizing the way that spatial data are represented in JSON. The draft version of the current specification, along with examples, may be found online.
GeoJSON is not really a new language, but a dialect or domain-specific version of JSON object representation, in the same way that GML is a geography-specific version of XML. As GeoJSON is adapted to fit the same domain for which GML is currently used, we are likely to see features added to it, such as support for multi-step transactions and more complex geometry types. Although this standard is still developing, it is relevant to know that GeoJSON has already been adapted for the open source project GeoServer and it has been proposed for inclusion in MapGuide Open Source.
Perhaps the most significant event for GeoJSON has come in the form of JSON and GeoJSON support being included in next year's release of FME 2008 by Safe Software Inc. JSON and GeoJSON read and write capability are already available in a downloadable Beta release available on Safe's website. Don Murray, president of Safe, explained in an e-mail to me: "Our corporate strategy at Safe is to ensure that we support as many formats as we can both present and future... GeoJSON definitely falls into the camp of a potential format of the future. Some new technologies fall by the wayside and our effort could be viewed as wasted… that is just the price to be paid for remaining on the edge in the data interoperability industry." Murray went on to state, "One thing that we will be able to do with our upcoming FME Server would be to simply put a GeoJSON view on top of any FME source including WFS, and GeoRSS." Surely the ability of FME to allow any data format to be served out to any GeoJSON consumer has the potential to increase the market demand for this developing standard.
From conception to mainstream in a year... What next?
Essentially, GeoJSON was adapted from JSON and then became geospatial mainstream technology in less than a year, with its inclusion in FME 2007 Beta. Incredibly, the GeoJSON Request for Comments (RFC) has not even been approved or finalized by any official geospatial standards committee. Our industry is being pushed by the rapid injection of interoperability and Web-based technologies, sometimes from companies that have no traditional foundation in GIS. Whether we focus on the classic analytical aspects of GIS or embrace the inclusion of GIS in the chain of data integration that makes up the enterprise workflow, industry demand inevitably will develop and promote critical technologies until they rapidly achieve mainstream status. It is up to the geospatial community to promote standards bodies that have enough organization agility to keep up with technology changes while maintaining adequate common sense to make good decisions. Whether GeoJSON becomes a true standard technology remains undecided, but you can be sure that the next "GeoJSON" is waiting for an opportunity to become the next "coolest thing" in electronic mapping technology.
Ed. note: The article was modified after its publication. The word "Beta" was added to the mention of FME 2007 at the end of the first sentence of the last paragraph.
Clearly, the number of GIS-related interoperability projects and standards is still growing in the industry. Looking at trade magazines, conference agendas and product literature, the need for interoperable geospatial solutions drives much of the discussion and new investment in the corporate and open source communities. The emergence of technologies as diverse as Feature Data Objects (FDO), the transaction Web Feature Service (WFS-T) and OpenLayers demonstrates the industry-wide impact of integration-ready technologies for data access, communication and visualization.
Examining some of these technologies, I cannot help but notice the meandering pathways they have traversed to become accepted or standardized. The migration of technology from one domain to another is a natural process in the whole IT industry. For example, although the extensible markup language (XML) finds its origin in the fledgling electronic publishing industry, XML is now accepted as a standard for communicating information between applications that may never display that information to a human.
In the early years of GIS, geospatial technology typically originated within the industry. Less commonly, technology may have seeped in from related domains such as the defense or environmental fields. In recent years, the intrusion of giant corporations with no geospatial history into our previously tightly-knit field has injected new thinking and technology while simultaneously increasing the market demand for GIS and GIS-like products and services. This new market demand, the "Google Maps phenomenon," bears a large part of the responsibility for the increased demand for the integration of mapping technology with mainstream IT systems. As the GIS industry attempts to supply technology to meet this newfound market demand, we are seeing the rapid transition of new technologies into the geospatial arena. Successful conventional technology ideas are adopted in the mainstream IT industry, and our industry is changing by necessity to build agile processes which allow us to adapt new technologies to satisfy these non-traditional market demands.
GeoJSON - From AJAX to XML Alternative
One emerging geospatial technology standard that bears monitoring, GeoJSON (pronounced jee-oh-jay-son, sometimes with emphasis on the last syllable), may result in a viable software messaging language (e.g. a computer software system to computer software system messaging language) that can be simultaneously more compact than XML and more readable by a human. Compactness increases in importance when considering the large amount of geospatial data that must be shared in some system integrations. (Insistence that languages for computer-to-computer communication should be "human readable" is a pervasive theme for many IT standards bodies, and that likely says more about software developers' reluctance to release control than it does the necessity that the information actually ever be readable.)
GeoJSON finds its history in the early years of the browser wars during which there were a lot of good ideas, but the industry often lacked the focus and physical bandwidth to put them into action. In the mid 1990's, Netscape and Microsoft built tools to attempt to best their rivals in Web browser functionality and capability. These early Internet giants recognized the commercial promise of the Web. They created tools that would allow Web developers to add dynamic functionality to their Web pages and to better communicate information back and forth from the browser to a server. JavaScript was pioneered by Netscape as a tool for allowing a Web page to have interactive functionality that wouldn't always require cycling a Web page to the server and back after every user action. Netscape also introduced a tool called Asynchronous JavaScript and XML (AJAX), which allowed developers to send information to a server and to retrieve a response without refreshing a Web page. Although Microsoft and Netscape's descendant, Firefox, continues to do things a little differently, nearly all popular browsers use a pattern for asynchronous browser-client interaction that resembles the pattern established by Netscape and is what we collectively call "AJAX."
AJAX found popularity in the early-to-mid 2000's when a few small companies and one critical, huge company recognized the importance of being able to exchange data with a server without refreshing the whole Web page. Coupled with JavaScript and other dynamic tools, AJAX enabled developers to build applications that could validate passwords, check spelling and refresh stock tickers without forcing the user to wait for a page to refresh. When Google rolled out Gmail and then Google Maps, the usefulness of AJAX technology was confirmed for Web developers, and AJAX was forced upon the geospatial community. AJAX-related techniques have become ubiquitous as a way to make better user-friendly Web-based maps than have been seen since early Java technology was applied to online mapping.
JSON vs. XML
While the ability to dynamically exchange data with a server expands the capability for the Web developer, the resulting desire to push more and more data over the Internet to build "cooler" applications forces developers to examine the quantity and the mechanisms for sending messages across the Web. Although the "X" in AJAX stands for "XML," the use of XML requires that developers translate programming, or "object," data into XML, send them across the Web, and then translate them back to object data on the other side. XML, by design, also includes a large amount of extra characters that may drastically increase the size of the message. It turns out that AJAX techniques didn't really require XML. Just about any text, whether formatted or not, could be passed between a browser and server using some of the same tools. Developers began exploring alternatives to XML for messaging and an obvious candidate arose out of the "J" in AJAX, which stands for JavaScript.
Compiled and run dynamically inside a browser application, JavaScript code can be modified dynamically during a Web page's operations such that changes in program operation may be intentionally caused by a developer while the program is running. Dynamic change might happen, for example, when a JavaScript call checks a server to see what menus should be drawn on the screen, then draws the menus that are allowed for the current user. This ability to write code that modifies itself implies that, at some level, the structure of data or "objects" that are manipulated in the code must be readable to a human. Indeed, JavaScript objects have a specific, fixed text representation called JavaScript Object Notation (JSON). JSON happens to be quite compact compared with XML, although it has some limitations that XML has been adapted to overcome. However, when developers realized that they were converting data from Python, Java or .NET into XML, then converting them to JSON to be used in a Web page, they naturally began to cut out the middleman and went straight from Python to JSON, for example.
Many different implementations of object-data-to-JSON converters now exist on the Web. Developers are experimenting with JSON as an interoperability language because JSON is easily adapted from many data representation formats and because it allows developers to sometimes create more compact messages than XML. Plus, I suspect that some deep disquiet exists in the developer community at the rapid rise in popularity of XML to "ubiquitous buzzword" status despite its painful verbosity. JSON seems here to stay.
Fledgling Technology: GeoJSON
The collision of Google-type Web interfaces with verbose messaging technologies, such as XML, created the opportunity in the geospatial community for developers to seek alternative messaging tools for the exchange of geographic information with Web applications and with other systems. JSON offered a well-supported option that also had become rapidly established in many development languages that have been adopted by the open source geospatial efforts, such as PHP, PERL and Python. Recently, the geospatial community has begun to experiment with a geographic dialect of JSON, GeoJSON, which is targeted at standardizing the way that spatial data are represented in JSON. The draft version of the current specification, along with examples, may be found online.
GeoJSON is not really a new language, but a dialect or domain-specific version of JSON object representation, in the same way that GML is a geography-specific version of XML. As GeoJSON is adapted to fit the same domain for which GML is currently used, we are likely to see features added to it, such as support for multi-step transactions and more complex geometry types. Although this standard is still developing, it is relevant to know that GeoJSON has already been adapted for the open source project GeoServer and it has been proposed for inclusion in MapGuide Open Source.
Perhaps the most significant event for GeoJSON has come in the form of JSON and GeoJSON support being included in next year's release of FME 2008 by Safe Software Inc. JSON and GeoJSON read and write capability are already available in a downloadable Beta release available on Safe's website. Don Murray, president of Safe, explained in an e-mail to me: "Our corporate strategy at Safe is to ensure that we support as many formats as we can both present and future... GeoJSON definitely falls into the camp of a potential format of the future. Some new technologies fall by the wayside and our effort could be viewed as wasted… that is just the price to be paid for remaining on the edge in the data interoperability industry." Murray went on to state, "One thing that we will be able to do with our upcoming FME Server would be to simply put a GeoJSON view on top of any FME source including WFS, and GeoRSS." Surely the ability of FME to allow any data format to be served out to any GeoJSON consumer has the potential to increase the market demand for this developing standard.
From conception to mainstream in a year... What next?
Essentially, GeoJSON was adapted from JSON and then became geospatial mainstream technology in less than a year, with its inclusion in FME 2007 Beta. Incredibly, the GeoJSON Request for Comments (RFC) has not even been approved or finalized by any official geospatial standards committee. Our industry is being pushed by the rapid injection of interoperability and Web-based technologies, sometimes from companies that have no traditional foundation in GIS. Whether we focus on the classic analytical aspects of GIS or embrace the inclusion of GIS in the chain of data integration that makes up the enterprise workflow, industry demand inevitably will develop and promote critical technologies until they rapidly achieve mainstream status. It is up to the geospatial community to promote standards bodies that have enough organization agility to keep up with technology changes while maintaining adequate common sense to make good decisions. Whether GeoJSON becomes a true standard technology remains undecided, but you can be sure that the next "GeoJSON" is waiting for an opportunity to become the next "coolest thing" in electronic mapping technology.
Ed. note: The article was modified after its publication. The word "Beta" was added to the mention of FME 2007 at the end of the first sentence of the last paragraph.
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