Solution: User-friendly interfaces were developed for end users so that they can do pavement information analysis, spatial analysis, and customer services from the interfaces.
Applications: The Pavement Querying System (PQS) allows end users to query pavement information by road name, road number, road class, maintenance area, pavement length, pavement width, pavement rating, date, wild card, and any combination of the above. The end users can also use the PQS to do pavement information analysis and statistics, routing, networking, and other spatial analysis. The purpose of this paper is to review the PQS developments, technical challenges encountered, and lessons learned.
Software: The PQS used ArcInfo, dBase, and UNIX C shell scripts on UNIX workstations running Solaris2.4.
The PQS is user-friendly interfaces. Most end users need little training to use it. Most of the applications can be done through the PQS, like routing, networking, and statistics. The PQS also saves time and money because of centralized developments.
We got the ArcInfo coverages from a vendor. The only attribute data (AAT - Arc Attribute Table) is road names. They are not good "links" at all for later "relates", but that is what we have. The person who signed contract with the vendor did not know much GIS and did not ask for more attribute data. It was a mistake. We started from here and fixed most errors.
The converted INFO database has road#, road names, and other pavement information. The road# is unique and is the best candidate for "relates". But the road names in this INFO database used different naming conventions from those in the "AATs". So we did some data processing before we can use road# for "relates". After the data processing, we used road names as "relate item" and copied over road# from the INFO database to the "AATs". Then, road# can be used for "real relates".
Actually, we did some QCs after the above steps to make sure that road# will be fine for "real relates". What we did was to compare the "AATs" with the converted INFO database. It was time consuming because we did it semi-automatically. We did so to ensure our future applications and it paid off.
Next, we decided to use "ordered relate" to connect the converted INFO database to the ArcInfo coverages (the "AATs"). This is one of the fastest "relates" of ArcInfo software.
The last step is to create user-friendly interfaces for the end users based on database designs and data modeling results. We used "pull down" MENUs as the main interfaces because most end users are used to AutoCAD's "pull down" MENUs. From the main MENU, the end users can query pavement information by road name, road number, road class, maintenance area, pavement length, pavement width, pavement rating, date, wild card, and any combination of the above. Following the query, they can generate a report, do statistics by various "case items", analize query results, create a map of their "interest area". They can also do routing and networking interactively to display specific routes, to create the best routes of selected "stops", and to "trace" routes "downstreams" or "upstreams". Other functions included: zooms, refresh, reset, area change, clear, and "command-line" option.
2. Pilot Study
We chose one township area to test everything before fully implementing our plan.
Minor changes were made during the "pilot study". This took some time, but it paid
off also for testing designs, modeling, plan, hardwares, softwares, performance, etc.
It is one of the "musts" for large applications.
3. Implementation
This was the last step of this application. It was a kind of easy after our "pilot
study" because we tested everything already during the "pilot study". Generally
speaking, the implementation went smoothly. We did some training and set up online
help while implementing this application. The online help is explanations of all
the interface "buttons". We also have a help desk to let end users talk to
application developers about any question or problem. One person is dedicated to
maintain this application for about 8 terminals connected to a server. The end users
can do their projects (statistics, routing, networking, analysis, maps, etc.) and
customer services (querying pavement information for customers) from the PQS.
4. Some Examples
(1). Query Results by Road# or Road Name
Querying by road# or road name will highlight the road on your screen and give you a report. A map can be generated also from the graphics on your screen. They can all be sent to a plotter or printer. The following is just the report:
trans1//road_number = 863610 trans1//rd_name = BAYOU ROAD length(mile) = 0.1054 trans1//desc = LAKE NED ROAD - LAKE NED ROAD trans1//class = LR5 trans1//m_a = 7 trans1//c_d = 4 trans1//p_len = 0.1846 trans1//u_len = 0.0000 trans1//width = 18 trans1//s_r = 67 trans1//s_r_date = Dec 26, 1990 trans1//rd_sign = BAYOU RD trans1//sign_co = W/G trans1//init_date = Jan 21, 1990(2). Statistics by Road Class
Statistics can be done by various "case items". This example is a statistics by road class:
1
CLASS =LR5
FREQUENCY = 266
SUM-P_LEN = 50.453300
MAX-P_LEN = 0.625000
MEAN-P_LEN = 0.189674
SUM-U_LEN = 1.299500
MAX-U_LEN = 0.713100
MEAN-U_LEN = 0.004885
MAX-WIDTH = 36.000000
MEAN-WIDTH = 19.451128
MAX-S_R = 99.000000
MEAN-S_R = 70.477444
2
CLASS =CM1
FREQUENCY = 5
SUM-P_LEN = 4.993900
MAX-P_LEN = 2.848600
MEAN-P_LEN = 0.998780
SUM-U_LEN = 0.000000
MAX-U_LEN = 0.000000
MEAN-U_LEN = 0.000000
MAX-WIDTH = 24.000000
MEAN-WIDTH = 21.600000
MAX-S_R = 80.000000
MEAN-S_R = 68.200000
3
CLASS =CN2
FREQUENCY = 38
SUM-P_LEN = 34.297900
MAX-P_LEN = 3.357300
MEAN-P_LEN = 0.902576
SUM-U_LEN = 0.000000
MAX-U_LEN = 0.000000
MEAN-U_LEN = 0.000000
MAX-WIDTH = 38.000000
MEAN-WIDTH = 21.684211
MAX-S_R = 99.000000
MEAN-S_R = 71.210526
(3). Best Route and How to Get ThereYou can pick some "stops" interactively on your screen. The best route will be highlighted and directions will be displayed on a separate window. A map can be generated also from the graphics on your screen. Like querying, all the results can be sent to a plotter or printer. The following is just a report of directions and time needed for the best route:
Starting at HWY 542 Travel west for 0.532 minutes, turn left onto FOURTEENTH ST Travel south for 0.135 minutes, turn right onto AVENUE A Travel west for 0.234 minutes, turn right onto EVALYN LN Travel northwest for 0.101 minutes, turn left onto THIRTEENTH ST Travel south for 0.168 minutes, turn right onto LAKE OITIS DR Travel west for 0.583 minutes, turn left onto INGLEBY RD Travel southwest for 0.301 minutes, go straight onto AVENUE C Travel west for 0.265 minutes, turn right onto SEVENTH ST Travel north for 0.358 minutes, turn right onto AVENUE A Travel northeast for 0.088 minutes, turn left onto HWY 542 Travel west for 0.362 minutes, End of path Total path length is 3.128 minutes
Technical challenges encountered: "relate" uses and data processing on the converted INFO database. Without the data processing, "relates" would be impossible. All "relates" details should be studied before using them. Otherwise, problems may arise later.
Lessons learned: "pilot study", database designs, data modeling, "standards", and INFO database. "Pilot study" is very useful, especially for large applications. Database designs and data modeling are the most important processes for any GIS projects. Goals will not be reached without these processes. "Standards" will make data sharing and exchange much easier. INFO database is not a very good database. It is not good enough for some of our applications and it does not have all the "functions" we need.