Home Articles Delivering spatial solutions on the web – An insight

Delivering spatial solutions on the web – An insight

Shourya Shukla
RMSI, A-7, Sector 16, NOIDA-201301
Tel: 91-118-4511102, Fax: 91-118-4511109
[email protected] 

Abstract:
The opportunities created by Web based Spatial applications are immense. The value and lower cost of ownership achieved by web based spatial technologies are universally accepted. However, apart from bandwidth constraints, stateless nature of web applications against stateful representations of traditional GIS applications offers some unique challenges for application developers.

Over the past few years, RMSI along with its strategic partners have aided several clients in web based Spatial solutions. With these experiences, RMSI has implemented various approaches using alternate technologies in achieving scalable web based designs.

The Onpoint suite of applications is a set of web based applications targeted at medium to large enterprises who need to share data in the intranet/ internet scenario. Using the Onpoint suite of applications as an example, the present paper highlights the functionality, design issues and the benefits that accrued from the development of these solutions.

The Internet
The Internet has truly revolutionized the way most organizations access information. A standardized set of protocols like TCP-IP, (Transmission Control Protocol – Internet Protocol), HTTP (HyperText Transfer Protocol), XML (eXtensible Markup Language) and a request-response architecture has allowed many organizations to share information among millions of users. E-Commerce and wider paradigms like E-business have ensured the transition of this universe of information from a research and a hacker’s haven to an entity which is a key to survival for most businesses globally.

Internet and GIS
Over the past few years, key GIS software vendors like ESRI, MapInfo Corp., Smallworld and Intergraph have released their software for making spatial data available over the net. The initial set of products from vendors has focussed on the process of publishing maps on the World wide web. However, true value is achieved when like its non-spatial counterpart, spatial data can become parts of an internet based solution architecture rather than a map publishing service.

A Stateless World
Unlike the underlying transmission protocol – TCP-IP, the Web networking protocol – HTTP is a stateless protocol. This means a webserver maintains no information about a request once the request has been processed. In a realistic scenario, two subsequent requests may come from different sources. In the case of a traditional GIS, all operations are performed on the already loaded spatial data. However, in a web based GIS scenario, this would imply that one user could ask for a map for India and the next one could ask the map for Japan. Extending this to a case of an enterprise or a large number of users on the internet, this can be a potential performance nightmare.

Case Study 1 – The ONPoint application
The ONPoint application is a thin-client, component-based, extensible web GIS application providing geo-processing capabilities that rival those of desktop GIS applications. In-spite of being a browser-based GIS application, it provides powerful spatial query, display, analysis and map printing functionality. The ONPoint application was developed jointly by RMSI and its strategic partner, Orion Technology Inc. of Canada for the various clients of Orion Technology Inc. Functionality Requirements
The ONPoint application was developed to serve the needs of a large number of enterprise users, who apart from sharing spatial data in a scalable yet cost-effective way, wanted the following features.

  1. Ability to see spatial data from multiple formats on the web.
  2. Ability to search and features based on the attribute database and locate them on the map.
  3. Ability to navigate through attribute data items and view them spatially on the map.
  4. Ability to Identify features on the client side map
  5. Ability to add geo-coded data.
  6. Ability to publish maps in Microsoft Word/ Adobe Acrobat PDF or HTML format
  7. Ability to customize the way a layer is rendered, etc.

Design Issues
The major design issues that had to be resolved to achieve optimum functionality were.

  1. Architecture to handle multiple simultaneous requests.
  2. Have adequate response times for each request.
  3. Minimize amount of information that is transferred over the web.
  4. Reduce the number of server trips.
  5. Maintain persistent information concerned with the user and a session.
  6. Eliminate data redundancy.
  7. Develop an intuitive user interface.
  8. Reduce dependence on single threaded components in the solutions without the danger of the data getting corrupted
  9. Allow individual users to customize the rendering of maps.

The Solution

  1. To solve the above problems the following approach was developed.
  2. To reduce the development time, the team used Industry standard GIS components from ESRI including map Objects Internet Map Server 2.0 (MO-IMS) and MapObjects 2.0.
  3. Internet Map server and multiple map server instances allowed multiple requests to be handled.
  4. To maintain the persistent data about a user and a session, the application development team developed a configuration database.
  5. Each user had his own copy of the data so that any user defined customization was stored.
  6. The entire server side architecture was split into web server components and application server components for better scalability
  7. The Client side mapping interactivity was achieved using a Java Applet that would maintain some session information on the client side, whereas the bulk of information was stored in the configuration database on the server end. This allowed small amount of information to be sent and faster response.
  8. The Client side querying and attribute search information was developed using Microsoft’s Active Server Pages (ASP) along with Server side ActiveX DLLs for free threaded operation.

Case Study 2 – A large Web based Farming Application
This project was for a large agricultural implement manufacturer in the US. In this yet to be launched web site the client wanted its customers (over a million farmers) to access their farm data over the web. 

