Which Heatmap Software for the Ministry of Land, Infrastructure, Transport and Tourism? Five Items to Check Before Comparing

Many practitioners who search for "heatmap MLIT" are likely trying to find which software will prevent problems in as-built management, how to prepare inspection-acceptable documentation, and how much point cloud and 3D design data handling is sufficient. However, if you start comparisons from the wrong point, you may be able to produce visually pleasing color maps but find that they cannot withstand the needs of on-site reports, 3D data verification, replacement during remeasurement, or discussions with supervisory personnel, which can actually increase rework.

The heatmap required for MLIT as-built management is not a mere visualization image. It is part of the as-built management charts that overlay 3D design data with as-built evaluation data, evaluate each point’s deviation against specification values, and present the results as a distribution. Therefore, what you should compare is not the software name itself but whether it can perform processing according to the management procedures and whether it will hold up through on-site operations.

Table of contents

• Prerequisites to know before choosing MLIT heatmap software

• Comparison item 1: Can 3D design data and measured data be correctly overlaid?

• Comparison item 2: Can the software appropriately color-code proportions relative to specification values?

• Comparison item 3: Can it handle both report submission and 3D data verification?

• Comparison item 4: Can it support the flow including measurement density and accuracy confirmation?

• Comparison item 5: Can it enable operations robust to inspection discussions and resubmission?

• Common mistakes in software comparisons

• How to introduce software without failing on site

• Summary

Prerequisites to know before choosing MLIT heatmap software

First, keep in mind that the heatmap referred to in MLIT as-built management is a management document used to assess the acceptability of as-built conditions across an area. In earthwork projects using ICT, creating heatmaps as as-built management charts under certain conditions and using them to determine acceptability by surface management is required. As-built management materials are organized on the premise that they are created using 3D design data and as-built evaluation data and submitted to supervising officers. In other words, the essence of software selection is not whether it can fill with color, but whether it constitutes a valid management document.

It is also important to understand at which on-site stages the heatmap will be used. As-built management charts are used to plot the deviations between the design surface and each point of the as-built evaluation data on a plane, allowing verification including variability. Inspectors check not only measured items, measurement frequency, and conformity to specification values but also assess variability according to the distribution legend. Therefore, software that only displays differences numerically is insufficient; you must compare how the evaluation is presented and how easy re-verification is.

Also, do not overlook that control locations and specification values differ by site. The approach is to create as-built management charts for each as-built verification location, and evaluations must be separated for flat areas, crest/top surfaces, slope faces, etc. That means a single overall map is not enough; if software does not make it easy to organize what range was evaluated against which criteria, it will be difficult to use in practice. At the comparison stage, always confirm whether it is natural to clip ranges and create charts for each control location.

Comparison item 1: Can 3D design data and measured data be correctly overlaid?

The first thing to check is whether 3D design data and measured data can be overlaid correctly without forcing. MLIT materials assume as a premise that as-built management documents are created using 3D design data and as-built evaluation data. What matters here is not just whether the software can read point clouds. It must be able to extract the comparison surface based on the design surface, clearly define the range you want to manage, and overlay the data used for comparison in the correct coordinate system and orientation. Software that is vague here cannot be trusted even if later-stage reports look tidy.

In practice, the accuracy and usability of this overlay directly affect work time and result stability. For example, it is crucial whether you can flexibly clip the evaluation range after loading the current point cloud, locally check the design and comparison surfaces, and proceed with comparisons after removing unnecessary points and outliers. Even if different software appear similar visually, weakness in this area can produce unnatural color distributions at locations prone to errors—such as slope shoulders, edges, top-edge areas, and structural boundaries—making it hard to tell whether differences are true as-built deviations or processing misalignments.

Especially before comparing, confirm whether difference evaluation based on the design surface can be performed with natural operations. MLIT explains that acceptability is judged by deviations between the 3D design surface and each point of the as-built evaluation data, and simple point-cloud viewers can be weak here. When selecting software, prioritize whether extraction of the comparison surface, calculation of deviation amounts, and clear definition of the evaluation area form a coherent, non-broken workflow over mere viewing functions.

Comparison item 2: Can the software appropriately color-code proportions relative to specification values?

