Support geometric types for postgres

[mehcode]

https://docs.rs/geo
https://www.postgresql.org/docs/current/datatype-geometric.html

• POINT -> geo::Coordinate<f64>
• LINE -> geo::Line<f64>
• LSEG -> geo::Line<f64>
• BOX -> geo::Rect<f64>
• PATH -> geo::LineString<f64>
• POLYGON -> geo::Polygon<f64>

[abonander]

All types

OID sources: https://github.com/postgres/postgres/blob/2743d9ae4a490a7d96b5c19d50694bd101a87dc8/src/include/catalog/pg_type.dat

Text encoding descriptions: https://www.postgresql.org/docs/current/datatype-geometric.html
The documentation specifies which text syntax you're looking for. For robustness, the implementation should not assume any specifics about whitespace around characters.

For text encoding, notice that several types share similar formats, so you may not need exactly one function per type.

Binary encoding implementation in C: https://github.com/postgres/postgres/blob/2743d9ae4a490a7d96b5c19d50694bd101a87dc8/src/backend/utils/adt/geo_ops.c

All values are big (network)-endian encoded.

POINT

• type OID 600, array type OID 1017
pg_type.dat lines 183-187
• Binary encoding: geo_ops.c line 1831

f64: x
f64: y

• Text encoding:

( x , y )

LINE

*type OID 628, array type OID 629
pg_type.dat lines 209-212

• Binary encoding: geo_ops.c line 1034

f64: A
f64: B
f64: C

where A, B, and C are coefficients in the equation Ax + By + C = 0

• Text encoding: { A, B, C }

LSEG

• type OID 601, array type OID 1018
pg_type.dat lines 188-192
• Binary encoding: geo_ops.c line 2064

f64: x1
f64: y1
f64: x2
f64: y2

• Text encoding:

[ ( x1 , y1 ) , ( x2 , y2 ) ]

BOX

• type OID 603, array type OID 1020
pg_type.dat lines 198-203
• Binary encoding: geo_ops.c line 489

f64: x1
f64: y1
f64: x2,
f64: y2

where (x1, y1) is the top-left corner and (x2, y2) is the bottom-right corner.

Text encoding:

( x1 , y1 ) , ( x2 , y2 )

PATH

• type OID 602, array type OID 1019
pg_type.dat lines 193-197

• Binary encoding: geo_ops.c line 1485

i8: closed (0 for false or 1 for true)
i32: N, number of points
for _ in 0 .. N {
    f64: point.x
    f64: point.y
}

• Text encoding:

[ ( x1, y1) , ... , ( xN , yN ) ] : open form
( ( x1 , y1 ) , ... , ( xN , yN ) ) : closed form

POLYGON

• type OID 604, array type OID 1027
pg_types.dat lines 204-208

• Binary encoding: geo_ops.c line 3556

i32: N, number of points
for _ in 0 .. N {
    f64: point.x
    f64: point.y
}

• Text encoding:

( ( x1 , y1 ) , ... , ( xN , yN ) )

[Freax13]

* `POLYGON` -> `geo::Polygon<f64>`

geo::Polygon is not equivalent to POLYGON as it also handles holes within the bounded area.

[nixpulvis]

I just left a comment on the geo crate (see mention above) and I'm also aware of https://github.com/pka/geozero which implemented the WKT/WKB types already. As I'm interested in working on this feature for the purpose of getting 3D points for my application, I'm curious what acceptable approach is.

I would frankly find it irritating to need two separate features for 2D and 3D points, but on the other hand I'm not sure if it can be avoided, since PostgreSQL itself implements a 2D point, while something like PostGIS implements others. So perhaps it's just a question of feature naming, "geo" implies the geo crate, while maybe geozero give you the "postgis" features?

I'd be personally tempted to start with the postgis feature, unless anyone can see a way in which these are dependent on each other?

[pka]

In the geospatial world, geometries are almost exclusively used together with the PostGIS extension. So implementing the PostgreSQL geometric types has not very high priority. As mentioned, geozero supports encoding/decoding PostGIS geometries with SQLx (example).