CAVEconnectome/CAVEclient

Querying synapses with bounding box fails

Opened this issue · 6 comments

javierhow commented

Hello!

I tried to run

Load synapse table

datastack_name = 'minnie65_public'
client = CAVEclient(datastack_name)
synapse_table = client.info.get_datastack_info()['synapse_table']
df=client.materialize.query_table(synapse_table,
bounding_box = [[0,0,0], [10, 10, 10]])

but this failed with error. TypeError: query_table() got an unexpected keyword argument 'bounding_box'

Any idea why?

Thanks!
Javier

javierhow commented

Hey Ben!

Hope you're having a good time.

I tried

dt = dict()
dt['ctr_pt_position'] = [[0, 0, 0], [10, 10, 10]]
df = client.materialize.query_table('synapse_table', filter_spatial=dt)

and it failed, too (TypeError: query_table() got an unexpected keyword argument 'filter_spatial').

Javi

bdpedigo commented

hi @javierhow - my mistake, the docs for that parameter are wrong (opened a PR to fix it) but it should be filter_spatial_dict. The following worked for me as an example:

import caveclient as cc

client = cc.CAVEclient("minnie65_public")


min_x = 208876 - 10000 / 4
min_y = 86590 - 10000 / 4
min_z = 24931 - 10000 / 40
max_x = 208876 + 10000 / 4
max_y = 86590 + 10000 / 4
max_z = 24931 + 10000 / 40
bounding_box = [[min_x, min_y, min_z], [max_x, max_y, max_z]]

synapse_table = client.info.get_datastack_info()["synapse_table"]

df = client.materialize.query_table(
    synapse_table,
    filter_equal_dict={"pre_pt_root_id": 864691135697251738},
    filter_spatial_dict={"pre_pt_position": bounding_box},
)

which found me 3 synapses.

Just a note: it was taking a while to run for me without filter_equal_dict set to something, I was too impatient to see how long it would really take

javierhow commented

Thanks! That worked.

I would like to look for everything in that bounding box without my request timing out – is that possible? Should I open a new issue?

ceesem commented

Javier, glad to see you using CAVE! There's very little we are doing other than passing the query off to PostGIS. It seems like these spatial queries are not particularly fast for large tables and are strongly limited by the performance of your SQL server (how much CPU and ram it's allocated, etc).

I would recommend chopping up your field of view into smaller regions and iterating over it. For a start, I would leave two of the dimensions in place and see how small you have to make the third before you start having reasonable performance.

We're starting to work on updated documentation, and a recipe along these lines would be a good one.

javierhow commented

Hello again Casey! :)

It looks like it always takes 8.6 minutes, no matter how large a field of view. It also looks like it always searches for locations in the native 4 x 4 x 40 nm resolution, even when I pass a desired_resolution parameter. Is that a mistake?