API to infer only geometry type/dimension

[kylebarron]

In cases like GeoArrow, it's nice to know if all input geometries have a common geometry type.

This would mean an API like

pub enum GeometryType {
    Point,
    LineString,
    ...,
    PointZ,
    PointM,
    PointZM,
}

and then

pub fn infer_type(wkt: &str) -> GeometryType {}

infer_type would only parse up to the first ( character, using that text to infer the geometry type and dimension.

There's a tradeoff between time spent first parsing the text to get the geometry types and then again to actually parse the geometries, vs memory overhead of parsing all objects first to Wkt objects and then inferring what type of array builder to use.

But I figure that scanning a string for the first instance of ( and matching those first characters should be very fast, especially if no numeric parsing needs to happen for that first stage.

Thoughts?

[kylebarron]

For reference, in geoarrow-rs we plan to use the wkt crate directly for reading/writing WKT instead of using the geozero wrapper. See geoarrow/geoarrow-rs#790, geoarrow/geoarrow-rs#762

[michaelkirk]

That seems useful.

With &str as input, it's straight forward.

With an arbitrary impl Read as input, it's less straight forward, since reading ahead to infer the type will consume those bytes, and make it no longer possible to parse the remaining Read as wkt.

To accommodate that, I guess we'd need to introduce some kind of "peakable" WktReader (name up for debate) that journals anything it consumes during the "infer geometry type/dimension" step so that it can be "replayed" when it comes time to parse to WKT.

Some bike-shedding:

A (GeometryType, Dimensions) tuple might be more elegant than a flattened list of Type x Dimension

pub enum Dimensions {
    XY, XYZ, XYZM, XYM
 }
 
pub enum GeometryType {
    Point,
    LineString,
    ...
   GeometryCollection
}

But maybe there's some reason I'm not considering to have a flattened list like you've proposed. Either way, that doesn't seem like a deal breaker to me.

[kylebarron]

With &str as input, it's straight forward.

I'm content with making this an API that uses &str for simplicity of implementation.

A (GeometryType, Dimensions) tuple might be more elegant than a flattened list of Type x Dimension

That's totally fine with me.