opengeospatial / geoparquet

Specification for storing geospatial vector data (point, line, polygon) in Parquet
https://geoparquet.org
Apache License 2.0
795 stars 56 forks source link

Declare `Z` in the geometry type? #132

Closed m-mohr closed 1 year ago

m-mohr commented 1 year ago
    Do we need to declare `Z` in the geometry type? It might make it a little harder on the writer side

_Originally posted by @kylebarron in https://github.com/opengeospatial/geoparquet/pull/131#discussion_r1004712064_

tschaub commented 1 year ago

I'd be in favor of removing this removing this language from the spec:

In case of 3D geometries, a " Z" suffix gets added (e.g. "Point Z")

I suppose someone could check the length of the bbox if they wanted to know how many dimensions they might encounter in coordinate values.

rouault commented 1 year ago

`` if they wanted to know how many dimensions they might encounter in coordinate values.

if M support is added someday, checking the bbox length will not be enough to distinguish Z from M.

tschaub commented 1 year ago

@rouault - Do you think it is important to know if the geometry includes Z? Curious if there are cases where not all positions have Z (and uncertain what this would mean for parsers that use this hint).

rouault commented 1 year ago

Do you think it is important to know if the geometry includes Z?

With my GDAL hat on, yes. There are definitely formats to which you could convert GeoParquet that need to distinguish upfront if geometries are going to be 2D or 3D. PostGIS is a prominent one. If that's not communicated upfront, the OGR Parquet driver would need to read the first feature (and possibly more features if the first ones have NULL geometries) to be able to guess the dimension. Mix of dimensions inside a layer is probably less common, and could be solved by declaring [ "Polygon", "PolygonZ" ] as geometry_type.

cholmes commented 1 year ago

Call 117 - We need to update the schema to reflect the spec, but general consensus seems to be we should do this.