list nodes / skids matching a given tag

[Gregory Jefferis]

Hi Tom et al,

I'd like to fetch the treenodes (and skids) that match a given character tag.

For example fetching the position of all cell bodies. Right now I use:

labels/stats

https://github.com/catmaid/CATMAID/blob/master/django/applications/catmaid/urls.py#L173

which fetches data for all tags for all skeletons. But what if I wanted to fetch a subset of tags or skeletons?

I can find the skids using 

/skeletons/node-labels

https://github.com/catmaid/CATMAID/blob/master/django/applications/catmaid/urls.py#L283

but that doesn't help with the tree nodes really. In fact since that endpoint finds skids using a numeric label id, how can I efficiently find the numeric id for a given label?

Many thanks as ever,

Greg.

--

Gregory Jefferis, PhD

Division of Neurobiology

MRC Laboratory of Molecular Biology

Francis Crick Avenue

Cambridge Biomedical Campus

Cambridge, CB2 OQH, UK

http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis

http://jefferislab.org

http://www.zoo.cam.ac.uk/departments/connectomics

[Chris Barnes]

Hi Greg,

The tag-table widget https://github.com/catmaid/CATMAID/blob/master/django/applications/catmaid/static/js/widgets/tag-table.js just fetches the labels/stats endpoint for all tags, caches it and then does the filtering client-side, which is probably what you're doing at the moment. Is that initial query slowing you down? In the frontend we didn't find the client-side processing to be limiting (compared to making new HTTP requests for every new filter), but maybe javascript is quicker for that sort of thing than R / python.

It probably wouldn't be difficult for us to modify the labels/stats endpoint to accept skeleton ID, treenode ID, tag ID or tag name constraints if doing it locally is hurting your workflow - just let us know.

In general, resolving string names to numeric IDs is a bit awkward and usually involves the "dumb" approach of fetching the mapping for every instance and then doing a lookup manually, because different class instances have different concepts of and uses for names.

Sorry I don't have any better news!

Regards

Chris

--
You received this message because you are subscribed to the Google Groups "CATMAID" group.
To unsubscribe from this group and stop receiving emails from it, send an email to catmaid+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Tom Kazimiers]

Hi Greg,

Chris is right: there is currently no such API in a stable release of
CATMAID that would allow you to get all treenodes and skeletons for a
particular tag. In principle this seems like useful functionality though
and I just added support for it:

https://github.com/catmaid/CATMAID/commit/921075a02a0f776549f773a5b239061cf580306b

I agree also with you and Chris that forcing the use of IDs on the API
level makes the API harder to use. Therefore, the label constraints for
the treenode query with /{project_ids}/treenodes/compact-detail now
supports both a label_names and a label_ids parameter. Labels are
expected to exist only once with a given name for a particular project.
The result contains detailed information on each matching treenode,
including its skeleton ID:

[ID, parent ID, x, y, z, confidence, radius, skeleton_id, edition_time, user_id]

I will try to update the FAFB server today or tomorrow.

Best,
Tom

[Gregory Jefferis]

Super! Thanks, Tom. Those changes will definitely be useful for us. Best, Greg.

[Tom Kazimiers]

On Mon, May 28, 2018 at 11:27:29PM +0100, Gregory Jefferis wrote:
>Super! Thanks, Tom. Those changes will definitely be useful for us.

Sure, no problem! I could imagine it would also be useful to have an
additional skeleton_ids parameter for this API to constrain also by
skeleton ID. I will probably add this later as well.

Best,
Tom

[Gregory Jefferis]

Sure, no problem! I could imagine it would also be useful to have an additional skeleton_ids parameter for this API to constrain also by skeleton ID. I will probably add this later as well.

Yes, that would certainly also be nice. But for anything except the most common labels, we can probably filter post hoc without much cost. Thanks again, Greg.

[Tom Kazimiers]

On Mon, May 28, 2018 at 11:50:13PM +0100, Gregory Jefferis wrote:
>
>> Sure, no problem! I could imagine it would also be useful to have an additional skeleton_ids parameter for this API to constrain also by skeleton ID. I will probably add this later as well.
>
>
>Yes, that would certainly also be nice. But for anything except the most common labels, we can probably filter post hoc without much cost. Thanks again, Greg.

The skeleton filter is now available as well. Good to have finally an
API for treenodes that can be filtered by labels and skeletons. Thanks
for bringing this up!

Cheers,
Tom