Add structure id and acronym to JSON

[wbwakeman]

What's the problem this feature will solve? LIMS needs to report the structure of the mouse brain in which a pin has been pinned. The JSON that is saved to LIMS has the CCF coordinates of the pin. Although it is possible to use that information to compute the structure at that location, I believe that information is already known in Cell Locator.

Describe the solution you'd like Include the structure acronym and id information in the JSON for each pin. (And ontology name and id too if that info is available to Cell Locator)

Without this information being passed from Cell Locator to LIMS, we will need to create a separate module that loads the CCF volume and annotation files so that we can look up the structure based on the CCF coordinates. If the structure information is included, then LIMS can just parse the JSON to save and present this valuable information to LIMS users.

Alternative Solutions Yes, we have a prototype for a module that computes the structure from the CCF coordinates that are in the JSON. That exercise is what made us wonder if there were any simpler solutions.

Additional context

[jcfr]

@wbwakeman Could you include a diff below outlining which attributes we should add ? Example of annotation are available here: https://cell-locator.readthedocs.io/en/latest/developer_guide/AnnotationFileFormat.html#versions

[wbwakeman]

Adding two lines to a snippet of JSON from that link (note that "name" already exists):

{
    "version": "0.1.0+2020.09.18",
    "markups": [
        {
          "name":"Gad2-IRES-Cre;Ai14-600202.11.02.03",
+        "structure_id": 362,
+         "structure_acronym":"MD"
            "markup": {
                "type": "ClosedCurve",
                "coordinateSystem": "LPS",
                "controlPoints": [
                    {
                        "id": "1",
                        "position": [
                            -7725.476777936878,
                            5071.924649397559,
                            -2858.6838622146615
                        ],
                        "orientation": [
                            -1.0,
                            0.0,

https://gist.github.com/wbwakeman/73b802e1072aff0ad18be28801ea0310 is an example of a json generated by CellLocator 0.2.0-2021-08-12 where I have added "structure_id" and "structure_acronym" for each of the three Fiducial points. Also a screenshot that may help illustrate the request

If it is easy to add another key that specifies what ontology or atlas the structure is part of, that would be really nice too. But maybe that is getting into the territory of #196 .

[wbwakeman]

JSON example: https://gist.github.com/wbwakeman/73b802e1072aff0ad18be28801ea0310

[allemangD]

Adding two lines to a snippet of JSON from that link (note that "name" already exists):

If it is easy to add another key that specifies what ontology or atlas the structure is part of, that would be really nice too. But maybe that is getting into the territory of #196.

I think it may make sense to use a nested structure to encode all of this information. In order to keep things consistent I would also like to add support for this in the file format conversion tool, but this would require these fields to be optional (or otherwise have some sensible default value).

I suggest:

"name": "Gad2-IRES-Cre;Ai14-600202.11.02.03",
"structure": {
  "id": 362,
  "acronym": "MD",
  "atlas": "..."
},
"markup": {

For files updated with the conversion tool, or otherwise as a "default" value, I suggest:

"name": "Gad2-IRES-Cre;Ai14-600202.11.02.03",
"structure": null,
"markup": {

@wbwakeman do you have any thoughts on this?

There is a question of what "id" to use for "atlas"; this could be the filename of the atlas, but it seems there should be a greater emphasis on portability. The strings "CCF" and "MNI" do not feel general enough, looking forward to #196. Does the atlas format have some kind of canonical name or ID that we could reference here? Otherwise I would omit "atlas", to be included in #196

[wbwakeman]

@allemangD I like your format suggestion. That should work well.

For the atlas identifier, I don't know what information the program has access to right now. This ticket should definitely not expand to holding additional information about the atlases that already exist in the system.

[allemangD]

That's a good point. I'll plan to add the "id" and "acronym" fields to that object, and will update the conversion tool to set null on existing files.