LCMSAnalyser Library: User Manual (Rev 4.7.0.

0)
October 2015

Copyright © 2015 by Pavemetrics Systems Inc.

All rights reserved.
Reproduction in whole or part in any way without written
permission from Pavemetrics is strictly prohibited.
Table of Contents

1 INTRODUCTION ...................................................................................................6
2 SYSTEM SPECIFICATIONS .................................................................................8
3 DEFINITIONS: PROFILE, ROAD SECTION AND SURVEY ...............................8
3.1 PROFILE...................................................................................................................... 8
3.2 LONGITUDINAL PROFILE ............................................................................................ 8
3.3 ROAD SECTION ........................................................................................................... 8
3.4 SURVEY ...................................................................................................................... 9
4 ROAD SURFACES ANALYSIS: QUICK START GUIDE ................................... 11
4.1 LOADING ROAD SECTIONS ....................................................................................... 11
4.2 ROAD SURFACE ANALYSIS ....................................................................................... 11
4.3 RETRIEVING RESULTS AND IMAGES ......................................................................... 11
4.4 PROCESSING NEXT ROAD SECTIONS ......................................................................... 11
4.5 GETTING SURVEY INFORMATION AND ROAD SECTION LIST (OPTIONAL) ................ 12
5 XML STRING: DEFINITION AND DESCRIPTION ........................................... 12
5.1 XML STRING FORMAT DESCRIPTION ....................................................................... 12
5.2 XML FORMAT DESCRIPTION FOR THE LCMS ANALYSIS RESULTS .......................... 14
Element start tag .............................................................................................................. 15
Content description.......................................................................................................... 15
6 PROCESSING PARAMETERS AND PROCESSING MODULES ....................... 16
6.1 PROCESSING PARAMETERS ...................................................................................... 17
6.2 CRACK DETECTION MODULE.................................................................................... 20
Description ...................................................................................................................... 20
Parameters....................................................................................................................... 20
XML output format .......................................................................................................... 22
6.3 RUTTING MODULE .................................................................................................... 24
Description ...................................................................................................................... 24
ASTM E1703 Standard .................................................................................................... 24
Taut wire (string line) method ......................................................................................... 25
Brazilian method.............................................................................................................. 26
Moving ruler line ............................................................................................................. 27
Five-Point Rut Depth Calculation ................................................................................... 28
Stitching left and right profiles ........................................................................................ 29
 Parameters....................................................................................................................... 31
XML output format .......................................................................................................... 32
6.4 MACRO-TEXTURE MODULE ...................................................................................... 35
Description ...................................................................................................................... 35
Parameters....................................................................................................................... 35
XML output format .......................................................................................................... 35
6.5 LANE MARKING MODULE ......................................................................................... 38
Description ...................................................................................................................... 38
Parameters....................................................................................................................... 38
XML output format .......................................................................................................... 39
6.6 POTHOLES MODULE ................................................................................................. 40
Description ...................................................................................................................... 40
Parameters....................................................................................................................... 40
XML output format .......................................................................................................... 40
6.7 DROP-OFF AND CURB MODULE ................................................................................ 42
Description ...................................................................................................................... 42
Parameters....................................................................................................................... 42
XML output format .......................................................................................................... 43
6.8 JOINTS MODULE FOR CONCRETE PAVEMENT ........................................................... 45
Description ...................................................................................................................... 45
Parameters....................................................................................................................... 45
XML output format .......................................................................................................... 47
6.9 RAVELING MODULE (OPTIONAL) ............................................................................. 48
Description ...................................................................................................................... 48
Parameters....................................................................................................................... 48
XML output format .......................................................................................................... 50
6.10 ROUGHNESS MODULE .............................................................................................. 52
Description ...................................................................................................................... 52
Computing and saving the longitudinal profiles using LcmsRoadInspect....................... 52
Computing and saving the longitudinal profiles using the analyser library
(LcmsAnalyserLib) ................................................................................................................. 53
Computing the IRI using LcmsRoadInspect .................................................................... 53
Computing the IRI using the analyser library (LcmsAnalyserLib) .................................. 55
Parameters....................................................................................................................... 55
XML output format .......................................................................................................... 57
Summary file format ........................................................................................................ 58
6.11 SLOPE AND CROSS-SLOPE MODULE .......................................................................... 60
Description ...................................................................................................................... 60
Parameters....................................................................................................................... 60
 XML output format .......................................................................................................... 61
6.12 WATER ENTRAPMENT CALCULATIONS .................................................................... 62
Description ...................................................................................................................... 62
Parameters....................................................................................................................... 62
XML output format .......................................................................................................... 62
6.13 GPS COORDINATES .................................................................................................. 65
Description ...................................................................................................................... 65
6.14 MARKING CONTOUR PARAMETERS .......................................................................... 66
Description ...................................................................................................................... 66
Parameters....................................................................................................................... 66
XML output format .......................................................................................................... 67
6.15 SEALED CRACK MODULE ......................................................................................... 69
Description ...................................................................................................................... 69
Parameters....................................................................................................................... 69
XML output format .......................................................................................................... 70
6.16 RENDERING PARAMETERS ....................................................................................... 72
Description ...................................................................................................................... 72
Parameters....................................................................................................................... 72
7 FUNCTIONS DESCRIPTION .............................................................................. 75
7.1 LCMSGETLIBVERSION............................................................................................. 75
7.2 LCMSSETLICENSEPATH ........................................................................................... 75
7.3 LCMSSETLUTSPATH ................................................................................................ 75
7.4 LCMSSETCONFIGFILENAME.................................................................................... 76
7.5 LCMSSETPROCESSINGPARAMS ............................................................................... 76
7.6 LCMSOPENROADSECTION ....................................................................................... 77
7.7 LCMSCLOSEROADSECTION ..................................................................................... 77
7.8 LCMSGETPROCESSINGPARAMS ............................................................................... 77
7.9 LCMSGETROADSECTIONINFO ................................................................................. 78
7.10 LCMSGETSYSTEMDATA (ADVANCED FUNCTIONALITIES) ....................................... 78
7.11 LCMSGETINTDATA .................................................................................................. 79
7.12 LCMSGETRNGIM ..................................................................................................... 80
7.13 LCMSGETRECTIFIEDRNGIM .................................................................................... 80
7.14 LCMSGETSTITCHEDRNGPROFILE ............................................................................ 81
7.15 LCMSGETSTITCHEDRNGINTPROFILE ...................................................................... 82
7.16 LCMSGETSTITCHEDRNGPROFILECALIB.................................................................. 83
7.17 LCMSGETSURVEYINFO ............................................................................................ 84
7.18 LCMSGETSURVEYROADSECTIONLIST .................................................................... 85
7.19 LCMSADDPROCESSINGMODULETOSELECTION ...................................................... 86
 7.20 LCMSREMOVEPROCESSINGMODULETOSELECTION ................................................ 86
7.21 LCMSGETPROCESSINGMODULESELECTION ............................................................ 87
7.22 LCMSPROCESSROADSECTION ................................................................................. 87
7.23 LCMSGETRESULT .................................................................................................... 87
7.24 LCMSGETRESULTIMAGE ......................................................................................... 88
7.25 LCMSCREATEOVERLAYIMAGE ................................................................................ 89
7.26 LCMSCREATEOVERLAYIMAGEFROMFILES ............................................................. 90
7.27 LCMSSAVERESULTIMAGE ....................................................................................... 90
7.28 LCMSCOMPUTELONGITUDINALPROFILE ................................................................. 91
7.29 LCMSGETCOMPUTELONGPROFILESTATUS ............................................................. 91
7.30 LCMSGETLONGPROFILEIRIVALUES ........................................................................ 92
7.31 LCMSGETLONGPROFILEELEVATION ....................................................................... 92
7.32 LCMSWAITCOMPUTELONGPROFILECOMPLETION .................................................. 92
7.33 LCMSGETLICENSEINFO ........................................................................................... 93
7.34 LCMSGETUSERDATASIZE ....................................................................................... 94
7.35 LCMSGETUSERDATA............................................................................................... 94
7.36 LCMSOPENFROMSTREAMDATA .............................................................................. 94
APPENDIX A: LIST OF ERROR CODES ................................................................... 96
1 Introduction
Pavemetrics’ Laser Crack Measurement System (LCMS) is a high-speed and high-resolution
transverse profiling system. Capable of acquiring full 4-meter width 3D profiles of a highway lane
at normal traffic speed, the system uses two laser profilers that acquire the shape of the
pavement. Both the resolutions and acquisition rate of the LCMS are high enough to perform
automatic cracking detection, macro-texture evaluation, rutting measurements, and much more.
Custom optics and high power pulsed laser line projectors allow the system to operate in full
daylight or in night time conditions. Road profile data are collected onboard the inspection
vehicle.
The LCMS is delivered with two complete Windows XP - Windows 7 (32 or 64 bits) DLL
libraries of C/C++ functions. These libraries allow the user to easily configure and operate the
system. LCMSDataAcquisition library is dedicated to data acquisition, while LCMSAnalyser is for
road surface analysis.
This document provides detailed indications on how the LCMS user can easily integrate and
link the LCMSAnalyser library with his own processing software GUI (Graphical User Interface). All
functions that must be called by the user’s GUI in order to process the acquired road surface data
are listed and described in the following sections of this document. As for the data acquisition
process, the reader is referred to the LCMS Data Acquisition User Manual, which explains how to
configure the sensors, start an acquisition, collect data, etc....
Figure 1 LCMS Software Organization
2 System Specifications
The analysis library works on about any processor that has at least 2GB of RAM. However,
analyzing thousands of kilometers of roads on a slow processor may become impracticable. To
achieve best performances, the library takes advantage of multi-core and multi-processor
architectures. The library also takes advantage of specialized instructions sets of Intel CPU. For
these reasons, it is highly recommended to perform survey analysis on Intel multi-core based
computers.

3 Definitions: Profile, road section and survey

In order to facilitate the understanding of the document, some basic definitions are given.
These definitions help explain how the LCMS system works at both levels, that is the acquisition
and processing levels.
It should be noted that this section of the document is common to both the Data Acquisition
User Manual and the Data Analyser User Manual.

3.1 Profile
A road profile is a set of (X,Z) data points captured along the transversal axis of the road (see
Figure 2). A profile is captured each time the LCMS controller receives a trigger signal from the
vehicle's odometer1. Typically, the LCMS system can capture one road profile every few
millimetres (5 mm at 100km/h). Each profile consists of up to 4160 data points. This value will be
referred to later in this document as being the number of points per profile.

3.2 Longitudinal profile

The longitudinal profile of the road is generated by measuring its shape along an imaginary
line in the direction of travel or longitudinal axis of the road (see Figure 2). The longitudinal
profile can then be used to compute various roughness indexes such as the IRI
(International Roughness Index).

3.3 Road section

A road section is a set of consecutive profiles that are merged together and saved in a
common file. A road section can be seen as a set of 3D coordinates (X,Y,Z), where X is the
coordinate along the transversal axis of the road, Y along the longitudinal axis, and Z is the depth
axis. The road section length is configurable and is set by the user before starting the acquisition.
A typical road section length is between 5 to 10 meters. The number of profiles per road section
depends on the encoder pitch of the vehicle's odometer. Road sections are saved by the

1
Synonym: Distance Measurement Instrument (DMI)
acquisition library using a proprietary file format. The file format includes all necessary data
required for the analyser library:
 Depth map of the road surface (also referred to as range data, or XYZ image, or height
values)
 Intensity Image of the road surface (that is the intensity of the laser line at each data point)
 User data (additional data that the user may want to attach to the road section at
acquisition time)
 Acquisition parameters and system status at acquisition time.
 Information about the road section relative to the survey it belongs to.
 Etc…

3.4 Survey
A survey is a group of road sections. A new survey is created each time a new acquisition is
started from the acquisition library. Each survey is identified by a unique identification number
(Survey ID) and each road section of a survey is labeled with a sequential number (Section ID). A
single survey can be composed of thousands of road sections, which would correspond to
hundreds of kilometers of road pavement having been inspected by the vehicle. The Section ID of
the first road section of a survey is always 0. All road sections from a same survey are saved in the
same folder.
 Longitudinal
profile

Y
X X-Z
Z Coor
ds.
Figure 2 LCMS Data Definitions
4 Road surfaces analysis: Quick start guide

4.1 Loading road sections

The first step is to load a road section into memory using the LcmsOpenRoadSection
function. Once the file is loaded, pre-processing operations will automatically be performed
by the library. That includes angular corrections to compensate the tilt angle on the vehicle,
merging profiles coming from both the left and right sensor, removing the overlap between the
left and right profiles, etc…
Before performing the road surface analysis, some useful information for the user can be
retrieved using the different “Get” type functions available in the library. That includes the survey
ID, the road section ID, the range and intensity images, the system status during acquisition, etc…
The different “Get” type functions are presented in Section 4.5.

4.2 Road surface analysis

Once a road section has been loaded, a call to LcmsProcessRoadSection gets the
library to perform the road surface analysis. The library offers different types of processing such
as rutting measurement, cracking detection and macro-texture evaluation. Each of these
functions is referred to as a processing module. At the users request and depending on the
availability, certain processing modules may be enabled or disabled. See Section 6 for details on
how to select modules. Most of those modules can be configured to suit user needs.

The available processing modules are:

 Cracking
 Rutting
 Macro-texture
 Lane marking
 Potholes
 Curbs & Drop-off (optional)
 Raveling detection (optional)
 Sealed cracking (optional)

4.3 Retrieving results and images

Once the analysis of a road section is completed, final results can be retrieved with calls to
LcmsGetResult and LcmsGetResultImage. The results are returned as an XML string. A
detailed description on how the results are organized into the XML string is given in Section 5.

4.4 Processing next road sections

Before being allowed to process the next road sections of a survey, the user first needs to
close the current road section using the LCMSCloseRoadSection function. This will allow the
library to free allocated memory. The analysis can then continue with the next section using the
LcmsOpenRoadSection, LcmsProcessRoadSection, and so on until the end of the
survey is reached. Note that the library retains processing parameters set prior to the call to
LcmsCloseRoadSection. Therefor the parameters only need to be set once.
4.5 Getting Survey information and road section list (Optional)
The library provides a pair of functions that give all relevant information about the current
survey. These functions help the user to navigate through the typically large number of road
sections that form a survey. The first one is LcmsGetSurveyInfo. This function returns a
structure containing the global information about the survey such as the total length and the total
number of road sections.
The second function is LcmsGetSurveyRoadSectionList which returns the list of road
sections than belong to the current survey. Each element of that list is a structure containing
information about the corresponding road section including the 'full path name' of the .fis data
file. Other information about each road section also includes the road section ID and its position
inside the survey, given in meters.
The road section list returned by LcmsGetSurveyRoadSectionList is ordered
sequentially. That is, the first road section of the survey is located at the beginning of the list and
the following road sections are listed in the same order as they were acquired. That makes the
road section list a convenient way to browse through the survey. If one wants to process all road
sections of a given survey, one only needs to loop through the list while calling
LcmsOpenRoadSection, LcmsProcessRoadSection and LcmsCloseRoadSection.

5 XML String: Definition and description

An XML string is a text (ascii) string in which the information is organized according to the
XML format. The main advantage of the XML format is that is a convenient way to organize
information hierarchically into a simple text file that can be read by any text editor. Figure 3a)
shows an example of an XML string displayed in a basic text editor (Notepad). Figure 3b) shows
another example where this time, the XML string is displayed in a common XML viewer (Internet
Explorer). An XML viewer reveals the hierarchical structure of the information contained in the
XML string. Moreover, it allows to collapse or to expand sub-trees, which helps navigate thought
the information.
The key concepts about the XML format are explained in the following sections. The
presentation will first focus on information needed to successfully interpret the XML result string
generated by the LCMS analysis library. Then, we will describe the organization of the analysis
results contained in the XML string. Although results are organized in a similar way for all
processing modules, each processing module has its particularities. Detailed output format
description for each processing module is provided in sections 0 to 0.
XML is widely used for the representation of arbitrary data structures. More details about the
XML specification can be easily found on the internet. For instance, Wikipedia has a good article
about XML format.

5.1 XML string format description

The first element of an XML string is the XML declaration. For the LCMS analysis library, the
XML declaration is:
<?xml version="1.0" encoding="UTF-8" ?>
 The XML declaration indicates that the string complies with XML format 1.0, and that the
character encoding scheme is UTF-8 (for the LCMS analysis library, the character set is limited to
plain US-ASCII, which is a subset of UTF-8).
Following the XML declaration is the XML information per-see. XML information is composed
of a sequence of XML elements. An XML element can contain other XML sub-elements organized
in a tree-like structure. There is no limit on how many sub-elements can contain an XML element,
or how deeply can sub-elements be nested into each other. The only restriction for the
organization of an XML string is that there must be only one root element. For the LCMS analysis
library, the root element is <LcmsAnalyserResults>.
An XML element is always delimited by its opening and closing tags. For example,
<ExampleOfElement>The Element Itself</ExampleOfElement>
A name must be specified for each element. It must appear in the opening tag and in the
closing tag. Everything between the opening and closing tags is the element itself. It can contain a
single piece of information, one or more other elements, or both.
 Figure 3 XML String displayed in a) a text editor and b) an XML Data Viewer

There are only few restrictions how to define element's name. Names cannot start with a
number, punctuation character or the "xml" letters. Also, names cannot contain space. Besides
these restrictions, any letters, numbers or others characters can be used to create an element
name that describe its content.
Some characters have special meaning in the XML format. These are "<", ">", "&", " ' " and " "
". If one of these needs to be used in an element's name or content, they must be replaced by the
following strings: "&lt", "&gt", "&amp", "&apos" and "&quot". This means that when reading an
XML string, one must look for "&" character and replace them and their associated string with the
appropriate character.

