Abstract: The challenges of getting geographic maps and information (the Elephant) to thousands of users across the Internet (the Straw) were highlighted in a three year international project for the government of Japan. This paper highlights the key issues in implementing the "Health Medical Welfare Information System" for the Ministry of Health and Welfare (MHW). This project brings desktop GIS to thousands of employees at all levels of government. Project requirements included support for many users, management of a large map base and use of inexpensive servers and browser-based delivery of applications. This paper discusses some of the unique approaches taken to meet these goals, including pre-processing of geographic information, a "Fat/Thin" client approach to network GIS and specialized information storage techniques. These approaches can be used in any system with a large map base, large user base and moderate hardware budget. This paper seeks to address issues of developing custom GIS software. The Japanese project is in its final stage and will be rolled out to employees of the Japanese government in the summer of 1999. It will eventually support a map base of the entire country at 1:2500 scale.

Project description

History

Japanese Ministry of Health and Welfare (MHW) defines their task as follows:

MHW contracted with Mitsubishi Electric Corporation (Tokyo, Japan) to implement the "Health Medical Welfare Information System" (direct translation). This system is a geographic information system (GIS) capable of providing non-experts access to detailed maps of Japan for geospatial analysis of MHW’s extensive databases. Mitsubishi partnered with Justec Corporation (Japan) and TechnoCare Corporation (Japan) to provide consulting and technology. Soft Reality, Inc. (Austin, Texas) was included in the project as a member of a consortium of companies called TechnoGroup that includes TechnoCare Corporation. The effort included completing digital maps of Japan to 1:25,000 scale, and beginning development of a 1:2500 scale basemap. These basemaps included political boundaries, transportation, parcel outline, building footprint, hydrology, feature names and land use. We liken the large map base and associated data represent an Elephant - large and difficult to manage. We liken the Internet to a Straw - a relatively small pipe with a fixed volume of throughput.

Challenges

The original MHW specification called for a system to store, manage, edit and analyze their databases in a geospatial format. The challenges were in the data.

1. Large areas had to be analyzed simultaneously. This meant that the digital map files would be very large.
2. The Japanese basemaps were polygon intensive - tens of thousands of polygons per map. A high performance display engine would be needed to prevent these maps from being unusable.
3. Storage for the large maps needed to be highly optimized, but must also be quickly addressable for display and query.
4. Tabular information (demographics, health statistics, facilities, etc.) had to be overlaid for large areas of the country.

International Agreements

The agreements between Justec, TechnoCare and Soft Reality had been constructed to align the goals of each party. In essence, every party was given a long-term benefit. For example, Soft Reality was given rights to modify, sell and market the technology it developed outside of Japan. This incentivized them to create a strong, technology foundation and to innovate. Innovation was further spurred with the agreements in that the Japanese partner companies would have access to any innovations that Soft Reality created for markets outside of Japan. Thus Justec and TechnoCare were incentivized to give Soft Reality some freedom to innovate.

This style of business bore fruit in 1996. Soft Reality quickly realized during MadHatter 1.0 development that the optimizations it was making to transfer MHW’s mapping information between the hard drive and memory would also work well when transferring information across a network. Soft Reality and TechnoCare presented a prototype Internet mapping technology to Justec. They realized that the technology could meet MHW’s requirements for an online system. This significantly changed the direction of the partnerships. It is interesting the goals of the group were aligned sufficiently that the entire team could change direction very quickly - from developing a geographic management system to creating a distributed GIS system.

Specification Challenges

Project MadX was initiated after completion of MadHatter. It included enhancements to the MadHatter graphics engine, completion of Internet map server software (MadServer) and implementation of a client component (MadX) that was installed on the client system and integrated the graphics engine. These components, working together, had to meet the following specifications:

1. The Japanese basemaps would be presented to the user as a single seamless multi-theme map.
2. Applications would be hosted by a Netscape web browser (MHW standard)
3. The MadX API would allow Japanese developers to create the applications and interfaces. This meant that the programmer interfaces and object models must be simple and easy-to-use.
4. The MadX component must be robust enough to support advanced geospatial analysis. This includes integration with tabular databases, spatial queries, user picking and edit/update capabilities.
5. The minimum system requirements would be low - Pentium class systems with 32Mbytes of RAM.
6. The system must service approximately 7000 employees. This meant that 32 simultaneous accesses must be supported continuously.
7. The system must run on inexpensive server hardware. A single Windows NT system running Microsoft Internet Information Server and a Sybase SQL relational database was specified.

The requirement of providing large detailed maps to thousands of users from a single web server drove most of the innovations for MadX. Many of the pieces had been put in place in the MadHatter development effort.

