Hi Jia I think its about the spec, and not the implementation (which is definitely good to reduce risk to need to change the spec). We actually wanted to get our Parquet reader/writer out for this effort, but as we see, it seems it depends on next Parquet-java release for the new Geo types on Parquet side.
But on the spec front, I was going to check if we needed anything, like additional specification for null/nan x,y,z,m coordinates as we were briefly brainstorming. I know we were also brainstorming about LINEAR edge interpolation algorithm for Geography type (and I know you guys were against it), but in any case these are not backward incompatible. Basically anything that would potentially be backward incompatible we should prioritize before V3 spec is finalized. Thanks Szehon On Tue, Apr 29, 2025 at 10:25 PM Jia Yu <ji...@apache.org> wrote: > Hi folks, > > For Iceberg Geo, we are still waiting for the PR of geospatial bounds and > geospatial predicate to be merged: > https://github.com/apache/iceberg/pull/12667 > > Should a release with core updates include this PR? > > Thanks, > Jia > > On Tue, Apr 29, 2025 at 10:21 PM Manu Zhang <owenzhang1...@gmail.com> > wrote: > >> Agree with Russell and JB that we make a "RC" release for V3 spec to test >> implementations, compatibility, etc before finalizing it. >> >> Thanks, >> Manu >> >> On Wed, Apr 30, 2025 at 12:24 PM Jean-Baptiste Onofré <j...@nanthrax.net> >> wrote: >> >>> Hi Ryan >>> >>> It sounds good. >>> >>> About multi-args transforms, with the clarification we did a couple of >>> weeks ago, I think we are good. >>> Maybe a release with the core updated before announcing spec v3 >>> officially would be a good idea ? >>> >>> Regards >>> JB >>> >>> Le mer. 30 avr. 2025 à 00:35, Ryan Blue <rdb...@gmail.com> a écrit : >>> >>>> Hi everyone, >>>> >>>> I think we’ve reached the point where it’s time to finalize and adopt >>>> the changes for Iceberg v3. We’ve been working toward this for the last few >>>> months and have now implemented the v3 features in the Java library to >>>> reduce the risk of needing changes or hitting problems (row lineage support >>>> in Spark 3.5 just went in!). We’ve also incorporated some clarifications >>>> and minor changes back into the spec from what we’ve learned. >>>> >>>> At this point, I’m confident that the spec is reasonable and correct. >>>> Thank you to everyone working on these reference implementations! >>>> >>>> The next step is to discuss any outstanding items or concerns about >>>> moving forward, and then to have a vote thread to adopt the spec. I’ll >>>> start off with a couple of items: >>>> >>>> One potential concern is that the upstream Variant spec hasn’t yet been >>>> finalized by the Parquet community, but we’ve built a full, independent >>>> implementation in Iceberg to validate the spec. I think the Parquet >>>> community is primarily waiting on getting the PRs in to have a Java >>>> reference implementation, so the risk of changes to the Variant spec is >>>> small. >>>> >>>> There’s also an on-going vote to add encryption keys in support of full >>>> table encryption that I think we want to get in. >>>> >>>> Any other items we may want to clear up? >>>> >>>> Ryan >>>> >>>