5.2 XML format description for the LCMS analysis results

Figure 3b) shows an example on how the LCMS analysis result is organized into the XML
string. The root element of the hierarchy is <LcmsAnalyserResults>. Each processing
module has a single processing entry at this root (<RutInformation>,
<CrackInformation>, etc…). Other informational entries are also available to provide useful
information about the system status. All possible entries are listed in Table 1. Detailed
information about the processing entries can be found in Section 6.

Element start tag Content description

<SurveyInfo> Basic information about the current survey (to which the
current road section belongs to). The survey information
can also be retrieved by calling function
LcmsGetSurveyInfo.
<RoadSectionInfo> Information status about the road section. The road
section status can also be retrieved by calling
LcmsGetRoadSectionInfo.
<ProcessingInformation> Values for the different processing parameters. The
processing parameters are configurable and their values
can be changed by the user. See Section 6 : Processing
Parameters and Processing Modules.
<ResultImageInformation> Resolution for the result images. See documentation of
function LcmsGetResultImage
<LaneMarkInformation> Lane marking results.
<RutInformation> Rutting results.
<PavementTypeInformation> Automatic pavement type detection results.
<CrackInformation> Crack detection results.
<MacroTextureInformation> Macro-texture results.
<PotholesInformation> Potholes detection results.
<SystemData> Information about the acquisition system. The system
data information can also be obtained by calling
LcmsGetSystemData.
Table 1 Entries for an XML string.
6 Processing Parameters and Processing Modules
Even though the LCMS analyser library is fully automated, some processing parameters can be
configured by the user based on his specific requirements. Figure 4 lists the processing
parameters from the <ProcessingInformation> element of the XML string. Parameters are
grouped into different categories: <CrackingModule_Parameters>,
<LaneMarkingModule_Parameters>, etc. Although the processing parameters have
default values, they can be changed either by setting a new value in a configuration file or by
calling function LcmsSetProcessingParameter. Section 6 provides more details on the
different processing parameters, as well as explanations on how they can be changed.

Figure 4 Processing parameters from the XML string

 Once the processing parameters are set properly, the user may activate the different
processing modules and perform the road surface analysis. The function LcmsGetResult will
return the appropriate results in the XML string, depending on processing modules that are
selected by the user. The processing modules selection is done by calling functions
LcmsAddProcessingModuleToSelection or
LcmsRemoveProcessingModuleToSelection. The modules currently activated can be
retrieved with a call to function LcmsGetProcessingModuleSelection.
At this time, five processing modules are available in the library. Sections 6.2 to 0 describe
these processing modules in more details.

6.1 Processing Parameters

Table 2 lists all parameters that can be changed by the user before the data are processed for
distress analysis. Parameters whose name starts with string ``GeneralParam`` are global
parameters not related to a specific processing module. The processing parameters specific to
each processing module are described in details in Section 6.2 to 0.

There are two convenient ways to change the value of a processing parameter:
 Calling function LcmsSetProcessingParams;
 Manually editing the configuration file LcmsAnalyserParam.cfg.

It should be noted that the configuration file is optional. If the user wants to change a
parameter’s value using the configuration file, he must first create the file in the working folder
where the analyser library (LcmsAnalyserLib.dll) is located. Alternately, the user may call function
LcmsSetConfigFileName to specify the name of location of the parameter file (new function
available with LcmsAnalyserLib 4.3.0.0). Here are the general guidelines when manually editing
the configuration file:

 All characters that follow the symbol % are ignored.

 Empty lines are ignored.
 The first character string of a line is the name of the system parameter (the key). The key
name can’t be changed by the user. It must match one of the parameters listed that is
editable.
 Next to the key name is the value of the parameter. Key name and value must be
separated by spaces or tabs
 The value of any parameter can be manually edited by the user
 In case a key name is repeated on several lines, the value associated to this key name is
the one from the last line.

Parameters Value Description

GeneralParam_SensorImagesOverlap_pix int The overlap in pixel used to
merge the left and right images
together.
 Note: Setting a value to this
parameter will overwrite the value
already defined at the acquisition
level. See SensorOverlap_pix in
the ``Lcms Data Acquisition
Manual``.

Min: 0
GeneralParam_ResultImageResolution_mm float The resolution of 1 pixel in the
result images (in mm).

Min: 1mm (1mm resolution can

produce extra-large images,
Default: depending on the road section
4mm length). Due to Windows
restrictions, LcmsRoadInspect
processing software can’t display
1mm resolution images.
GeneralParam_ResultImageJpgSaveQuality integer Quality of the JPG result images.

Default: Min: 0%
75% Max: 100%
GeneralParam_OverlayImageJpgSaveQuality integer Quality of the JPG results images
(with results overlay).

Default: Min: 0%
75% Max: 100%
GeneralParam_ConfigurationAngleDeg float The configuration angle of the
sensor on the vehicle.
Note: Setting a value to this
parameter will overwrite the value
already defined at the acquisition
level.

Min: -45 degree

Max: +45 degree
GeneralParam_CentralBandWidth_mm integer The width of the central band, in
mm, as defined by AASHTO. See
Default: Figure 5.
1000mm
Min: 0mm
GeneralParam_WheelPathWidth_mm integer The width of each wheel path
band, in mm, as defined by
AASHTO. See Figure 5.
Default:
750mm Min: 0mm
GeneralParam_CurbDropoffSide integer This parameter is specific to the
Drop-off/Curb module. It indicates
for which side of the road the
drop-off/curb module will be
applied.

0: Passenger side.
Default: 1: Driver side.
0 2: Both sides.
GeneralParam_FilesAreAlphabeticallySortable Integer Users can choose any file naming
 convention to name the files they
collect during a survey, although it
is recommended that the list of
files is alphabetically sortable
(See LcmsSaveSurveyData in the
“Lcms Data Acquisition Manual”
for more details). If the list of files
Default: is not alphabetically sortable, then
1 that parameter MUST be set to 0.
GeneralParam_SubSamplingFactorStitchedProfile Integer The sub-sampling factor that is
used to compute the stitched
range profiles. The stitched range
profiles are down sampled along
the transversal axis of the road.

Default: Min: 8
8 Max: 512
CrackingModule_Parameters Parameters specific to the
cracking module. See Section 6.2.
LaneMarkingModule_Parameters Parameters specific to the lane
marking module. See Section 6.5.
PotholeModule_Parameters Parameters specific to the pothole
module. See Section 6.6.
MacroTextureModule_Parameters Parameters specific to the macro-
texture module. See Section 6.4.
RuttingModule_Parameters Parameters specific to the rutting
module. See Section 6.3.
DropoffModule_Parameters Parameters specific to the drop-
CurbModule_Parameters off & curbs module. See Section
6.7.
ResultRenderer_Parameters Parameters specific to the
rendering options when creating
the result images. See Section
6.16.
JointModule_Parameters Parameters specific to the joint
module. See Section 6.8.
RoughnessModule_Parameters Parameters specific to the
roughness module. See Section
6.10.
SlopeAndCrossSlopeModule_Parameters Parameters specific to the slope
and cross slope module. See
Section 6.11.
RavellingModule_Parameters Parameters specific to the
raveling module. See Section 6.9.
SealedCrackModule_Parameters Parameters specific to the sealed
crack module. See section 6.15.
Table 2 Processing parameters
 1 2 3 4 5

Figure 5 AASHTO bands definition.

6.2 Crack detection module

Description
The crack detection module is certainly the most important processing module. For any given
road section, the library will output the list of cracks with their associated severity (width). Crack
detection is performed from the range (3D) data image, for which a depth threshold is applied in
order to identify potential cracks. The depth threshold parameter is determined automatically by
the library using the local texture information of the road surface. The resulting potential cracks
image is then processed to remove lonely cracks, which are typically caused by asperities on the
road surfaces. The last step of the crack detection algorithm is to join together the remaining
cracks in order to form continuous segments. These final segments are the list of cracks saved in
the XML string.

Parameters
Table 3 lists the parameters that can be configured by the user for the crack detection module.

Parameters Value Description

CrackingModule_Sensitivity float This parameter became obsolete in
LcmsAnalyserLib 2.8.6.0.

Default: 1
CrackingModule_AutomaticPeakDetection integer Enable-disable the Automatic Peak Detection
threshold adjustment method (APD method).
The peak detection threshold is used to identify
potential cracks in the images. The threshold
defines the minimal depth for a potential crack
to be detected. When turned on, the APD
Default: method automatically determines the optimal
1(enable) threshold based on the texture of the road.
CrackingModule_UserDefinedPeakDetectionTh float The peak detection threshold (in mm) that is
resL_mm used for the left sensor when the APD method is
Default: disabled (see above).
2 mm
CrackingModule_UserDefinedPeakDetectionTh float The peak detection threshold (in mm) that is
resR_mm Default: used for the right sensor when the APD method
2 mm is disabled (see above).
CrackingModule_AutoPavementTypeDetection Integer Enable-disable the automatic pavement type
detection algorithm. The pavement type can be:
Asphalt, Concrete, Concrete with transverse
Default: grooves, Concrete with longitudinal grooves, or
0(disable) Highly textured.
CrackingModule_UserDefinedPavementType integer The pavement type, as defined by the user. This
setting will be ignored if the automatic pavement
type detection is enabled. Possible values are:
1: Asphalt
2: Concrete
3: Grooved concrete (transversally)
4: Grooved concrete (horizontally)
Default: 1 5: Highly textured (or porous)
CrackingModule_EdgeCrackingEnable integer Enable-disable the edge cracking detection.
Edge cracking are cracks located outside of the
lane limits. When enabling the edge cracking
detection mode, make sure to also activate the
Default: 0 curb-dropoff processing module to prevent
(disable) detecting cracks on the shoulder of the road.
CrackingModule_MinCrackLength_mm Integer The minimum length of a crack to be valid, in
millimeter. All cracks shorter than this value are
Default: not reported in the results.
175 mm
CrackingModule_MinCrackDepth_mm float The minimum depth of a crack on asphalt (in
millimeter). All cracks that have a depth smaller
Default: than this value are not reported in the results.
0mm
CrackingModule_MinCrackDepthConcrete_mm float The minimum depth of a crack on concrete (in
millimeter). All cracks that have a depth smaller
Default: than this value are not reported in the results.
0.75mm
CrackingModule_MinCrackDepthTinning_mm float The minimum depth of a crack on grooved
concrete (in millimeter). All cracks that have a
depth smaller than this value are not reported in
the results.
A special algorithm is implemented for crack
detection on grooved (tinned) pavement.
Grooves are pre-filtered using a spatial
Default: frequency filter that evaluates the distance
0mm between the grooves.
CrackingModule_WideCracks_mm Float The maximum width of a crack. Cracks wider
than this parameter are removed from the crack
2
Default: list
100mm
CrackingModule_DeepCracks_mm float The maximum depth of a crack. Cracks deeper
than this parameter are removed from the crack
3
Default: list
100mm
CrackingModule_FilterDeepANDWideCracks integer Determines if the deep and wide crack filtering
is performed using an AND operation (default)
Default: 1 or an OR operation. AND means that a crack is
removed if both its width and depth are greater
than the parameters defined by the user.
Table 3 User configurable parameters for the crack detection module.

XML output format

Figure 6 shows how the crack detection results are organized in the XML string. The <Unit>
element lists the unit definitions (meter, millimeter, etc…) for the different result entries. The
actual crack detection information is in the <CrackList> element. The crack list may contain
any number of <Crack>. A <Crack> has an identifier (<CrackID>), a crack length (<Length>)
and a list of connected <Node>. A <Crack> element always has at least two <Node>.
A <Node> is a point along a crack. It is defined by two coordinates (<X> and <Y>), a <Width>
value and a <Depth> value. The <Width> and <Depth> values are the average severity and
depth of the crack between two successive nodes.
The node coordinates <X> and <Y> are given with respect to the lower-left corner of the
result images (see LcmsGetResultImage documentation in Section 7.24). In order to
determine the exact match between the <X> and <Y> coordinates of a crack from the XML file
and the pixel coordinates of the same crack in the result images, one must use the
GeneralParam_ResultImageResolution_mm parameter (see Section 6.1).

2
Depending on parameter CrackingModule_FilterDeepANDWideCracks
3
Depending on parameter CrackingModule_FilterDeepANDWideCracks
Figure 6 XML Output format for the cracking processing module.
6.3 Rutting module

Description
The rutting processing module allows the user to retrieve the rutting information (rut depth,
rut width, cross-section, percent deformation, etc...) for a specific road section, at different
locations (for instance, at every 1m). Rutting computation is based either on:

 The ASTM E1703 standard: ``Standard Test Method for Measuring Rut-Depth of
Pavement Surfaces Using a Straightedge``.
 The taut wire (string line) method.
 The Brazilian method.
 The moving ruler line method.
 The Five-Point Rut Depth calculation (AASHTO R48-2).
No matter which rutting computation method is chosen, the rutting computation module
always computes two ruts: the left and right wheel path ruts. The interval between each rut
measurement can be configured by the user.

ASTM E1703 Standard

The ASTM Straightedge method is computed over left and right profiles, independently. The
profiles do not need to be stitched together. It should be noted that the LCMSAnalyser library
uses exactly the same algorithm as the Pavemetrics’s Laser Rut Measurement System (LRMS).
The ASTM method always looks for the longest rut in each profile. The rut depth is the
greatest distance between the straightedge and the pavement. In addition, the ASTM method
also computes the rut width and the cross-section. The percent deformation is also computed.
The ASTM method allows performing rut classification. Three different rut types can be
detected: short-radius single rut, large-radius single rut and short-radius multiple ruts. Note that a
rut that has a depth smaller than 5mm is categorized as no rutting. Figure 8 illustrates examples of
two different rut types: a ``short radius – multiple ruts`` on the left and a ``large radius rut`` on the
right.

Figure 7: Rut Extractor Parameter Description for the ASTM straight-edge method.
 Figure 8 Examples of Short radius - Multiple ruts (left) and large radius rut (right)

Taut wire (string line) method

The taut wire method can only be computed over a 4m stitched left-right profile (see Section
XXX). Figure 9 compares the straightedge method and the taut wire method. For the taut wire
method, “an imaginary wire is stretched across the 4m transverse profile enveloping the high
points and fixed at either end” (Austroads Test Method AG:AM/T009).
 Figure 9 Straightedge versus String line (taut wire) methods for rut computation (from Austroads Test method
AG:AM/T009).

Brazilian method
Figure 11 illustrates the Brazilian’s method for measuring rutting. By moving the Brazilian
rutting equipment, whose ruler length is fixed (see Figure 10), along the profile, the deepest value
obtained is chosen as the final rutting result. The Brazilian method can be computed on either the
left and right profiles (independently), or using the stitched profile.
 Figure 10 Brazilian rutting’s measurement equipment

Figure 11 Brazilian rutting’s method

Moving ruler line

The moving ruler method is a variation of the Brazilian method. In this case, the length of the
ruler will be changed from the defined length to 0mm at each displacement of the ruler along the
profile (see Figure 12). Then the deepest value will be the rutting value measured for that profile.
The moving ruler line can only be applied on a 4m stitched profile (see Section XXX).

Figure 12 Moving ruler method

Five-Point Rut Depth Calculation
The Five-point rut depth measurement was developed according to AASHTO standard practice
R48-10: “Determining Rut Depth in Pavements”. This method uses only 5 transverse profile
measurements at fixed location along the entire lane (even though the LCMS can use more than
4000 measurements per profile). Because the number of points is limited to only 5, this method is
not expecting to return accurate results. As expressed in AASHTO R48-10:
- “While this practice is based on a five-measurement transverse profile, more than five
measurements greatly improve the accuracy and enhance the likelihood of identifying
the maximum and average rut depth given survey vehicle wander and various rut
configurations”.
- “Technology is available to provide more than 1000 data points across the entire lane
width. With such a transverse profile measurement, algorithms can be applied that
remove texture effects, compensate for vehicle wander, and resolve a string-line rut
value for each wheel path. This is the preferred methodology for rut data collection.”

The transverse locations for the five-point measurement procedure are shown in Figure 13.
- D5 is the location of the left lane mark as detected by the LCMSAnalyser library.
- D1 is the location of the right lane mark as detected by the LCMSAnalyser library.
- D3 is the center of the lane
- D2 and D4 depend on the width values for the central band and the wheel path bands
(GeneralParam_CentralBandWidth_mm and
GeneralParam_WheelPathBandWidth_mm).
The rut depths are computed as shown in Figure 14.

Figure 13 The Five-Point Rut Depth method (AASHTO R48-10)

 Figure 14 Five-Point Rut Depth calculations (AASHTO R48-10)

Stitching left and right profiles

Some of the rutting methods described in the previous paragraphs require a single 4m
transverse profile to compute the rut parameters. This is the case for the taut wire method, the
Brazilian method on stitched profile, the moving ruler line method, and the five-point rut depth
calculation.

Two different methods can be used to build the stitched profile:

 Manual method:
o The laser profilers are never installed perfectly flat on the vehicle.
o Users have to manually determine the slope of the left and right profiles.
o The procedure to determine the left and right slopes is to first scan a flat
surface (for instance, a flat concrete slab) and then to adjust the slope
parameters (RuttingModule_LeftCorrectionSlope and
RuttingModule_RightCorrectionSlope) until the resulting stitched profiles
become flat
o Enabling both parameters RuttingModule_DisplayEnable and
RuttingModule_ExportRutProfileData in the configuration file can be very
useful to fine tune the adjustments of the slope parameters using the
LcmsRoadInspect software. See for instance Figure 15.
 Automatic method