The next important point is whether the color-coding rules align with the management procedures. As part of checking as-built management charts, heatmaps should show deviation results as a percentage relative to specification values, color-code the range from minus 100 percent to plus 100 percent, display a clear color legend, distinguish regions around ±50 percent and around 80 percent with different colors, and show values outside specifications in another color. In short, any pretty gradient is not acceptable.

This is the area most easily misunderstood in software comparisons. Some general analysis software can color-display difference values freely, but their evaluation axis may center on absolute real distances, and they may be weak in organizing results as percentages relative to specification values. In practice, you need to show not just where red and blue areas are, but what level of margin or exceedance those colors mean relative to the specification value, in a form that can be shared with supervisory personnel and inspectors. During comparison, check freedom of color-legend settings, fixed thresholds, separate colors for out-of-spec values, and how out-of-range points are handled.

It is also important whether you can plot results per point. MLIT materials indicate plotting results at each data point. This is crucial to understand local variability or biases concentrated at edges that average values hide. Some software smooths and interpolates surfaces for readability, which can reduce the visibility of raw data point distribution. Even if the display looks tidy, a representation that obscures the reality of measurement points weakens the documentation.

Furthermore, it is desirable to show both sides even for work types where specifications are set only on one sign. This may seem minor but is practically important because evaluators want to intuitively grasp which direction and by how much deviation occurs. If software assumes only one-sided evaluation, the meaning of colors becomes awkward and requires unnecessary explanation. At the comparison stage, confirm whether initial color settings can be changed and whether the evaluation axis can be treated symmetrically.

Comparison item 3: Can it handle both report submission and 3D data verification?

The third comparison item is support for submission formats. MLIT indicates that as-built management materials can be delivered as PDFs or as 3D data with a viewer, and that electronic deliverables should confirm storage of 3D design data and similar items. In other words, heatmap software must be more than a tool that outputs images; it must reconcile reporting and 3D verification. At comparison, check whether static report output is sufficient or whether you can handle 3D data review in a single flow.

On site, software that allows tracing back to the evidence is more valuable than software that only outputs neat reports. The reason is simple: heatmaps are not a one-off submission—they are checked during discussions and inspections with questions like "Which point and what deviation does this color refer to?" and "Which surface was this range evaluated against?" If you have an environment in which you can confirm the relevant range and attributes on a 3D view as well as in a PDF, the speed of exchanges changes drastically. Recently, trials of supervision and inspection using digital data have progressed, and the traditional approach to submitting charts is being reconsidered. For the future, it is safer to choose a configuration strong in 3D data utilization rather than report-only software.

That said, more features are not always better. What matters is the balance between polished submission materials and traceability of verification data. Check whether it is easy to organize mean, max, min, data count, evaluated area, and rejected point counts; whether the relationship between the heatmap and aggregate values is clear; and whether re-output preserves formatting. These mundane aspects will matter later. During comparison, prioritize output stability and completeness as explanatory materials over flashy display performance.

Comparison item 4: Can it support the flow including measurement density and accuracy confirmation?

The fourth point to check is whether the software supports not only heatmap creation but also the upstream flow of measurement conditions and accuracy confirmation. MLIT materials state that as-built evaluation data must meet a certain point density when creating as-built management materials using 3D design data and as-built evaluation data. At supervision and inspection, confirmation of accuracy verification test reports for each 3D measurement technology is also performed. Thus, even if the heatmap is correct, unclear original measurement conditions weaken the overall persuasiveness of the materials.

“Support” here does not mean everything must be completed inside the software. It includes whether, at data import, density shortages, missing data, outliers, and local roughness are easy to detect; whether the information needed for accuracy confirmation and the heatmap creation process are not excessively separated; and whether replacing with remeasurement data is easy—i.e., operational ease. On site, re-measurements and re-specifying target ranges are not uncommon. Software that forces you to redo the whole process each time may look fine on paper but will be a burden in practice.

This viewpoint is especially important where multiple measurement technologies are used on site. Optimal approaches vary by site conditions—terrestrial measurements, aerial measurements, using construction history data, etc. MLIT also indicates directions for as-built management using 3D measurement technologies and supervision/inspection utilizing construction history data. Therefore, software that accepts multiple data sources and processes them without breaking comparison conditions will be more durable than software that handles only specific input formats.

Comparison item 5: Can it enable operations robust to inspection discussions and resubmission?

