Add geo-traits reader implementation

[kylebarron]

We have a new core geo crate: geo-traits! This enables zero-copy vector data interchange throughout the GeoRust ecosystem.

This means that any library out there that accepts geo-traits input will just work with shapefile geometries.

This PR implements these traits on new-types around shapefile geometry types.

Change list

• Traits are implemented on existing types where possible. E.g. traits are implemented on Point{M,Z}, MultiPoint{M, Z}, and PolyLine{M, Z}.
• A new MultiPolygon type is created to wrap a shapefile::Polygon. This is a necessity because geo_traits::PolygonTrait makes a distinction between interior and exterior rings. So a bit of pre-processing is needed to ensure that consumers get constant-time coordinate access.
• A few new public types are necessitated by being the iteration objects from MultiPolygon and Polyline.

Questions

• How to handle the dimension for Z geometry types, since we don't know up front whether they'll have M values or not.

[tmontaigu]

I don"t know if checking the NO_DATA for M values is worth doing, maybe we could let that thing to the user (but then it's not clear if that's a good idea)

[kylebarron]

I don"t know if checking the NO_DATA for M values is worth doing, maybe we could let that thing to the user (but then it's not clear if that's a good idea)

I think the semantics here are that data producers are expected to produce valid data, so I think we should keep the check for M values.

[kylebarron]

geo-traits 0.2 has been released, and I updated this PR to use that.

[tmontaigu]

This is not consistent with the import for &PointM

[kylebarron]

I updated this to check if self.m <= NO_DATA, but I'm not sure if that's the correct behavior. It seems like a PointM should always have an m value, because if it didn't have one, it could just be a Point, right?

[tmontaigu]

Thanks for this

[kylebarron]

While switching to use this implementation in geoarrow-rs, I realized that I couldn't fully use it directly because the MultiPolygon and MultiPolygonZ types from geo_traits_impl aren't publicly exported. We aren't able to directly implement the traits on the core Polygon type because the trait impl needs to know where the interior and exterior rings start and stop, and we need a processing step to find that out.

Ideally I'd prefer a method on the already-public Polygon struct like as_trait that returns impl PolygonTrait<T = f64>, but that doesn't work because the Polygon is generic, so we wouldn't know which geo_traits MultiPolygon struct to convert it to.

So perhaps the best solution is to publicly export the MultiPolygon structs from geo_traits_impl and document when to use them. There are From<> impls on MultiPolygon and MultiPolygonZ, but the types aren't public to use that impl.

[tmontaigu]

Ideally I'd prefer a method on the already-public Polygon struct like as_trait that returns impl PolygonTrait<T = f64>, but that doesn't work because the Polygon is generic, so we wouldn't know which geo_traits MultiPolygon struct to convert it to.

Not sure I fully understand this be cause we could have

impl Polygon {
  pub fn as_geo_trait(self) -> MultiPolygon;
}

impl PolygonM {
  pub fn as_geo_trait(self) -> MultiPolygonM;
}

impl PolygonZ {
  pub fn as_geo_trait(self) -> MultiPolygonZ;
}

Also i'm tempted to make them be methods that returns results instead of panicking

And I still think we need to pub expect the wrapper types with have for the geo_traits as it might prevent the user
from doing some things (just like you have encountered)

[kylebarron]

Ideally I'd prefer a method on the already-public Polygon struct like as_trait that returns impl PolygonTrait<T = f64>, but that doesn't work because the Polygon is generic, so we wouldn't know which geo_traits MultiPolygon struct to convert it to.

Not sure I fully understand this be cause we could have

impl Polygon {
  pub fn as_geo_trait(self) -> MultiPolygon;
}

impl PolygonM {
  pub fn as_geo_trait(self) -> MultiPolygonM;
}

impl PolygonZ {
  pub fn as_geo_trait(self) -> MultiPolygonZ;
}

Oh, maybe you're right; I'm not sure what I was thinking.

Also i'm tempted to make them be methods that returns results instead of panicking

Where do they currently panic?

And I still think we need to pub expect the wrapper types with have for the geo_traits as it might prevent the user from doing some things (just like you have encountered)

In general, as long as the user can access something that implements the desired "top-level" trait, I don't think we need to export the concrete structs. In the same way as the WKB crate (I wrote) returns an opaque impl GeometryTrait<T = f64>. The user doesn't need to have access to the concrete structs.