o The manual method described in the preceding paragraph can lead to
imprecision if the scanned surface is not perfectly flat, or if the vehicle is
tilted.
o The automatic method will perform the stitching automatically using a
Slope&CrossSlope calibration file.
o The Slope&CrossSlope calibration procedure is described in the LCMS Data
Acquisition manual, Appendix H.
o Pavemetric’s IMUs and validation object are necessary to perform the
Slope&CrossSlope calibration procedure.
 o The calibration file should be copied on the acquisition computer, in the same
folder where the AcquisitionParams.cfg file is located.
o A Slope&CrossSlope license is not required to use the automatic stitching
method. However, Slope&CRossSlope will only be available if a
Slope&CrossSlope license is valid.
The automatic method will always be applied when a calibration is available. Start
LcmsRoadInspect and click on SystemInfo if you are not sure whether or not a calibration files is
available. Make sure that Geometric calibration and IMU calibrations are both available, with
calibration IDs different than 0. Start LcmsRoadInspect and click on SystemInfo if you are not sure
whether or not a calibration file is available. Make sure that Geometric calibration and IMU
calibrations are both available, with calibration IDs different than 0. See Figure 16.

Figure 15 Manual method to determine the left and right slopes for stitching the left and right profiles.
 Figure 16 Checking if whether or not a calibration is available.

Parameters
Table 4 lists the parameters that can configure by the user for the rutting processing module.
Parameters Value Description
RuttingModule_Method unsigned int The method used for rutting computation

0: Straightedge (ASTM)
1: Taut wire (string line)
Default: 0 2: Brazilian
3: Brazilian on stitched profile
4: Moving ruler on stitched profile
5: Five-point rut depth calculation
RuttingModule_EvaluationInterval_m float The interval (distance) between
successive rut measurements. For
example, if the interval is set to 2m and the
road sections length is 10m, then each
XML string will have 5 rut depth
Default: 1m measurements.
RuttingModule_FirstEvalPosition_m float Position of the first rut measurement in the
survey.

Default: Min. : 0m
0m Max. : Survey length (m)
RuttingModule_GageWidth_mm integer The width of the gauge used for measuring
the rut. See Figure 7.
Default:
40mm
RuttingModule_StraightEdgeLength_mm integer Applies only for ASTM method. The length
of the straightedge used for simulating the
Default: manual rut measurement. This parameter
2000mm is obsolete (LcmsAnalyserLib V3.5.3).
 The algorithm always searches for the
longest rut in the profile
RuttingModule_BrazilianRulerLength_mm integer Applies only for Brazilian method. The
length of the ruler bar used for measuring
Default: the rut.
1200mm
RuttingModule_DisplayEnable int Set this parameter to 1 to display the
0 rutting info over the result image.
RuttingModule_ExportRutProfileData int Set this parameter to 1 in order to export
the X-Z profile points used to compute the
rutting parameters. The profiles are
exported in the XML files as a vector. The
coordinates of the straightedge and the
gauge are also exported. Note that this
function outputs down-sampled and
0 normalized profiles. It should only be used
to see the shape and position of the ruts.
Data points located outside of the lane
marks are not exported.
RuttingModule_LeftCorrectionSlope float This parameter sets the slope of the left
transverse profile. The sensors are never
perfectly flat on the vehicle. The slope
correction allows correcting for non-flat
profiles. The slope must be set to a proper
value when computing ruts using a merged
stitched profile (modes 1, 3, 4), otherwise
the stitched profile may have a V-shape (or
0.0 inverted V-shape).
RuttingModule_RightCorrectionSlope float This parameter sets the slope of the right
transverse profile.
0.0
RuttingModule_FilterKernel_mm int This parameter controls the length of the
filtering kernel in mm. Profile filtering is
necessary to avoid cracks, small
125 asperities, etc…
Table 4 User configurable parameters for the rutting module.

XML output format

Figure 18 shows how rut measurement information is organized in the XML result string. The
<Unit> element lists the unit definitions (meter, millimeter, etc…) for the different result
entries. The actual rut measurement information can be found in the <RutMeasurement>
elements. The number of <RutMeasurement> available depends on two parameters:
1) The length of the road section being processed and
2) The RuttingModule_EvaluationInterval_m processing parameter.

Each <RutMeasurement> element contains different entries:

 <Position> gives the position of the measurement along the longitudinal direction,
with respect to the beginning of the survey.
 <ProfileIndex> gives the index of the profile that was used to compute the rut
parameters. The index is given for the current road section. The corresponding profile
can be retrieved with a call to LcmsGetStitchedRngProfile
  <Laneside> indicates if the measurement is related to the left or right wheel path
of the lane.
 <Depth> and <Width>
 <CrossSection> is the area computed between the straightedge and the
pavement surface.
 <Type> gives the rut type.
o 0 = ASTM : no rutting (rut depth <5 mm),
o 1 = ASTM : Short Radius - Multiple Ruts.
o 2 = ASTM : Short Radius – Single rut.
o 3 = ASTM : Large radius.
o 4 = Brazilian rut : No classification.
o 5 = Taut wire: Full lane rut (See Profile A in Figure 9).
o 6 = Taut wire: Half lane rut (See Profile B in Figure 9).
o 7 = Moving ruler line.
o 8 = 5-Pt Rut Depth.
 <PercentDeformation> is the deformation is the road profile compared to the
straight-line segment that joins the two profile extremity points together. The percent
deformation is computed according to AASHTO Standard Practice PP 69-10. The
straight-line length is subtracted from the profile length. The result is divided by the
straight-line length, and then multiplied by 100. (AVAILABLE starting from
LcmsAnalyserLib 4.5.X.X and above). Note that for rutting methods based on stitched
profile, the percent deformation value is duplicated for the left and right ruts.
 <RutProfileData> is the X-Z data vector (down-sampled and normalized) used to
compute the rutting values (optional, this element is saved only if
RuttingModule_ExportRutProfileData is set to enable (1)):
o <RutProfileDataSize>: Number of X-Z points in the vector.
o <RutProfileDataX>: All X coordinates separate with a space.
o <RutProfileDataZ>: All Z coordinates separate with a space.
o <StraighEdgeCoords>: This element contains two points that define the
position of the straightedge line.
o <MidLineCoords>: This element contains two points that define the
position of the midline (ruler line).

Figure 17 shows a rut profile data vector X-Z displayed as a graph in Excel (including the
straightedge and midline coordinates).

Figure 17 Example of a rut profile vector displayed in excel (blue = data points, red = straightedge line, green =
midline)
Figure 18 XML Output format for the rutting processing module (for the case where parameter
RuttingModule_ExportRutProfileData is disabled)
6.4 Macro-texture module

Description
The macro-texture processing module measures the pavement surface texture in each of the
five AASHTO bands: the central band, the two wheel path bands, and the two outside bands. The
algorithm is based on a “digital sand patch method” that computes the air void-content volume
between a digital 3D surface and the road surface itself. The output is a Mean Texture Depth
(MTD) value that is similar to the manual sand patch method described in ASTM E965 : ``Standard
Test Method for Measuring Pavement Macrotexture Depth Using a Volumetrics Technique``.

Parameters
The processing parameters for the macro-texture module are listed in Table 5:
Parameters Value Description
MacroTextureModule_ReportingMode integer The reporting mode for the macro-texture
measurements:
0 (standard): The macro-texture values in
each band are averaged along the
complete road section length.
Default: 0 1 (detailed): Intermediate macro-texture
(standard) values are computed every 250mm.
GeneralParam_CentralBandWidth_mm integer The width of the central band, in mm, as
defined by AASHTO.
Default:
1000mm Min: 0mm
GeneralParam_WheelPathWidth_mm integer The width of each wheel path band, in mm,
as defined by AASHTO.
Default:
750mm Min: 0mm
MacroTextureModule_Algorithm int 0: The output is MTD.
Default: 0 1: The output is MPD and RMS (Root
Mean Square) Roughness
Table 5 User configurable parameters for the macro-texture module.

XML output format

Figure 19 and Figure 20 show the <MacroTextureInformation> element that is saved
in the XML string when the macro-texture module is enabled. As for the other processing
modules, the <Unit> element first lists the different metric units in which the results are
expressed.

The <Bands> element reports the six limit positions for the five AASHTO bands. The band
limit positions depend on parameters GeneralParam_CentralBandWidth_mm and
GeneralParam_WheelPathWidth_mm, as well as on the positions of the left and right lane
limits.

Next, the XML string will contain either one or several <MacroTextureMeasurement>
elements. The “standard” reporting mode has only one element, while the “detailed” reporting
mode will generate several elements. Each <MacroTextureMeasurement> element contains
the macro-texture values for each of the five bands:
 <Position> gives the position of the measurement along the longitudinal
direction, with respect to the beginning of the survey.
 <Length> is the longitudinal length considered for the macro-texture computation.
The possible values are:
o Road section length (5m, 8m, 10m, etc…) for the “standard” reporting mode,
o 0.25m for the “detailed” reporting mode.
 <BandReport> gives the results for each of the 5:
o <BandIndex>: The band index (1, 2, 3, 4 or 5).
o <MTD>: The Mean Texture Depth (MTD) value computed for the
corresponding band.

Figure 19 XML output format for the macro-texture processing module (algorithm is MTD)
Figure 20 : XML output format for the macro-texture processing module (algorithm is MPD)
6.5 Lane marking module

Description
The lane marking module detects and returns the positions of the left and right lane marks on
the road. It should be noted that other processing modules exploit the marking lane information.
For instance, the lane marks locations are used by the rutting module so that both wheel path
ruts do not exceed the actual transversal road width of the traffic lane. In the same way, the
crack detection module detects cracks only within the two marking lanes. Also, lane marking
positions are necessary to determine the AASHTO band positions used for the macro-texture
measurements.

Parameters
Table 6 lists the processing parameters available to control the lane marking processing
module.
Parameters Value Description
LaneMarkingModule_Mode integer This parameter specifies the lane marking
detection mode.
0: Automatic detection is enabled. In case
no lane marking are found, the two lane
marks are centered in the image using the
road width parameter. If only one lane
marking is detected, the other lane
marking is positioned relatively to the lane
mark that was found using the road width
parameter. The road width parameter is
ignored in the case where both lane marks
are detected.
1: Automatic detection is disabled. The
user must specify the position of the two
lane marks.
2: Automatic detection is disabled. The
lane marks are centered in the images
using the road width parameter.
3: Automatic detection is enabled only for
the left lane mark. The right lane mark is
positioned relatively to the left lane mark
using the road width parameter.
4: Automatic detection is enabled only for
the right lane mark. The left lane mark is
positioned relatively to the right lane mark
using the road width parameter. Similar to
Default: 0 mode 3 for users driving on the left side of
the road.
LaneMarkingModule_UserSpecifiedPosLeft_mm float Position of the left lane mark as defined by
the user. This parameter is considered
only when the lane marking detection
Default: -1 mode is set to 1 (automatic detection is
disabled).
LaneMarkingModule_UserSpecifiedPosRight_mm float Position of the right lane mark as defined
by the user. This parameter is considered
only when the lane marking detection
mode is set to 1 (automatic detection is
Default: -1 disabled).
LaneMarkingModule_RoadWidth_mm float Total width for the lane road. This
Default: parameter is ignored in the case where the
3600mm two lane marks are automatically detected.
LaneMarkingModule_RoadMarkingPosOffset_mm float Moves the lane marks toward the center of
the road. This parameter is useful to
eliminate false crack detections at the
Default: edge of the pavement and the painted lane
0mm marks.
LaneMarkingModule_AutoDetectModeWithMemory Integer This parameter is used only for these
automatic detection modes. When it is set
to 1, the lane mark information (positions,
types) of the previous processed road
section is stored in the memory. This info
will help the library place the lane mark in
the following road section if the lane mark
Default: 1 is not present or detected.
LaneMarkingModule_ModeWithMemory_SectionRa Integer This parameter defines the number of
nge road sections affected/remembered in
AutoDetectModeWithMemory when the lane
Default: 2 mark is not present or detected.
Table 6 User configurable parameters for the lane marking module.

XML output format

Figure 21 shows how lane marking detection results are organized in the XML result string.
The lane marking detection information can be found in the two <LaneMark> elements.
 <LaneSide> indicates if the position is given for the left or right lane mark.
 <Position> indicates the position of the lane mark, with respect to the left border
of the result image.
 <Type> indicates the type of the lane mark.
o Type 0: there is no lane mark found.
o Type 1: a lane mark detected.
o Type 2: lane mark not found, but it takes the position of the previous
detected lane mark (available only when the parameter
LaneMarkingModule_AutoDetectModeWithMemory is activated).
o Type 3: the user defines its position or it has a default position (when using
LaneMarkingModule_Mode 1 and 2).

Figure 21 XML Output format for the lane marking processing module.
6.6 Potholes module

Description
This processing module detects the potholes on the road surface. The pothole’s
characteristics (maximum depth, severity, bounding box and perimeter) are saved in the XML file.
It should be noted that all areas in which a pothole is detected are excluded from the crack
detection results, making it impossible to detect cracks inside a pothole. The pothole’s severity is
determined according to the criteria defined by the FHWA (Federal Highway Administration) in
their ``Distress Identification Manual for the Long-Term Pavement Performance Program``
published in 2003.

Parameters
Currently, only the pothole’s minimum width parameter can be configured by the user.
Parameters Value Description
PotholeModule_MinWidth_mm integer This parameter defines the minimum diameter a pothole
must have to be detected. The 150mm default value is
set according to the ``Distress Identification Manual for
the Long-Term Pavement Performance Program``
Default: 150 published by FHWA (Federal Highway Administration).
mm
PotholeModule_MaxWidth_mm Integer This parameter defines the diameter of the largest hole
that can be detected as a pothole.
Default: 750
mm
Table 7 User configurable parameters for the pothole module.

XML output format

Figure 22 shows how pothole detection results are organized in the XML result string. The
positions (bounding box and perimeter) are given with respect to the lower-left corner of the road
section result image (see LcmsGetResultImage documentation in Section 7.24). In order to
determine the exact match between the position of a pothole in the XML file and the pixel
coordinates of the pothole in the result images, one must use the
GeneralParam_ResultImageResolution_mm parameter (see Section 6.1). For each
pothole detected in the road section, its characteristics and description are contained in the
<Pothole> element:
 <MaximumDepth> is the maximal depth of the pothole (below the pavement
surface).
 <AverageDepth> is the average depth of the pothole.
 <Area> is the area in square meter.
 <Severity> is defined according to FHWA Distress Identification Manual:
o Low: < 25 mm deep.
o Moderate: 25mm to 50mm deep.
o High: > 50 mm deep.
 <BoundingBox> is the X,Y coordinates of the box that surrounds the pothole
 <Perimeter> gives the list of points (<Node>) that form the pothole’s perimeter.
The perimeter is useful mainly for drawing purposes.

Figure 22 XML Output format for the pothole processing module.

6.7 Drop-off and Curb module

Description
The module detects and returns the position and the height of the drop-off (i.e. edge drop-
off, or shoulder drop-off4) on the road (if available). This information may be exploited by other
processing modules. So far, the drop-off/curb locations are used to re-positioning the actual
transversal road width of the traffic lane by comparing with the lane marks positions. The module
can detect the drop-off/curb on both sides of the road. The position and height of the drop-
off/curb found on the road section will be written in the XML result file. User can choose where
place the first measurement and set the interval value between the successive measurements.

Figure 23 Pavement Drop-off Figure 24 Pavement Curb

Parameters
The interval at which the library measures the drop-off/curb is configurable. The drop-
off/curb data can be measured at every 10cm, 1 m, or 10 m, etc.

Parameters Value Description

DropoffModule_FirstEvalPosition_m float This parameter specifies the position of the
first measurement of the drop-off
Min. value: 0m.
Max. value: RoadSectionLength_m

Default: 0m
DropoffModule_EvaluationInterval_m float This parameter specifies the interval
between the successive drop-off
measurements.
Min. value:

4
“Shoulder” means the portion of a highway that provides lateral support to the roadway and that may accommodate
emergency vehicles. “Shoulder drop-off” means the vertical differential, where the paved surface of the roadway is higher than the
surface of the shoulder, between the paved surface of the roadway and the paved or non-paved surface of the shoulder.
 AcquisitionResolution_mm /1000
Max. value: RoadSectionLength_m

(See LCMSDataAcquisition User Manual

for a definition of those two system
Default: 1m parameters).
DropoffModule_MinHeightDropoff_mm float The minimun height to determine whether
the pavement dropoff is detected.
Defaut:
12.5 mm
CurbModule_FirstEvalPosition_m float This parameter specifies the position of the
first measurement of the curb
Min. value: 0m.
Max. value: RoadSectionLength_m

Default: 0
CurbModule_EvaluationInterval_m float This parameter specifies the interval
between the successive curb
measurements.
Min. value:
AcquisitionResolution_mm /1000
Max. value: RoadSectionLength_m

(See LCMSDataAcquisition User Manual

for a definition of those two system
Default: 1m parameters).
CurbModule_MinHeightCurb_mm float The minimum height to determine whether
the curb is detected.
Default:
22.5 mm
DropoffModule_LaneLimitOffset_mm int Moves the lane limit toward the center of
the road. This parameter is useful to
Default: eliminate false crack detections on drop-
150 mm off.
CurbModule_LaneLimitOffset_mm int Moves the lane limit toward the center of
the road. This parameter is useful to
eliminate false crack detections on the
curb of the pavement.

*:Lib. Version 3.5.33.0: The default setting

Default: is now 300mm. Previous default setting
300 mm* was 250mm.
Table 8 Configurable drop-off and curb parameters

XML output format

