Matlab API: various bug fixes

[CarawaySeed42]

Fix bugs where OpenCRG Matlab API functions would not handle arguments correctly,
remove necessary components of the CRG header, introduce unwanted coordinate shifts,
or rely on optional header entries.

Resolves: #9

Signed-off-by: Patrick Kuemmerle patrick.kuemmerle@3d-mapping.de

---

Remaining issues:

• If map projection (mpro) field exists then crg_ext_slope and crg_ext_banking do not work, see Matlab-API: Inconsistencies by adding or removing map projection field #10
• Because both extraction functions reevaluate the grid crg_eval_uv2z will set valid border points to NaN, see Evaluation of border points #6
• crg_ext_slope does not work if any z at v=0.0 is NaN, because crg_evaluv2z and spl_smooth will fail to return valid refline elevations

[yash-shah-asam]

ASAM OpenCRG CCB 2025 12 15: Approved and can be merged for the next release.

[jorauh]

I don't like fault tolerance, so I suggest to

• improve documentation
• implement argument checking with useful error messages.
  Fault tolerance hides users's mis-understanding and increases further fault risks.

If you are ok with that, may I give some proposal?
e.g.
% V vector of v values (single)
% length(v) == 1: defines half width of road (postive value)
% length(v) == 2: defines right/left edge of road [vmin vmax]
% length(v) == nv: defines length cut positions [vmin ... vmax]

case 1
if v < 0 error ...
case 2
if v(1) >= v(2) error ...
case 3
... (check for increasing values)

[jorauh]

If the crg struct is successfully checked, poff is always defined (see crg_check_data.m)
The idea behind is to avoid this kind of individual checks in all routines by providing a complete check of all structure elements at single check routines.

[CarawaySeed42]

This is an older "bug fix" used in our company and I can not tell you why this was changed but I agree that it should be unnecessary

[3Dbastian]

This was introduced as easy workaround, otherwise crg_cut_iuiv using an CRG which has an mpro field does not work.

[CarawaySeed42]

The problem was the crg_cut_iuiv function, where poff was erroneously omitted. This issue is addressed in the latest commit

[jorauh]

I suppose these are mostley errors due to missing checks, which should guarantee a complete crg struct. Please let us look for the real reasons behind the problems and not fix them later in individual routines - we will never find all of them.

[CarawaySeed42]

#47 (review)
I agree on removing fault tolerance and replacing it with useful error messages.

#47 (review)
I agree that the proposed bug fixes are higher level band aid fixes.
The underlying problem is that some api functions break a valid input crg struct, call crg check and then report an error because they themself or the crg check broke it. I assume the solution to that, years ago, was to delete header entries until the error was gone without proper testing.

Fixing the underlying problem is obviously preferrable but someone has to spend the time to get to the root of the problems, test every possible combination of valid crg header parameters with all api functions because the crg check surely has to be changed and preferrably write unit tests.

But I am open to discuss how to tackle these bugs. This will also lead to the general problems with the map projection that many api functions cant handle properly (see #10 (comment))

[jorauh]

If we introduce workarounds, we will worsen the long-term stability of opencrg. Even though analyzing (and fixing) problems may seem difficult, this is the only way to ensure that we will continue to have a stable product in the long term.
We will hardly be able to achieve complete coverage of all possibilities through testing. But if we are prepared to address and resolve reported errors and problems promptly, as we have done in the past, we will soon be back to a stable state. Please help to highlight known problems with the MATLAB toolset; I am ready to contribute to the solution.

If the introduction of map projections in Release 1.2.0 has not yet been fully implemented in a number of MATLAB tools, that is another task.

[CarawaySeed42]

Agreed, then the only bug fixes we keep from these commits are proper numerical function argument checks but removing fault tolerances and the ones where position information is thrown away for no reason

[CarawaySeed42]

Workarounds have been removed again.
crg_ext_slope and crg_ext_banking reverted back to removing position information!

[asadekasam]

OpenCRG 2026.02.09: @CarawaySeed42 & @jorauh are still working on it.

[CarawaySeed42]

Latest commit introduced a workaround free solution for extract slope and banking functions, when considering the master branch code as not a workaround.

[jorauh]

@CarawaySeed42 :
I suggest to continue work on this branch/PR until I did some further fixes on crg_append and maybe related functions.
The current status is quite error-prone, so I will even remove some previously available (only somtimes working) functionality and add somee missing (as in crg_cut_iuiv).
These "editing" functions (cut, append, ...) were introduced long time ago, and nobody took care about consequences when using the geo-referencing (previously with lon/lat in header only and currently with the mpro).
Any things I also should have a deeper look into?
OK with that?

[CarawaySeed42]

@jorauh
That is fine by me.
Yes, there are a lot of issues with lon/lat/mpro. One thing I found, but have not tested extensively yet is, that
crg_check_wgs84 is called twice during the crg_check. Once during crg_check_head and towards the end of crg_check.
A function that modifies the refline usually let's crg_check recalculate said refline, but that doesn't work because the geographic coordinates are often dependent on crg_check_data which runs later.
In short: My guess is, that removing crg_check_wgs84 from crg_check_head might make the proper support of lat/lon/mpro a lot easier, but again, I have not tested it extensively. But crg_check_wgs84 definitely shouldn't run twice.

[CarawaySeed42]

One more addition to handling lat/lon and mpro in API functions modifying the refline:
If you have a map projection the crg check can always recalculate the geographcial coordinates after modifying the refline.
If you don't have one then it gets a little bit more involved unless you just omit lat/lon altogether.

[jorauh]

Suggesting to merge this PR, since my further fixes on the georeferencing topics will take some more time.

[jorauh]

One more fix for crg_write which didn't work on current matlab release.

[CarawaySeed42]

for i = 1:numel(f) would be independent of the size/dimension of f, but this is good as well

Otherwise no objections to the commited changes to crg_write

[jorauh]

One more addition to handling lat/lon and mpro in API functions modifying the refline: If you have a map projection the crg check can always recalculate the geographcial coordinates after modifying the refline. If you don't have one then it gets a little bit more involved unless you just omit lat/lon altogether.

This is not always possible: if the modifiers e.g. scale the refline, the map projection becomes invalid. I will handle this and further cases in #77

[CarawaySeed42]

True, my answer was directed towards cutting or appending CRGs.

[asadekasam]

OpenCRG CCB 2026.03.09: Ready for merge