# Equivalent of zarr's get\_coordinate\_selection?

**URL:** <https://forum.tiledb.com/t/equivalent-of-zarrs-get-coordinate-selection/413>\
**Category:** Uncategorized\
**Created:** [December 28, 2021, 3:25pm UTC](https://forum.tiledb.com/t/equivalent-of-zarrs-get-coordinate-selection/413 "2021-12-28T15:25:14Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![joe-m](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.tiledb.com/joe-m/32/188_2.png) [@joe-m](https://forum.tiledb.com/u/joe-m)\
**Post date:** [December 28, 2021, 3:25pm UTC](https://forum.tiledb.com/t/equivalent-of-zarrs-get-coordinate-selection/413/1 "2021-12-28T15:25:14Z")

</div>

Hi,  
I have a (geospatial) dataset which is a 2D dense array 21,600 x 43,200 with float values. From this set I would like to read a set of ~100,000 coordinate pairs (corresponding to locations) and get back an array of 100,000 floats. Performance is important in this use-case.

I have been using zarr and the get\_coordinate\_selection function for the same task and this works pretty well - and specifically it seems to treat the request as a ‘batch’ to ensure that the chunks needed are decompressed only once. However I would like to compare the performance to TileDB and also I am interested in database (especially Trino) integration. I was looking at multi\_index, but this seems to take a cross\_product of ranges which is a bit different.

How best to achieve this? I am using Python API but C#/C++ also fine. I have an uneasy feeling that I am just missing something in the documentation, in which case apologies in advance! 🙂

Thanks!

---

<div class="post-metadata">

**Author:** ![ihnorton](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.tiledb.com/ihnorton/32/23_2.png) [@ihnorton](https://forum.tiledb.com/u/ihnorton)\
**Post date:** [January 7, 2022, 2:50pm UTC](https://forum.tiledb.com/t/equivalent-of-zarrs-get-coordinate-selection/413/2 "2022-01-07T14:50:48Z")

</div>

Hi @joe-m,

Apologies for the delayed response. Point queries are not currently supported – only cross-product of ranges (as you observed). However, note that ranges do not need to be slices. For example:

```auto
a.multi_index[[1],[3,4]]

```

in Python corresponds to:

```auto
query.add_range(0,1,1)
query.add_range(1,3,3)
query.add_range(1,4,4)

```

in the C++ or C# API.

@stavros indicated to me that we will bump this up in the backlog for implementation (the plan is to support arbitrary subarray slices, not only point queries).

Best,  
Isaiah

---

<div class="post-metadata">

**Author:** ![joe-m](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.tiledb.com/joe-m/32/188_2.png) [@joe-m](https://forum.tiledb.com/u/joe-m)\
**Post date:** [January 21, 2022, 3:05pm UTC](https://forum.tiledb.com/t/equivalent-of-zarrs-get-coordinate-selection/413/3 "2022-01-21T15:05:25Z")

</div>

Hi Isaiah,

Thanks for the reply. Support for arbitrary subarray slices sounds even better and I think will be important for our use case: good to hear that is being bumped up.

Thanks,  
Joe

---

<div class="post-metadata">

**Author:** ![joe-m](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.tiledb.com/joe-m/32/188_2.png) [@joe-m](https://forum.tiledb.com/u/joe-m)\
**Post date:** [April 12, 2022, 2:32pm UTC](https://forum.tiledb.com/t/equivalent-of-zarrs-get-coordinate-selection/413/4 "2022-04-12T14:32:41Z")

</div>

Hi,

Please can I check: is there a GitHub issue for this support of subarray slices that I can track? We are very interested in this feature for the OS-Climate project.

Many thanks,  
Joe

---

<div class="post-metadata">

**Author:** ![stavros](https://avatars.discourse-cdn.com/v4/letter/s/51bf81/32.png) [@stavros](https://forum.tiledb.com/u/stavros)\
**Post date:** [April 13, 2022, 11:58pm UTC](https://forum.tiledb.com/t/equivalent-of-zarrs-get-coordinate-selection/413/5 "2022-04-13T23:58:40Z")

</div>

Opened new issue here: [https://github.com/TileDB-Inc/TileDB/issues/3076](https://github.com/TileDB-Inc/TileDB/issues/3076). We will try to scope it soon. Thanks for your patience.