feat(arrow/extensions): add support for geoarrow.point by Mandukhai-Alimaa · Pull Request #545 · apache/arrow-go

Mandukhai-Alimaa · 2025-10-23T22:15:55Z

Rationale for this change

There is no support for geoarrow in go

What changes are included in this PR?

Add support for geoarrow.point and register it as extension type and add tests for the geoarrow.point

Are these changes tested?

Yes, the newly added test and all the other tests are passing.

Are there any user-facing changes?

Users will be able to use geoarrow.point as an extension type.

Mandukhai-Alimaa · 2025-10-23T22:21:39Z

This is part of solving #504. On the last PR to add support for the final geoarrow data type will add the closes tag and close the issue

zeroshade · 2025-10-24T20:41:45Z

arrow/extensions/geoarrow_point.go

+func (p Point) IsEmpty() bool {
+	return math.IsNaN(p.X) && math.IsNaN(p.Y) && math.IsNaN(p.Z) && math.IsNaN(p.M)
+}


the comment says "NaN or zero" but you're only checking for NaN here

zeroshade · 2025-10-24T20:46:32Z

arrow/extensions/geoarrow.go

+// GeometryEncoding represents the encoding method for geometry data
+type GeometryEncoding int
+
+const (
+	EncodingGeoArrow GeometryEncoding = iota
+)


what would be the alternate to this that would be the other constants?

zeroshade · 2025-10-24T20:48:24Z

arrow/extensions/geoarrow.go

+	// Encoding specifies the geometry encoding format
+	Encoding GeometryEncoding `json:"encoding,omitempty"`


I don't see this in the spec, where is this member coming from?

zeroshade · 2025-10-24T20:50:40Z

arrow/extensions/geoarrow.go

+	// CRS contains PROJJSON coordinate reference system information
+	CRS json.RawMessage `json:"crs,omitempty"`


While it should be PROJJSON it could also be other formats

zeroshade · 2025-10-24T20:51:44Z

arrow/extensions/geoarrow.go