Figure 25 shows an example in which the drop-off/curb detection results are organized in the
XML result string. The drop-off information can be found in the <DropoffInformation>
element which contains three sub elements: <Unit>, <Measurements> and <Perimeter>.
The measurement unit of the X-position, Y-position and height of the drop-off are indicated in the
subs elements of <Unit> : <PositionX>, <PositionY> and <Height> respectively.
The <Measurements> element includes the X, Y-position and height values of the drop-offs
found at the specific places on the road which is defined by user through the parameters:
DropoffModule_FirstEvalPosition_m and
DropoffModule_EvaluationInterval_m. The <Perimeter> element contains the
perimeters of all drop-offs located on the processed road section.
The same layout is applied for curb detection results. The <CurbInformation> element
contains three sub elements: <Unit>, <Measurements> and <Perimeter>.

Figure 25 XML Output format for the drop-offs/curbs processing module

6.8 Joints Module for concrete pavement

Description
This processing module detects the transversal and longitudinal joints of concrete pavements.
The position, the length, perimeters and the faulting value of each transverse joint are saved in
the XML file. For the longitudinal joints, only the position and the length are computed and saved
in the XML file. It should be noted that areas in which there is a joint are excluded from the crack
detection results, making it impossible to detect cracks inside a joint. In order to activate this
module, users have to set CrackingModule_AutoPavementTypeDetection to 1 in
LcmsAnalyserParam.cfg5.

Parameters
Three parameters can be configured when using the Joint detection module. These are the
transversal interval (JointModule_EvalPositionDistance_mm), the footprint
(JointModule_MeasurementDistance_mm), and the average transversal windows width
JointModule_AveragingWindowWidth_mm. These three configurable parameters
correspond with A, B and C respectively as shown in Figure 26 below.

Parameters Value Description

JointModule_EvalPositionDistance_mm float This parameter specifies the interval
between the successive faulting
measurements on a transverse joint.

Default: Min. value: 100mm.

500mm Max. value: RoadSectionWidth_mm
JointModule_MeasurementDistance_mm float This parameter specifies the distance
between two measured points on either
side of a transverse joint.

Default: Min. value: 50 mm

300mm Max. value: 500 mm
JointModule_AveragingWindowWidth_mm float This parameter specifies the average width
of the transversal windows in which the
library get sampling data points to
measure the faulting.

Default: Min. value: 1mm.

200mm Max. value: RoadSectionWidth_mm
JointDetectorModule_MinLength_mm_Longi Float The minimal length for longitudinal joints.
Shorter joints are removed from the list of
Default: results.
1500mm
JointDetectorModule_MinLength_mm_Trans Float The minimal length for transversal joints.
Shorter joints are removed from the list of
Default: results.
300mm

5
In fact, if the users are certain that the type of pavement being currently processed is concrete; they can ignore the
CrackingModule_AutoPavementTypeDetection parameter and set the CrackingModule_UserDefinedPavementType to 2 (or 3 or 4 –
see Table 3) in order to activate the Joint Module.
JointDetectorModule_MinJointAngle_degree Float These two parameters define the angle
_Trans, limits for a joint to be considered
JointDetectorModule_MaxJointAngle_degree Default: transversal. 0 degree means a perfectly
_Trans, [-12.5,12.5] transversal (horizontal) joint.
deg.
JointDetectorModule_MinJointAngle_degree Float These two parameters define the angle
_Longi, limits for a joint to be considered
JointDetectorModule_MaxJointAngle_degree Default: longitudinal. 90 degrees means a perfectly
_Longi, [80,100] longitudinal (vertical) joint.
deg.
JointDetectorModule_MinPercent_Trans_Int Unsigned These two parameters define the minimum
int confidence level (in percentage) for the
JointDetectorModule_MinPercent_Trans_Rn transversal joint detection in the intensity
g and the range respectively. These
Default: 60 parameters will determine whether the
detected candidate can be considered as a
transversal joint.
JointDetectorModule_MinPercent_Longi Unsigned This parameter define the minimum
int confidence level acceptable (in
percentage) for the longitudinal joint
Default: 60* detection.
70**
*40 was set for the previous version.
** since Lib version 4.6.3.1 (2015-09-24)
Table 9 Configurable joint of concrete pavements parameters

C
A

Figure 26 Notations of the module’s parameters

XML output format
Figure 27 shows how joints and faulting detection results are organized in the XML result
string. The faulting is calculated for the transversal joints only. The results are saved in the
<ConcreteJointInformationElement> . The first element is the <Units> element
which specifies the units used to output the different results. Then, the (X,Y) coordinates of the
start and end points), the transversal length as well as the faulting measurements of each
detected transversal joints are saved in the <JointList> element. The vertical joint ( or
longitudinal joint) are saved under the <VerticalJointList>. All (X,Y) coordinates are
returned with respect to the lower-left corner of the road section result image (see
LcmsGetResultImage documentation in Section 7.24). In order to determine the exact match
between the position of a joint in the XML file and its coordinates in pixel in the result images, one
must use the GeneralParam_ResultImageResolution_mm parameter (see Section 6.1).
It’s worth noting that the -10000 value stands for the invalid/out of range data.

Figure 27 XML Output format for joint processing module

6.9 Raveling module (optional)

Description
Raveling is defined has the “wearing away of the pavement surface caused by dislodging of
aggregates particles and loss of asphalt binder. Raveling ranges from loss of fines to loss of some
coarse aggregate and ultimately to a very rough and pitted surface with obvious loss of
aggregate” (source: Distress Identification Guide, US Dept of Transportation, Federal Highway Administration).

Figure 28 explains the raveling algorithm that is implemented in the LCMS library. The raveling
index is computed for each square, and the results are reported in the XML files.

Figure 28 Raveling algorithm

Parameters
Table 10 lists the different parameters that can be configured for the raveling processing
module.
Parameters Value Description
ResultRenderer_RavelingDisplay int Enables the raveling display in the output
images. When enabled, the squares will be
colored light blue, dark blue or red based
on the severity of the raveling index
Default: 0 (0=disable, 1=enable). See Figure 29 for
an example. (OBSOLETE)
ResultRenderer_EnableRavelingDisplay int Enables the raveling display in the output
images. When enabled, the squares will be
colored light blue, dark blue or red based
on the severity of the raveling index
Default: 0
 (0=disable, 1=enable). See Figure 29 for
an example.

ResultRenderer_EnableRavelingZoneDisplay int Enables the display of raveling numbers in

the output images. When enabled, the
Default: 0 AVC, RPI or RI values are displayed in
each zone (square) used to compute the
raveling values. See Figure 30 for an
example.
ResultRenderer_RavelingZoneType_RI_AVC int Determines if the value displayed in each
_RPI raveling zone is: the RI (0), the RPI (1) or
the AVC (2).
ResultRenderer_EnableRavelingZoneDisplay
Default: 0 must be enabled.
ResultRenderer_RavRate1_cm3_m2 float Sets the low threshold for the Raveling
Index. This threshold is used only for
Default: 150 display purposes only; it does not affect
cm3/m2 the raveling index values.
ResultRenderer_RavRate2_cm3_m2 float Sets the intermediate threshold for the
Raveling Index. This threshold is used only
Default: 300 for display purposes only; it does not affect
cm3/m2 the raveling index values.
ResultRenderer_RavRate3_cm3_m2 float Sets the high threshold for the Raveling
Index. This threshold is used only for
Default: 500 display purposes only; it does not affect
cm3/m2 the raveling index values.
RavelingModule_Threshold_cm3_m2 float The threshold used to calculate the
<AffectedPercentage> result.
Default: 100
cm3/m2
Table 10 Configurable parameters for the raveling processing modules.
 Figure 29 Example of a raveling overlay result when ResultRenderer_RavelingDisplay is enabled.

Figure 30 Example of a raveling overlay result when ResultRenderer_EnableRavelingZoneDisplay is enabled and

ResultRenderer_RavelingZoneType_RI_AVC_RPI is set to 0.

XML output format

The raveling results reported in the XML are global (per road section) and local (per square).
Global results include the <RavelingIndicator> and the <AffectedPercentage>:
 <RavelingIndicator>: The average raveling index for the whole image.
 <AffectedPercentage>: The percentage of squares that are above the raveling
threshold
Local results include:
 <X> and <Y> coordinates of the local square in the image (left-bottom corner)
 <AVC>: The Air Void content (cm3/m2)
 <RPI>: The Road Porosity (cm3/m2)
 <RI>: The Raveling Index (cm3/m2)
 <RI_Area>: The area of the local square that is affected with raveling, in square
millimeters.

Figure 31 XML format for the raveling module.

6.10 Roughness module

Description
The roughness module can be used in two different ways:
- Compute and save the longitudinal profiles of the road, and/or
- Compute the International Roughness Index (IRI) from the measured longitudinal profiles.

Accordingly, users have two options: they can retrieve the raw longitudinal profiles and then
calculate their own Roughness Index (which may be different than the well-known IRI) using any
software or method, or they can compute the IRI values for the longitudinal profiles using the
LCMS software.

As with other processing modules, the users may use either the LcmsRoadInspect software to
get the longitudinal profiles and the IRI values, or they may develop their own software using the
LcmsAnalyserLib library.

Computing and saving the longitudinal profiles using LcmsRoadInspect

The LCMS computes two (usually one for each wheel path) longitudinal profiles of the road
using the 3D data points AND the vertical accelerations stored in the FIS files of a survey. The
acceleration data will only be saved if the system is equipped with the optional IMU modules.

