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)
x,y to link/node conversion
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
Black Hawk county
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.
Fire Services Institute
Part of Phase 2 of the GIS-ALAS project is to assist the ISUs
Fire Institutes 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.
Cedar Falls project
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.
Vision for the future of crash systems in Iowa
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%
- Manual process to supplement x% Accuracy to y% Accuracy
- Population of crash records with infrastructure data from
- Transportation data Microstation MDL (Microstation Design
- 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
departments 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.
Interface of the location tool
The location tools 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 mouses 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 Dans 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
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
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.
Notes from 9/3/98 meeting: Tim Strauss, Tadd Geis, Michael
Pawlovich, Mary Jensen, Jack Latterel
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
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.