wgtmac commented on code in PR #240:
URL: https://github.com/apache/parquet-format/pull/240#discussion_r1769496232
##########
src/main/thrift/parquet.thrift:
##########
@@ -237,6 +237,97 @@ struct SizeStatistics {
3: optional list<i64> definition_level_histogram;
}
+/**
+ * Interpretation for edges of GEOMETRY logical type, i.e. whether the edge
+ * between points represent a straight cartesian line or the shortest line on
+ * the sphere. It applies to all non-point geometry objects.
+ */
+enum Edges {
+ PLANAR = 0;
+ SPHERICAL = 1;
+}
+
+/**
+ * A custom binary-encoded polygon or multi-polygon to represent a covering of
+ * geometries. For example, it may be a bounding box or an envelope of
geometries
+ * when a bounding box cannot be built (e.g. a geometry has spherical edges,
or if
+ * an edge of geographic coordinates crosses the antimeridian). In addition,
it can
+ * also be used to provide vendor-agnostic coverings like S2 or H3 grids.
+ */
+struct Covering {
+ /**
+ * A type of covering. Currently accepted values: "WKB".
+ */
+ 1: required string kind;
Review Comment:
> Is this necessary? It is not in the Iceberg version so I'm wondering if it
is something that is required for the initial release.
Yes, it is not used by Iceberg. `Covering` was discussed in
https://github.com/apache/parquet-format/pull/240#discussion_r1615980422 to
make it flexible enough to add more kinds of geospatial indexes without
changing the Parquet spec in the future.
> Parquet already has types (physical and logical). There is a reason for
the use of another term here.
Sorry that I cannot find the original discussion. IIRC, `Covering/type` was
proposed in the beginning and then switched to `Covering/kind` for similar
reasons. So I'll keep using `kind` unless there is a better idea.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
