Location Tool Advisory Committee

September 2, 1998
CTRE Large Conference Room

Present: Pat Cain, John Nervig, Terry Dillinger, Peggi Knight, Mary Jensen, Rich Rothert, Joyce Emery, Jack Latterel, Tadd Geis (AMS), Reg Souleyrette (CTRE), Tim Strauss (CTRE), Michael Pawlovich (CTRE), Brad Estochen (CTRE)

Advisory Committee Membership

The project Advisory Committee will consist of Mary Jensen (Project Monitor), Peggi Knight, Joyce Emery, Richard Rothert, and John Nervig.

GIS-ALAS update (brief)

Michael Pawlovich is currently working on a translator to convert x,y locations to link-node (Task 3 of GIS-ALAS phase 2). The conversion will facilitate the use of data located via GPS and/or smart maps by Access ALAS, which currently relies on the link-node system. This enables the continued use of Access ALAS until such a time when it is modified for use without the link-node system. This task is scheduled to be completed by the end of September.

CTRE received low-resolution photos from UNI, in a different projection, preventing their immediate use in GIS ALAS (UNI is working to correct the problem). Early in the calendar year, the ALAS team received some information from the UNI team in the form of GIS shape files containing the locations of all the hospitals in the state as well as ambulance service districts for Black Hawk county.

Part of Phase 2 of the GIS-ALAS project is to assist the ISU’s Fire Institute’s pilot project to assess the impacts of Highway 218 corridor relocation and expansion into the "Avenue of the Saints." Brad Estochen developed a series of maps for the Iowa Fire Service Institute. In all, 60 maps were printed (15 for each of 4 counties) that displayed the fire service districts with the old and proposed alignments of highway 218 as it passes through Southeast Iowa.

The GIS-ALAS project team has a small contract to assist the Cedar Falls Department of Public Safety to integrate its data directly into GIS-ALAS. The project is intended largely as a technology transfer activity, to assist the department in managing and analyzing its own data. Work on this project will make use of, and be coordinated with, existing efforts on the location tool and MARS implementation.

The following items were written on the board for discussion:

• Advantage Safety, laptops in field with smart map à x, y, route
• Office-based location tool, driver and paper officer reports à x, y, route
• Translator: x, y, route à fnode, tnode, distance à x% Accuracy?
• Manual process to supplement x% Accuracy to y% Accuracy
• Population of crash records with infrastructure data from base records
• Transportation data Microstation MDL (Microstation Design Language)
• Node to x, y (MDL or CTRE method)

Two diagrams were handed out. The first, prepared by Dan Gieseman, outlined the initial design of the location tool from a programming perspective. The second, taken from the project proposal, depicted the flow of data from the crash location, through the police department’s local office and the DOT, to data analysis tools such as GIS-ALAS and Access-ALAS.

A wide-ranging discussion of the location tool ensued, incorporating the topics listed below.

The location tool’s interface should have the same look and feel as Advantage Safety to maximize the consistency of the entire product. AMS will perform the necessary modifications to give it this look and feel.

It is important to note that a pen, not a mouse, will be used in the field to specify location and input other data. This has implications for the design of the location tool (e.g., no right and left mouse clicks, likely less precision when compared with a mouse’s crosshairs).

The size of monitor in the vehicle should be considered. The map displayed by the location tool should use as much of the screen as possible.

The group discussed possible reference layers that would be used to assist officers and other crash locators identify locations. The following layers were identified: roads, hydrology (rivers, streams), milepost markers, bridges, railroad lines/crossings, ramps, and corporate limits. Several of these items (e.g., bridges, rail crossings) have reference nodes where they intersect with the roadway. A scale bar would also be useful for giving officers a feel for map distance when locating crashes and specifying distance from an intersection.

The location tool outlined in Dan’s diagram can be incorporated within MARS as a stand-alone item, e.g., a dll.

We need to identify a suitable process to update the information included with the location tool (e.g., the reference layers, especially the roads).

The computers in the police vehicles are not really "laptops." They are permanently installed in the vehicles. Updating the reference maps entails going out to each car (e.g., with a floppy disk or CD) or doing a wireless update. Ideally, we would update only those records that had changed, rather than re-installing entire databases. This may not be feasible, however, given current GIS database technology.

There is an interest in minimizing what happens on the "laptop," consistent with providing the data necessary to pinpoint a crash location. For integrating roadway data, the relevant fields (i.e., those in the base records and in the crash file) could be included on the laptop and checked by the officer and included in crash report, or only the segment ID could be recorded and the roadway fields added later. It would be useful to have a time stamp, i.e., an indicator of the time period for which given values in the road file are valid; this would address the issue of concurrency, i.e., making sure the road data are valid for the date of the crash. We also need to be aware of roads having more than one name (aliases), but the procedure developed should pass along only the "true" name.

In terms of data requirements, the worst case is what would be needed for State Patrol officers, who patrol several counties and may work on several systems of roads. There may also be cases in which county officers must cross jurisdictional lines, e.g., a Boone County Sheriff needing to record a crash in Story County. For each county, we could provide data of surrounding counties, or we could simply provide each county its own data and treat cross-border problems as an exception.

As an Advisory Committee, we need to specifically address the above issues (exactly how to integrate roadway data, which roadway fields to include on the in-vehicle computers, how to do updates, etc.) This will be discussed at the next Advisory Committee meeting.

The location tool has the potential to be used for a variety of purposes (e.g., citations, police calls, etc.), but we should focus on making a crash location tool first without getting lost in the possibilities.

OIM is written in Visual Basic 3. Advantage Safety and the location tool are being written in Visual Basic 5. Although it would be nice to make the location tool compatible with OIM, it likely will not be possible. This is consistent with the larger effort: except for slight enhancements, no new functionality will be developed for OIM.

There is a technical issue related to getting "feet from the intersection" with MapObjects using a latitude/longitude reference layer.

There may be interest in developing a "portable" translator, to allow users to convert lat/long (from the new location tool) data back into link-node for immediate use of Access ALAS in the local's office.

Tadd suggested having an AMS Visual Basic programmer spend a week or so in Ames working with CTRE to develop the tool. The programmer has a good background in Visual Basic and none in GIS. Our strengths complement each other. The visit would probably occur in early/mid-October.

Driver Services may need to address the issue of getting the location tool to work with APS (the system used to enter MARS data) in an OS/2 environment.

Can't do right/left mouse clicks, at least in the mobile units. The officers will be using pen-based computers. Pens can be less precise than crosshairs on the screen with a mouse.

Need to have a "close" button. The officers don't like to use the "X" button at the top right.

Need to address coordinate systems used (dispatch vs. vehicle, and different ones used in different parts of the state)

Can MapObjects, e.g., read in UTM GPS coordinates and use lat/long for the map interface?

Issue with dll developed by CTRE: need to determine what the public functions are that AMS would be able to work with (probably set all of them to be public).

Setting zoom extents - make sure dll can take parameters from Advantage Safety

User defaults set outside in Advantage Safety

Some black and white laptop displays, some color (the newer ones). Some colors more easily seen.

Touch on, e.g., Gilbert, get pre-determined zoom level (instead of drop down menus).

Button for selecting city, area of county.