Name |
Description
and usage |
Complexity |
Specific Req |
Field Data Collection List (FDCL) |
This
is a paper book produced annually that includes PMS segmentation and county
mileposts, pavement type, percent predominant pavement type, and location
references (NJct U54/K15 15.234 which comes from a manually maintained
Reference table). It is used by field
data collectors, PMS data users, and many people just for the references. |
Medium |
9.1.1.1 and 9.1.1.2 |
Projects (outstanding, submitted, future) |
This
is a dataset that is constantly maintained that sometimes takes the form of
reports, interfaces, forms, and even workflows. The data represents tracking of pavement
projects from the time they are candidates, to district selections, to 1R (or
other program) selections, to "real" projects (have a number
assigned), to let projects, to "open to unrestricted traffic"
.... The formats of these reports vary
by different users and uses. Note that
the data behind these reports comes from many different sources (1R
Candidates, District Selections, WinCPMS, Letting Lists, Completed Rehab Form
submissions, .... They are used by the
project selection processes (1R and 3R), CRF, many of the mapping reports,
and Transportation Planning as they update their pavement histories. |
High
(lots of sources to get to this data) |
10.2 and 10.2.1 |
Data Collection Maps |
This
set of GIS maps shows shows the inventory locations to be collected for
LCMS/NOS, WHIPAVSAUR, FWD, SKID... vs what has been collected in the current
cycle. Basically, this report is
showing data collection progress. |
Medium |
7.1.2 |
Data Loaded Maps |
This
set of GIS maps shows where collected data has been loaded to the appropriate
PMS data tables over the inventory as a back drop. Basically, this report is showing data
loading progress. |
Medium |
7.1.2.1 |
Candidate Project Lists and Maps |
This
paper report or dataset (or workflow) which is the results of PMS analysis
that indicates candidate project locations and scopes for each of the 6
districts for their consideration |
High
(lots of sources to get to this data) |
7.1.5 and 7.1.6 |
District Selection |
This
(typically comes back as an email with a spreadsheet attachment and) is the
district response to the candidate lists that indicates which projects and
scopes they selected including the possibility of projects that were not on
the candidate list |
High
(lots of sources to get to this data) |
7.1.5 and 7.1.6 |
Approved for 402s |
This
is (typically an email with a spreadsheet attachment and is) the response to
the district response that indicates approval by the Chief of Construction
and Materials to projects and scopes for a district for a cycle |
Low |
3.1
see also (7.1.5, 7.1.6, and 11.1) |
Candidate Maps |
This
is a paper map based on the 1R process to show candidate project locations
and scheduled projects in each district.
They are used by District Staff to help them decide which 1R projects
to do in their next cycle. |
High
(lots of sources to get to this data) |
7.1.5 |
Action History Table and Maps |
This
is a paper report and a process that results in a database table that
summarizes contiguous roadway segments annually with candidate information,
planned project information, past project information, ... |
Medium |
7.1.3 |
Pavement Sandwiches |
This
can be a paper report or dataset (or interface) and represents a section of
roadway and both its action history in the form of what was done when and in
the form of what physical pavements exist there now |
High
(mostly due to aggregation rules and precision concerns) |
7.1.3 |
Condition Reports (Annual, IKE, State PM dashboard, others?) |
These
may be paper reports or datasets (or workflows) that simply provide some
aggregation of pavement condition data or predicted condition data or work
types and amounts accomplished or scheduled to other parts of the Agency |
Medium |
11.2 |
Condition Maps (Roughness, Rutting, Faulting, Transverse
Cracking, Joint Distress, Pavement Type, SKID, FWD, Surface Age, ...) |
These
typically are paper maps showing various pavement condition information |
Low |
7.1.4 |
DQMP Check |
This
is a paper report that follows the Kansas Pavement Condition Data Collection
Quality Management Plan to produce an annual report documenting the quality
of the collected data |
Medium |
9.1.1.3 |
KTA data |
This
can be a paper book or dataset (or interface)
produced annually that provides pavement condition data collected by
KDOT but for the KTA (and HPMS). It includes roughness, rutting, and faulting
following KDOT methods and could include more PMS condition data (transverse
cracking, structural data, SKID, ...) .
It is used by KTA for input into their PMS and reports. |
Low |
11.2 |
SKID book |
This
is a paper book generated mostly to facilitate field data collection. The current process to generate this book
also creates unique IDs and data record placeholders in existing tables. The
book is used by field data collectors to determine where they need to gather
friction data. |
Medium |
9.1 and 9.1.1.2 |
SKID map |
This
is a paper map based on the SKID book to show locations that need to be
collected along with some additional details like where projects have just
been completed and where there might be construction pending. |
Low |
9.1.1.1 See also 7.x |
FWD map |
This
is a paper map showing locations to collect FWD based on a list generated by
Pavement Evaluation staff. |
Low |
9.1.1.1 |
HPMS report card |
This
is a paper report following FHWA guidance that uses the HPMS submittal data
to check pavement data and summarize condition. The official version of this report will
come back from FHWA software, but this version needs to use data in the PMS
so that we know the answers before we go through the submittal process. |
Medium |
4.1.1.2 |
Mandli data reports to move from XML and profile to the PMS
database |
These
datasets are the current means of taking the processed LCMS data and using
Mandli's Road View Workstation tools to assemble it into attributes
(roughness, rutting, faulting, (various forms of ) cracking, ...) at various
aggregations (frame, tenths, segments, projects, ...) for import into data
tables each year. |
High |
9.1.1 |
DS, CS, PL, report summaries for feeding GASB, TAMP, ACFR, PMs,
Auditors, Annual Report) |
These
may be paper reports or datasets (or workflows) that provide pavement condition data in the forms of
Distress State, Condition State, and Performance Level distributions to other
parts of the Agency mostly as detail to the more aggregated summaries
reported elsewhere |
Low |
5.1 for TAMP and 11.2
for all others |
Widows and Orphans |
This
can be a paper report or dataset (or interface or workflow) produced regularly (weekly?) that provides
analysis of referential integrity (e.g. inventory record with no condition
data or vice versa), internal checks (e.g. components of PMSID concat
correctly into the PMSID), and logical checks (e.g. scheduled projects have
future not past dates). It is used by
PMS staff to check the database. |
Medium |
21 |
District Mileage Allotments |
This
can be a paper report or dataset (or interface or workflow) produced annually as part of the 1R
process. It represents the number of
miles allocated to each district to target as they select projects from the
candidate project lists. Historically,
rules have been applied to assign minimum proportions of the projects
selected from different categories versus this district total. Those rules helped keep the PMS output and
the implementation of projects somewhat in sync. The mileages are used by the Districts when
selecting projects and by PMS to check proportions and totals for projects
which get selected by each district. |
High
(lots of process to get to this data) |
3.1 |
1R Tour Supplemental Data |
This
is typically a dataset that summarizes pavement history, traffic, pavement
width, NHS, ... for candidate project locations for the field reviews |
Low |
11.1 |
Additional Reports |
Note
that this list of reports is not exhaustive and that respondants should
indicate if they have a limit to the numbers of reports included in their bid
so that it does not become a point of contention during implementation. |
Varies |
11.2 |
|
|
|
|