In order to generate the longitudinal profiles using the LcmsRoadInspect software, users must
first load a survey using the open button. If your LCMS license allows the Roughness module, a
start button will appear at the bottom right of the user interface (see Figure 32). Click on the start
button and a popup window will prompt you to enter the start and end sections of the survey you
want to process. Once the selection is made, click the start button and the longitudinal profiles
will be generated and saved in the folder that has been selected. The files are saved in PPF or ERD
file format (see Table 11, parameter: RoughnessModule_CreateERDfile). The file
formats PPF and ERD are both compatible with the Proval software (available at
http://www.roadprofile.com). Proval is the most commonly used software to view and analyze
pavement profiles.
 Figure 32: Snapshot of LcmsRoadInspect with the Roughness module (Long. Profile) enabled.

Computing and saving the longitudinal profiles using the analyser library
(LcmsAnalyserLib)
Alternately, the users may extract the longitudinal profiles using their own software (using the
functions available in the LcmsAnalyserLib library). In that case, the user will have to call functions
such as LcmsComputeLongitudinalProfile, LcmsGetLongProfileElevation,
LcmsWaitComputeLongProfileCompletion, etc. These functions are described in
Section 7.

Computing the IRI using LcmsRoadInspect

The procedure to compute the IRI values using LcmsRoadInspect is slightly different than the
one described above for computing only the longitudinal profiles. After loading the data, the user
must select the Proc. Multiple button (see Figure 33) in order to compute the IRI values and save
the results in the XML files. The Proc. Multiple button allows processing all files of a survey for all
processing modules that are activated (cracking, lane marking, rutting, etc…). Note that the IRI
values will only be computed and saved if the IRI option is selected in the list of available
processing modules. The longitudinal profiles (PPF or ERD files) are also saved with the XML files.
 Figure 33 Snapshot of LcmsRoadInspect for computing the IRI values.

When the processing starts, the software first computes the full longitudinal profiles of the
survey. Note that during that time, no result images will be displayed. Nevertheless, the software
is not frozen and the analysis time and the progress are still displayed in the main software
window (see Figure 34). Once the longitudinal profile is ready, the calculation of the IRI values is
performed on each road section and the result image are displayed as soon as they are ready.
 Figure 34 Analysis time and progress status are displayed while computing the longitudinal profiles.

Computing the IRI using the analyser library (LcmsAnalyserLib)

As explained above, the computation of IRI values always requires that the longitudinal is
available. When coding their own software, users must first call
LcmsComputeLongitudinalProfile and then wait for the process to be done. When the
longitudinal profile is available, users can retrieve either the global IRI value for the survey using
LcmsGetLongProfileIRIvalues, or they can call LcmsProcessRoadSection to compute the IRI
values of each individual road section. In the latter case, the IRI values are saved in the XML files.

Parameters
The parameters that can be modified for the processing of the longitudinal profiles are listed
in Table 11:
Parameters Value Description
RoughnessModule_EnableLowpassFilter Integer This parameter is used to disable (0) or
enable (1) the low pass filtering of the
Default: 1 longitudinal profiles.
RoughnessModule_LowPassFilterCutoff_Hz Integer This parameter is used to specify the cutoff
frequency (in Hertz) of the Butterworth
Default: filter if low pass filtering is enabled.
30Hz
RoughnessModule_EnableHighpassFilter Integer Set this parameter to 1 to enable the high-
pass filtering. Used mainly for analysis and
Default: 0 certification.
RoughnessModule_HighPassFilterCutoff_m Float Used to specify the cutoff wavelength (in
meter) of the high-pass filter.
Default: 91
RoughnessModule_EnableBridgingFilter Integer This parameter is used to disable (0) or
enable (0) the bridging filter. This filter
simulates the bridging action of a tire and
Default: 0 helps eliminating narrow dips. The filter is
applied longitudinally and transversally.
RoughnessModule_BridgingFilterBaseLength_mm Float This parameter is used to set the base
length (footprint) of the bridging filter.
Default:
70 mm
RoughnessModule_BridgingFilterPenetrationDept Float This parameter is used to set the target
h_mm penetration depth of the bridging filter.
Default: Usually, this parameter is set to a value
1 mm between 0.5 to 1.0 mm.
RoughnessModule_OutputResolutionMode Integer This parameter is used to select the output
resolution of the longitudinal profiles.
0: use the same resolution as the
acquisition step (typically 0.005 m).
1: use the resolution specified by the
Default: 0 OutputResolution_m parameter.
RoughnessModule_OutputResolution_m Float This parameter specifies the resolution of
the longitudinal profiles (in meter) if the
Default: OutputResolutionMode parameter is 1.
0.25 m
RoughnessModule_BelowSpeedThreshold_kmh Float This parameter specifies the minimum
speed for which the elevation profile is
considered valid. A local processing will be
Default: applied to this section and it will be
25.0 km/h reported in the summary file(s).
RoughnessModule_SummaryInterval1_m Float This parameter specifies the interval in
meter used to report the IRI values for the
Default: 0.0 first summary file using SI units. The file is
(no file saved in “csv” format (Excel compatible).
created)
RoughnessModule_SummaryInterval2_m Float This parameter specifies the interval in
meter used to report the IRI values for the
Default: 0.0 second summary file using SI units. The
(no file file is in “csv” format.
created)
RoughnessModule_SummaryInterval1_mile Float This parameter specifies the interval in
mile used to report the IRI values for the
Default: 0.0 first summary file using imperial units. The
(no file file is in “csv” format.
created)
RoughnessModule_SummaryInterval2_mile Float This parameter specifies the interval in
mile used to report the IRI values for the
Default: 0.0 second summary file using imperial units.
(no file The file is in “csv” format.
created)
RoughnessModule_OffsetFromMiddleOfLane_m Float This parameter specifies the longitudinal
profiles measurement position. For
example, a value 0.875 (meter) means that
the left elevation profile will be measured
0.875 m to the left of the lane center and
that the right elevation profile will be
Default: measured at 0.875 m to the right of the
0.875 m lane center. June 2015: This parameter
will become obsolete. Users should
rather enable
 RoughnessModule_AutoOffsetFromMiddleOf
Lane and change the width of the central
and wheel path bands.
RoughnessModule_AutoOffsetFromMiddleOfLane Integer When set to 1, the library uses the band
width parameters
(GeneralParam_CentralBandWidth_mm
and GeneralParam_WheelPathWidth_mm)
to determine the longitudinal profiles
Default: 0 measurement position.
RoughnessModule_CreateERDfile Integer When set to 1, elevation profiles will also
be saved in the ERD format.
Default: 0
RoughnessModule_CreateCombinedERDfile Integer Set to 1 to enable the creation of a
combined (left and right elevation profiles
Default: 0 in the same file) ERD file.
RoughnessModule_CreatePPFfile Integer When set to 1, elevation profiles in PPF
format will be created. Set to 0 to disable.
Default: 1
RoughnessModule_XMLreportingInterval_m Float This parameter is used to specify the
reporting interval for the IRI values in the
Default: XML files. Valid value range is from 1.0 m
1.0 m to road section length.
Table 11 User configurable parameters for the roughness module

XML output format

Figure 35 shows how roughness information is organized in the XML result string. The
roughness information section begins with the element <RoughnessInformation>. The sub-
element <Unit> specifies the unit used to output the results. The element
<LongitudinalInterval> specifies the interval over which the IRI will be averaged and
reported. The roughness measurements section begins with the element
<RoughnessMeasurements>. The sub-element <BelowSpeed> will be “yes” if the speed
went below the specified below speed threshold (default: 25 km/h) or “no” if not. Each series of
roughness measurements starts with the sub-element <Roughness> and includes the
transversal position (<PositionX>), the number of values in the series (<NbrValues>) and
the values (<IRI>). Note: The longitudinal profile processing must have been done on the
selected survey prior to the processing for the other defects/characteristics of the road in order to
have the roughness information included in the XML files.
 Figure 35: XML output format for roughness module.

Summary file format

As seen in Table 11, summary files in “csv” (comma-separated values) can also be created.
These files, which can be easily read using Excel, summarize the IRI analysis. For instance, they
contain the number of below speed sections, the average speed of the survey, the overall IRI
value, and the local IRI values at different intervals. For a same survey analysis, the users can
choose to report IRI values at different distance: for instance, every 10m
(RoughnessModule_SummaryInterval1_m 10) AND every 100m
(RoughnessModule_SummaryInterval1_m 100). See Figure 36 for an example of a summary file
where the IRI values are reported every 10 meters (RoughnessModule_SummaryInterval1_m 10).
Figure 36: Summary file example.
6.11 Slope and cross-slope module

Description
This processing module measures the slope, the cross-slope and the radius of curvature of the
road. It outputs the slope, cross-slope, curvature, longitudinal measurement position and validity
flag in the XML file. It simulates the process of placing a digital level on a 2.7 meter (user
configurable) straightedge with 5 cm (user configurable) diameter stand-off. See Figure 37 for an
illustration. Note that the sensors must be equipped with IMUs in order to use this module and
that the system should be calibrated using the calibration object.

Figure 37: Actual straightedge and digital level used to measure slope and cross-slope (illustrated). For slope
measurement, the straightedge is rotated 90°.

Parameters
The parameters that can be modified for the processing of slope and cross-slope are listed in
Table 12.

Parameters Value Description

SlopeAndCrossSlopeModule_EvaluationInte float The interval (distance) between
rval_m successive slope, cross-slope and
curvature measurements. For example, if
the interval is set to 2m and the road
Default: sections length is 10m, then each XML
1m string will have 5 slopes/cross-
slopes/curvature measurements.
SlopeAndCrossSlopeModule_FirstEvalPositi float Position of the first slope, cross-slope and
on_m curvature measurements in the survey.
Default: Min. : 0m
0m Max. : Survey length (m)
SlopeAndCrossSlopeModule_StraightEdgeL int The length of the straightedge used for
ength_mm Default: simulating the manual slope/cross-slope
2 700 mm measurement.
SlopeAndCrossSlopeModule_DiskWidth Int Diameter of the stand-off used for
Default: simulating the manual slope/cross-slope
50 mm measurement.
SlopeAndCrossSlopeModule_UserDefCalibI Int User can define the calibration ID number
D of SlopeAndCrossSlope module. The ID is
Default:0 used for loading the right calibration
information.
Table 12: User configurable parameters for the slope and cross-slope module.
XML output format
Figure 38 shows how slope and cross-slope measurements are organized in the XML result
string. The slope and cross-slope results section begin with the element
<SlopeCrossSlopeInformation>. The sub-element <Unit> specifies the unit used to
output the results. Each slope measurement begins with the element <SlopeMeasurement>
and includes the value of the slope (<Slope>), the validity of the measurement (<Valid>), the
overlap flag (<InsufficientOverlapWarning>), the position from the beginning of the
survey at which the measurement is taken (<SurveyPosition>) and the radius of curvature
(<Curvature>). A value of 1 for the element <Valid> means the measurement is valid and 0
indicates an invalid measurement. A value of 1 for the element
<InsufficientOverlapWarning> indicates the overlap is not sufficient to provide the best
possible estimation of the slope but not necessarily that it is not good. The cross-slope
measurement begins with the sub-element <CrossSlopeMeasurement> and includes the
value of the cross-slope (<CrossSlope>), the validity of the measurement (<Valid>) and the
position from the start of the survey at which the measurement is taken (<SurveyPosition>).
A value of 1000 or -1000 for the element <Curvature> means that road is straight (very high
radius).

Figure 38: XML output format for slope and cross-slope module.
6.12 Water entrapment calculations

Description
Water entrapment depth is the amount of water that accumulates on a transverse profile.
The water usually accumulates in the wheel paths. The cause for water entrapment in transverse
profiles is usually a mix between of high rutting and small cross-slope angle. For those transverse
profiles, the drainage gradient is too low to evacuate water from the road.
Water entrapment is computed based on the Standard Practice for Determining Pavement
Deformation Parameters and Cross Slope from Collected Transverse Profiles. (ASSHTO Designation:
PP 69-10)
Both the rutting and the slope and cross-slope modules are required to compute the water
entrapment information. Water entrapment calculation is automatically enabled when these two
modules are enabled.

Parameters
The parameters that can be modified for the processing of water entrapment are listed in
Table 13.

Parameters Value Description

RuttingModule_EvaluationInterval_m float The interval (distance) between
successive water trap measurements. For
example, if the interval is set to 2m and the
road sections length is 10m, then each
XML string will have 5 water trap
Default: 1m measurements.
RuttingModule_FirstEvalPosition_m float Position of the first water trap
measurement in the survey.

Default: Min. : 0m
0m Max. : Survey length (m)
WaterTrapModule_MinTrapDepth_mm float The minimum trap depth for a water trap to
Default: be saved in the result.
2 mm
Table 13: User configurable parameters for water entrapment calculations.

XML output format

Figure 39 shows the water entrapment output format in the XML files. Figure 40 illustrates
some water traps (straight edge and mid line lines are displayed in light blue) that are found for a
transverse profiles. Ruts are illustrated in red.

It is worth noting that:

 <Position> and <PositionIndex> will always be the same as for the rutting module. It is
the rutting module that controls the start and interval between water entrapment
measurements, not the Slope& Cross-slope module.
 A <WaterTrapMeasurement> element is created for each measurement interval (even
though for the case where no water traps are found).
 Multiple <WaterTrap> can be encountered for a single transversal profile.
Figure 39 XML output format for water entrapment calculations.
Figure 40 Water trap examples.
6.13 GPS coordinates

Description
If GPS coordinates are present6, they will be automatically saved in the XML string when
processing the data (for any modules). The XML output format for the GPS coordinates is shown
in Figure 41. Note that the <Date> sub-element will be added only if it is available since it is not
included in all NMEA sentences. The valid values for the sub-element <Date> are the following: 0
(fix not available), 1 (non-differential GPS fix available), 2 (differential GPS (WAAS) fix available)
and 6 (estimated).

Figure 41 output format for GPS coordinates

6
See Lcms Data Acquisition Manual, Appendix E for more details on how to collect the GPS
coordinates and save them with the road section data.
6.14 Marking contour parameters

Description
The marking contour module is used to determine the boundary of any road surface markings
(line marks, arrows, etc…). This module is always enabled when processing the data. It has no
effect on the output results, unless the user decides to exclude the cracks that are detected over
the road surface markings (see Table 14 for the list of processing parameters). The perimeter of
each detected marking contour is saved in the XML files.

Parameters
Table 14 lists the settings that can be configured by the user.

Parameters Value Description

ResultRenderer_EnableMarkingContourDisplay int Set this parameter to 1 to display
the marking contours over the
result image.
Default: 0
MarkingContourModule_ExcludeCracksOnMarking int Set this parameter to 1 to
remove all the cracks that are
detected on the markings (see
Default: 0 Figure 42).
MarkingContourModule_IntMin int This parameter is the level of
intensity which the library based
on to determines whether the
road surface marking exists.
This parameter is obsolete. The
minimum intensity is now
computed automatically by the
Default: 175 library.
MarkingContourModule_MinArea_m2 float The minimum area (in square
meters) for a region to be
Default: considered as a marking
0.015 contour.
 Table 14 User configurable parameters for the marking contour module.

a. Intensity image b. Marking contour with cracks c. Marking contour where cracks
excluded
Figure 42 An example of marking contour detection

XML output format

Figure 43 shows how marking contour perimeters are organized in the XML result string. Each
individual marking contour has an index <MarkingID> followed by its perimeter.
Figure 43: XML output format for marking contour module.
6.15 Sealed crack Module

Description
The sealed crack detection module has been added to the LcmsAnalyser library at version 4.0
(January 2015). The algorithm assumes that the sealed crack surface is smoother than the rest of
the pavement. Therefore, the detection is performed on both the range (3D) and intensity (2D)
data images from which the smoothness (similar to texture) and edges (contrast in the intensity
images) information are extracted. Afterward, the morphological and filtering operations are
performed in order to obtain the most substantial sealed cracks candidates. Then these
candidates are validated with the smoothness information to get the final results. Sealed cracks
are displayed over the result images as a red blob (see Figure 44a). It is also possible to display a
skeleton representation of the different blobs (see Figure 44b).

There are some notices when using module:

 A sealed crack that is broken or damaged will be detected as a 3D crack, not a sealed
crack.
 It is not possible to detect a 3D crack over a sealed crack.
 If the sealed crack is in very bad condition (sealing is very old, aggregates start to be
visible over the sealing, etc…), then it will be more difficult to identify the crack as a
sealed crack.
 Additional, there is too much garbage on concrete roads that can be confused with a
sealed crack (joints, oil patches, skid marks, etc…). Therefore, the sealed crack
detection is disabled on Concrete roads (at least for the moment).
 Besides, the detection will not work well on wet pavement.

Parameters
The following parameters can be modified by the user to adapt the sealed crack detection
algorithm.
Parameters Value Description
ResultRenderer_EnableSealedCrackSkeletonDispla int Set this parameter to 1 to display
y the skeleton over the sealed
cracks on result image (see
Default: 0 Figure 44 Sealed Crack
Detection Result).
SealedCrackModule_MinBlobArea_m2 float This parameter specifies the
minimum area of a blob to be
detected as a sealed crack.
Default: 0.02
SealedCrackModule_MinDiff_IOSmoothness float The algorithm computes the
difference in smoothness index
between the surface inside a
sealed crack candidate and its
surrounding. If the different is
greater than the value of this
parameter, that candidate will be
assigned as a sealed crack in
Default: 0.2 final result.
Table 15 Sealed Crack Module Parameters
 a b
Figure 44 Sealed Crack Detection Result

XML output format

Figure 45 shows how sealed crack results are organized in the XML result string. The sealed
crack information contains two parts: sealed cracks’ perimeters (<SealedCrackPerimeters>) and its
skeletons (<SealedCrackSkeletonList>). Please note that, the number of Sealed Cracks (in the first
part) do not necessary correspond to the number of Sealed Crack skeletons (in the second part)
because of the filtering and morphological operations. In other words, a Sealed Crack Blob can be
composed by one or more Sealed Crack Skeleton components.
Figure 45 Sealed Crack XML format
6.16 Rendering parameters

Description
The rendering parameters let the user specify how the detection results (cracks, lane marks,
etc.) are displayed over the result images (line colors, line thickness, etc…). Colors are expressed
as RGB (Red,Green,Blue) values. Their format in the parameter file must be is: R,G,B
where R, G and B are integer values between 0-255.

Parameters
Table 16 lists the settings that can be configured by the user.

Parameters Value Description

ResultRenderer_StripColorRGB RGB value Lane marks color (default = pink)

Default:
255,128,255
ResultRenderer_CrackColorRGB_Sev0 RGB value Very weak cracks color (default =
light blue).
Default:
64,255,255
ResultRenderer_CrackColorRGB_Sev1 RGB value Weak cracks color (default =
green).
Default:
0,192,0
ResultRenderer_CrackColorRGB_Sev2 RGB value Medium cracks color (default =
orange).
Default:
255,151,15
ResultRenderer_CrackColorRGB_Sev3 RGB value Major cracks color (default =-
red).
Default:
255,0,0
ResultRenderer_CrackSeverity0_MaxWidth_mm Float Maximum width for a very weak
crack.
Default: 3
ResultRenderer_CrackSeverity1_MaxWidth_mm Float Maximum width for a weak
crack.
Default: 6
ResultRenderer_CrackSeverity2_MaxWidth_mm Float Maximum width for a medium
crack. Width value over this
Default: 20 threshold is major.
ResultRenderer_CrackRenderMinWidth_mm Float Cracks with a width smaller than
this parameter are not displayed.
Default: 0
ResultRenderer_CrackBrushSize_pix Int Thickness of the crack lines (in
pixel).

Default: 2 Min: 1 pixel

ResultRenderer_CrackRenderOffsetX_pix Int Horizontal offset (in pixel) for the
crack lines.

Default: 10 Min: 0 pixel

ResultRenderer_CrackRenderOffsetY_pix Int Vertical offset (in pixel) for the
crack lines.

Default: 10 Min: 0 pixel

ResultRenderer_EnableRoughnessDisplay Int Set this parameter to 1 to enable
the display of the transversal
Default: 0 measurement positions of
longitudinal profiles (yellow).
ResultRenderer_EnableSCSlopeDisplay Int Set this parameter to 1 to display
the Slope, Cross-Slope and
Default: 0 Curvature measurement over the
result image.
ResultRenderer_EnableRuttingDisplay Int Set this parameter to 1 to display
the Rutting measurements over
Default: 0 the result image.
ResultRenderer_EnableJointFaultingValueDisplay Int Set this parameter to 1 to display
the concrete joint faulting
Default: 0 measurements over the result
image.
ResultRenderer_EnableMacroTextureDisplay Int Set this parameter to 1 to display
the macro texture measurement
Default: 0 over the result image.
ResultRenderer_EnableRavelingDisplay int Set this parameter to 1 to display
the raveling measurement over
the result image (see section 6.9
Default: 0 for more detail).
ResultRenderer_Display_Alligator_Cracks int Set this parameter to 1 to display
the rectangles over the alligator
cracks in the result image.
Default: 0
ResultRenderer_Display_Multiple_Cracks int Set this parameter to 1 to display
the rectangles over the multiple
cracks in the result image.
Default: 0
Table 16 User configurable parameters for the rendering module.

1. Strip (configurable)
2. Very weak cracks (configurable)
3. Weak cracks (configurable)
4. Medium cracks configurable)
5. Major cracks (configurable)
6. Pothole (non-configurable)
7. Drop-off (non-configurable)
8. Curb (non-configurable)
9. Marking contour (non-configurable)
Figure 46 Results with color rendering
7 Functions Description

7.1 LcmsGetLibVersion
void LcmsGetLibVersion(char _acLibVersion[32])
Description :
Returns information about the used version of the analyser library.
Parameters :
 _acLibVersion: Array of char that will be filled with a string indicating the version of the
library.
Returned value :
None.
Preconditions :
This function can be called at any time.
Post conditions :
None.

7.2 LcmsSetLicensePath
void LcmsSetLicensePath(const char *_pcLicensePath)
Description :
Specifies where the license file can be found (License.txt). By default, the license path is set to the
working directory. A call to this function is not needed if the license file is located in the working directory.
A valid license is required to obtain access to any of the library features other than those related to the
basic reading of the data.
Parameters :
 _pcLicensePath: Pointer to the string giving the path of the location of the license file.
Returned value :
None.
Preconditions :
This function must be called prior to the first call to LcmsOpenRoadSection.
Post conditions :
None.
Note :
If the given path is invalid, the license file will not be found. Since the library doesn't require a license file
to read data, the user will be not be warned of this until the moment he uses a feature that is under
licensing rights. The error code related to this condition is
'LCMS_ANALYSER_ERROR_LICENSE_FILE_NOT_FOUND'

7.3 LcmsSetLutsPath
void LcmsSetLutsPath(const char *_pcLutsPath)
Description :
Specifies where the LUT data files (.ltx and .ltz files) can be found. Under normal system operation,
LUTs (Look-Up Tables) data are included in each road section files. Unless one needs to process files
that do not contain LUT data, a call to this function is necessary. The default path for the LUT files is set
to the working directory. A call to this function is not needed under normal circumstances..
Parameters :
  _pcLutsPath: Pointer to the string giving the path of the location of the LUT data files.
Returned value :
None.
Preconditions :
This function must be called prior to the first call to LcmsProcessRoadSection.
Post conditions :
None.

7.4 LcmsSetConfigFileName
void LcmsSetConfigFileName (const char *_pcConfigFilePath, const char
*_pcConfigFileName)
Description :
Specifies the name and/or the location for the configuration parameter file (see Section 6.1). The default
path for the configuration file is set to the working directory, and the default filename is
LcmsAnalyserParam.cfg.
Parameters :
 _ pcConfigFilePath: Pointer to the string giving the path of the location of the configuration
file. If NULL, then the current working directory is used.
 _ pcConfi pcConfigFileName: Pointer to the string giving the name of the configuration file.
If NULL, then the filename is LcmsAnalyserParam.cfg.
Returned value :
None.
Preconditions :
This function must be called prior to the a call to LcmsOpenRoadSection.
Post conditions :
None.

7.5 LcmsSetProcessingParams
ERROR_CODE LcmsSetProcessingParams(const char *_pcProcessingParamsString, void
*_pUserVarPtr)
Description :
Sets a new value for a processing parameter.
Parameters :
 _ pcProcessingParamsString: Descriptive string for the processing parameter (for
example: “GeneralParam_SensorImagesOverlap_pix”). See Section 6.1 for the list of processing
parameters.
 pUserVarPtr: Pointer to the processing parameter value
Returned value :
LCMS_ANALYSER_NO_ERROR if the function is successful
LCMS_ANALYSER_ERROR_INVALID_PARAMETER if the name of the parameter is invalid
any other error code otherwise.
Preconditions :
This function can be called at any time. The new value for the processing parameter will be effective for
the next call to LcmsProcessRoadSection.
Post conditions :
None.
7.6 LcmsOpenRoadSection
ERROR_CODE LcmsOpenRoadSection(const char * _pcFilename)
Description :
Loads a road section into memory. Once the file is loaded, the road section is ready to be processed.
The user can also call any “Get Type” functions to retrieve information about the road section (for
instance, range data image, intensity image, distance from beginning of the survey, etc...).
Parameters :
 pcFilename: Name of the road section file to be loaded (including the path of the folder in which
the file is located.)
Returned value :
LCMS_ANALYSER_NO_ERROR if the road section has been successfully loaded or any other error
code otherwise.
Preconditions :
None.
Post conditions :
LcmsProcessRoadSection can be called following a successful call to LcmsOpenRoadSection.

