Format support about geozero HOT 9 CLOSED

Inserting points should be working as it is. See https://docs.rs/geozero/0.7.3/geozero/postgis/index.html for the required traits. Regarding your problem, maybe this geometry type has to be added to sqlx::Type trait impl. Will have a look at it. We could also discuss this on Discord.

from geozero.

@pka OK I'm trying to understand how this all works and where things should be added. I'm very confused by the current organization of things. Part of this is probably my lack of understanding, but I also think there's a lot of room for improvement, even just within geozero, not to mention the broader georust ecosystem.

I see that there's a PointZ defined in geozero-shp but it only seems to be used for BBoxZ. I'm wondering if anyone already has a plan for how to resolve these types and structures across the ecosystem. Once I have an idea of where everything should live I can start chipping away at the reader/writer implementations.

I'm not sure the abstraction of GeozeroGeometry makes sense for all types. For example, there's plenty of geometries which do not have a notion of an srid. Additionally, CoordDimensions seems like it has a very specific set of data formats in mind. I don't see this composing well in general. If I were to just continue down this path, I'd either need to create a new GeozeroGeometry3D to redefine dims or I'd more likely need to remove the default implementation which returns the 2D CoordDimensions::xy().

Before I can think about how to deal with all this, I would like understand what (if anything) we share with georust/geo other than conversion functions between them. I'm not currently sure if I need to plan on making changes to both crates, or if I can pretend like each other don't really exist. I think I'm of the opinion there's really no need for two competing geo libraries in Rust, but I'm new here so maybe I'm missing the critical separation of concerns somewhere.

At a high level I view the ideal structure of this crate as follows:

1. Data structures and/or traits for the complete set of supported geometric types
2. Implementations of various features to convert to and from other formats (essentially the goal of this issue)
3. Implementations of other traits and public modules for supporting things like postgis in a single place
4. A nice cli for converting all these formats (possibly moved into another repo?)

Sorry if this is going a bit off topic, but I honestly don't know where else to start with this.

from geozero.

Some of the geozero design choices are caused by my work in the GIS ecosystem, where OGC standards play a dominant rule. A primary goal was to avoid another geometry implementation and provide an efficient conversion between existing geometry formats instead. I'm quite happy with current state and will maybe bring geozero-cli to a useful state, possibly more similar to PDAL than ogr2ogr.

My suggestion for your use case is to find a geometry data structure which fits your needs (see also https://github.com/pka/awesome-georust and the gaming ecosystem). Then let it be my problem to map that to the simple features model 😉

from geozero.

@pka I just need a PostGIS geometry(PointZ) compatible equivalent of (f64, f64, f64). Since I was hoping to use sqlx for my project, I'd like it to be compatible with this crate's Encode and Decode traits as well.

Have I missed an obvious solution to this problem?

from geozero.

Added a quick implementation.

EDIT: force pushed x times and made it a proper example for a minimal implementation: 60ffbb1

from geozero.

@nixpulvis Your request did cost me a few hours of sleep, I hope it worked out for you? The current version is in tests/postgis.rs

from geozero.

@pka I appreciate the time you've given me here, however it seems there's more that needs to be done to get this to work with sqlx. I don't see how this will implement the Encode trait needed to write points to the DB. Also, I'm still getting error: unsupported type geometry for param #9 (param 9 is my geometry(PointZ) column) when I try and use this PointZ struct in my code.

from geozero.

Changed the query in the postgis test to SELECT 'POINT(1 2 3)'::geometry(POINTZ) and still don't get the unsupported type geometry error when decding to the custom PointZ geometry type.

from geozero.

Support matrix is moving into documenation: https://docs.rs/geozero/

from geozero.