Chris Andrews introduces readers to GeoJSON, a data interchange format that holds potential. “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.”
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.)
JSON vs. XML
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.