The fifth is whether the software can enable operations robust to inspections, discussions, and resubmissions. When comparing software, attention tends to focus on import formats, color settings, and report appearance, but actual differences in practice show up more here. Inspections check measurement items, measurement frequency, and conformity to specification values, and also verify variability according to the distribution legend. If software cannot quickly reproduce the evaluation conditions when re-explanation is needed, the burden on site staff increases.

For example, the ability to quickly re-specify evaluation ranges, revise specification settings, change legends, zoom in on specific locations, or replace with re-measurement data makes a huge difference. Software that can produce a report only once at the first attempt is less helpful than software that can stably re-output the same rules in response to change requests. When multiple sections or multiple time points of as-built verification are involved, the ease of templating and saving conditions is indispensable.

Also important is how easy it is to align stakeholders’ perceptions. Site personnel, surveying staff, construction managers, and supervising officers each want slightly different information. Someone may want the positions of out-of-spec points, another may want the overall variability trend, and another may want to verify that submission formats comply with the procedures. In software selection, consider whether one analysis result can be presented from multiple perspectives and whether it remains easy to explain even when the reviewer changes. Heatmaps are colored diagrams and at the same time documents for building consensus.

Common mistakes in software comparisons

Given the five items above, common comparison failures become clear. The most frequent mistake is choosing based on visual flair. High-resolution 3D displays and smooth color rendering are attractive, but if percentage display relative to specification values, threshold separation, separate coloring for out-of-spec values, and per-point result verification are weak, the software is hard to use as MLIT as-built management materials. For heatmaps, clarity of correspondence to evaluation rules matters more than beauty.

Another common mistake is thinking that point-cloud processing alone is sufficient. While point-cloud processing is important, as-built management becomes practical only when it connects to comparison with the design surface, separation by control location, report creation, and preparation of deliverable data. Configurations that require repeated handoffs between different software tend to cause conversion errors and setting mismatches and reduce reproducibility. In comparisons, focus less on the strength of each individual process and more on whether the overall workflow is short and stable.

Further, choosing based only on the current single site is risky. If site conditions change, measurement methods, control locations, data volume, frequency of discussions, and delivery formats may also change. Software that seems adequate now may become difficult to use when you move to different work types or sites. Therefore, check not only specific screens or a single sample report but whether the software can process data under different conditions with the same quality. If you plan on long-term use, prioritize flexibility that can accommodate future digitalization of supervision and inspection.

How to introduce software without failing on site

So how should you proceed when actually introducing software? In short, decide your company’s standard workflow first, not the software name. Determine when you will measure, which range you will evaluate, who will prepare the design data, which format you will submit, and which screens or reports you will show during discussions. Once these are fixed, required functions become clear. If you choose software with these points unclear, you may end up with feature-rich tools that nonetheless do not work for the site.

Next, test with realistic site data rather than ideal data. Compare using point clouds with edge missing data, partially coarse point clouds, design surfaces that need control-location separation, and cases requiring replacement after re-measurement; this will reveal truly robust software. Performing such validation during initial implementation greatly reduces rework after starting operations. In particular, always check whether evaluation conditions can be saved and reapplied and whether report formatting remains stable on re-output.

Also, do not consider heatmap software in isolation. In practice, measurement, coordinate verification, alignment with design data, as-built verification, and report generation form a chain. Trying to solve heatmap needs only at later stages will leave you to deal with upstream data quality and coordinate alignment problems afterwards. To increase the chance of successful introduction, judge how naturally candidate software connects with upstream and downstream processes.

Summary

When comparing MLIT heatmap software, the five essential checks are whether it can correctly overlay 3D design data and measured data; whether it can color-code proportions relative to specification values according to the procedures; whether it supports both report submission and 3D verification; whether it supports the flow for measurement density and accuracy confirmation; and whether it enables operations robust to inspections, discussions, and resubmissions. If you start by looking for product names, you can be misled, but working backward from requirements clarifies the comparison criteria.

If you are also looking ahead to on-site labor savings, it is especially important not to isolate heatmap creation but to consider upstream coordinate checks, handling of control points, and on-site position verification. For example, using an iPhone-mounted GNSS high-precision positioning device like LRTK can make it smoother to confirm site coordinates and establish reference positions, which helps prepare prerequisite data for later heatmap creation. If you want to connect the whole site workflow reasonably from the upstream stage rather than only creating pretty heatmaps, reconsidering the positioning environment and including it in your evaluation can further improve the efficiency of as-built management.