Bomb out when format doesn't support M

[jidanni]

Feature description

$ ogr2ogr m.geojson j.geojson -dialect SQLite -sql \
  "SELECT CastToXYM(GEOMETRY) FROM blarf';"
$

should say

M not supported in GeoJSON. Quitting!

It would save hours of head scratching.

It should be triggered by all attempts to read or write M on non supporting filetypes.

Here perhaps also say

Try https://gdal.org/en/latest/drivers/vector/jsonfg.html instead.

Or maybe

You forgot to use the -dim option. Bye!

[jratike80]

Perhaps related #11147

[rouault]

I don't know how to solve that and if need to. "Traduttore, traditore". There are plenty of different paths where GDAL cannot exactly convert the input. If we failed everytime we cannot exactly translate, we won't do much. It can also be argued that just warning could be noisy.

[jratike80]

It seems that that GDAL behaves as planned but perhaps misses the documentation part https://gdal.org/en/stable/development/rfc/rfc61_support_for_measured_geometries.html

The user-oriented API functions (CreateLayer, CreateFeature, and SetFeature) should (silently) strip out the measures before continuing to the I* methods in drivers that do not support measures. This (side effect) may not be what is wanted in some usage scenarios but it would follow the pattern of what is already done with nonlinear geometries. This should be documented.

Maybe this feature was not implemented in user-oriented tools https://gdal.org/en/stable/development/rfc/rfc61_support_for_measured_geometries.html#drivers

Once the support for M coordinates is in place the driver will advertise the support.

I do not see that advertized with for example gdal --format csv. With Python I believe this is one way to check the capability

ds = ogr.GetDriverByName("CSV").CreateDataSource("del.csv")
ds.TestCapability(ogr.ODsCMeasuredGeometries)
True
ds = ogr.GetDriverByName("GeoJSON").CreateDataSource("del.json")
ds.TestCapability(ogr.ODsCMeasuredGeometries)
False