| Name | Description and usage | Complexity | Specific Req |
| KHUB->PMS - reference matching | This is the connection between KDOT's PMS and KDOT's Inventory system network noting that PMS uses a Centerline Network with a defined county-based LRSm and the Inventory system uses a carriageway county-based LRSm | High (the standard will be KDOTs arbitrary definition of "close enough") | 6.1. & 6.1.1 |
| KHUB->PMS - Data from KHUB (Traffic, NHS, Maintenance, Class, Shoulder, other?) | This is the connection between KDOT's PMS and KDOT's Inventory system specifically to pass data from the inventory system to PMS likely using the two different (but close) networks | Medium (pulling data from someone else) | 6.1.2 |
| PMS->KHUB - HPMS frame-based data (pre or post conflation) | This is the connection between KDOT's PMS and KDOT's Inventory system specifically to pass HPMS pavement condition data from PMS to the inventory system | Low (passing data to someone else) | 4.1.1 and 6.1.3 |
| PMS->KHUB - HPMS non-state frame-based data (pre or post conflation) | This can be a paper report or dataset (or interface or workflow) produced annually as part of the HPMS process. The data is collected by KDOT PMS forces despite it being for locations that are not KDOT ownership nor maintenance responsibility. Transportation Planning provides descriptions of the locations where data is required. PMS collects the data and then provides it back to Planning as unconflated pavement condition data following HPMS rules | Low (passing data to someone else) | 4.1.1.5 |
| PMS->KHUB - Priority Formula (segmented) data (including Remaining Life) | This is the connection between KDOT's PMS and KDOT's Inventory system specifically to pass Priority Formula pavement condition data from PMS to the inventory system | Low (passing data to someone else) | 3.3. & 6.1.3 |
| PMS<->GIS | The proposed solution is expected to provide map-based UIs and reports so that users can see and edit data in map views. If the GIS is native to the solution, that is fine. If the proposed solution will use an external interface for this functionality, KDOT uses ArcGIS and a KDOT specific ArcGIS platform called KanPlan. | Medium (this is probably a pretty standard connection between data and mapping tools, just everyone's implemetation has a few quirks). | 7.1. |
| PMS->KHUB Projects - Submitted Completed Project Info (FORM) | This is the connection (possibly a workflow) between KDOT's PMS and KDOT's Inventory system specifically to pass completed project information from PMS (actually from the CRF process) to the inventory system | Low (passing data to someone else) | 10.2.1 |
| Field->PMS - Completed Rehab Form (FORM) | This is the connection (currently a webform) to manage responses from field personnel and get completed project information | High (uses a number of sources and requires external folks to provide data to PMS) | 10.2 |
| PMS(data)->NCV - Pavement image and data viewer requires feed and care | This is the connection between KDOT PMS's pavement image and condition (think video log with pavement data) and all the necessary data to feed it that currently comes from stored images and many tables of data | High (lots of pieces have to come together to feed this system in real time to function as the viewer we are used to) | 9.2 |
| PMS->Performance Measures Dashboard (TBD) | This is a future connection between KDOT PMS condition data and/or analysis and KDOT Performance Measure Dashboards | Low (passing data to someone else) | 4.2 & 4.3 & 11.2 |
| Pavemetrics->PMS - Pull data from XML (not Mandli reports) | This is a future possible connection that shortcuts many of the steps currently involved in the processing of pavement condition data by using directly (or more directly) the outputs from the collection systems instead of requiring intermediate steps to generate data for and population of database tables (direct from XML or maybe direct from shapefiles) | High (requires understanding raw or partially compiled pavement data and procedures to convert the data into pavement condition items like roughness, rutting, faulting, cracking, ..., involves some form of location info, many pieces and parts) | 9.1. & 9.1.1 |
| WhiPavSur->PMS - Extract JD data from WhiPavSur and load to PMS tables | This is the connection between KDOT PMS developed application to collect joint distress data and storing that data | Low (existing process is straight forward just needs to get some info about where to collect to the external system and bring the data back in once it is collected) | 9.1 |
| PMS->DQMP checker | This may be a report only, but it could be an interface that accesses the pavement condition data prescribed in the DQMP for the annual check and helps walk users through performing the checks and generating the report(s) | Medium (as an interface, this simply walks people through the escalating tiers of checking the pavement condition data) | 9.1.1.3 |
| PMS->KTA (REPORT?) | This may be a report only, but it could be an interface to allow the Kansas Turnpike Authority to access the pavement condition data collected by KDOT on the KTA directly | Low (passing data to someone else) | 11.2 |
| LCMS->Road View Workstation | This may be a bit of a placeholder, but KDOT PMS data collection systems may act more like separate systems that need to have interfaces to the primary PMS application. If so, then this represents the link between our pavement condition collection system (LCMS) and the Mandli Roadview Workstation tools that convert that standard Pavemetrics data into HPMS and KDOT specific elements (like IRI, rutting, ...) | Medium (as an interface or possibly workflow, this is just moving data and users through the process) | 9.1 |
| WinCPMS->PMS Project Data including Costs | This is a future possible connection between KDOT WinCPMS (the project management system) and KDOT PMS so that the PMS system can track scheduled projects and as a source for project costs | High (getting data from another system that doesn't play nicely) | 10.1 |
| Crashes->PMS | This is a future possible connection between KDOT (whatever now holds crash data) and KDOT PMS so that the PMS can use accident information in pavement surface decisions. | High (getting data from another system that isn't known to PMS) | 6.1 (maybe) |
| Skid->PMS | This may be a bit of a placeholder, but KDOT PMS data collection systems may act more like separate systems that need to have interfaces to the primary PMS application. If so, then this represents the link between our pavement surface friction system and PMS | Medium (as an interface or possibly workflow, this is just moving data and users through the process) | 8.1.5 & 9.1.1 |
| FWD->PMS | This may be a bit of a placeholder, but KDOT PMS data collection systems may act more like separate systems that need to have interfaces to the primary PMS application. If so, then this represents the link between our pavement structural Falling Weight Deflection system and PMS | Medium (as an interface or possibly workflow, this is just moving data and users through the process) | 9.1.1 |