Future Driver Priorities?

[C-Loftus]

Hi there,

I was thinking about potentially doing some work to contribute a few other drivers. I was thinking it might make sense to have a driver that works easily with static local data (i.e. something that doesn't require any container setup) and would be useful for demoing the application to others.

However, I wanted to check in with the maintainers. Are there specific drivers that might be relevant to add / prioritize?

---

For myself, I think I am most interested in adding a geoparquet provider. Would this be acceptable to look into?

[b4l]

Hi @C-Loftus ,

An object store driver for geoparquet is very high on my personal wishlist!

I prototyped something along these lines in a private repository for point cloud data. I can give you access or open a draft PR if you are interested in not starting from scratch.

Generally, drivers are quite self-contained in the current architecture, so feel free to add whatever you need.

Looking forward to it!

[C-Loftus]

Great makes sense! Yeah if you want to open a draft PR or just have it in a branch that would be great. I am less familiar with point cloud data but I can take a look.

I may have a bit less time in the coming weeks but my goal is to eventually get around to contributing this sorta thing.

[C-Loftus]

I have a question if you don't mind @b4l :

Do we want the geoparquet provider to have both read and write support? I see there is a FeatureTransactions trait but I wasn't sure if writing geoparquet is out of scope given the fact writes cause the entire geoparquet file to be rewritten, and wouldn't really be a good fit for a live API. If this is out of scope / not a good idea, I was wondering if it would be reasonable to add a FeatureReadOnly trait or something similar.

[b4l]

GeoParquet is not suitable for transactions. It needs table formats like Iceberg to efficiently handle transactions (CRUD). I just left it unimplemented for now, but more graceful error handling would be a start.

Ultimately, the read-only should also be implemented in the service, composing the desired routes and corresponding capabilities/conformance. We could refactor this to use a finer-grained builder pattern for services and, maybe, a generic service trait to bundle backend, routes, conformance, state, and other components, as @ChristianBeilschmidt proposed at some point.