bug: Parser can't infer ZM dimensionality correctly for certain WKT strings

[petern48]

Creating either one of the following geometries fails with the following error on SedonaDB, even though they succeed on PostGIS. This behavior occurs in the cli, the tests, etc.

select st_geomfromtext('GEOMETRYCOLLECTION Z (POINT (1 2 3))')
-- fails

select st_geomfromtext('GEOMETRYCOLLECTION (POINT (1 2 3))');
-- postgis infers this to be xyz based on st_hasz, st_hasm calls

select st_geomfromtext('point (1 1 1)');
-- postgis infers this to be xyz based on st_hasz, st_hasm calls

Error:

Internal error: WKT parse error: Missing closing parenthesis for type.
This issue was likely caused by a bug in DataFusion's code. Please help us to resolve this by filing a bug report in our issue tracker: https://github.com/apache/datafusion/issues

(Ignore that it misleadingly says "Datafusion's code")

[paleolimbot]

Thank you for opening!

This would be coming from the wkt crate, although we could also use geoarrow-c to speed this up considerably. There's definitely a lot of WKT out there along the lines of POINT(1 2 3) even though I don't think it is strictly correct. I'm not sure if that is worth "fixing" (it's slower to parse the WKT if you have to infer the dimensions from the coordinates).

(We should also fix it to use an execution_err!()!)

[petern48]

If / whenever this is supported, we should add these test cases to st_has(z/m), as mentioned in #170