presentation - GIS-T

advertisement
This presentation is to share with you our story on how we tackled the new FHWA
retroreflectivity requirements.
1
The 2009 FHWA Retroreflectivity Requirements stated that agencies had until January 2012
to implement an assessment or management method that is designed to maintain traffic
sign retroreflectivity at or above the established minimum level. Signs that are identified
using the assessment or management method as failing to meet established minimum
levels had to be replaced by January 2015, with the exception of street name and overhead
guide signs which had until January 2018 to be replaced.
Retroreflectivity is a measurement of the amount of light that is reflected back to the
viewer, making what they see appear brighter and easier to read. Because the
retroreflective properties of traffic control signs deteriorate over time, active maintenance
of signs is needed in order to ensure that they are clearly visible at night.
On May 14, 2012, a final rule was published that extended the compliance date
for implementation and continued use of an assessment or management method to June
13, 2014 and refined the compliance date to only apply to regulatory and warning signs,
and not others. In addition, the final rule eliminated the target compliance dates of 2015
and 2018 for the replacement of signs.
2
Beginning in January of 2011, the City of High Point Department of Transportation finally
turned to GIS to find a solution to quickly bring us to compliance with the original 2009
deadline of implementing an assessment or management method to maintain traffic sign
retroreflectivity.
But before we could implement a management method, we had to compile a digital
inventory of our traffic signs. We wanted a GIS data layer that showed the sign locations
and contained attributes about each sign.
3
At that time, we had a card file inventory “system” that consisted of index cards arranged
by street name. On each card was a date and description of why a sign was installed. There
was no specific information about sign size, face sheeting, or location. So we couldn’t use
this to build our GIS layer.
4
We began to examine vendor products already marketed for sign inventory and
management, but they were way out of our budget. There were also concerns over data
collection methods and ownership, as well as the look of the final product.
When we ran our project concept by our IT department, we found out that there was a
promising in-house solution already being tested out by the Fire Department.
5
The Fire Department was collecting pre-entry data in the field with laptops and air cards by
using an internet-based mapping application built on the ESRI platform. The question did
come up about whether we should be using GPS to locate each sign, but the City had
recently acquired ¼-FT resolution aerials that would provide sufficient landmarks and detail
to locate our signs. We could still get sub-meter accuracy without having to wait minutes
for the GPS to collect each point. Also, the sign shop crews already had laptops in their
trucks so all we needed to purchase were air cards, which are much cheaper than GPS
units. So we worked with IT to modify the Fire Department’s application for signs and got
this…(next slide)
6
With app in hand, we divided up the city using the garbage truck route zones. I printed
maps of each zone, and we tackled the city one zone at a time. When it came to sign
assemblies, the sign shop staff preferred being able to see the sign faces on a map instead
of a dot, so we collected one point per sign face, denote in an attribute field that the sign
was part of an assembly, and take a photo to link to the image filename.
7
So here are the attributes that we collected for each sign. To minimize variations and errors
when collecting sign attributes, we confined input to pull-down lists.
When the Assembly was changed to Y, an entry box popped up to add the photo filename.
The box stayed populated as we added the other signs on the assembly.
We broke down the extensive list of signs into classes to speed up selection. Depending on
the class selected, the Description list would change.
I also created a Sign Dictionary for reference, especially to look up the width and height of
signs.
8
We have 3 crews of 2 working the sign shop. I took each crew out for a month to train
them on the sign collection application. Collection was scheduled for 3 days a weeks, 8
hours a day. No collection on rainy days. With a crew of 3, you had one to drive, one to
work the laptop, and one to step out of the vehicle and relay back the sheeting type and
the installation date (if there was one written on the back of the sign). Eventually, we were
able to recognize sheeting from within the vehicle and only stepped out to get the
installation date. In the heat of the summer, we tried using binoculars and found that they
did help some to see the sheeting and dates without having to step out all of the time.
Once all 3 crews had been trained, we were able to have 2-3 crews collecting data each
day. We were able to collect inventory from both sides of the street on one pass along
most of our local 2-lane roads. However, roads that had a center turn lane or divided
median required 2 passes. We did not collect any signs along the interstates.
We tested the application in April 2011 and we able to launch in May. We completed the
inventory in 5 month. There were a few streets that were under construction so we had to
go back later to collect those at a later date.
9
With the inventory complete, we identified that there were 355 Stop signs and 187 Yield
signs that needed to be upgraded from the Engineer Grade sheeting at an estimated cost of
$38,000. Over 50% of our signs (mostly street name signs) have engineer grade sheeting
and would need to be replaced to comply with the new retroreflectivity requirements.
I created a street atlas showing the location of those signs. The crews divided up the pages
amongst themselves and replaced all the Yields and 175 of the Stops over 3 months. The
remaining 180 Stops were replaced over the winter this year. Before GIS, when the shop
used the cruise-at-night method, they only changed an average of 26 signs a month
compared to 120 signs a month.
10
Inventory complete. Now how to manage all those signs?
There were certain criteria that we were looking for in a management program that we
found in TEAMS:
1. We wanted to continue on the Internet-based app route, since we’d just bought air-cards
and we hoped that it would be cheaper than purchasing software and annual licensing fees
for each computer
2. We wanted to continue working off of an interface that was map driven instead of form
driven
3. We wanted map symbology to show the sign faces
4. We wanted it to be cheap, so if it doesn’t work out we weren’t deep in a financial hole.
11
Before TEAMS, in 2007, an Access database was set up to track work done by the sign
crews in order to submit a reimbursement request to NCDOT for maintaining signs and
markings on state roads.
The sign location was described by which street it was on, what side of the street, then
how far (quarter) it was from the closest cross street (at street) or which corner of the
intersection it was on. These descriptions were quite subjective and accuracy varied from
crew to crew. So, thankfully, with our signs mapped, we no longer needed to rely on that
anymore.
We did keep the work descriptions since they are sufficiently descriptive of the duties
performed by the sign shop.
12
In TEAMS, the sign is located on Bing Maps which is embedded in the application. You can
see that assemblies have a tree symbol that reveals the sign contents when you hover your
mouse over the location. Double-clicking a sign accesses its database where you can view
and add information using the links in the left menu bar. The work history form is simple
and contains the same work descriptions used in the former Access database. In addition
you can identify which equipment piece within an assembly you fixed from a pull down list
that is populated by the inventory data.
So now that we had a way to enter work history, we examined how to communicate work
requests.
13
Before TEAMS, there were 2 ways that Office staff requested sign work from the field crew:
through the Office List or a Work Order.
The Office List were problems called in by citizens and staff. The calls were written down on
a sheet of paper. Urgent signs like Stops and Yields were immediately dispatched by radio
or phone to the sign shop. Otherwise, each morning, the Sign Shop would call the office to
get the list of repairs needed. As repairs were completed they could radio in.
14
Traffic engineers communicated needed repairs to the Sign Shop through a Work Order.
Using a Access database form, an engineer types in the location and detailed description of
work to be done. Then prints the form which is picked up by the Sign Shop Manager to
hand to a crew. The crew writes on the form what materials they used, who did the work,
the amount of time spent, and any other notes. The form is handed back to their Manager
who returns it to City Hall for the Transportation administrative assistant to type the crew’s
handwritten notes back into the Access database form.
15
In TEAMS, the Office List and Work Order processes are consolidated into Trouble Ticket
and eliminate the paper trail.
The title of the ticket indicates to the crew whether the job is an Office List or a Work Order
assignment. This tool is accessible by double-clicking on a sign from the map. Saving the
Trouble Ticket launches an email to the task originator and assigned parties. Plus, if the
crews have their laptops open to TEAMS, a notification pops up on their screen. When the
task is completed, the crew simply changes the Status from Open to Closed and an email
gets sent out to notify all involved parties that the ticket has been closed and describes the
work done.
16
With our newly implemented sign management system, we have been able to eliminate a
lot of human errors and duplication of records. In addition, we are able to retrieve work
history and sign conditions to better maintain our traffic signs. Communication between
the sign shop and city hall is simplified. And most important, trees need no longer sacrifice
their precious limbs to our card files and paper trails.
17
The biggest lesson learned from this experience is how to get the end users – the field crew
– to really buy in. We originally met resistance from our field crew, so involving them in the
development of the inventory system was crucial to get their buy-in. We bribed them with
catered breakfast meetings to get their input on big things like what data needed to be
collected and little things like having the signs symbolized as sign faces instead of dots.
Don’t just dump the software and process on the supervisor and have the crew do all the
work. Go get your hands dirty and collect data with them; sit down with them individually
and in groups and learn how best to communicate with them; build rapport with the crews;
gain their trust; become a team member.
Another important lesson that we learned from our field crew is to not settle for what the
vendor offers. Demand what you want. We saw a lot of demos and visited our neighboring
municipalities to see what they were using before we knew what we wanted. Once we
knew what we wanted, we kept looking for a vendor who could meet our needs.
As a result, not only has our Sign Shop bought into the new system, they’ve taken
ownership of the data collected and take pride in the excellence of their work.
18
https://www.dropbox.com/sh/tfy2ql1i8akdjdr/v1Z1-CvVt6
19
Download