A Web Services Solution for Work Management Operations
Continued...

An Implementation Application

Septic system failures are significant problems in fast-growing rural areas. Most septic systems are more than 30 years old, more than 25 percent are experiencing some sort of failure, and 10 percent overflow on an annual basis.

Current methods are inadequate for mapping and managing resources as well as tracking problems and planning appropriate and effective solutions. New technologies must be identified and solutions implemented to provide information and work management solutions that address the existing problems. Wastewater services are primarily maintenance, inspection, and emergency response operations.

Field inspectors use paper-based maps and work orders for locating housing facilities (parcels) and sewer features (such as sewer lines, manholes, meters, pumping stations) and executing tasks in the field. Completed paper work orders are finally updated to a spreadsheet or a database through manual data entry. Current approaches are inefficient and not cost effective for achieving wastewater work management objectives. Paper-based data collection methods introduce data inconsistency and delays in work order execution caused by manual data entry methods. Changes to spatial data in the field are difficult to incorporate into paper maps.

User Requirements

The application framework should provide the infrastructure and tools to execute wastewater work management operations efficiently in the office and field. Supervisors should be able to retrieve vector and raster data layers for a specified spatial extent from a remote spatial database and view and query parcels and sewer features for a complaint area. Supervisors should also be able to issue work orders by creating task descriptions that contain the date for completion, the inspector's name, and supporting vector data layers.

Field inspectors should be able to query and download work orders and execute tasks in the field remotely using the Internet or desktop synchronization.

Work Flow

The work flow for a typical call starts with an incoming complaint such as a sewer backup. The supervisor creates a work order. Each work order contains the task description, creation and completion dates, the inspector's name, and the supporting vector and raster datasets required. The field inspector downloads the work order and executes the tasks in the field. Completed work orders are updated and closed.

The work flow includes

• Step 1—A supervisor at an office desktop receives a complaint. Based on the complaint address, the complaint parcel is located.
• Step 2—The image and vector data showing manholes and the sewer main in proximity to the parcel is extracted by sending a request to Image and Feature data services. The desktop application or manager extracts the data returned and displays it to the field inspector.
• Step 3—Suspected wastewater lines are redlined, and the tasks to be executed are provided.
• Step 4—Task information and redlined features, along with the current extent of the map, are saved to a work order in the database.
• Step 5—The field inspector uses a mobile application to retrieve the work order from the database.
• Step 6—The field inspector views and edits the information pertaining to the assigned work order in the field and updates the database with the completed work order.

Implementation

The primary components in the software architecture are spatial services, spatial database, work manager, and mobile application.

Spatial Services

Spatial services are a set of reusable components developed to execute work management operations. The services are implemented for both Java and .NET platforms. Java services interface with desktop applications, and .NET services interface with the mobile interfaces. Two primary services usable by any application are feature and image services. A feature service provides GML-encoded dataset information for a specific vector layer. Subsetting is possible by providing spatial extents. An image service provides image data to user applications.

Spatial Database

The spatial database is the central repository for geographic information. The database stores vector layers as tables. In this example, the PostgreSQL database was configured with PostGIS, an extension package that spatially enables PostgreSQL, to store spatial data types such as shapefiles and ArcInfo files. [PostgreSQL is a SQL-compliant, open-source, object-oriented relational database management system.]

Work Manager

The work manager is a desktop GIS application developed to provide services to supervisors or managers, allowing them to view, create, and edit work orders on a daily basis. The work manager uses Java Web services to access spatial datasets and create and track work orders. The work manager communicates with Java services using an XML-based SOAP protocol. For example, a user request for a vector layer or dataset is executed against the database by a Java service, and GML-encoded vector dataset information is delivered.

The work manager creates shapefiles on the fly to visualize GML-encoded vector datasets. Java Web services also provide integration of image data into the work manager along with vector datasets. Image datasets are published through an ArcIMS image server.

Figure 3: The work manager interaction with feature and image data services

Figure 3 shows the work manager interaction with feature and image data services. Typically, a work manager sends a SOAP request to a Java Web service to retrieve vector and raster data within a selected spatial extent. The Java Web service communicates with the database for vector data and ArcIMS for image data. The Java Web service returns vector data in GML and a raster image to the desktop application. The desktop application converts GML to shapefiles and overlays the image extracted from an ArcIMS image server. The work manager has been implemented in MapObjects—Java Edition.

Mobile Application

The mobile GIS application provides field users with maps to view and query for geographic information. Custom-built forms have been developed to view and edit work order related information in the field. The mobile application utilizes .NET services to download and upload work orders and support the datasets (i.e., maps) used to execute tasks in the field.

The mobile application communicates with .NET services using XML-based SOAP protocol. A SOAP request for work order information is processed by a .NET service, and a work order is delivered. Each work order will contain XML-encoded information relating to its creation date, tasks to execute, task priority, and support datasets. The mobile application creates shapefiles from XML-encoded information on the fly. The mobile application was developed in ArcPad.

Conclusion

Through a Web services framework, GIS applications can exchange geographic information transparently, which results in easy data integration. Since the data exchanged between applications is GML encoded, it is portable across multiple applications operating on different platforms. Data and business operations modeled through GML schema documents provide intelligence (i.e., semantics) to user applications for interpretation, validation of data exchanged, and reusability. Limitations, such as cost of data conversion from XML to other formats usable by applications, still exist. With the increasing number of applications accessing spatial data services, interfaces to service providers and users need to agree on standard message structures and the content of data exchange for interoperation. Utilizing an asynchronous messaging model for exchanging data between applications will provide improved scalability and throughput while reducing latency.

References

Spatial Data Standards and GIS Interoperability White Paper, Esri, January 2003.

Rosen, Mike, and Jim Boak, "Developing a Web Services Strategy," eAI Journal, January 2002, pp. 39-43. (Also online at www.bijonline.com/PDF/Rosen.pdf.)

Acknowledgment

This article was developed under Assistance Agreement No. X828421010 awarded to Mississippi State University by the U.S. Environmental Protection Agency to fund projects for the Small Drinking Water Systems Regional Technical Assistance Center.

About the Authors

Venu Kanaparthy works as an applications programmer on the Professional Services team at Esri. He holds a master's degree in computer engineering from Mississippi State University, Starkville. He can be reached at vkanaparthy@esri.com.

Dr. Charles "Chuck" O'Hara works at the GeoResources Institute at Mississippi State University (MSU). He has directed numerous projects that have focused on diverse applications of spatial technologies that include spatial decision support, geospatial information management, algorithms for spatial data analysis and processing, and generating quality metrics and performance benchmarks for analysis of spatial data products. O'Hara holds a doctorate from the University of Mississippi in engineering science with a focus on geological and environmental engineering. He joined the faculty at MSU after working with the United States Geological Survey for 10 years as a project manager, GIS specialist, and hydrologist. He can be contacted at cgohara@erc.msstate.edu.