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
- Perform map navigation functions similar to the Onpoint application
- 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.
- 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
- Achieve all the design objectives of the Onpoint application and in addition
- Develop a client side vector-editing tool that would run within the browser and was independent of the browser.
- 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.
- Apart from the image data, allow vector data to be streamed over the web.
- Allow the user to send the modified vector data back for updating the database.
- Procedures for validating the data sent back by the user.
- Track sessions across multiple users to minimize data transfer over the web.
- A single request from the user could return over a million spatial entities.
- 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.
- 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.
- Spatial data was stored in ESRI's Spatial Database Engine (SDE) for Oracle with multiple database connections for fast retrieval.
- The development team selected ESRI's MapObjects 2.0 for creating the maps and handling on the fly projections.
- The architecture was developed to support multiple web servers and map servers to handle peak performance loads.
- Developed algorithms for various projection related tasks.
- The entire server side architecture was split into web server components and application server components for better scalability
- 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.
- 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.
- Low level socket programming was done to stream the data back to the server.
- 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
- To integrate the spatial solution with the enterprise data-warehousing application of the municipality.
- 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.
- 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.
- 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.
- 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.
- 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.
- In consultation with the clients, the application development team developed a database model integrated with the remaining warehousing application to maintain persistent information.
- 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.
- 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
- A good and evolved database design is necessary for achieving scalability in system design
- New technologies like eXtensible Markup language (XML) offer better communication between clients and servers
- A distributed design on the server end improves response times and offer higher scalability.
- 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