"Fat/Thin" Client - In order to support thousands of users, MadX had to move all of the processing to the client systems. The MadX client component is a Component Object Model (COM) component. COM allows MadX to make extensive use client system resources. Data received from the network is cached on the hard drive. Memory and CPU are used to render and display the maps. The geospatial analysis applications are implemented as client components. This minimizes the server resources required. For example, the MadX component maintains its own database of server-based map filenames and the coordinates of their coverages. This allows MadX to use the client CPU query for the names of the files it needs to satisfy a view, and sends this information the server.This is called a Fat/Thin client architecture. Traditionally, the "Thin Client" approach implies a client system with scarce resources. The Fat/Thin client approach will operate with a resource-scarce client, but is able to take advantage of resource rich clients as well. This is also called a self-scaling client architecture.

Pre-Processing of Data - To decrease the strain on the server, all data is stored in a special, pre-processed data format called Internet Graphics Data (IGD) format. The IGD file format is, in essence, a "Quad Tree" structure on disk. All objects - points, lines, polygons, text and symbols - have been sorted and grouped together. These groups are stored in indexed sections in an IGD file. Any one object in a large map can be found and retrieved quickly based on its coordinates. Furthermore, any one section can be quickly retrieved based on its coordinates. IGD files store objects in the smallest footprint possible without loss of information.

When the MadServer receives a request from a user for information, it does not need to do anymore than open the file, extract the sections required and compress and transmit the raw data.

This approach works will for MHW, since they had already standardized on the IGD file format for all of their map data.

Project status

The early phases of this multi-year effort have been complete. MHW has largely completed the 1:25,000 scale digital basemap and has 1:2500 scale maps of most major population centers. The data is being stored in a database designed by Soft Reality. They are in the final months of testing of an internal prototype. By end of this summer, the tools developed by Justec will be rolled out on the government’s networks.

In 1998 MadX 2.0 was released. It provided support for large raster images, CD-ROM distribution and optimized speed.

MadX is currently marketed worldwide by Soft Reality under the trade name EarthKey™.

MadX version 3.0 is being completed and work will resume in the summer of 1999. Modifications will include simultaneous access to multiple map servers, spatial directory services and offline operation.

Lessons learned

Considerations for Developing Full Custom Solutions

The success of any distributed system is only successful if the users accept and use it. Developing a custom system provides an organization with the most flexibility to deliver the right solution. However, this implies that an organization has a strong understanding of what the users need and want, has an infrastructure in place to manage complex projects and has a greater budget/schedule flexibility (implying a significant payoff). The following issues drove the decision to use a custom solution:

1. The geospatial industry had no provided off-the-shelf solutions.
2. There was a significant and obvious return on investment and a mandate to implement the system.
3. The parties wanted long-term control of the technology roadmap.
4. Project partners were available that - beyond a doubt - had a background in solving similar problems.The project partners had a financial incentive to complete the project. The technology developed would be used to create new products for sale worldwide.
5. The partner companies had experience managing complex software projects.

1. Are there inflexible budget constraints?
2. Are there inflexible schedule constraints?

An International solution development partner can provide expertise not easily available domestically. There are also economies of cost, as some countries have significantly lower labor costs for technical development. International projects suffer from the basic problems of language barriers, currency fluctuations and cultural differences. The risks of a project finishing over budget and late are significantly enhanced with a development effort distributed internationally. The following items were critical to reducing risk:

1. Have a good multi-national interface for each interface between teams. TechnoCare played the critical role of interfacing between our Japanese partner companies and Soft Reality.
2. Compartmentalize technical components: Build components, not software. Create API’s where developers from one country must interface with developers from another country. Minimize interaction between international development teams. Programming languages are best method of communicating for programmers of different countries. Design a project to offer autonomy for each development team.
3. Strategic use of gray areas in the specification can provide the autonomy necessary for development teams.
4. Be ready to live up to your commitments.
5. Make sure agreements align all goals. This can pay big dividends long-term.
6. Use small implementation teams. This is a core of the Soft Reality philosophy.

The MadHatter and MadX development projects were quite successful considering the technical risks and risks introduced by a multi-national development effort. The agreements between the parties encouraged a level of innovation that had large positive effects. Furthermore, the parties involved retain opportunities for future successes. The products have the potential to lead the GIS industry in Japan for large-scale efforts.

The projects had some very difficult technical specifications to meet. In most systems, supporting many users and large map bases implied a significant server hardware investment. The MadX project met the goal of providing large map bases to thousands of users with inexpensive server hardware. The Fat/Thin client architecture allows for a high degree of user interactivity. The easy to use objects and APIs provide for quick development of easy-to-use applications.

The team continues to work together on future versions of the system for new customers. Version 3.0 of MadX will provide enhancements that expand the market for these products in Japan and elsewhere.
 

© Copyright 1999 Soft Reality, Inc. All rights reserved. http://www.softreality.com/