This is exciting!
+1 (non-binding)
On Mon, May 19, 2025 at 3:27 PM Ryan Blue wrote:
> +1 (binding)
>
> I’ve gone through the changes in detail and I’m confident that they are
> implementable and working.
>
>- Reviewed and updated row lineage core implementation,
>readers/writers, and up
+1 (non-binding)
Thanks for putting this together!
Jia Yu
On Tue, May 6, 2025 at 2:09 PM Szehon Ho wrote:
> Hi everyone,
>
> As discussed briefly in
> https://lists.apache.org/thread/ncj0xjh2ct5xvovn4tzc45lkm1wbmorq, there
> is a minor clarification for geo type bounds that we
the PyIceberg side, we're also working to catch up on the V3
> capabilities <https://github.com/apache/iceberg-python/issues/1818>.
> Having a Java release that exposes these capabilities helps, so we can do
> round-trip validation.
>
> Kind regards,
> Fokko
>
>
> O
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 wrote:
> Agree with R
+1 (non-binding)
Thank you!
On 2025/03/19 00:01:00 Szehon Ho wrote:
> Hi everyone,
>
> While working on the reference implementation for Geometry/Geography spec,
> we noticed some parts that can be simplified for this first version:
>
>1. Default values should always be null (requires WKT s
+1 (non-binding)
I can’t wait to see the impact it will have on the broader geospatial community!
Jia Yu
On 2025/02/06 20:01:16 Szehon Ho wrote:
> Hi everyone
>
> We would like to add Geometry and Geography types to the Iceberg V3 spec:
>
> https://github.com/apache/ice
imeline of
this proposal.
Thanks,
Jia
On Tue, Aug 6, 2024 at 4:50 PM Szehon Ho wrote:
>
> It makes sense to me, thanks for summarizing it, it's an exciting list of new
> features.
>
> For Geo, I will let Wherobots engineers (Jia Yu and others) working there to
> comment, but geo
dicate pushdown to rely on x/y
>>> min/max column metadata instead of a partition key? We see use-cases where
>>> a table with a geo column can be partitioned by a different key(e.g. date)
>>> or combination of keys. It would be great to support such use cases from
>
you
> guys! I am not a 'geo expert' and I will definitely need to pull in Jia Yu
> for some of these points.
>
> Although most calculations are done on the query engine, Iceberg reference
> implementations (ie, Java, Python) does have to support a few calculations
> to hand
Dear all,
This is Jia Yu from Wherobots (Apache Sedona). This is a follow-up
regarding a recent topic discussed in the last Iceberg community sync:
how to add geospatial support in Iceberg [1] [2]. We had a preliminary
meeting today with some folks from Apple.
Here is a summary about today&#
10 matches
Mail list logo