+}
+
+// GeometryMetadata contains metadata for GeoArrow geometry types
+type GeometryMetadata struct {


you're missing the optional crs_type member which should be one of

"projjson"

"wkt2:2019"

"authority_code"

"srid"

zeroshade · 2025-10-24T21:19:59Z

arrow/extensions/geoarrow_point.go

+// Value returns the Point at the given index
+func (p *PointArray) Value(i int) Point {
+	pointType := p.ExtensionType().(*PointType)
+	structArray := p.Storage().(*array.Struct)


need to determine whether it is interleaved or separate before you assume it's a struct

zeroshade · 2025-10-24T21:20:36Z

arrow/extensions/geoarrow_point.go

+	point := Point{Dimension: pointType.dimension}
+
+	if p.IsNull(i) {
+		return point


why not use NewEmptyPoint?

zeroshade · 2025-10-24T21:24:46Z

arrow/extensions/geoarrow_point.go

+	switch point.Dimension {
+	case DimensionXY:
+		return []float64{point.X, point.Y}
+	case DimensionXYZ:
+		return []float64{point.X, point.Y, point.Z}
+	case DimensionXYM:
+		return []float64{point.X, point.Y, point.M}
+	case DimensionXYZM:
+		return []float64{point.X, point.Y, point.Z, point.M}
+	default:
+		// Should never happen but defensive programming
+		panic(fmt.Sprintf("unknown coordinate dimension: %v", point.Dimension))
+	}


implement MarshalJSON on the Point type and then just use that

zeroshade · 2025-10-24T21:26:34Z

arrow/extensions/geoarrow_point.go

+	structBuilder := b.Builder.(*array.StructBuilder)
+	structBuilder.Append(true)


same comment as above needs to handle the interleaved OR separate cases

zeroshade · 2025-10-24T21:28:20Z

arrow/extensions/geoarrow_point.go

+
+// AppendNull appends a null value to the array
+func (b *PointBuilder) AppendNull() {
+	b.ExtensionBuilder.Builder.(*array.StructBuilder).AppendNull()


same comment as above, need to handle the FixedSizeList case

paleolimbot

Very cool!

I will take a closer look over the weekend, but I did want to quickly point out up front that geoarrow.wkb is the only one required for GeoParquet/Parquet Geometry/Geography support (because in Parquet land everything is WKB binary). Functionally that just means there's a tiny bit of CRS translation that has to happen on read/write (and a bit of WKB parsing if you would like to support writing statistics).

Implementing the other extension types is also very cool but fairly difficult (the matrix expansion of point/linestring/polygon/multipoint/multilinestring/multipolygon by xy/xyz/xym/xyzm by interleaved/separated is sort of insane to deal with and is not widely used).

Mandukhai-Alimaa · 2025-10-27T03:05:37Z

@paleolimbot, before you spend time looking at this, I will address @zeroshade's feedback and fix some stuff first.

But for the bigger picture, do you think I should punt on geoarrow.point and start with geoarrow.wkb ? It sounds like it would provide more value. What do you think?

paleolimbot · 2025-10-27T03:55:38Z

But for the bigger picture, do you think I should punt on geoarrow.point and start with geoarrow.wkb ?

If you are aiming for Parquet Geometry/Geography support, yes, because geoarrow.point isn't used in any part of that. The metadata for geoarrow.wkb is the same as for geoarrow.point (e.g., CRS, edges), and so I think most of this PR is equally relevant to that.

dwilson1988 · 2026-03-03T14:31:33Z

@Mandukhai-Alimaa - I'm looking into the iceberg side of this currently and am happy to help take this across the finish line. I think @paleolimbot is probably right about WKB being the priority here - I'll start with this branch and change it to support WKB first with a route to support non-encoded native types as well as a future PR

Mandukhai-Alimaa · 2026-03-03T15:27:55Z

@dwilson1988 that sounds good. Thank you.

zeroshade · 2026-03-04T17:22:43Z

@dwilson1988 feel free to ping me when you update this so I know to take another pass/look at this!

dwilson1988 · 2026-03-07T00:52:54Z

@zeroshade - I'm going to create a separate PR with the general pattern I came up with and an implementation for the WKB encoding.

Had a question though. For Go, https://github.com/twpayne/go-geom is a pretty solid package that has memory layout virtually identical to GeoArrow - it's used in a lot of Go that uses geometry. (Disclaimer: my company uses it a lot internally). Would you be okay adding it as a dependency? That would allow all GeoArrow types (including WKB/WKT) to Value as a geom.T very efficiently and I think make the whole thing much more useful.

Alternatively, I have a decent path to make it fairly easy for users to register their own external geometry types I think (but I got to play around a bit more to be sure it works well enough)

dwilson1988 · 2026-03-09T14:43:10Z

I should be more clear - WKT/WKT would Value as geom.T but the others as their native go-geom types (*geom.Point, *geom.Polygon, etc)

paleolimbot · 2026-03-09T14:49:44Z

I would personally recommend inlining the logic you need unless there's a good way to add an optional dependency. I think I upstreamed SedonaDB's interval handling into arrow-rs/parquet-geospatial which should have all you need (mainstream geometry implementations mostly don't handle wraparound intervals and so they aren't all that useful anyway).

dwilson1988 · 2026-03-09T14:52:35Z

Dewey - was more interested in the types themselves since they are robust implementations that are fairly ubiquitous in the Go world. The WKT/WKB parsing itself wouldn't be terrible, but the geometry types themselves would be essentially recreating what's already in go-geom.

paleolimbot · 2026-03-09T15:04:17Z

I am not familiar with the Go internals, but I'm surprised that you need concrete types for anything? (At least in terms of minimal requirement for writing statistics or doing pruning, I am not sure any of those types would help?)

dwilson1988 · 2026-03-09T15:29:47Z

In arrow? We can provide the raw structs and such, but that puts a lot of burden on the user to get a concrete type. I agree that with iceberg we don't need much, but for a particular Value, getting the raw arrow structs is less immediately useful than getting a Go type back (as is already done for other types like uuid).

dwilson1988 · 2026-03-09T15:31:43Z

arrow/extensions/geoarrow_point.go

+)
+
+// Point represents a point geometry with coordinates
+type Point struct {


@paleolimbot - I meant for these types. For all the concrete geoarrow native encodings, I wanted to use go-geom types for each instead of redefining new ones.

https://github.com/twpayne/go-geom/blob/407ce645ab08a9a093e599ca07522d8fa483806d/point.go#L15

feat(arrow/extensions): add support for geoarrow.point

b79c4a6

Mandukhai-Alimaa requested a review from zeroshade as a code owner October 23, 2025 22:15

zeroshade requested review from amoeba, lidavidm and paleolimbot October 24, 2025 20:31

zeroshade requested changes Oct 24, 2025

View reviewed changes

paleolimbot reviewed Oct 24, 2025

View reviewed changes

zeroshade mentioned this pull request Nov 19, 2025

wip: feat(metadata): Geometry and Geography metadata support apache/iceberg-go#628

Open

dwilson1988 reviewed Mar 9, 2026

View reviewed changes

		// Encoding specifies the geometry encoding format
		Encoding GeometryEncoding `json:"encoding,omitempty"`

		// CRS contains PROJJSON coordinate reference system information
		CRS json.RawMessage `json:"crs,omitempty"`

		structBuilder := b.Builder.(*array.StructBuilder)
		structBuilder.Append(true)

Conversation

Mandukhai-Alimaa commented Oct 23, 2025

Rationale for this change

What changes are included in this PR?

Are these changes tested?

Are there any user-facing changes?

Uh oh!

Mandukhai-Alimaa commented Oct 23, 2025

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!

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!

Mandukhai-Alimaa commented Oct 27, 2025

Uh oh!

paleolimbot commented Oct 27, 2025

Uh oh!

dwilson1988 commented Mar 3, 2026

Uh oh!

Mandukhai-Alimaa commented Mar 3, 2026

Uh oh!

zeroshade commented Mar 4, 2026

Uh oh!

dwilson1988 commented Mar 7, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dwilson1988 commented Mar 9, 2026

Uh oh!

paleolimbot commented Mar 9, 2026

Uh oh!

dwilson1988 commented Mar 9, 2026

Uh oh!

paleolimbot commented Mar 9, 2026

Uh oh!

dwilson1988 commented Mar 9, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

dwilson1988 commented Mar 7, 2026 •

edited

Loading