GIS services module giving the event type, the time of the event, and the location of the event. This module matches the location information in the request to agen- cies registered in the corresponding area to determine which agencies should be receiving this information. When matching requests to registrants, the GIS module must accurately translate and transform the location information of the request to locations on file. Since many agencies use different GIS systems, the EPAD GIS services module must be able to accurately “translate” the location information it receives so that the proper agencies are notified.
Figure 7 shows how a Web services query is satisfied using the EPAD architecture.
A first responder sends a message containing a location in Well Known Text to the EPAD. The EPAD parses the message and generates a spatial SQL query to send to the database. The EPAD system adds a buffer to the query to handle horizontal error in the TIGER boundary data as well as error (in as far as it can be determined) in the incoming message. The query is then run against all data layers simultane- ously, and returns matching agencies that desire notification. This list is passed to a messaging system10 that sends out alerts according to the agencies’ instructions received from the EPAD (COMCARE, October, 2004).
horizontal accuracy.11 When messages containing spatial coordinates are passed to the EPAD’s Web services interface, the coordinates are used in a spatial query against the EPAD database. Because of known horizontal error in the TIGER data and because of much less predictable error in the incoming coordinate data, there is a chance that all of the desired agencies will not be returned by the EPAD system without the addition of an error factor. This factor makes the spatial object of the incoming message larger before passing it to the EPAD.
The key question is how much larger to make the spatial query to achieve the desired result of returning all appropriate agencies all of the time. The GIS term for mak- ing the spatial object larger is “buffering.” If the buffer added to the object is too small, the system risks not returning an agency that should have been returned and subsequently notified. Obviously, depending on the type of event, a missed agency notification could have serious consequences. If the buffer is too large, a large number of agencies nowhere near the incident are returned. For the EPAD, it is probably more important to capture all agencies registered for notification in a larger area and take a chance that extra agencies are notified rather than miss an agency.
Nevertheless, a reasonable estimate of the maximum horizontal error for both the TIGER and incoming coordinates must be developed. The National Map Accuracy Standard (NMAS) developed by the United States Geological Survey may be used as a starting point to define horizontal error for the two sources (TIGER and the location information in the request). NMAS defines maximum acceptable horizontal error for datasets at various scales such that 90% of well-defined points fall within the acceptable error level for data of a given accuracy level. The challenge is to ar- rive at a buffer value that delivers the correct set of agencies (from a spatial query perspective) close to 100% of the time.
According to the U.S. Census Bureau, TIGER, which was developed by hand digi- tizing 1:100,000 scale paper survey sheets, generally meets national map accuracy standards for 1:100,000 scale data. This means that 90% of well-defined points should fall within 166.7 feet of the feature they are describing. If one were to use 166.7 feet as a buffer, 10% of the time one could expect a spatial query to miss one or more agencies. In a study that compared global positioning system (GPS) gathered point locations corresponding to features in TIGER such as road intersections, the displacement between the original map and the GPS-enhanced road positions was often as large as 210 feet (Liadis, 2000). Clearly the buffer distance for TIGER will need to be greater than 166.7 feet.
More problematic is the coordinate information that comes to the EPAD as part of Web service queries. By requiring additional information in the Web service mes- sage, it may be possible to develop a rule-based approach to improving accuracy.
For example, information in the message for “technique used to derive coordinates”
could be used to estimate the size of the buffer to be applied. If data describing the accuracy of the coordinate being sent can be included in the Web services message,
it would be possible to develop custom buffers on-the-fly based on the accuracy defined in the message.
Assuming the NMAS standard represents one standard deviation, it is also possible to calculate buffers to fit any desired confidence level. If the accuracy of the incom- ing coordinates is unknown, this approach can be applied to incoming coordinate values. The two error levels expressed in feet may then be added together to obtain a total buffer distance to apply. This would result in a one-size-fits-all approach for handling the total expected horizontal error. Both buffer calculation techniques are planned for the EPAD.
Another type of error inherent in TIGER data is attribute error. Attribute error results when a polygon does not have the correct descriptive database information linked to it. In the case of this project, key attribute fields are federal information processing standards (FIPS) codes and name information. For the EPAD, attribute error is estimated using a sampling approach, which randomly selects records, then compares the results to some known source for boundary information.
EPAD. Next. Generation
While the system design and components identified here are adequate for current EPAD processing, changes will need to be made as the EPAD is extended for in- formation sharing during international emergency events. Immediate consideration needs to be given for the inclusion of boundary data for Mexico and Canada so that incidents traversing borders can be handled in the same manner as any other incidents. Boundary data sources for both countries need to be identified. While census organizations exist in Mexico and Canada, it is not known exactly how the data provided by those organizations compare to the U.S. Census TIGER dataset.
Some questions that need to be considered when incorporating data from Mexico and Canada include the spatial accuracy of each country’s census data, their use of FIPS or equivalent codes, the data formats used, licensing restrictions, and each country’s update cycles.
Political boundary data for both Canada and Mexico are currently available in some form, and data samples appear to match the United States fairly closely in terms of jurisdiction hierarchy. While the spatial fit appears close when viewing all of North America, there are gaps and overlaps between country datasets. A brief examination of the border data match up between the U.S. and Mexico found gaps as large as 5 kilometers between country border lines, as well as large areas of overlap. An examina- tion of the match between the U.S. and Canada found significant gaps and overlaps, although not quite as large as those found between the U.S. and Mexico.
In most cases, it will not be possible to determine which country’s boundary is correct for a given location along a boundary line. A relatively simple rectification process would involve choosing one boundary and correcting the other boundary to match the first. In order to determine the best approach for addressing border error between the U.S., Mexico, and Canada, careful consideration will be given to the ways in which the EPAD will be used for border-related events and the con- sequences of incorrect results being returned by queries. This consideration will include an assessment of the legal consequences of incorrect queries. (Of course, an understanding of the legal repercussions relating to incorrect query results is important to consider in relation to all areas of the EPAD system.)
Another consideration for the project will be deciding the best way to provide a basemap service. The first option, currently in use, is to purchase an existing basemap service such as TopoZone. The second option is to build a basemap service in-house.
The two approaches have their advantages and disadvantages in different areas.
A commercial solution provides access to commercially-provided databases that are more complete than TIGER in terms of road coverage for fast developing areas of the country. However, TopoZone, the product offering selected for the EPAD, does not provide basemapping services for Mexico or Canada. In addition, a remote service such as TopoZone is accessed across the Internet and therefore could affect system performance as Internet traffic patterns vary.
By building an in-house basemap service, a reasonably consistent basemap across the U.S., Mexico, and Canada can be created by using a combination of data sources.
Also, an in-house service will, assuming loads are well balanced, provide much faster response times than an Internet-based service. It will also give more control when it comes to system stability and scalability issues. Unless another commercial product offering can provide the same benefits, it is likely that a custom-developed basemap service will be deployed.