paleolimbot commented on code in PR #2971:
URL: https://github.com/apache/parquet-java/pull/2971#discussion_r1974432299


##########
parquet-column/src/main/java/org/apache/parquet/column/statistics/geometry/BoundingBox.java:
##########
@@ -0,0 +1,203 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements.  See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership.  The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License.  You may obtain a copy of the License at
+ *
+ *   http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied.  See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.parquet.column.statistics.geometry;
+
+import org.apache.parquet.Preconditions;
+import org.locationtech.jts.geom.Coordinate;
+import org.locationtech.jts.geom.Envelope;
+import org.locationtech.jts.geom.Geometry;
+
+public class BoundingBox {
+
+  private double xMin = Double.POSITIVE_INFINITY;
+  private double xMax = Double.NEGATIVE_INFINITY;
+  private double yMin = Double.POSITIVE_INFINITY;
+  private double yMax = Double.NEGATIVE_INFINITY;
+  private double zMin = Double.POSITIVE_INFINITY;
+  private double zMax = Double.NEGATIVE_INFINITY;
+  private double mMin = Double.POSITIVE_INFINITY;
+  private double mMax = Double.NEGATIVE_INFINITY;
+
+  public BoundingBox(
+      double xMin, double xMax, double yMin, double yMax, double zMin, double 
zMax, double mMin, double mMax) {
+    this.xMin = xMin;
+    this.xMax = xMax;
+    this.yMin = yMin;
+    this.yMax = yMax;
+    this.zMin = zMin;
+    this.zMax = zMax;
+    this.mMin = mMin;
+    this.mMax = mMax;
+  }
+
+  public BoundingBox() {}
+
+  public double getXMin() {
+    return xMin;
+  }
+
+  public double getXMax() {
+    return xMax;
+  }
+
+  public double getYMin() {
+    return yMin;
+  }
+
+  public double getYMax() {
+    return yMax;
+  }
+
+  public double getZMin() {
+    return zMin;
+  }
+
+  public double getZMax() {
+    return zMax;
+  }
+
+  public double getMMin() {
+    return mMin;
+  }
+
+  public double getMMax() {
+    return mMax;
+  }
+
+  // Method to update the bounding box with the coordinates of a Geometry 
object
+  // geometry can be changed by this method
+  void update(Geometry geometry, String crs) {
+    GeospatialUtils.normalizeLongitude(geometry);

Review Comment:
   > Let's only do normalizeLongitude when the CRS field == "srid:4326" or 
unset in both Geography and Geometry types.
   
   I think we don't want to mess with user coordinates for Geometry (where 
there's nothing in the spec constraining the valid values)...I would be 
surprised if there is any file writer anywhere that does this. For Geography we 
do constrain the valid values (plus it would not make somebody's valid geometry 
invalid since the definition of Geography ensures this); however, I am still 
not sure that messing with user coordinates is a good idea for a Parquet 
implementation (for Sedona, perhaps, this would be more squarely in scope).
   
   > Splitting a geometry to 2 halves will cause lots of trouble
   
   Apologies for not making that clear, I don't think a Parquet implementation 
should do the splitting...they typically arrive this way (e.g., Fiji is usually 
a MULTIPOLYGON with valid geometries on either side of the antimeridian). The 
algorithm for generating a more effective bounding box with wrapping is 
something like "generate bounds for all contiguous sequences and recursively 
accumulate them looking for a good place to split" (with apologies if that's 
implemented here and I missed it!)
   
   I think both of these things are good ideas...my point is just that they are 
complex topics that need a bit more research/testing and not strictly necessary 
for merging the initial support.



-- 
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]

Reply via email to