Matlab-API: Inconsistencies by adding or removing map projection field

[HeyImJordi]

If map projection is added or removed the crg-check fails.

There are different options to overcome this:

• map projection field shall only be added or removed by a function which ensures the consistency of all header information
• wgs (ebeg, nbeg, eend, nend) fields should always be recalculated within function which change the reference line of the crg (what includes adding mpro fied)

[CarawaySeed42]

Additional remarks on the map projection field and its implications:
Because there was talks about backwards and forwards compatibility I want to clarify something.

The CRG APIs are generally backwards and forwards compatible but using a CRG file using the map projection (v1.2) is not (forward) compatible to older releases. This is due to how the integration of the geographical coordinates is handled.

With a map projection every refline points coordinates can exactly be mapped to a geographical coordinate.
Before the map projection was introduced, the geographical coordinates are merely an approximation.
-> Loading a 1.2 crg file using mpro with an older CRG API version usually leads to a crg_check error, because the integration of the geograpical coordinates of the refline end fails to match the one stated in the header.

[jorauh]

1. Geographical coordinates have originally been a very simple "nice to have" feature, just to make visible where on the globe a measured road surface is. For this, lon/lat information was defined in the header by ebeg/nbeg and/or eend/nend value pairs. So the begin and/or the end of the measured road would be known later on. If only one of the pairs is available, at least one of begin or end of the measured road could be located on the globe.
   This feature is currently only working for both pairs available, someone implemented a check no more allowing just one pair.
2. Using both pairs allows an approximation along the measured road, if the distance between each of the pairs and the distance between the xbeg/ybeg and xend/yend pairs are sufficiently similar and large. It fails e.g. for a closed circle with coincidence of start and end points Matlab-API: crg_cut from a circuit #5 , the approximation might get very bad for much bended roads. The tests for sufficiently similar and large were always unreliable and the error messages were difficult to understand.
3. Introduction of a map projection in v1.2.0 solved this flaw, but introduced new issues, since the provided concept in not yet fully implemented and tested. As stated in this issue and the previous comment and in other issues like Matlab-API: crg_cut from a circuit #5 , we have inconsistencies and compatibility violations. It also fails for re-positioning and scaling modifiers and crg manipulating functions like crg_cut_iuiv and crg_append.

Altitude information has to be considered separately in all 3 cases.

My suggestions and next steps (please comment if something is missing or misleading):

• re-activate the original verision 1. and solve problems which might have been caused by single pairs adequately.
• provide more useful warnings/error messages for 2.
• assure that 3. does not generate compatibility violations
• always remove geo-information (with warning) if it becomes invalid due to manipulation by modifyers or functions.