Functionality Requirements

  1. Perform map navigation functions similar to the Onpoint application
  2. Apart from the spatial map data, which is passed to the end user as an image, a farmer can receive vector data denoting farm boundaries overlaid on top of the satellite imagery in the background. 
  3. The application was required to fetch a large amount of geo-referenced data, including satellite imagery (over 4 terabytes of information), prepare maps and stream it down to the user’s browser. 

Design Issues
The application demanded a scalability factor well beyond the Onpoint application. In summary, the design objectives were 

  1. Achieve all the design objectives of the Onpoint application and in addition
  2. Develop a client side vector-editing tool that would run within the browser and was independent of the browser.
  3. The vector data was stored in geographic projection and the imagery in UTM. To achieve the correct overlay of the vector data over the satellite imagery, on the fly projection conversions were required.
  4. Apart from the image data, allow vector data to be streamed over the web.
  5. Allow the user to send the modified vector data back for updating the database.
  6. Procedures for validating the data sent back by the user.
  7. Track sessions across multiple users to minimize data transfer over the web.
  8. A single request from the user could return over a million spatial entities. 
  9. The entities retrieved would require being thematically shaded for better end user visualization.

The Solution
The web based farming application offered some unique challenges to the application development team. The following steps outline the various facets of the solution.

  1. A refined configuration database model for handling a very large number of users was developed. The database was migrated to Oracle for faster retrieval and scalability.
  2. Spatial data was stored in ESRI’s Spatial Database Engine (SDE) for Oracle with multiple database connections for fast retrieval.
  3. The development team selected ESRI’s MapObjects 2.0 for creating the maps and handling on the fly projections.
  4. The architecture was developed to support multiple web servers and map servers to handle peak performance loads.
  5. Developed algorithms for various projection related tasks.
  6. The entire server side architecture was split into web server components and application server components for better scalability
  7. The Client side mapping interactivity was achieved using a Java Applet that would maintain the state on the client side as well as allow client side editing of vector data.
  8. The Client side Querying and attribute information was developed using Microsoft’s Active Server Pages (ASP) along with Server side ActiveX DLLs for free threaded operation. 
  9. Low level socket programming was done to stream the data back to the server.
  10. All data updates from a client were carried out in a transaction mode to allow rolling back in case if invalid spatial geometry.

Case Study 3 – Municipal Warehousing Application (Onpoint 2000)
The Municipal Data Warehousing Application was developed for a municipality in the US. The initial application was required to be scaled from a intranet application to an internet application. The client wanted its various planning officers in various divisions of the municipality to access data in real time. A very important aspect of this was the tight integration of this application with the existing data warehousing application. 

Functionality Requirements

  1. To integrate the spatial solution with the enterprise data-warehousing application of the municipality.
  2. The application had two distinct modules. The first module was a general property enquiry where in an enterprise user can form complex queries based on current, planned and historic data of the planning region.
  3. The query returned a map of the selected areas with tabular data around which further analysis can be done.Thematic maps could be prepared to further analyze the map displayed. The user could also view a wide array of documents like building plans, vector drawing files, etc. associated with the property.
  4. The second module called the Property Notification Module, allowed city-planning officials to spatially select a single or a set of properties as a subject. A buffer region generated around the subject properties identified the set of notification properties. The user could further generate custom notifications and generate mailing labels for these properties, thus automating a large part of the municipality’s day to day work.

Design Issues
Like the previously described applications, the municipal warehousing application offered some unique perspectives to the problem.

  1. Comparatively large amounts of attribute data were required to be sent from the server application to the client side browser. The data returned in a typical query response exceeded the maximum number of records of data that could be displayed on the client side thus necessitating multiple server trips to browse through the entire result set. 
  2. Preparing thematic symbols on the client side without the use of any ActiveX Controls or plug-ins to achieve cross-browser usability.

The Solution
The municipal warehousing application required certain added functionality.

  1. In consultation with the clients, the application development team developed a database model integrated with the remaining warehousing application to maintain persistent information.
  2. The existing thematic mapping functionality offered by third party components was not found to be scalable. A Thematic-mapping component was developed to prepare thematic maps across the large spatial and attribute databases in a reasonable time.
  3. EXtensible Markup language (XML) was used to transfer the large amount of data returned from the query to minimize the number of server trips.

Summary 
The three case study applications though seem pretty similar offered an increasing amount of interactivity with the system. The higher level of interactivity demanded more scalable and responsive architecture. To summarize

  1. A good and evolved database design is necessary for achieving scalability in system design
  2. New technologies like eXtensible Markup language (XML) offer better communication between clients and servers
  3. A distributed design on the server end improves response times and offer higher scalability.
  4. To achieve a good design all sub-components and tiers of an application should be optimized. Focussing on a particular tier alone does not make an application scalable.

Reference
Mishra,B. 1999, “Implementing Web technology for an enterprise”, Paper presented at MapIndia Conference 1999.