[geo] add geospatial statistics and bbox types for parquet #8225

kaushiksrini · 2025-08-26T01:58:00Z

Which issue does this PR close?

Builds on [Feature] geometry and geography logical type implementations #7799 by supporting the new struct GeospatialStatistics.

Rationale for this change

This is part of a draft to support geospatial types (geometry and geography) in Parquet. This has been

What changes are included in this PR?

Structs for supporting geospatial statistics information (bbox and geospatial types) derived from thrift classes.
Would appreciate feedback on structure and where certain parts should go.

Are these changes tested?

Yes

Are there any user-facing changes?

If there are user-facing changes then we may require documentation to be updated before approving the PR.

If there are any breaking changes to public APIs, please call them out.

kylebarron · 2025-08-26T02:09:38Z

parquet/src/geospatial/statistics.rs

+    /// # Returns
+    /// 
+    /// A new `BoundingBox` instance with the specified coordinates.
+    pub fn new(xmin: f64, ymin: f64, xmax: f64, ymax: f64, zmin: Option<f64>, zmax: Option<f64>, mmin: Option<f64>, mmax: Option<f64>) -> Self {


Instead of having this very verbose constructor with 8 arguments, I'd suggest having new() take only the required 4 values for the 2D box. Then have a with_zrange that takes in non-null zmin and zmax and have a with_mrange that takes in non-null mmin and mmax. This also ensures that it's impossible to define a null zmin with non-null zmax.

kylebarron · 2025-08-26T02:11:29Z

parquet/src/geospatial/statistics.rs

+    /// - 4: MultiPoint
+    /// - 5: MultiLineString
+    /// - 6: MultiPolygon
+    /// - 7: GeometryCollection


I'd suggest also linking to https://github.com/apache/parquet-format/blob/ae39061f28d7c508a97af58a3c0a567352c8ea41/Geospatial.md#geospatial-types for the full allowed list of type ids.

kylebarron · 2025-08-26T02:12:35Z

parquet/src/geospatial/statistics.rs

+// ----------------------------------------------------------------------
+// Bounding Box
+
+/// Represents a 2D/3D bounding box with optional M-coordinate support.


Maybe best to just copy the full upstream docstring https://github.com/apache/parquet-format/blob/ae39061f28d7c508a97af58a3c0a567352c8ea41/Geospatial.md#bounding-box

kylebarron · 2025-08-26T02:13:34Z

parquet/src/geospatial/statistics.rs

+    /// # Returns
+    /// 
+    /// A `GeospatialStatistics` instance with no bounding box or type information.
+    pub fn new_empty() -> Self {


Maybe cleaner to remove this and just implement Default?

kylebarron · 2025-08-26T02:16:06Z

@alamb may have opinions on whether we should create a new feature flag for this?

kaushiksrini · 2025-08-26T02:53:30Z

Thanks @kylebarron for the feedback - made some changes

kylebarron · 2025-08-26T04:13:47Z

parquet/src/geospatial/statistics.rs

+                if bbox.zmin.is_some() && bbox.zmax.is_some() {
+                    new_bbox = new_bbox.with_zrange(bbox.zmin.unwrap().into(), bbox.zmax.unwrap().into());
+                } else if bbox.zmin.is_some() != bbox.zmax.is_some() {
+                    return Err(ParquetError::General(format!("Z-coordinate values mismatch: {:?} and {:?}", bbox.zmin, bbox.zmax)));
+                }


Up to you but maybe slightly easier to read if you match (bbox.zmin, bbox.zmax) instead of having these two if clauses.

parquet/src/geospatial/statistics.rs

paleolimbot

This is a great start!

I am still new to this reader, but I wonder if a reasonable endpoint for this PR would be a test that reads the example files in the parquet-testing repository and demonstrates that the Thrift statistics/logical type information can be accessed from the ParquetMetadata as exposed by the user-facing reader class.

I'm happy to iterate with you here on Parquet Spec/basic Rust issues (although Kyle and Andrew are the ones who actually know this particular reader!).

(Background: Kaushik and I met offline at Community over Code this year and he kindly reminded me about this PR!)

paleolimbot · 2025-09-16T04:24:04Z

parquet/src/geospatial/statistics.rs

+///
+/// Special cases:
+/// - For X values only, xmin may exceed xmax. In this case, a point matches if x >= xmin OR x <= xmax
+/// - This wraparound occurs when the bounding box crosses the antimeridian line


Suggested change

/// - This wraparound occurs when the bounding box crosses the antimeridian line

/// - This wraparound can occur when the bounding box crosses the antimeridian line

paleolimbot · 2025-09-16T04:31:15Z

parquet/src/geospatial/statistics.rs

+    mmax: Option<f64>,
+}
+
+impl BoundingBox {


I believe this needs getters for the fields here (or they won't be accessible by code reading the metadata!)

paleolimbot · 2025-09-16T04:33:30Z

parquet/src/geospatial/statistics.rs

+    /// * `bbox` - Optional bounding box defining the spatial extent
+    /// * `geospatial_types` - Optional list of geometry type identifiers


I think it is important to explicitly specify what a bbox of None means (i.e., no information was provided), and what geospatial_types of None means (i.e., we don't have any information about the geometry types).

paleolimbot · 2025-09-16T04:37:13Z

parquet/src/geospatial/statistics.rs

+                new_bbox = match (bbox.zmin, bbox.zmax) {
+                    (Some(zmin), Some(zmax)) => new_bbox.with_zrange(zmin.into(), zmax.into()),
+                    (None, None) => new_bbox,
+                    _ => return Err(ParquetError::General("Z-coordinate values mismatch".to_string())),


Unless there's some previous precedent (I don't know this reader very well), rather than error here, I think keeping the bbox.z/m/min/max values set to None is a better choice (i.e., don't pass on bad statistics but don't abort the entire read because some writer wrote questionable values).

paleolimbot · 2025-09-16T04:38:57Z

parquet/src/geospatial/statistics.rs

+            } else {
+                None    
+            };
+            let geospatial_types = geo_stats.geospatial_types;


Here you have to be careful...if I remember correctly, if geo_stats.geospatial_types is empty, you have to set GeospatialStatistics.geospatial_types to None (i.e., the file did not provide information about the statistics).

paleolimbot · 2025-09-16T04:42:11Z

parquet/src/geospatial/statistics.rs

+    #[test]
+    fn test_geo_statistics_from_thrift() {
+        let stats = GeospatialStatistics::new(Some(BoundingBox::new(0.0, 0.0, 100.0, 100.0)), Some(vec![1, 2, 3]));
+        let thrift_stats = to_thrift(Some(&stats));
+        assert_eq!(from_thrift(thrift_stats).unwrap(), Some(stats));
+    }


This will need tests to cover the branches for mismatched z/m values and for cases where the z/m values are present

parquet/src/geospatial/statistics.rs

paleolimbot · 2025-09-16T04:43:17Z

parquet/src/geospatial/statistics.rs

+        assert_eq!(thrift_bbox.xmin, 0.0f64);
+        assert_eq!(thrift_bbox.ymin, 0.0f64);
+        assert_eq!(thrift_bbox.xmax, 100.0f64);
+        assert_eq!(thrift_bbox.ymax, 100.0f64);


Suggested change

assert_eq!(thrift_bbox.xmin, 0.0f64);

assert_eq!(thrift_bbox.ymin, 0.0f64);

assert_eq!(thrift_bbox.xmax, 100.0f64);

assert_eq!(thrift_bbox.ymax, 100.0f64);

assert_eq!(thrift_bbox.xmin, 0.0);

assert_eq!(thrift_bbox.ymin, 0.0);

assert_eq!(thrift_bbox.xmax, 100.0);

assert_eq!(thrift_bbox.ymax, 100.0);

(I've never seen that needed in a test...was it required?)

paleolimbot · 2025-09-16T04:47:11Z

parquet/src/geospatial/statistics.rs

+    /// Minimum X coordinate (longitude or easting)
+    xmin: f64,
+    /// Minimum Y coordinate (latitude or northing)
+    ymin: f64,
+    /// Maximum X coordinate (longitude or easting)
+    xmax: f64,
+    /// Maximum Y coordinate (latitude or northing)
+    ymax: f64,
+    /// Minimum Z coordinate (elevation/height), if present


I know that in Thrift these are all separate, although they may be more ergonomic to use as:

x_range: (f64, f64), y_range: (f64, f64), z_range: Option<(f64, f64)>, m_range: Option<(f64, f64)>,

...which would eliminate the need for a caller to do the same type of checking with respect to the case where z/mmin was specified but z/mmax was not

I like the idea of using tuples here

I'm OK with either here (they are not pub and the accessors all need to be there anyway). This really is how the object is defined for Thrift.

paleolimbot

Thank you for cleaning this up!

Would a reasonable next step be to add a test reading one of the example files in parquet-testing/data/geospatial? It looks like there is a function that can get you the path to that directory here:

arrow-rs/arrow/src/util/test_util.rs

Lines 85 to 100 in 7efb395

    
           /// Returns the parquest test data directory, which is by default 
        
           /// stored in a git submodule rooted at 
        
           /// `arrow/parquest-testing/data`. 
        
           /// 
        
           /// The default can be overridden by the optional environment variable 
        
           /// `PARQUET_TEST_DATA` 
        
           /// 
        
           /// panics when the directory can not be found. 
        
           /// 
        
           /// Example: 
        
           /// ``` 
        
           /// let testdata = arrow::util::test_util::parquet_test_data(); 
        
           /// let filename = format!("{}/binary.parquet", testdata); 
        
           /// assert!(std::path::PathBuf::from(filename).exists()); 
        
           /// ``` 
        
           pub fn parquet_test_data() -> String {

A good file to start with is probably https://github.com/apache/parquet-testing/blob/a3d96a65e11e2bbca7d22a894e8313ede90a33a3/data/geospatial/geospatial.parquet .

alamb · 2025-09-21T13:07:00Z

Would a reasonable next step be to add a test reading one of the example files in parquet-testing/data/geospatial? It looks like there is a function that can get you the path to that directory here:

Here is an example of what we did for variant: https://github.com/apache/arrow-rs/blob/main/parquet/tests/variant_integration.rs

alamb

Thank you @kaushiksrini and @paleolimbot -- this is looking quite close to me

I think it is important to minimize the size of the ParquetMetaData structure before merging this (I left a suggestion on how to do so)

As this would be a public API change, I also think it is important to add at least one "read existing file with statistics tests" as @paleolimbot suggested, to show that we have the round trip data structures working.

cc @etseidl as this adds the geospatial statistics / thrift support which is relevant to the thrift-remodel working that is ongoing

alamb · 2025-09-21T13:09:54Z

parquet/src/file/metadata/mod.rs


        #[cfg(not(feature = "encryption"))]
-        let base_expected_size = 2312;
+        let base_expected_size = 2792;


this is a fairly non trivial increase in size (as the parquet metadata size is already a challenge for many users)

Can we please reduce this size by Boxing the Geo statistics? Something like

instead of

geo_statistics: Option<geo_statistics::GeospatialStatistics>,

Make it like

geo_statistics: Option<Box<geo_statistics::GeospatialStatistics>>,

(that would add just 8-16 bytes for another pointer rather than the size of the inlined structure)

parquet/src/geospatial/mod.rs

alamb · 2025-09-21T13:13:13Z

parquet/src/geospatial/bounding_box.rs

+    }
+
+    #[test]
+    fn test_bounding_box_to_thrift() {


Another good set of tests for thrift encoding/decoding would be "roundtrip" tests that create a thrift structure -> rust --> thrift and ensure all fields survive the round trip

kaushiksrini · 2025-09-22T03:56:08Z

Thank you for the feedback @alamb and @paleolimbot! I’ve made the suggested changes — please let me know if there’s anything else I should address.

paleolimbot

Thank you!

This seems reasonable from my end (but I'm new here and Andrew may have some comments!)

kylebarron · 2025-09-24T00:18:43Z

parquet/src/file/metadata/mod.rs

+    /// Returns geospatial statistics that are set for this column chunk,
+    /// or `None` if no geospatial statistics are available.
+    pub fn geo_statistics(&self) -> Option<&geo_statistics::GeospatialStatistics> {
+        self.geo_statistics.as_ref().map(|boxed| boxed.as_ref())


Suggested change

self.geo_statistics.as_ref().map(|boxed| boxed.as_ref())

self.geo_statistics.as_deref()

kylebarron · 2025-09-24T00:19:44Z

parquet/src/file/metadata/mod.rs

            size_statistics,
-            geospatial_statistics: None,
+            geospatial_statistics: geo_statistics::to_thrift(
+                self.geo_statistics.as_ref().map(|boxed| boxed.as_ref()),


Suggested change

self.geo_statistics.as_ref().map(|boxed| boxed.as_ref()),

self.geo_statistics.as_deref(),

kylebarron · 2025-09-24T00:21:37Z

parquet/src/file/metadata/mod.rs


+    /// Sets geospatial statistics for this column chunk.
+    pub fn set_geo_statistics(mut self, value: geo_statistics::GeospatialStatistics) -> Self {
+        self.0.geo_statistics = Some(Box::new(value));


Do we want the Box only to be an implementation detail? If the user already has a GeospatialStatistics, then this has to be copied in Box::new?

I'm just wondering whether there's any value in having the API take in a Box<GeospatialStatistics> instead of boxing it inside this function

Left it as is since I felt the user doesn't necessarily need to know the memory-level implementation details, and there's no performance difference (Box::new moves rather than copies). However, open to suggestions!

I think the point would be if a user already has a Box<GeospatialStatistics> they could pass it in which would be a pointer copy, rather than this which might have to move data from the stack to the heap

Got it! I changed it to a take in a heap allocated object

kylebarron · 2025-09-24T00:26:17Z

parquet/src/geospatial/bounding_box.rs

+    /// Converts our internal `BoundingBox` to the Thrift-generated format.
+    fn from(b: BoundingBox) -> parquet::BoundingBox {
+        parquet::BoundingBox {
+            xmin: b.get_xmin().into(),


Tiny nit: since we have access to the private attributes here, it might be slightly more readable to use those, but up to you:

Suggested change

xmin: b.get_xmin().into(),

xmin: b.xmin.into(),

kylebarron · 2025-09-24T00:28:28Z

parquet/src/geospatial/bounding_box.rs

+
+        new_bbox = match (bbox.zmin, bbox.zmax) {
+            (Some(zmin), Some(zmax)) => new_bbox.with_zrange(zmin.into(), zmax.into()),
+            // If both None or mismatch, set it to None and don't error


Here and below, slight wording suggestion

Suggested change

// If both None or mismatch, set it to None and don't error

// If either None or mismatch, leave it as None and don't error

kylebarron · 2025-09-24T00:29:07Z

parquet/src/geospatial/mod.rs

+// specific language governing permissions and limitations
+// under the License.
+
+//! This module provides functionality for working with geospatial data in Parquet file as defied in the [spec][parquet-geo-spec].


Suggested change

//! This module provides functionality for working with geospatial data in Parquet file as defied in the [spec][parquet-geo-spec].

//! This module provides functionality for working with geospatial data in Parquet file as defined in the [spec][parquet-geo-spec].

kylebarron · 2025-09-24T00:33:15Z

parquet/src/geospatial/statistics.rs

+    /// Optional bounding defining the spatial extent, where None represents a lack of information.
+    bbox: Option<BoundingBox>,
+    /// Optional list of geometry type identifiers, where None represents lack of information
+    geospatial_types: Option<Vec<i32>>,


I think in the future we may want a more strongly-typed enum than a bare i32, but this is fine for now.

More strongly-typed enums are possibly the work of the geoarrow-rs and Sedonas of the world (where interested clients can convert the identifiers into nice structures if they need to). I think here we're just trying to provide the bare minimum for other libraries to be able to access the statistics.

Since this is not a public field, we can also potentially change it in the future too, though I do see it is part of the constructor

In my opinion it is fine to leave like this and we can adjust / update in a future release

kylebarron · 2025-09-24T00:35:19Z

parquet/src/geospatial/statistics.rs

+    /// Minimum X coordinate (longitude or easting)
+    xmin: f64,
+    /// Minimum Y coordinate (latitude or northing)
+    ymin: f64,
+    /// Maximum X coordinate (longitude or easting)
+    xmax: f64,
+    /// Maximum Y coordinate (latitude or northing)
+    ymax: f64,
+    /// Minimum Z coordinate (elevation/height), if present


I like the idea of using tuples here

kaushiksrini · 2025-09-25T04:11:03Z

Thanks @kylebarron for the review! Implemented the suggestions

alamb

Thank you @kaushiksrini and @paleolimbot and @kylebarron

There are a few more comments to resolve on this PR I think but nothing we couldn't do as a follow on PR

Please let me know when it is ready to merge and I'll do so!

alamb · 2025-09-25T19:25:38Z

parquet/src/file/metadata/mod.rs


+    /// Sets geospatial statistics for this column chunk.
+    pub fn set_geo_statistics(mut self, value: geo_statistics::GeospatialStatistics) -> Self {
+        self.0.geo_statistics = Some(Box::new(value));


I think the point would be if a user already has a Box<GeospatialStatistics> they could pass it in which would be a pointer copy, rather than this which might have to move data from the stack to the heap

alamb · 2025-09-25T19:27:30Z

parquet/src/geospatial/statistics.rs

+    /// Optional bounding defining the spatial extent, where None represents a lack of information.
+    bbox: Option<BoundingBox>,
+    /// Optional list of geometry type identifiers, where None represents lack of information
+    geospatial_types: Option<Vec<i32>>,


Since this is not a public field, we can also potentially change it in the future too, though I do see it is part of the constructor

In my opinion it is fine to leave like this and we can adjust / update in a future release

alamb · 2025-09-25T19:35:21Z

parquet/src/geospatial/statistics.rs

+/// Converts a Thrift-generated geospatial statistics object to the internal representation.
+pub fn from_thrift(
+    geo_statistics: Option<TGeospatialStatistics>,
+) -> Result<Option<GeospatialStatistics>> {


since this is infallable (always returns Ok) maybe we could make the from_thrift function just return Option

That would also let you simplify the body if you wanted

pub fn from_thrift( geo_statistics: Option<TGeospatialStatistics>, ) -> Option<GeospatialStatistics> { let geo_stats = geo_statistics?; let bbox = geo_stats.bbox.map(|bbox| bbox.into()); // If vector is empty, then set it to None let geospatial_types: Option<Vec<i32>> = geo_stats.geospatial_types.filter(|v| !v.is_empty()); Some(GeospatialStatistics::new(bbox, geospatial_types)) }

…bject

alamb · 2025-09-28T13:22:30Z

I think we have bikeshed this one enough -- than you @kaushiksrini and @kylebarron @BlakeOrth and @paleolimbot

feat: add geospatial statistics and bbox types for parquet

3e48593

kaushiksrini marked this pull request as draft August 26, 2025 01:58

github-actions bot added the parquet Changes to the parquet crate label Aug 26, 2025

kylebarron reviewed Aug 26, 2025

View reviewed changes

kaushiksrini added 3 commits August 25, 2025 22:48

fix docstring for bounding box

f100238

simplify bbox constructor

2386afe

use default and reference geospatial types to parquet format

896bf58

kylebarron reviewed Aug 26, 2025

View reviewed changes

kylebarron approved these changes Aug 26, 2025

View reviewed changes

BlakeOrth reviewed Aug 26, 2025

View reviewed changes

parquet/src/geospatial/statistics.rs Show resolved Hide resolved

kaushiksrini added 2 commits August 26, 2025 18:39

style: use match statements for z/m bbox

2134d05

test: update expected sizes by 480

17013cc

kaushiksrini marked this pull request as ready for review August 27, 2025 02:34

kaushiksrini changed the title ~~[draft] add geospatial statistics and bbox types for parquet~~ [geo] add geospatial statistics and bbox types for parquet Aug 27, 2025

kaushiksrini marked this pull request as draft August 27, 2025 02:34

kaushiksrini added 5 commits September 13, 2025 10:01

docs: add docs for geospatial types

722233b

style: reorder imports

4d3a9a7

Merge branch 'main' into feat_new_geometry_geography_types

38f5faa

Merge branch 'main' into feat_new_geometry_geography_types

149310c

Update mod.rs

d88e33f

paleolimbot reviewed Sep 16, 2025

View reviewed changes

kaushiksrini added 4 commits September 16, 2025 22:57

remove verbose documentation and add getters/setters

85ae1cb

update to_thrift tests to test with z and m values

e06b795

update docs and reading from thrift

49b7323

new file for BoundingBox

0a523d5

kaushiksrini added 4 commits September 17, 2025 23:32

remove default for bounding box

9458d6d

update docs for geospatial

c737bad

fix tests due to xmax, ymin arg switch

f29a3c0

reorder imports for lint checks

af812b2

kaushiksrini marked this pull request as ready for review September 19, 2025 16:47

kaushiksrini added 2 commits September 19, 2025 13:02

update imports in docs

a4f32b4

style: run formatter

c4a6404

paleolimbot reviewed Sep 20, 2025

View reviewed changes

alamb reviewed Sep 21, 2025

View reviewed changes

kaushiksrini added 4 commits September 21, 2025 22:19

docs: add backticks for rendering

18d1533

refactor: use Box to reduce memory burden on parquet metadata

f8d50a3

refactor: add round trip thrift bbox testing

da01007

test: add test that reads an existing file for geo stats

55a8bfe

paleolimbot reviewed Sep 23, 2025

View reviewed changes

kylebarron reviewed Sep 24, 2025

View reviewed changes

kylebarron approved these changes Sep 24, 2025

View reviewed changes

kaushiksrini added 2 commits September 24, 2025 23:27

refactor: use tuples for x, y, z, m values

1d285ae

formatting fixes

e7509f0

alamb approved these changes Sep 25, 2025

View reviewed changes

alamb mentioned this pull request Sep 25, 2025

Add Parquet geospatial statistics utility #8414

Merged

kaushiksrini added 2 commits September 26, 2025 20:26

refactor from_thrift return

a456811

changed setter for geospatial statistics to accept a heap-allocated o…

5401a96

…bject

alamb merged commit 4ba9a25 into apache:main Sep 28, 2025
16 checks passed

paleolimbot mentioned this pull request Oct 1, 2025

Support writing GeospatialStatistics in Parquet writer #8523

Closed

kaushiksrini mentioned this pull request Oct 31, 2025

[Feature] geometry and geography logical type implementations #7799

Closed

	/// - This wraparound occurs when the bounding box crosses the antimeridian line
	/// - This wraparound can occur when the bounding box crosses the antimeridian line

		/// * `bbox` - Optional bounding box defining the spatial extent
		/// * `geospatial_types` - Optional list of geometry type identifiers

	/// Returns the parquest test data directory, which is by default
	/// stored in a git submodule rooted at
	/// `arrow/parquest-testing/data`.
	///
	/// The default can be overridden by the optional environment variable
	/// `PARQUET_TEST_DATA`
	///
	/// panics when the directory can not be found.
	///
	/// Example:
	/// ```
	/// let testdata = arrow::util::test_util::parquet_test_data();
	/// let filename = format!("{}/binary.parquet", testdata);
	/// assert!(std::path::PathBuf::from(filename).exists());
	/// ```
	pub fn parquet_test_data() -> String {

	self.geo_statistics.as_ref().map(\|boxed\| boxed.as_ref())
	self.geo_statistics.as_deref()

	self.geo_statistics.as_ref().map(\|boxed\| boxed.as_ref()),
	self.geo_statistics.as_deref(),

	// If both None or mismatch, set it to None and don't error
	// If either None or mismatch, leave it as None and don't error

	//! This module provides functionality for working with geospatial data in Parquet file as defied in the [spec][parquet-geo-spec].
	//! This module provides functionality for working with geospatial data in Parquet file as defined in the [spec][parquet-geo-spec].

[geo] add geospatial statistics and bbox types for parquet #8225

[geo] add geospatial statistics and bbox types for parquet #8225

Uh oh!

Conversation

kaushiksrini commented Aug 26, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Which issue does this PR close?

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kylebarron commented Aug 26, 2025

Uh oh!

kaushiksrini commented Aug 26, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

paleolimbot left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

paleolimbot left a comment

Choose a reason for hiding this comment

Uh oh!

alamb commented Sep 21, 2025

Uh oh!

alamb left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kaushiksrini commented Sep 22, 2025

Uh oh!

paleolimbot left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

kaushiksrini commented Aug 26, 2025 •

edited

Loading