Loading page…
Please wait while we prepare this page.
7-day free trial7-day free trialPlease wait while we prepare this page.
Standards and practical guidance
Match flexible, concrete, block and unpaved visual-condition observations to the appropriate exchange family and retain assessment evidence.
Choose the visual-data exchange family from the pavement type and the source edition. A file extension is a label for a defined structure. Renaming a file does not convert its fields, assessment meanings or network references into that structure.
This guide concerns COTO TMH-18, Committee Draft 5.0, February 2016. TMH-9 concerns visual assessment; TMH-18 supplies exchange structures for the resulting road-condition data. Confirm the editions and delivery profile agreed for the project before preparing the files.
Determine whether the records describe flexible surfaced, concrete, block or unsurfaced pavement. Keep the assessment date and section context with the records. Where a road changes surface type, check the segmentation and required treatment with the receiving authority rather than assuming one definition covers the entire road.
Use the assessment method and field definitions that belong to the relevant pavement type. Similar column names do not establish that two rating scales or distress definitions have the same meaning. A structural validator cannot reconstruct a field assessment that was never made.
Table 5 in the cited TMH-18 edition lists .flx for flexible pavement surfaced visual-condition summaries, .con for concrete, .blc for block and .vgi for unsurfaced visual-condition summaries. Treat that mapping as the start of the check, then read the relevant full field definition.
Legacy file names from another edition should be handled explicitly. Do not infer an automatic equivalence between an older extension and a current schema. Retain the original export, identify its edition and document any conversion before using a newer exchange structure.
Make a field-by-field mapping that identifies the source field, destination field, permitted values, missing-value treatment and any transformation. Distinguish a direct copy from a calculated or recoded value. Keep the calculation or recoding rule available for a second engineer to review.
Do not fill a missing assessment with a favourable rating to complete the record. An omitted observation and a recorded absence of distress are different evidence. Follow the adopted definition for missing or inapplicable values and record any unresolved information in the handover.
Confirm that identifiers, measurement dates and kilometre positions refer to the intended network version. Review section boundaries and coverage. A structurally well-formed visual record can still describe the wrong road position or fail to cover part of the required network.
For an illustrative problem, a section changes from a flexible surface to block paving. Copying one assessment format across the boundary may produce a complete-looking table while applying the wrong definitions. Resolve the section and format choice before treating the file as ready for review.
Compare the available check template with the intended exchange family, its fields and its edition. A template's presence or a successful upload does not establish that the service checks every visual-assessment rule. Read the findings and their coverage, including checks that did not run.
Retain assessor and source evidence with the project where required, alongside the exported file, mapping notes and review record. The resulting validation evidence should state what was checked and which questions remain for engineering judgement.
The cited sources describe their own requirements. Practical checklists and examples do not replace the receiving authority’s adopted profile. Platform review and certification are described in the product documentation.
Record the edition, selected checks and unresolved questions alongside the delivered files.
Open the working templates