Troubleshooting: Geocoding Warning: “Could Not Be Matched” for One or More Flight Lines

📌 Problem

During the Geocoding process, LP360 displays one or more warnings in the geocoding log similar to:

'YYYYMMDD_hhmmss' could not be matched!

This warning appears once per affected flight line (or “leg”). In some cases, geocoding completes and produces usable data. In other cases, the warning is followed by additional log messages indicating that no LiDAR points were written for the affected flight line, resulting in missing data.

🔍 Root Cause

The warning occurs when geocoding cannot find LiDAR data that overlaps the start time of a defined flight line. This can happen for several reasons, including timing mismatches, incorrect laser file association, or flight lines that do not correspond to actual data collection.

When the warning is immediately followed by messages indicating that zero points were written, the underlying cause is typically a complete lack of overlapping LiDAR data for that flight line.

🧠 What Is “Could Not Be Matched”?

Each flight line processed during geocoding is identified by a timestamp in the format:

YYYYMMDD_hhmmss

Geocoding attempts to match that timestamp against:

• The raw LiDAR data (laser files)
• The post‑processed trajectory (SBET / TRJ)

If no LiDAR data overlaps the start time of the flight line, geocoding logs:

'YYYYMMDD_hhmmss' could not be matched!

In many cases, this simply indicates a short or unnecessary flight line and does not affect the final dataset. However, additional log messages must be reviewed to determine whether data was actually lost.

✅ Probable Resolutions

1. Determine Whether the Warning Represents a Real Failure

Review the geocoding log immediately after the could not be matched warning. If the next two lines state:

MDLS writer wrote 0 points
Las writer wrote 0 points

then the warning must be treated as an error. This indicates that no LiDAR points were written for that flight line and the resulting dataset is incomplete.

2. Verify the Correct RXP File Is Associated with the Cycle (Riegl Systems)

On systems using Riegl scanners, RXP files may be manually associated with a Cycle. Selecting the wrong RXP file is a common cause of this issue.

RXP files follow the naming convention:

YYMMDD_hhmmss.rxp

Compare the RXP timestamp to the Cycle name:

Cycle_YYMMDD_hhmmss

The RXP timestamp must fall within the Cycle’s time window. If the RXP occurs before the Cycle start or significantly after the Cycle end, it cannot be the correct file and will result in zero points during geocoding.

3. Confirm Laser Time Coverage Using the RiUnite (SDCX) Log

When RXP files are processed, RiUnite generates an .sdcx.log file. This log reports the actual start and end times of the laser data.

Look for entries similar to:

File start: hh:mm:ss
File end:   hh:mm:ss

Compare these times to:

• The trajectory start and end times
• The timestamp shown in the geocoding warning, for example:

'20260507_154342' could not be matched!

If the warning timestamp falls outside the laser file’s time range, geocoding cannot match that flight line and will write zero points.

4. Re‑Import the Data if Necessary

If multiple flight lines are affected or the correct laser file is uncertain, create a new LP360 project, re‑import the Cycle, re‑associate the correct RXP file, and re‑run geocoding.

📚 Additional Notes

The could not be matched warning is often benign when it occurs for very short or unnecessary flight lines and no zero‑point output is reported. Always rely on the presence of “MDLS writer wrote 0 points” and “Las writer wrote 0 points” to determine whether the warning represents actual data loss.

📬 Need Help?

If you're still stuck, please Contact Support for assistance. Include the Geocoding.log, the .sdcx.log, your LP360 version, and a screenshot of the flight lines.