7.7 LcmsCloseRoadSection
void LcmsCloseRoadSection()
Description :
Closes the current road section file. This function should be called prior to making a new call to
LcmsOpenRoadSection.
Parameters :
None
Preconditions :
None.
Post conditions :
Allocated memory has been freed. Any call to one of the “Get Type” functions or to function
LcmsProcessRoadSection will fail with an error message.

7.8 LcmsGetProcessingParams
ERROR_CODE LcmsGetProcessingParams(const char *_pcProcessingParamsString, void
*_pUserVarPtr)
Description :
Returns the value of a processing parameter.
Parameters :
 _ pcProcessingParamsString: Descriptive string for the processing parameter (for
example: “GeneralParam_SensorImagesOverlap_pix”). See Section 6.1 for the list of processing
parameters.
 pUserVarPtr: Pointer to the processing parameter value
Returned value :
LCMS_ANALYSER_NO_ERROR if the function is successful
LCMS_ANALYSER_ERROR_INVALID_PARAMETER if the name of the parameter is invalid, any other
error code otherwise.
Preconditions :
This function can be called at any time.
Post conditions :
None.
 7.9 LcmsGetRoadSectionInfo
ERROR_CODE LcmsGetRoadSectionInfo(sLcmsRoadSectionInfo *_pRdSectionInfo)
Description :
Retrieves information about the road section that was previously loaded into memory using the
LCMSOpenRoadSection function.
Parameters :
 _pRdSectionInfo A structure to be filled with the road section information. This output
structure contains the following parameters:
o unsigned int uiSurveyID: A unique identification number for the survey to which
the road section belongs. All road sections from a same survey have the same
uiSurveyID.
o unsigned int uiSectionID: A sequential number that represents the order in
which each of the road sections were acquired by the acquisition library. uiSectionID =
0 is always assigned to the first road section of a survey.
o double dDistBE_m[2]: The position of the first and the last profile of the road
section. These positions are given in meters with respect to the beginning of the
survey.
o double dTimeBE_s[2]: The time when the first and the last profile of the road
section were acquired. This temporal information is given in seconds. Time 0s is the
beginning of the acquisition.
o unsigned int uiNbProfiles: The number of profiles in the road section. This
number depends on both the road section length and the longitudinal resolution.
These parameters must be defined defined before prior to beginning the data
acquisition.
o double dSectionLength_m: The road section length, in meters. This parameter
must be defined prior to beginning the data acquisition.
o double dSpeed_kmh: The average speed, in kilometers per hour, at which the
vehicle was moving while collecting the road section.

Returned value :
LCMS_ANALYSER_NO_ERROR if the function call is successful or any other error code otherwise.
Preconditions :
A road section must have been loaded (see function LcmsOpenRoadSection).
Post conditions :
None

7.10 LcmsGetSystemData (advanced functionalities)

ERROR_CODE LcmsGetSystemData(
sLcmsSystemParam *_ pSystemParam,
sLcmsSystemStatus *_pSystemStatus,
sLcmsSystemInfo * _pSystemInfo,
sLcmsSensorParam *_aSensorParam,
sLcmsSensorAcquiStatus *_aSensorAcquiStatus);
Description :
A call to this function returns valuable information about the LCMS system and its sensors. The sensors
are the 3D laser-camera modules themselves, while the system is the combination of all equipments that
are related to the LCMS such as the two sensors, the controller, the frame grabber boards, the
odometer, etc....
The information returned by LcmsGetSystem data can be categorized into 3 groups :
1- Parameters (sLcmsSystemParam and sLcmsSensorParam): The parameters define the working
configuration of the sensors and the whole system. Most parameters are specified in the configuration
 file that is loaded by the acquisition library at initialisation time. Some others are specified by other
means at initialisation time and are not under control of the end-user while the rest of the parameters
can be modified by the user during the acquisition. Values that are returned by LcmsGetSystemData
are those that were in effect at the end of the acquisition of the current road section.
2- System Information (sLcmsSystemInfo) : Information about the components of the system that
acquired the current road section. Examples of system information are the version of the acquisition
software, the model and serial numbers of each sensor, etc.
3- Status (sLcmsSystemStatus and sLcmsSensorAcquiStatus): Status of the system at the
moment the current road section was acquired.
Parameters :
 _pSystemParam: Returns the values of the parameters related to the system. For instances,
the system parameter structure include the odometer settings, the physical distance between
the two sensors, etc... Refer to the LCMSStruct.h header file for the list of parameters
contained in that structure.
 _pSystemStatus: Returns the status of the system at the moment the road section was
captured. The system status structure includes the time and date, any fault conditions, etc...
Refer to the LCMSStruct.h header file.
 _pSystemInfo: Returns information about the system. For instance, the system information
structure includes the version of the acquisition software, model number and serial number of
each sensor, etc... Refer to the LCMSStruct.h header file
 _aSensorParam: Returns the two parameters structure associated to a pair of sensors. The
sensor parameter structure includes grab windows dimensions, automatic gain control settings,
peak detector settings, etc.... An array of two sLcmsSensorParam structures must be
allocated by the user before calling this function. Refer to the LCMSStruct.h header file.
 _aSensorAcquiStatus: Returns acquisition status conditions such as the number of
profiles that were missed during the survey, the load of the output buffer, any frame grabber
error code, number of trigger pulses received by the sensor, etc... An array of two
sLcmsSensorAcquiStatus structures must be allocated by the user before calling this
function. Refer to the LCMSStruct.h header file.

Returned value :
LCMS_ANALYSER_NO_ERROR if the function call is successful or any other error code otherwise.
Preconditions :
A road section must have been loaded (see function LcmsOpenRoadSection).
Post conditions :
None

7.11 LcmsGetIntData
ERROR_CODE LcmsGetIntData(unsigned char * _pIntData[2]);
Description :
Returns the intensity image for the current road section. Intensity image has the same dimension as the
range data. In other words, there is one intensity point for each range data point.
Data buffers must be allocated by the user before calling this function. The size of each buffer is defined
by the number of profiles in the current road section and the number of points per profile :
BufferSize=sLcmsSensorParam.uiNbProfiles*sLcmsSensorParam.uiProfileNbPoints
Data points inside the buffers are arranged profile by profile: intensity values of the first profile are stored
first, and then values of the second profile, and so on.
Parameters :
 _pIntData[2]: Array of two pointers to the intensity images. Each pointer must point to a
buffer of the appropriate size that has been previously allocated by the user. The two buffers
 will be filled with data coming from respectively the left and the right sensor.
Returned value :
LCMS_ANALYSER_NO_ERROR if the road section has been successfully loaded or any other error
code otherwise.
Preconditions :
A road section must have been loaded (see function LcmsOpenRoadSection).
Post conditions :
None.

7.12 LcmsGetRngIm
ERROR_CODE LcmsGetRngIm(unsigned char * _pRngData[2]);
Description :
Returns an image representation of the depth map (synonyms for depth map are: Z data, range data,
height values, etc…) of the road surface. This function does not perform any rectification of the road
surface. The depth values are simply re-mapped linearly between 0 and 255. Max depth = 0, Min depth
= 255.
Data buffers must be allocated by the user before calling this function. The size of each buffer is defined
by the number of profiles in the current road section and the number of points per profile :
BufferSize=sLcmsSensorParam.uiNbProfiles*sLcmsSensorParam.uiProfileNbPoints
Data points inside the buffers are arranged profile by profile: range values of the first profile are stored
first, and then values of the second profile, and so on.
Parameters :
 _pRngData[2]: Array of two pointers to the range images. Each pointer must point to a buffer
of the appropriate size that has been previously allocated by the user. The two buffers will be
filled with data coming from respectively the left and the right sensor.
Returned value :
LCMS_ANALYSER_NO_ERROR if the road section has been successfully loaded or any other error
code otherwise.
Preconditions :
A road section must have been loaded (see function LcmsOpenRoadSection).
Post conditions :
None.

7.13 LcmsGetRectifiedRngIm
ERROR_CODE LcmsGetRectifiedRngIm(unsigned char *_pRectifiedRngIm[2]);
Description :
Returns an image representation of the depth map (synonyms for depth map are: Z data, range data,
height values, etc…) of the road surface. This function performs a rectification of the road surface that
leads to a better rendering of depth information by visually enhancing small details of the surface.
Without the image rectification, the depth information would vary significantly from one region of the road
surface to another. These low frequency variations occur gradually. For instance, they correspond to
normal transversal slope, ruts or changes in the height of the sensors with respect to the surface due to
the vehicle's suspension. Depth map rectification process removes from the depth map all lower
frequencies and leaves only the higher frequencies that correspond to the details of the surface (cracks,
texture, etc.).
Data buffers must be allocated by the user before calling this function. The size of each buffer is defined
by the number of profiles in the current road section and the number of points per profile :
 BufferSize=sLcmsSensorParam.uiNbProfiles*sLcmsSensorParam.uiProfileNbPoints
Data points inside the buffers are arranged profile by profile: rectified values of the first profile are stored
first, and then values of the second profile, and so on.

Parameters :
 _pRectifiedRngIm [2]: Array of two pointers to the rectified range images. Each pointer
must point to a buffer of the appropriate size that has been previously allocated by the user.
The two buffers will be filled with data coming from respectively the left and the right sensor.
Returned value :
LCMS_ANALYSER_NO_ERROR if the road section has been successfully loaded or any other error
code otherwise.
Preconditions :
A road section must have been loaded (see function LcmsOpenRoadSection).
Post conditions :
None.

7.14 LcmsGetStitchedRngProfile
ERROR_CODE LcmsGetStitchedRngProfile(unsigned int _auiIndexJ, float _fLeftProfileSlope, float
_fRightProfileSlope, float * _pRngProfX, float *_pRngProfZ, int &_iNbrValidPts);
Description :
Returns the range data (Z axis) for a given stitched (left and right combined) profile. The range data
represent that actual shape of the transverse profile of the road. The stitched profile is sub-sampled
along the transversal axis of the road ( GeneralParam_SubSamplingFactorStitchedProfile). The
minimum value for the sub-sampling factor is 8. The stitched profile is also normalized at 0mm. Negative
values mean deeper data points (rutting, cracks, etc…).

Data buffers must be allocated by the user before calling this function. The size of the different data
7
buffers must be at least :
BufferSize=(sLcmsSensorParam.uiProfileNbPoints x 2) /
GeneralParam_SubSamplingFactorStitchedProfile

Parameters :
 unsigned int _auiIndexJ: This value indicates the index of the requested profile. It must
be assigned by the user to a value that lies within the following limit:
[0,sLcmsSensorParam.uiNbProfiles-1].
 float _fLeftProfileSlope: This parameter is used to correct the slope of the left profile.
Use a value of 0 if no correction is desired.
 float _fRightProfileSlope: This parameter is used to correct the slope of the right
profile. Use a value of 0 if no correction is desired.
 float *_pRngProfX: Pointer to the X data of the stitched profile. The pointer must point to a
buffer of the appropriate size that has been allocated by the user. The buffer will be filled with
data coming from the left and right sensors.
 float *_pRngProfZ: Pointer to the depth data (Z) of the stitched profile. The pointer must
point to a buffer of the appropriate size that has been allocated by the user. The buffer will be
filled with data coming from the left and right sensors.
 int &_iNbrValidPts: This parameter will be set to the number of valid points in the
stitched profile. The maximum number of points is (sLcmsSensorParam.uiProfileNbPoints x 2) /

7
Because of rounding operations, it is safer to allow larger data buffer.
 GeneralParam_SubSamplingFactorStitchedProfile. Note that it can be less if there is an
overlap between the two sensors (iOverlapPixel ) or if some data are invalid.
Returned value :
LCMS_ANALYSER_NO_ERROR if the road section has been successfully loaded or any other error
code otherwise.
Preconditions :
A road section must have been loaded (see function LcmsOpenRoadSection).
Post conditions :
None.

7.15 LcmsGetStitchedRngIntProfile
ERROR_CODE LcmsGetStitchedRngIntProfile(unsigned int _auiIndexJ, float _fLeftProfileSlope, float
_fRightProfileSlope, float * _pRngProfX, float *_pRngProfZ, unsigned char *_pIntProf, int &_iNbrValidPts);
Description :
Returns the range data (Z axis) and the Intensity data for a given stitched (left and right combined)
profile. The range data represent that actual shape of the transverse profile of the road. The stitched
profile is sub-sampled along the transversal axis of the road
(GeneralParam_SubSamplingFactorStitchedProfile). The minimum value for the sub-sampling factor
is 8. The stitched profile is also normalized at 0mm. Negative values mean deeper data points (rutting,
cracks, etc…).

Data buffers must be allocated by the user before calling this function. The size of the different data
8
buffers must be at least :
BufferSize=(sLcmsSensorParam.uiProfileNbPoints x 2) /
GeneralParam_SubSamplingFactorStitchedProfile

Parameters :
 unsigned int _auiIndexJ: This value indicates the index of the requested profile. It must
be assigned by the user to a value that lies within the following limit:
[0,sLcmsSensorParam.uiNbProfiles-1].
 float _fLeftProfileSlope: This parameter is used to correct the slope of the left profile.
Use a value of 0 if no correction is desired.
 float _fRightProfileSlope: This parameter is used to correct the slope of the right
profile. Use a value of 0 if no correction is desired.
 float *_pRngProfX: Pointer to the X data of the stitched profile. The pointer must point to a
buffer of the appropriate size that has been allocated by the user. The buffer will be filled with
data coming from the left and right sensors.
 float *_pRngProfZ: Pointer to the depth data (Z) of the stitched profile. The pointer must
point to a buffer of the appropriate size that has been allocated by the user. The buffer will be
filled with data coming from the left and right sensors.
 unsigned char *_pIntProf: Pointer to the intensity data of the stitched profile. The pointer
must point to a buffer of the appropriate size that has been allocated by the user. The buffer will
be filled with data coming from the left and right sensors.
 int &_iNbrValidPts: This parameter will be set to the number of valid points in the
stitched profile. The maximum number of points is (sLcmsSensorParam.uiProfileNbPoints x 2) /
GeneralParam_SubSamplingFactorStitchedProfile. Note that it can be less if there is an
overlap between the two sensors (iOverlapPixel ) or if some data are invalid.
Returned value :
LCMS_ANALYSER_NO_ERROR if the road section has been successfully loaded or any other error

8
Because of rounding operations, it is safer to allow larger data buffer.
 code otherwise.
Preconditions :
A road section must have been loaded (see function LcmsOpenRoadSection).
Post conditions :
None.

7.16 LcmsGetStitchedRngProfileCalib
ERROR_CODE LcmsGetStitchedRngProfileCalib(unsigned int _auiIndexJ, float * _pRngProfX, float
*_pRngProfZ, int &_iNbrValidPts);
Description :
Returns the range data (Z axis) for a given stitched (left and right combined) profile. The range data
represent that actual shape of the transverse profile of the road. The stitched profile is sub-sampled
along the transversal axis of the road ( GeneralParam_SubSamplingFactorStitchedProfile). The
minimum value for the sub-sampling factor is 8. The stitched profile is also normalized at 0mm. Negative
values mean deeper data points (rutting, cracks, etc…).
The main difference with previous function LcmsGetStitchedRngProfile is that the left and right
slope parameters are not needed when calling this new function. On the other hand, a slope-cross-slope
pre-calibration is required to make a call to this new function.

Data buffers must be allocated by the user before calling this function. The size of the different data
9
buffers must be at least :
BufferSize=(sLcmsSensorParam.uiProfileNbPoints x 2) /
GeneralParam_SubSamplingFactorStitchedProfile

Parameters :
 unsigned int _auiIndexJ: This value indicates the index of the requested profile. It must
be assigned by the user to a value that lies within the following limit:
[0,sLcmsSensorParam.uiNbProfiles-1].
 float *_pRngProfX: Pointer to the X data of the stitched profile. The pointer must point to a
buffer of the appropriate size that has been allocated by the user. The buffer will be filled with
data coming from the left and right sensors.
 float *_pRngProfZ: Pointer to the depth data (Z) of the stitched profile. The pointer must
point to a buffer of the appropriate size that has been allocated by the user. The buffer will be
filled with data coming from the left and right sensors.
 int &_iNbrValidPts: This parameter will be set to the number of valid points in the
stitched profile. The maximum number of points is (sLcmsSensorParam.uiProfileNbPoints x 2) /
GeneralParam_SubSamplingFactorStitchedProfile. Note that it can be less if there is an
overlap between the two sensors (iOverlapPixel ) or if some data are invalid.
Returned value :
LCMS_ANALYSER_NO_ERROR if the road section has been successfully loaded or any other error
code otherwise.
Preconditions :
A road section must have been loaded (see function LcmsOpenRoadSection). A slope-crosslope
calibration file is required.
Post conditions :
None.

9
Because of rounding operations, it is safer to allow larger data buffer.
7.17 LcmsGetSurveyInfo
ERROR_CODE LcmsGetSurveyInfo(sLcmsSurveyInfo * _psSurveyInfo, int
_iMilliseconds=INFINITE)
Description :
Returns the information about a specific survey. The survey information includes a unique Survey ID, the
total length of the survey, the total number of road sections that belongs the survey, etc... When the user
calls LcmsOpenRoadSection for the first time, the library automatically starts a search for other road
section files that come from the same survey. The search is performed only in the current directory.
Upon search completion, survey information is compiled and can be accessed through this function.
The search may take a while when performed on surveys with thousands of files. A timeout parameter
lets the user specify a timeout value. The default behavior is an infinite timeout, meaning that the
function returns only when the compilation of the survey information is completed
(_iMilliseconds=INFINITE). User may want to specify a maximum wait time. If survey information
is not available when the maximum wait time has elapsed, the function returns with the specific error
code LCMS_ANALYSER_ERROR_TIMED_OUT. This feature allows for a non-blocking behavior of the
function.
Parameters :
 _psSurveyInfo: A structure to be filled with the survey information. The structure contains the
