The first cities developed and prospered around the concept that each family did not have to provide all of its own needs. For example, a person could specialize in making clothing and rely on others to provide food, horseshoes, jewelry, etc. to the marketplace. Online services operate on this same principle: it is often better and cheaper to outsource certain business functions.
Today, some individuals are beginning to rely on their bank's online payment services to pay bills. Companies in complimentary industries are flocking to online business exchanges as a way to more efficiently manage core business functions such as supply chains, order fulfillment and just-in-time inventory management. This paper describes how technologies in this area apply to the geospatial industry and how Syncline uses Esri technology to power their flagship online service, MapCiti.com.
Large software companys like Sun, Microsoft, and IBM have recently been promoting their Web services architectures (Sun's is called SunONE and Microsoft's is .NET). Despite all the press coverage they get, the initiatives are still in their infancy. There are few, if any, applications deployed on the .NET or the ONE architecture. However, companies have been providing online services for years. The problem is not that people cannot access online services. It's that online services from different vendors cannot interoperate. This section describes some of the existing services as an introduction and background for a deeper discussion of the next generation of integrated geospatial services.
There are numerous types of Internet-based geospatial services currently available or in development. The most basic geospatial service is access to data. Downloading data is often a manual process involving logging on to an FTP site or navigating through a set of Web pages to find the right file to download. This access methodology is below the standards of modern online services, and will be better integrated into the workflow of data users in the future. Many companies are working on systems that will allow a user to download data on demand.
For example, when I was working as a GIS consultant in the early 1990s, I downloaded all of the 1:24,000 scale hydrography from the USGS server because I used it so frequently. What I would have liked to do was bring up a map in ArcPlot and make a request to the USGS server for hydrography for the area I was working in. The data would then be cached on my hard drive, and as I panned and zoomed, more data would be downloaded into my local cache. As I worked on projects around the state, I would be hitting the server less and less, because my cache would grow. I would have been willing to pay for this service to avoid the countless days spent figuring out exactly what data I had to order for each project. Software such as ArcIMS and ArcGIS will make this scenario a reality before the end of the decade.
Sometimes, all you need is a map—a geospatial information graphic. The ubiquitous example of using a map service is MapQuest. It is ridiculous for all but a few organizations to buy street data for the entire country and build a geocoding and routing application so that customers can get directions to their stores. It makes much more sense to contract with MapQuest to provide this service. MapQuest, however, only provides a few basic map services. You have limited ability to add your own data to the map, and you can't drill down into the underlying attribute data behind it.
Geocoding is the ability to determine a geographic coordinate for a street address (reverse geocoding finds the street address of a geographic coordinate). You may need to geocode addresses to get the locations of customers into a mapping application for further analysis. Most geocoding software will get the address right at least 80% of the time. If you want to do better than that, but not invest in a geocoding system yourself, services exist to handle this, such as Sagent's CentrusOnline.
While I know of no common online services providing analyitics, the complete vision of distributed services must include this type of functionality. An example is population growth forecasting. A regional planner could access population data from the US Census, economic projections from the US Bureau of Labor Statistics, and input these into a growth model from another source. You could perform numerous highly sophisticated analyses that simply couldn't get done in a typical business environment.
Many other application areas could have been discussed here, such as routing services that solve shortest path or "travelling salesman" problems. One could even imagine a service that could take a three-dimensional terrain model and provide lighting effects based on a specified time of day, and return an image. The possibilities are truly limitless in a world with powerful servers and fast Internet access.
An online service can take many forms. Most existing services are self-contained Web-based applications such as MapQuest (http://www.mapquest.com) for driving directions or TerraServer (http://terraserver.microsoft.com) for aerial photographs. Another, newer category of online services are application programming interfaces, or online APIs. The biggest difference between the two is that online APIs offer more flexibility, but do not provide a user interface for constructing a request or formatting a response. The intent of this paper is to promote sophisticated XML-based online services, but they can be understood best in the context of traditional Web "services." In this section, Web APIs are explained, from the early, simple APIs to the new models being proposed today.
There are three main components to any online API.
The World Wide Web is arguably the first online service API. There is a client—the Web browser, a server that understands requests and how to fulfill them—a Web server, and a communictions protocol—Hypertext Transfer Protocol (HTTP). The Web browser sends commands in a format the server understands to a Web server using the HTTP protocol (over TCP/IP of course). If you try to send a request to a Web server using vocabulary it doesn't understand, it will respond with an error. Also, if you try to send a request in Web "language" to an FTP or database server, you will not get a good response.
The vocabulary of a Web request is called a URL. This is the familiar http://www.amapco.com/file/called/index.html. This basically means, find the computer whose domain name is www.amapco.com and send this URL to the TCP/IP port 80 (if not port is specified in the URL, port 80 is implied by convention). A Web server should be listening for requests on this port, and when it gets the above request, it looks for a file named "index.html" in a directory named "called" which is in a directory named "file" which resides in the "root" of the Web server's public directory.
Since the Web's inception, there have been extensions to this simple model, but this is the basic model that has become commonplace.
A Web server responds to requests simply by sending the file back to the computer that requested it. The server should also send back a little snippet of information called the MIME header, which tells the client what type of file is coming back. It could be HTML text, plain text, XML text, a GIF image, a JPEG image, a Flash file, etc.
The Web, in general, requires that requests and responses are sent over the Internet using the HTTP protocol. While this doesn't seem worth mentioning, there were many architectural decisions made that now seem obvious. The most important feature of the HTTP protocol is that it is a stateless, one-time transaction, meaning that one request gets exactly one response. Nothing about the requesting client is known before or after the lifetime of the request. Programmers get around this limitation with cookies, Java applets, and other tricks, but these are all extensions, and usually unapproved extensions, to the formal World Wide Web specification.
That is the extent of the Web API. It is elegant in its simplicity, as we know many highly functional applications have been built on the Web. Its simple hyperlinking scheme for embedding URLs from multiple Web servers makes it an example of content integration from multiple sources, and it has been able to support orders of magnitude more users than it was intended to.
The simple Web case just described only allows static content—usually HTML text and images—to be requested. People also wanted a way to build customized content based on the user's input. This led to the CGI (Common Gateway Interface) interface to Web services, which is a standardized way to send initialization parameters to any program running on your Web server. You may know these services, commonly called CGI engines, better by their company or implementation-specific names, such as Microsoft ASP pages, Java servlet engines, or Allaire ColdFusion. Now with CGI, Web pages are more like true user interfaces to powerful, customizable, distributed programming resources.
The OpenGIS Consortium (OGC) has published a standard vocabulary for basic Web mapping services that is based on CGI. It is called the Web Map Service Implementation Specification (WMS).
The CGI request is still a URL, but at some part in the URL, there is a question mark, and everything after the question mark is a list of key/value pairs. In this example, mapserver.cgi is the name of an application to run on the server that knows how to respond to WMS requests. The WMS specification is basically a document that describes what keys and values may be in a WMS request—the vocabulary, and what the server's response should be.
http://www.amapco.com/mapserver.cgi?VERSION=1.1.0&REQUEST=GetMap&SRS=EPSG%3A4326&BBOX=-97.105,24.913,78.794,36.358&WIDTH=560&HEIGHT=350&LAYERS=BUILTUPA_1M,COASTL_1M,POLBNDL_1M&STYLES=0XFF8080,0X101040,BLACK&FORMAT=image/png&BGCOLOR=0xFFFFFF&TRANSPARENT=TRUE&EXCEPTIONS=application/vnd.ogc.se_inimage
If everything goes well on the server end, a WMS should return a map image.
Figure 1: from the Web Map Service Implementation Specification version 1.1.0
There are many special cases that must be handled, making the official WMS specification document a bit complex, but at its most basic level, the application developer only needs to know how to populate the correct values for five or six map definition parameters.
Populating the correct values for a WMS request requires knowledge of the geospatial data stored on the server. Prior to any map requests, the server must tell the client a few things, such as what data layers are available, what area of the world the data covers, and what image formats maps can be returned in. The API for accomplishing this task is also a part of the WMS specification.
The request is still a simple URL that has two required key/value pairs—request=GetCapabilities&service=WMS. The response is an XML document containing lots of useful information about what the server can do. The people writing the WMS specification realized that the end user of these Capabilities documents would be a computer, not a person. All OGC specifications are programming language and operating system neutral, so the most appropriate language for platform neutral computer-to-computer communication is XML. A sample capabilities document is shown in Appendix A. The typical scenario is that an application consumes capabilities documents and uses them to construct GUI-based applications. For example, Syncline has built a WMS viewer that puts this "face" on a capabilities document.
Figure 2: Java GUI for WMS Capabilities
Syncline's initial entry into geospatial services is the MapCiti platform. MapCiti.com is a Web site that lets a user upload their own data into the system, assemble data sets into maps using various cartographic tools, and optionally restrict access to these maps to a limitied audience. Access to the maps and the underlying data can take any one of the many forms of online services that have been described in this paper.
Figure 3: MapCiti map access paradigms
Currently the most common way to view maps and query data is through the MapCiti Java applet, which provides functionality similar to Esri's ArcExplorer desktop program, but runs in a Web browser. Panning, zooming, querying and more can be quickly and easily performed by the user.
Many of our clients would prefer to have their constituents or customers access MapCiti functionality from within the context of their own Web site, so Syncline developed a simple URL-based API for launching the MapCiti applet from an external Web site.
Access to Esri's Geography Network is another service offered by MapCiti. While participating in the Geography Network only requires that your server "speak" Esri's ArcXML vocabulary—not be based on an Esri software product—Syncline's ability to easily integrate with the Geography Network is based on the fact that MapCiti's map rendering engine was built around ArcIMS. MapCiti applet to MapCiti server communication is in a vocabulary unique to our service, but more generic requests can be made directly to the underlying ArcIMS engine in its native vocabulary, ArcXML. Our customers have the ability to decide whether their maps will be available through this interface.
A MapCiti customer may not want to direct interested parties to the full mapping and querying interface of the MapCiti client to do all tasks. A town might want to build a simple Web page on their site where a resident could type in their address and immediately see a map of their property. Or the assessing department might want a link on their internal Web site where they could click for a quick listing of all properties sold in the past thirty days. This functionality can be realized through an HTML API.
On the back end, a service provider like Syncline develops a set of helper applications that respond to HTML requests for small bits of information. They then publish the commands that the server will accept. Customers then create forms in Web pages that take advantage of the API to build custom functionality. The MapCiti HTML API will likely be based on the OGC WMS API described earlier, so that our services can integrate well with services from other organizations that Syncline, or our customers might subscribe to.
The advantage of an HTML API is that it is simple and easy to implement for Web page designers. The disadvantage is that it only works for Web pages. Creating an XML API allows the service to be integrated into other applications—on a Web page, another server, or even a desktop application. It also facilitates the integration of services from more than one service provider. Developers can build applications in any language that reads text and communicates over the Internet, such as Java, C, Perl, etc.
The real power of an XML API for geospatial services will be to introduce GIS to non-traditional markets, where there is a wealth of programming talent, but little reason to invest in full-fledged GIS installations. Syncline is using the MapCiti technology platform to build this type of service for a number of industries. We envision them using geospatial intelligence to study consumer trends, sales territories, store siting issues and things we have yet to think about. The applications that get built could leverage a local corporate database, supply chain or customer relationship management software, and other services to build a custom application suite.
The technologies and business processes that support full integration and deployment of distributed XML services are just reaching a level of maturity, so widespread adoption may be one or two years in the future, but all of the leading global software providers have announced application development architectures around the concept that the lines between individual software packages and the Internet are constantly blurring. While each company's vision of how online services should be developed and what they should do is highly correlated with what that company already does well, they all rely on XML and XML-related technologies in their architecture, so they all feel that XML will be the lingua franca of online services. To differing extents, Esri, IBM, Microsoft, Oracle, the OpenGIS Consortium, and Sun envision a world where the application on your computer screen (or your phone, PDA, radio, refridgerator, etc.) is really a window into functionality and data that resides on decentralized servers and is delivered to you as needed over the Internet.
This new framework is an opportunity for us in the GIS industry to bring powerful geospatial tools to non-traditional markets. But to participate in this framework, we must fully adopt XML and related technologies like SOAP and UDDI. Our industry has talked about data sharing, discovery and exchange for years, but we haven't even been able to create a search engine, like Altavista, where you can count on finding all available sources of geospatial information. I believe this is one of those points in time where GIS has the opportunity to become a common component of business analytics by implementing the XML-based distributed services architecture described here.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!DOCTYPE WMT_MS_Capabilities SYSTEM "http://www.digitalearth.gov/wmt/xml/capabilities_1_0_7.dtd" [
<!ELEMENT VendorSpecificCapabilities EMPTY>
]>
<WMT_MS_Capabilities version="1.0.7" updateSequence="20010620">
<!-- Service Metadata -->
<Service>
<!-- The WMT-defined name for this type of service -->
<Name>GetMap</Name>
<!-- Human-readable title for pick lists -->
<Title>The GLOBE Program Visualization Server</Title>
<!-- Narrative description providing additional information -->
<Abstract>Web Map Server maintained for The GLOBE Program by Digital Earth and GLOBE Visualizations
at NASA Goddard Space Flight Center. Contents include GLOBE student data and
environmental data from NOAA, NASA and other sources. Contact: webmaster@www.digitalearth.gov.</Abstract>
<KeywordList>
<Keyword>environment</Keyword>
<Keyword>weather</Keyword>
<Keyword>education</Keyword>
<Keyword>science</Keyword>
</KeywordList>
<!-- Top-level address of service or service provider. See also onlineResource attributes of <dcpType> children.
-->
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://www.globe.gov/"/>
<!-- Fees or access constraints imposed. -->
<Fees>none</Fees>
<AccessConstraints>none</AccessConstraints>
</Service>
<Capability>
<Request>
<Map>
<Format>
<GIF/>
</Format>
<DCPType>
<HTTP>
<Get>
<OnlineResource xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:href="http://globe.digitalearth.gov/viz-bin/wmt.cgi"/>
</Get>
</HTTP>
</DCPType>
</Map>
<Capabilities>
<Format>
<WMS_XML/>
</Format>
<DCPType>
<HTTP>
<Get>
<OnlineResource xmlns:xlink=http://www.w3.org/1999/xlink
xlink:href="http://globe.digitalearth.gov/viz-bin/wmt.cgi"/>
</Get>
</HTTP>
</DCPType>
</Capabilities>
</Request>
<Exception>
<Format>
<WMS_XML/>
<INIMAGE/>
</Format>
</Exception>
<Layer>
<Title>The GLOBE Program Visualization Server</Title>
<SRS>EPSG:4326</SRS>
<LatLonBoundingBox minx="-180" miny="-90" maxx="180" maxy="90"/>
<Dimension name="time" units="ISO8601"/>
<Layer>
<Title>Context Layers</Title>
<Layer queryable="0">
<Name>COASTLINES</Name>
<Title>Coastlines</Title>
<Abstract>Context layer: Coastlines</Abstract>
<Style>
<Name>default</Name>
<Title>Default</Title>
<LegendURL format="GIF" width="180"
height="50">http://globe.digitalearth.gov/globe/en/icons/colorbars/COASTLINES.gif</LegendURL>
</Style>
</Layer>
<Layer queryable="0">
<Name>NATIONAL</Name>
<Title>National Boundaries</Title>
<Abstract>Context layer: National Boundaries</Abstract>
<Style>
<Name>default</Name>
<Title>Default</Title>
<LegendURL format="GIF" width="180"
height="50">http://globe.digitalearth.gov/globe/en/icons/colorbars/NATIONAL.gif</LegendURL>
</Style>
</Layer>
<Layer queryable="0">
<Name>STATE</Name>
<Title>State/Provincial Boundaries</Title>
<Abstract>Context layer: State/Provincial Boundaries</Abstract>
<Style>
<Name>default</Name>
<Title>Default</Title>
<LegendURL format="GIF" width="180"
height="50">http://globe.digitalearth.gov/globe/en/icons/colorbars/STATE.gif</LegendURL>
</Style>
</Layer>
<Layer queryable="0">
<Name>RIVERS</Name>
<Title>Rivers</Title>
<Abstract>Context layer: Rivers</Abstract>
<Style>
<Name>default</Name>
<Title>Default</Title>
<LegendURL format="GIF" width="180"
height="50">http://globe.digitalearth.gov/globe/en/icons/colorbars/RIVERS.gif</LegendURL>
</Style>
</Layer>
<Layer queryable="0">
<Name>RAILS</Name>
<Title>Railroads</Title>
<Abstract>Context layer: Railroads</Abstract>
<Style>
<Name>default</Name>
<Title>Default</Title>
<LegendURL format="GIF" width="180"
height="50">http://globe.digitalearth.gov/globe/en/icons/colorbars/RAILS.gif</LegendURL>
</Style>
</Layer>
<Layer queryable="0">
<Name>CITY_NAMES</Name>
<Title>City Names</Title>
<Abstract>Context layer: City Names</Abstract>
<Style>
<Name>default</Name>
<Title>Default</Title>
<LegendURL format="GIF" width="180"
height="50">http://globe.digitalearth.gov/globe/en/icons/colorbars/CITY_NAMES.gif</LegendURL>
</Style>
</Layer>
<Layer queryable="0">
<Name>WMT_GRATICULE</Name>
<Title>Alignment Test Grid</Title>
<Abstract>Context layer: The WMT Graticule is a 10x10 degree grid for testing alignment.
At smaller scales, grid
spacing is 1x1 degree.</Abstract>
<Style>
<Name>default</Name>
<Title>Default</Title>
<LegendURL format="GIF" width="180"
height="50">http://globe.digitalearth.gov/globe/en/icons/colorbars/WMT_GRATICULE.gif</LegendURL>
</Style>
</Layer>
<Layer queryable="0">
<Name>OTHER_BOUNDARIES</Name>
<Title>County/Other Boundaries</Title>
<Abstract>Context layer: County/Other Boundaries</Abstract>
<Style>
<Name>default</Name>
<Title>Default</Title>
<LegendURL format="GIF" width="180"
height="50">http://globe.digitalearth.gov/globe/en/icons/colorbars/OTHER_BOUNDARIES.gif</LegendURL>
</Style>
</Layer>
<Layer queryable="0">
<Name>ROADS</Name>
<Title>Roads</Title>
<Abstract>Context layer: Roads</Abstract>
<Style>
<Name>default</Name>
<Title>Default</Title>
<LegendURL format="GIF" width="180"
height="50">http://globe.digitalearth.gov/globe/en/icons/colorbars/ROADS.gif</LegendURL>
</Style>
</Layer>
<Layer queryable="0">
<Name>WATERSHEDS</Name>
<Title>Watershed Boundaries</Title>
<Abstract>Context layer: Watershed Boundaries</Abstract>
<Style>
<Name>default</Name>
<Title>Default</Title>
<LegendURL format="GIF" width="180"
height="50">http://globe.digitalearth.gov/globe/en/icons/colorbars/WATERSHEDS.gif</LegendURL>
</Style>
</Layer>
<Layer queryable="0">
<Name>URBAN_AREAS</Name>
<Title>Outline of urban areas</Title>
<Abstract>Context layer: Outline of urban areas</Abstract>
<Style>
<Name>default</Name>
<Title>Default</Title>
<LegendURL format="GIF" width="180"
height="50">http://globe.digitalearth.gov/globe/en/icons/colorbars/URBAN_AREAS.gif</LegendURL>
</Style>
</Layer>
</Layer>
</Capability>
</WMT_MS_Capabilities
Holland, Roberta, "Services battle to heat up," eWEEK, http://www.zdnet.com/eweek/stories/general/0,11011,2767986,00.html, June 4, 2001.
IBM Corporation, "developerWorks: Web services: The Web services (r)evolution," http://www-106.ibm.com/developerworks/webservices/library/ws-peer1.html?dwzone=ws.
Microsoft Corporation, "Microsoft .net," http://www.microsoft.com/net.
The OpenGIS Consortium, "Web Map Service Implementation Specification," http://www.opengis.org.
Oracle Corporation, "Online Services," http://www.oracle.com/online_services/index.html?content.html.
Sun Microsystems, "Sun Open Net Environment (SUN ONE)," http://www.sun.com/software/sunone.
World Wide Web Consortium, "Extensible Markup Language," http://www.w3c.org/xml.
World Wide Web Consortium, "HyperText Markup Language Home Page," http://www.w3c.org/MarkUp/.
Raj R. Singh
CTO
Syncline.com, Inc.
373 Washington
Street
Boston, MA 02108
Phone: +1 (617) 986-1000
Fax: +1 (617) 986-1001
rs@syncline.com