paleolimbot commented on code in PR #45459: URL: https://github.com/apache/arrow/pull/45459#discussion_r1975800987
########## cpp/src/parquet/geometry_statistics.h: ########## @@ -0,0 +1,164 @@ +// 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. + +#pragma once + +#include <cstdint> +#include <memory> + +#include "parquet/platform.h" +#include "parquet/types.h" + +namespace parquet { + +/// \brief Structure represented encoded statistics to be written to and read from Parquet +/// serialized metadata. +/// +/// See the Parquet Thrift definition and GeospatialStatistics for the specific definition +/// of field values. +class PARQUET_EXPORT EncodedGeospatialStatistics { + public: + static constexpr double kInf = std::numeric_limits<double>::infinity(); + + EncodedGeospatialStatistics() = default; + EncodedGeospatialStatistics(const EncodedGeospatialStatistics&) = default; + EncodedGeospatialStatistics(EncodedGeospatialStatistics&&) = default; + EncodedGeospatialStatistics& operator=(const EncodedGeospatialStatistics&) = default; + + double xmin{kInf}; + double xmax{-kInf}; + double ymin{kInf}; + double ymax{-kInf}; + double zmin{kInf}; + double zmax{-kInf}; + double mmin{kInf}; + double mmax{-kInf}; + std::vector<int32_t> geospatial_types; + + bool has_z() const { return (zmax - zmin) != -kInf; } + + bool has_m() const { return (mmax - mmin) != -kInf; } + + bool is_set() const { return !geospatial_types.empty(); } +}; + +class GeospatialStatisticsImpl; + +/// \brief Base type for computing geospatial column statistics while writing a file +class PARQUET_EXPORT GeospatialStatistics { + public: + GeospatialStatistics(); + explicit GeospatialStatistics(std::unique_ptr<GeospatialStatisticsImpl> impl); + explicit GeospatialStatistics(const EncodedGeospatialStatistics& encoded); + GeospatialStatistics(GeospatialStatistics&&); + + ~GeospatialStatistics(); + + /// \brief Return true if bounds, geometry types, and validity are identical + bool Equals(const GeospatialStatistics& other) const; + + /// \brief Update these statistics based on previously calculated or decoded statistics + void Merge(const GeospatialStatistics& other); + + /// \brief Update these statistics based on values + void Update(const ByteArray* values, int64_t num_values, int64_t null_count); + + /// \brief Update these statistics based on the non-null elements of values + void UpdateSpaced(const ByteArray* values, const uint8_t* valid_bits, + int64_t valid_bits_offset, int64_t num_spaced_values, + int64_t num_values, int64_t null_count); + + /// \brief Update these statistics based on the non-null elements of values + /// + /// Currently, BinaryArray and LargeBinaryArray input is supported. + void Update(const ::arrow::Array& values); + + /// \brief Return these statistics to an empty state + void Reset(); + + /// \brief Encode the statistics for serializing to Thrift + /// + /// If invalid WKB was encountered, empty encoded statistics are returned Review Comment: I'll put this in my top level comment below shortly, but I could be convinced either way on this one. I don't think we validate JSON or UUIDs either, but also we don't generate statistics for them that involve actually parsing them. There are some other flavours of WKB that some libraries emit (e.g., EWKB from PostGIS or GEOS before a certain version), and some geometry types that are sometimes written that we don't support (curved things, TINs, etc.) which would sort of be like JSON with comments being put in a JSON column. Is that error material or would it end up just being annoying for a user? I'm honestly not sure. -- 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]