following parameters:
o unsigned int uiSurveyID:: The unique identification number associated with the
survey.
o char acSurveyPath[1024]: The path of the folder where the road sections are
saved.
o unsigned char aucSensorEnable[2]: Indicates which sensors were enabled
during the survey ([0] = Left, [1] = Right; 0 = Disabled, 1 = Enabled).
o int iTotalNbSections: Total number of road sections in the survey.
o double dTotalLength_m: Total length (in meters) of the survey.
o double dMeanSpeed_kmh: The average speed of the vehicle during the survey.
o double dFirstTimeStamp_s: The timestamp of the first profile captured in
this survey (in seconds).
o double dLastTimeStamp_s: The timestamp of the last profile captured in
this survey (in seconds).
o double dSectionLength_m: The length of each road section (in meters).
o int iSectionNbProfiles: The number of profiles in each road section
belonging to the current survey.
o unsigned int uiNbValidSections: The number of road sections that are
valid. Valid road sections are those available in the folder containing the current
survey.
 _iMilliseconds: Timeout before the function returns, in milliseconds. Default value is
INFINITE.
Returned value :
LCMS_ANALYSER_NO_ERROR if the function call is successful.
LCMS_ANALYSER_ERROR_TIMED_OUT if the timeout occurs before survey information is available.
Any other error code otherwise.
Preconditions :
A road section must have been loaded (see function LcmsOpenRoadSection).
Post conditions :
None
7.18 LcmsGetSurveyRoadSectionList
ERROR_CODE LcmsGetSurveyRoadSectionList(sLcmsRoadSectionFileInfo
*_psRoadSectionInfo, int _iNbMaxElem, int _iMilliseconds=INFINITE)
Description :
Returns the list of road sections that come from the same survey as the current road section. Refer to
the LcmsGetSurveyInfo function for more details about survey information.
This function copies the road section list data into an array of sLcmsRoadSectionFileInfo
structure. This array must be allocated by the user before calling this function. To ensure that the
provided array is large enough, the user should first call LcmsGetSurveyInfo. The size of the array
must be at least sLcmsSurveyInfo.uiNbValidSections.
The information returned by this function can be useful to navigate through a survey. For instance, if one
would like to process all road sections of a particular survey, one can loop through this list and process
iteratively all the road sections it contains by calling the LcmsOpenRoadSection,
LcmsProcessRoadSection and LcmsCloseRoadSection functions.
The list of road sections is ordered by increasing values of SectionID. Only valid road sections are
indexed into the list. For this reason, the size of the list (sLcmsSurveyInfo.uiNbValidSections)
may thus be smaller than sLcmsSurveyInfo.iTotalNbSections. Valid road sections are those that
can be found in the current directory. Other road sections are the missing ones. There are several
reasons why a particular road section is missing. It could have been copied to a different folder, the file
may be corrupted, or the file has not been saved at acquisition time. In the latter case, the causes of
missing road sections are usually hardware failures, laser interlock opening (since laser is turned off,
there is no valid information to save) or output buffer overflows.
As for the LcmsGetSurveyInfo function, a maximum wait time may be specified so the function is not
blocking while it collects survey information. See LcmsGetSurveyInfo function for more details.
Parameters :

 _psRoadSectionInfo Pointer to the array of sLcmsRoadSectionFileInfo structure to be

filled with the requested info. The array must be allocated by the user. The
sLcmsRoadSectionFileInfo structure contains the following two fields:
o char acFilePathName[1024]: The full path name of the road section file.
o sLcmsRoadSectionInfo sRdSectionInfo: Information about the road section
(see LcmsGetRoadSectionInfo function for more details).
o _iNbMaxElem: Size of the array provided by the user. The dimension of the array
should be at least sLcmsSurveyInfo.uiNbValidSections. Otherwise, only the
first _iNbMaxElem elements of the road section list will be copied.
 _iMilliseconds Maximum wait time before the function returns, in milliseconds. Default
value is INFINITE.
Returned value :
LCMS_ANALYSER_NO_ERROR if the function call is successful.
LCMS_ANALYSER_ERROR_TIMED_OUT if the maximum wait time elapsed before the survey
information becomes available.
Any other error code otherwise.
Preconditions :
A road section must have been loaded (see function LcmsOpenRoadSection).
Post conditions :
None
7.19 LcmsAddProcessingModuleToSelection
ERROR_CODE LcmsAddProcessingModuleToSelection(unsigned int
_uiProcessSelectBitField)
Description :
Adds one or more processing modules to the current selection. The selected processing modules are
those that will be executed by the function LcmsProcessRoadSection().
Parameters :

 _uiProcessSelectBitField: A 32bits bit field that indicates which processing modules must
be added to the current selection. A series of bit masks are defined by the library to help the user
fill the bit field (see file LcmsAnalyserLibStruct.h). There is one bit mask for each available
processing module. More than one processing module may be added at once using the bitwise
'OR' operator ('|'). The processing modules available are:
o LCMS_PROC_MODULE_ALL: Add all available processing modules according to licensing
rights.
o LCMS_PROC_MODULE_LANE_MARKING: Performs detection of lane marking.
o LCMS_PROC_MODULE_CRACKING: Performs detection of cracks.
o LCMS_PROC_MODULE_RUTTING: Performs rut measurements at regular intervals.
o LCMS_PROC_MODULE_MACRO_TEXTURE: Performs macro texture evaluation.

Returned value :
LCMS_ANALYSER_NO_ERROR if the function call is successful.
LCMS_ANALYSER_ERROR_LICENCE_INVALID_OPTION_ID if the selected processing module is not
available due to licensing rights
LCMS_ANALYSER_INVALID_PROC_MODULE if the selected processing module doesn't exist.
Preconditions :
None. This function can be called at any time. The settings remain the same until the next call to
LcmsAddProcessingModuleToSelection or LcmsRemoveProcessingModuleFromSelection
functions.
Post conditions :
A call to this function changes the current processing module selection.

7.20 LcmsRemoveProcessingModuleToSelection
void LcmsRemoveProcessingModuleToSelection (unsigned int
_uiProcessSelectBitField)
Description :
Removes one or more processing modules to the current selection. The selected processing modules
are those that will be executed by the function LcmsProcessRoadSection().
Parameters :

 uiProcessSelectBitField: A 32bits bit field that indicates which processing modules must be
added to the current selection. A series of bit masks are defined by the library to help the user fill
the bit field (see file LcmsAnalyserLibStruct.h). There is one bit mask for each available
processing module. More than one processing module may be added at once using the bitwise
'OR' operator ('|'). See function LcmsAddProcessingModuleToSelection for the list of
available choices.
Returned value :
Void
Preconditions :
None. This function can be called at any time. The settings will remain the same until the next call to
 LcmsAddProcessingModuleToSelection or LcmsRemoveProcessingModuleFromSelection
functions.
Post conditions :
A call to this function changes the current processing module selection.

7.21 LcmsGetProcessingModuleSelection
void LcmsGetProcessingModuleSelection (unsigned int
*_puiProcessSelectBitField)
Description :
Returns the current processing module selection. The selected processing modules are those that will
be executed by the function LcmsProcessRoadSection().
Parameters :

 _puiProcessSelectBitField: A pointer to the processing selection. The processing

selection is saved as a bit field. Bit masks can be used to determine if a given processing module
is currently selected or not. This can be done using a bitwise 'AND' operation ('&') between the bit
field (puiProcessSelectBitField) and the appropriate bit mask. See function
LcmsAddProcessingModuleToSelection() for the list of available bit masks.
Returned value :
Void
Preconditions :
None. This function can be called at any time.
Post conditions :
None.

7.22 LcmsProcessRoadSection
ERROR_CODE LcmsProcessRoadSection();
Description :
Performs the analysis of the current road section.
Parameters :
None.
Returned value :
LCMS_ANALYSER_NO_ERROR if the analysis is successful, or any other error code otherwise.
Preconditions :
A road section must have been loaded (see function LcmsOpenRoadSection).
Post conditions :
Processing results can be retrieved through LcmsGetResult() and LcmsGetResultImage()
functions.
7.23 LcmsGetResult
ERROR_CODE LcmsGetResult(char **_pcXmlResultString, unsigned int
*_puiStringLength)
Description :
Returns the processing results following a call to LcmsProcessRoadSection(). Results are provided
as a XML string.
Parameters :
  _pcXmlResultString: A pointer to a pointer of char. The function sets the provided pointer of
char so that it points to the XML result string. The XML string referred by the pointer is stored in a
memory space already located inside the library. The user must not delete this pointer. The
pointer remains valid until the next call to
LcmsOpenRoadSection(),LcmsCloseRoadSection() or LcmsProcessRoadSection().
The user must save the string on disk or copy it to another memory location before calling any of
these functions. The string '0' terminated as any conventional 'C' string.
 _puiStringLength A pointer to the length of the string. The length of the string includes the
'0' terminating character.
Returned value :
LCMS_ANALYSER_NO_ERROR if the operation is successful,
LCMS_ANALYSER_NO_RESULT_AVAILABLE if LcmsProcessRoadSection() hasn't been called
before, or hasn’t completed successfully
Preconditions :
A successful call to LcmsProcessRoadSection() must have been completed.
Post conditions :
None.

7.24 LcmsGetResultImage
ERROR_CODE LcmsGetResultImage(int _iImageType, sLcmsResultImage
**_psResultImage)
Description :
Returns the result image. The result image processing involves:
 Merging operation of the left and right sensors
 Image stitching to compensate for the installation angle of the sensor (typically 15 degrees)
 Image re-sampling to match the physical aspect ratio of the road surface.
 Image resolution can be controlled with setting GeneralParam_ResultImageResolution_mm.
Default value is 4mm per pixel.
The function LcmsCreateOverlayImage()can be used to render any detection result on a result
image generated by this function .
Parameters :

 _iImageType: The type of image to be returned:

o LCMS_RESULT_IMAGE_INTENSITY: The intensity image of the road surface.
o LCMS_RESULT_IMAGE_RANGE: An image representation of the rectified depth map
(range data, height values) of the road surface.
o LCMS_RESULT_IMAGE_3D: A mix of both the intensity and range images, where a 3D
effect is simulated with artificial lighting.
 _psResultImage: A pointer to a pointer of a sLcmsResultImage structure. The function
will set the provided pointer so that it points to the result image structure. The result image
structure referred by the returned pointer is stored in a memory space located inside the
library. The user must not delete this pointer. Also, the pointer remains valid until the next call
to LcmsOpenRoadSection(),LcmsCloseRoadSection() or
LcmsProcessRoadSection(). The result image structure contains the following fields:
o int iImageType: The type of result image.
o int iWidth: The width of image buffer.
o int iHeight: The height of the image buffer.
o unsigned char *pucImageData: Pointer to the image data buffer.

Returned value :
 LCMS_ANALYSER_NO_ERROR if the operation is successful,
LCMS_ANALYSER_NO_RESULT_AVAILABLE if the function LcmsProcessRoadSection() wasn't
called before or if it hasen’t completed successfully or any other error code otherwise.
Preconditions :
None.
Post conditions :
None.

7.25 LcmsCreateOverlayImage
ERROR_CODE LcmsCreateOverlayImage(char *_pcXmlResultString, unsigned int
_uiProcessSelectBitField, char *_pcOptions, LcmsResultImage
*_psBackgroundImage, LcmsResultImage **_psOverlayImage)
Description :
Renders the analysis results over a result image.
Parameters :

 _pcXmlResultString: Pointer to the XML result string. The string is obtained by calling
LcmsGetResult.
 _uiProcessSelectBitField: A 32 bit field that specifies which of the processing module
results need to be rendered. For more information on how to set this bit field, see
LcmsAddProcessingModuleToSelection() function.
 _pcOptions: Pointer to a string reserved for future usage.
 _psBackgroundImage: Pointer to the result image that will be used as a background image
to render the analysis results. The result image is obtained by calling LcmsGetResultImage.
 _psOverlayImage A pointer to a pointer of an sLcmsResultImage structure. The
function will set the provided pointer so that it points to the result image structure. The result
image structure referred by the returned pointer is stored in a memory space located inside the
library. The user must not delete this pointer. Also, the pointer remains valid until the next call
to LcmsCreateOverlayImage(). The result image structure contains the following fields:
o int iImageType: The type of result image. The three types of result image that
can be created by this function are
LCMS_RESULT_IMAGE_OVERLAY_INTENSITY_RGB32 and
LCMS_RESULT_IMAGE_OVERLAY_RANGE_RGB32 and
LCMS_RESULT_IMAGE_OVERLAY_3D_RGB32.
o int iWidth: The width of the image buffer.
o int iHeight: The height of the image buffer.
o unsigned char *pucImageData: Pointer to the image data buffer. Note that the
image created by LcmsCreateOverlayImage() is a color image of type RGB32
(there is 4 bytes per pixel and they are stored in interleave scheme, that is, the 4 bytes
of the first pixel are stored first than the 4 bytes of the second one and so on). The
size of the buffer referred by this pointer in bytes is thus 4 times the size of the image
in pixels.

Returned value :
LCMS_ANALYSER_NO_ERROR if the operation is successful or any other error code otherwise.
Preconditions :
None.
Post conditions :
None.
7.26 LcmsCreateOverlayImageFromFiles
ERROR_CODE LcmsCreateOverlayImageFromFiles(char *_pcXmlResultFileName,
unsigned int _uiProcessSelectBitField, char *_pcOptions, char
*_pcBackgroundImageFileName, LcmsResultImage **_psOverlayImage)
Description :
Performs the same operation as LcmsCreateOverlayImage() except that it uses data stored on disk
to create the requested image.
Parameters :

 _pcXmlResultFileName: Pointer to the file name that contains the XML result string.
 _uiProcessSelectBitField: A 32 bit field that specifies which processing modules need
to be rendered. For more information on how to use this bit field, see
LcmsAddProcessingModuleToSelection() function.
 _pcOptions: Pointer to a string reserved for future usage.
 _pcBackgroundImageFileName Pointer to the filename that contains the result image
that will be used as background to render analysis results.
 _psOverlayImage A pointer to a pointer of an sLcmsResultImage structure. The
function will set the provided pointer so that it points to the result image structure. The result
image structure referred by the returned pointer is stored in a memory space located inside the
library. The user must not delete this pointer. Also, the pointer remains valid until the next call
to LcmsCreateOverlayImage(). The result image structure contains the following fields:
o int iImageType: The type of result image. The three types of result image that
can be created by this function are
LCMS_RESULT_IMAGE_OVERLAY_INTENSITY_RGB32 and
LCMS_RESULT_IMAGE_OVERLAY_RANGE_RGB32 and
LCMS_RESULT_IMAGE_OVERLAY_3D_RGB32.
o int iWidth: The width of the image buffer.
o int iHeight: The height of the image buffer.
o unsigned char *pucImageData: Pointer to the image data buffer. Note that the
image created by LcmsCreateOverlayImage() is a color image of type RGB32
(there is 4 bytes per pixel and they are stored in interleave scheme, that is, the 4 bytes
of the first pixel are stored first than the 4 bytes of the second one and so on). The
size of the buffer referred by this pointer in bytes is thus 4 times the size of the image
in pixels.
Returned value :
LCMS_ANALYSER_NO_ERROR if the operation is successful or any other error code otherwise.
Preconditions :
None.
Post conditions :
None.

7.27 LcmsSaveResultImage
ERROR_CODE LcmsSaveResultImage (const char * _pcFilename, sLcmsResultImage
*_psResultImage);
Description :
Saves the result image in a JPG image.
Parameters :
 _pcFilename: Name of the file where to save the image.
 _psResultImage: A pointer to the result image that should be saved.
 Returned value :
LCMS_ANALYSER_NO_ERROR if the operation is successful,
LCMS_ANALYSER_NO_RESULT_AVAILABLE if the function LcmsProcessRoadSection() was not
called before or if it has not completed successfully or any other error code otherwise.
Preconditions :
A successful call to LcmsProcessRoadSection() must have been completed.
Post conditions :
None.

7.28 LcmsComputeLongitudinalProfile
ERROR_CODE LcmsComputeLongitudinalProfile (float _fStartPosition_m, float
_fLength_m, const char * _pcFilenamePrefix, int _iReturnAtCompletion);
Description :
Generate the elevation profiles for the current survey.
Parameters :
 _fStartPosition_m: Specifies the position (meter) in the survey from which the elevation
profiles will be generated.
 _fLength_m: Specifies the length (meter) of the profiles to be generated.
 _pcFilename: Name of the prefix that will be used to generate the filenames of the elevation
profiles (example: “c:\\temp\\LongProfile”).
 _iReturnAtCompletion: Specifies whether the function should return immediately (0) or
wait for the processing to complete (>0).

Returned value :
LCMS_ANALYSER_NO_ERROR if the operation was successful.
eERROR_LONG_PROFILE_OUTSIDE_SURVEY_RANGE if start position or end position (start+length) is
outside survey range.
eERROR_WRITING_PROVAL if the prefix filename is invalid.
See Appendix A for the list of possible errors.
Preconditions :
A road section must have been loaded (see function LcmsOpenRoadSection).
Post conditions :
None.

7.29 LcmsGetComputeLongProfileStatus
ERROR_CODE LcmsGetComputeLongProfileStatus (float &_fPercentCompletion, int
&_iDone);
Description :
Returns the completion percentage estimation of the longitudinal profile processing.
Parameters :
 _fPercentCompletion_m: The estimated percentage of completion.
 _iDone _m: Specifies whether the processing is done (>0) or still in progress (0).
Returned value :
LCMS_ANALYSER_NO_ERROR if the operation was successful.
See Appendix A for the list of possible errors.
Preconditions :
 A longitudinal profile processing must have been started using the
LcmsComputeLongitudinalProfile function.
Post conditions :
None.

7.30 LcmsGetLongProfileIRIvalues
ERROR_CODE LcmsGetLongProfileIRIvalues (float &_fLeftIRI_mkm, float
&_fRightIRI_mkm);
Description :
Returns the computed IRI values of the generated longitudinal profiles.
Parameters :
 _fLeftIRI_mkm: The IRI value (m/km) for the left wheel path longitudinal profile.
 _fRightIRI_mkm: The IRI value (m/km) for the right wheel path longitudinal profile.
Returned value :
LCMS_ANALYSER_NO_ERROR if the operation was successful.
See Appendix A for the list of possible errors.
Preconditions :
The longitudinal profile processing must be completed (See the function
LcmsGetComputeLongProfileStatus).
Post conditions :
None.

7.31 LcmsGetLongProfileElevation
ERROR_CODE LcmsGetLongProfileElevation (int _aiNbrPtsElevation[2], float
*_apfElevation[2]);
Description :
Returns the longitudinal elevation profiles.
Parameters :
 _aiNbrPtsElevation: The number of points for each elevation profiles.
 _apfElevation: The elevation profiles (in meter). Memory will allocated by the function.
Returned value :
LCMS_ANALYSER_NO_ERROR if the operation was successful.
See Appendix A for the list of possible errors.
Preconditions :
The longitudinal profile processing must be completed (See the function
LcmsGetComputeLongProfileStatus).
Post conditions :
None.

7.32 LcmsWaitComputeLongProfileCompletion
ERROR_CODE LcmsWaitComputeLongProfileCompletion (float &_fPercentCompletion,
int &_iDone, int _iWaitTimeout_ms);
 Description :
Wait the specified period of time for the completion of the longitudinal profile processing.
Parameters :
 _fPercentCompletion_m: The estimated percentage of completion.
 _iDone: Specifies whether the processing is done (>0) or still in progress (0).
 _iWaitTimeout_ms: The period of time (ms) for which to wait for the processing
completion.
Returned value :
LCMS_ANALYSER_NO_ERROR if the operation was successful.
See Appendix A for the list of possible errors.
Preconditions :
A longitudinal profile processing must have been started using the
LcmsComputeLongitudinalProfile function.
Post conditions :
None.

7.33 LcmsGetLicenseInfo
ERROR_CODE LcmsGetLicenseInfo(sLcmsLicenseInfo *_psLicenseInfo)
Description :
Retrieves information about the license available for current road section.
Parameters :
 _ psLicenseInfo: A structure to be filled with the license information. An array of two
sLcmsLicenseInfo structures must be allocated by the user before calling this function (refer
to the LCMSStruct.h header file). This output structure contains the following parameters:
o char acCreationDate [7]: The creation date of the license.
o char acExpirationDate [7]: The expiration date of the license.
o char acModelNumber [5]: Model number of sensor.
o char acSerialNumber [6]: Serial number of sensor.
o unsigned int uiProcessModuleBitField: A 32bits bit field that indicates which
processing modules is available. See LcmsAnalyserLibStruct.h.
o unsigned char ucSupportedAcquiLib_MajVer: Major supported version
number for the acquisition library (for example, in version 1.234, 1 is the major
version.).
o unsigned char ucSupportedAcquiLib_MinjVer: Minor supported version
number for the acquisition library (for example, in version 1.234, 234 is the minor
version.).
o unsigned char ucSupportedAnalysisLib_MajVer: Major supported version
number for the analysis library (for example, in version 1.234, 1 is the major version.).
o unsigned char ucSupportedAnalysisLib_MinVer: Minor supported version
number for the analysis library (for example, in version 1.234, 234 is the minor
version.).

Returned value :
LCMS_ANALYSER_NO_ERROR if the function call is successful or any other error code otherwise.
Preconditions :
A road section must have been loaded (see function LcmsOpenRoadSection).
Post conditions :
None
7.34 LcmsGetUserDataSize
ERROR_CODE LcmsGetUserDataSize (int &_iDataSize);
Description :
Get the size in byte of the user data saved in the current road section (see the SaveSurveyData
function).
Parameters :
 _iDataSize: User data size in byte.
Returned value :
LCMS_ANALYSER_NO_ERROR if the operation was successful.
See Appendix A for the list of possible errors.
Preconditions :
A road section must have been loaded (see function LcmsOpenRoadSection).
Post conditions :
None.

7.35 LcmsGetUserData
ERROR_CODE LcmsGetUserData (char *_pcUserData);
Description :
Get the user data saved in the current road section. The data can then be cast in the appropriate type.
Parameters :
 _pcUserData: A pointer to an array of at least _iDataSize bytes (see LcmsGetUserDataSize
function).
Returned value :
LCMS_ANALYSER_NO_ERROR if the operation was successful.
See Appendix A for the list of possible errors.
Preconditions :
A road section must have been loaded (see function LcmsOpenRoadSection).
Post conditions :
None.

7.36 LcmsOpenFromStreamData
ERROR_CODE LcmsOpenFromStreamData (const char *_pStreamData, unsigned int
_uiDataSize, const char *_pcAcqFilename);
Description :
Opens a road section that has not been saved on file. Instead, the road section has been acquired by a
different computer and sent through a TCP-IP connection. See LcmsSendSurveyData documentation in
the LCMS Data Acquisition Manual.
IMPORTANT NOTE: When using the standard data processing mode and LcmsOpenRoadSection (from
file), all files must be loaded before they can be processed. That allows sorting the different road
sections of a survey based on their road section ID. When using data streaming mode, the road section
data is ready to be processed immediately after it has been opened using LcmsOpenFromStreamData.
On the other hand, that means that the survey information won’t be available, and thus the preceding
and next road section data files are not going to be loaded. As a result, depending on the configuration
angle of the system on the inspection vehicle, the resulting images won’t be saved as perfect rectangles
Parameters :
 _pStreamData: A pointer to the road section data. See the streaming data format in
 LcmsSendSurveyData documentation (LCMS data Acquisition manual)
 _uiDataSize: The size of the road section data in bytes. That information is available in the
streaming data format.
 _pcAcqFilename: A filename to be associated with the road section (streaming data are
not loaded from file; they don’t have a filename unless the user specifies one.). That
information is available in the streaming data format, or the user may choose a different
filename.
Returned value :
LCMS_ANALYSER_NO_ERROR if the operation was successful.
See Appendix A for the list of possible errors.
 Appendix A: List of Error Codes
Error
Class Description
code
0 LCMS_ANALYSER_NO_ERROR
1 LCMS_ANALYSER_ERROR_READING_LUTS
2 LCMS_ANALYSER_ERROR_LICENSE_OPTION_NOT_ALLOWED
3 LCMS_ANALYSER_ERROR_EXPIRED_LICENSE
4 LCMS_ANALYSER_ERROR_INVALID_LICENSE
5 LCMS_ANALYSER_ERROR_LICENSE_FILE_NOT_FOUND
6 LCMS_ANALYSER_ERROR_LICENCE_ACQUI_LIB_VER_NOT_SUPPORTED
7 LCMS_ANALYSER_ERROR_LICENCE_ANALYSIS_LIB_VER_NOT_SUPPOR
DLL TED
Interface 8 LCMS_ANALYSER_ERROR_COULD_NOT_OPEN_FILE
error code 9 LCMS_ANALYSER_ERROR_NO_OPEN_FILE
10 LCMS_ANALYSER_ERROR_TIMED_OUT
11 LCMS_ANALYSER_ERROR_INVALID_PROC_MODULE
12 LCMS_ANALYSER_ERROR_NO_RESULT_AVAILABLE
13 LCMS_ANALYSER_ERROR_INVALID_PARAMETER
14 LCMS_ANALYSER_ERROR_NULL_POINTER
15 LCMS_ANALYSER_ERROR_OUT_OF_MEMORY
16 LCMS_ANALYSER_ERROR_COULD_NOT_WRITE_FILE
17 LCMS_ANALYSER_ERROR_WHILE_READING_JPG_FILE
100000 eNO_ERROR
100001 eERROR_INVALID_PARAMETER
100002 eERROR_FILE_NOT_FOUND,
100003 eERROR_READING_FILE,
100004 eERROR_INVALID_FILE_FORMAT,
100005 eERROR_NOT_ENOUGH_MEMORY,
100006 eERROR_EMPTY_SURFACE_DATA_BUFFER,
100007 eERROR_FILE_CORRUPTED,
100008 eERROR_NO_OPEN_FILE,
Base 100009 eERROR_READING_LUTS,
error code 100010 eERROR_RESIZING_LUTS,
100011 eERROR_IPP_ALLOC,
100012 eERROR_IPP_HUFFMAN_DECODE,
100013 eERROR_DEPOMPRESS_RANGE_DATA,
100014 eERROR_DECODE_RANGE_DATA,
100015 eERROR_DEPOMPRESS_INTENSITY_DATA,
100016 eERROR_NO_DATA_LOADED,
100017 eERROR_LISTING_SURVEY_FILES,
100018 eERROR_RETREIVING_FILE_INFO,
100019 eERROR_LICENSE_FILE_NOT_FOUND,
100020 eERROR_EXPIRED_LICENSE
100021 eERROR_LICENCE_ACQUI_LIB_VER_NOT_SUPPORTED,
100022 eERROR_LICENCE_ANALYSIS_LIB_VER_NOT_SUPPORTED,
100023 eERROR_INVALID_LICENSE,
100024 eERROR_LICENSE_OPTION_NOT_ALLOWED,
100025 eERROR_COULD_NOT_OPEN_FILE,
100026 eERROR_COULD_NOT_WRITE_FILE,
100027 eERROR_COULD_NOT_READ_FILE,
100028 eERROR_RD_SECTION_NOT_ENOUGH_PROFILE,
100029 eERROR_CREATE_WAITABLE_TIMER,
100030 eERROR_CREATE_THREAD,
100031 eERROR_THREAD_STILL_RUNNING,
100032 eERROR_ABNORMAL_THREAD_TERMINATION,
100033 eERROR_TIMED_OUT,
100034 eERROR_SURVEY_INFO_COLLECTION_INTERRUPTED,
100035 eERROR_INVALID_PROC_MODULE,
100036 eERROR_NO_RESULT_AVAILABLE,
100037 eERROR_INVALID_PROC_PARAMS_LANE_MARK,
100038 eERROR_NULL_POINTER,
100039 eERROR_IMAGE_FILTER,
100040 eERROR_INVALID_BACKGROUND_IMAGE_TYPE,
100041 eERROR_STD_STRING,
100042 eERROR_STD_STRING_APPEND,
100043 eERROR_IMAGE_CONVERSION_FAILED,
100044 eERROR_INVALID_CONFIG_FILE_FORMAT,
100045 eERROR_LONG_PROFILE_OUTSIDE_SURVEY_RANGE
100046 eERROR_LONG_PROFILE_MISSING_ROAD_SECTION
100047 eERROR_LONG_PROFILE_NO_IMU_DATA
100048 eERROR_LONG_PROFILE_PROCESS_ABORTED
100049 eERROR_PROCESS_RUNNING
100050 eERROR_INVALID_PROC_PARAMS_ANGLE
100051 eERROR_OBSOLETE_PARAMETER
100052 eERROR_INVALID_PROC_PARAMS_JOINT
100053 eERROR_INVALID_PROC_PARAMS_CRACK
100054 eERROR_INVALID_PROC_PARAMS_DROPOFF
100055 eERROR_INVALID_PROC_PARAMS_SEALEDCRACK
100056 eERROR_INVALID_PROC_PARAMS_RUTTING
100057 eERROR_READING_STREAM
100058 eERROR_INVALID_PROC_PARAMS_SUBSAMPLING
100059 eERROR_MISSING_TERRAINMAPPING_DATA
100060 eERROR_LONG_PROFILE_MISSING_IMU_DATA
100061 eERROR_TERRAINMAPPING_COULD_NOT_OPEN_ALIGNMT_PTS_FILE
 100062 eERROR_TERRAINMAPPING_ALIGNMT_PTS_FILE_INVALID_FORMAT
100063 eERROR_NO_RUTTING_RESULTS
100064 eERROR_CONFIGFILE_NOT_FOUND
136000 eNO_ERROR
136001 eERROR_OUT_OF_MEMORY
136002 eERROR_INVALID_PARAMETERS
136003 eERROR_PERIMETER_BUG
136004 eERROR_INTEL_LIB
136005 eERROR_WRITING_PROVAL
136006 eERROR_INVALID_LANE_FOUND
136007 eERROR_INVALID_PROFILE_NUMBER
Roughness 136008 eERROR_FILTER_CREATION
Module 136009 eERROR_INVALID_TIMESTAMP_STEP
136010 eERROR_NO_IMU_DATA_AVAILABLE
136011 eERROR_NO_PROFILE_DATA_AVAILABLE
136012 eERROR_NO_CORRELATION_MATCH
136013 eERROR_LCMS_DATA_SIZE_MISMATCH
136014 eERROR_NOT_ENOUGH_PROFILE_DATA_AVAILABLE
136015 eERROR_COULD_NOT_OPEN_LOG_FILE
136016 eERROR_IMAGE_FILTER
136017 eRROR_COULD_NOT_CREATE_SUMMARY_FILE
136018 eERROR_STD_STRING_APPEND
141001 eERROR_INVALID_PARAMETER
141002 eERROR_PARAMETERS_NOT_SET
141003 eERROR_NOT_ENOUGH_MEMORY
Rut 141004 eERROR_NO_AVAILABLE_RESULT
Analyser 141005 eERROR_IMAGE_FILTER_FAILED
Module 141006 eERROR_RUT_PROFILE_FILTER_NOT_ENOUGH_LINES
141007 eERROR_STD_STRING_APPEND
141008 eERROR_INVALID_PARAMETER_SAVE_PROFILES
141100 eERROR_SNAKE_3D
201001 eERROR_INVALID_PARAMETER
201002 eERROR_FILE_NOT_FOUND
201003 eERROR_READING_FILE
201004 eERROR_INVALID_FILE_FORMAT
Data 201005 eERROR_NOT_ENOUGH_MEMORY
Reader IO 201006 eERROR_EMPTY_SURFACE_DATA_BUFFER
error code 201007 eERROR_FILE_CORRUPTED
201008 eERROR_NO_OPEN_FILE
201009 eERROR_READING_LUTS
201010 eERROR_RESIZING_LUTS
201011 eERROR_IPP_ALLOC
 201012 eERROR_IPP_HUFFMAN_DECODE
201013 eERROR_DEPOMPRESS_RANGE_DATA
201014 eERROR_DECODE_RANGE_DATA
201015 eERROR_DEPOMPRESS_INTENSITY_DATA
201016 eERROR_NO_DATA_LOADED
201017 eERROR_LISTING_SURVEY_FILES
201018 eERROR_RETREIVING_FILE_INFO
201019 eERROR_LICENSE_FILE_NOT_FOUND
201020 eERROR_EXPIRED_LICENSE
201021 eERROR_LICENCE_ACQUI_LIB_VER_NOT_SUPPORTED
201022 eERROR_LICENCE_ANALYSIS_LIB_VER_NOT_SUPPORTED
201023 eERROR_LICENCE_INVALID_OPTION_ID
201024 eERROR_INVALID_LICENSE
201025 eERROR_LICENSE_OPTION_NOT_ALLOWED
201026 eERROR_COULD_NOT_OPEN_FILE
201027 eERROR_RD_SECTION_NOT_ENOUGH_PROFILE
201028 eERROR_CREATE_WAITABLE_TIMER
201029 eERROR_CREATE_THREAD
201030 eERROR_THREAD_STILL_RUNNING
201031 eERROR_ABNORMAL_THREAD_TERMINATION
201032 eERROR_TIMED_OUT
201033 eERROR_SURVEY_INFO_COLLECTION_INTERRUPTED
201034 eERROR_DATA_NOT_AVAILABLE
201035 eERROR_INVALID_CONFIG_FILE_FORMAT
201036 eERROR_INVALID_STREAM_FORMAT
201037 eERROR_NO_STREAM_DATA
201038 eERROR_FILE_CONFLICT
201039 eERROR_NO_GPS_DATA
201040 eERROR_NO_IMU_DATA_AVAILABLE
201041 eERROR_CREATE_SURVEY_FILE
201042 eERROR_READING_FIS_FILE_FOR_SURVEY_FILE_CREATION
201043 eERROR_GEOMETRIC_PARAM_NOT_FOUND_IN_FILE
201044 eERROR_INS_PARAM_NOT_FOUND_IN_FILE
201045 eERROR_IMU_PARAM_NOT_FOUND_IN_FILE
201046 eERROR_COULD_NOT_OPEN_CALIB_FILE
201047 eERROR_NO_INS_DATA_AVAILABLE
201100 eERROR_SNAKE_3D
201101 eERROR_FAKE_3D
204001 eERROR_INVALID_PARAMETERS
Data eERROR_NOT_ENOUGH_MEMORY
204002
Writer IO
error code 204003 eERROR_COULD_NOT_OPEN_FILE
204004 eERROR_ERROR_WRITING_FILE
204105 eERROR_STREAM_DATA_EXCEED_LIMIT
204106 eERROR_WINSOCK_INIT_FAILED
204107 eERROR_FAILED_TO_CREATE_SOCKET
204108 eERROR_FAILED_TO_CONNECT
204109 eERROR_ERROR_SENDING_DATA
204110 eERROR_SHUTDOWN_SERVER
204111 eERROR_CLEANING_SOCKET
Table 17 Error codes.