Spots initialisation

[tischi]

@constantinpape
A spots source could be transformed, right?
That means that we treat it essentially like an image or a segmentation source, right?

There is something confusing now. Because to instantiate the spots I need the table.
Thus, specifying the default table in the spotDisplay is too late.
Maybe I should open the default table anyway and then potentially add more tables later during the display?

In fact that's also how my code for the segmentation looks like.
In that sense, specifying the default table at the display level is weird, because we MUST have a default table?! Ah, maybe for segmentation we also allow without any table...
But for spots?

[constantinpape]

A spots source could be transformed, right?
That means that we treat it essentially like an image or a segmentation source, right?

Yes!

There is something confusing now. Because to instantiate the spots I need the table. Thus, specifying the default table in the spotDisplay is too late. Maybe I should open the default table anyway and then potentially add more tables later during the display?

In fact that's also how my code for the segmentation looks like. In that sense, specifying the default table at the display level is weird, because we MUST have a default table?! Ah, maybe for segmentation we also allow without any table... But for spots?

This sounds to me like we should change how the table is specified in the source level metadata, and specify the default table there instead of in the view.
So the source metadata becomes:

"tableData": {
  "tsv": {
     "relativePath": "path/to/table-folder"
  },
  "defaultTable": "default.tsv"
}

and in the view we should change "tables" -> "additionalTables".

If we want to do these changes we should do it for both segmentation and spot source (also since you are using the same logic here as far as I understand).

It should still be possible to support segmentations without a table; but spot sources will always have a table (since it's their only source of data).

Let me know if this is what you have in mind, then I can change the table spec here (and we can eventually update it everywhere else).

[tischi]

Seems to make sense to me. If there is a table folder, I would say there MUST be a default table in that folder. Thus requiring this on the source level feels right.

[constantinpape]

I updated the table spec here and also added a branch with a updated segmentation table spec in another project: mobie/sponge-fibsem-project#2
(So you can test the code for that as well.)

[tischi]

Thanks, I am struggling to deserialise this though...

"spots": {
        "tableData": {
          "defaultTable": "default.tsv",
          "tsv": {
              "relativePath": "tables/transcriptome"
          }
        }
      }

I tried:

public class SpotDataSource extends AbstractDataSource
{
	// Serialization

	public TableData tableData;

        // The one below is what we used to have
	//public Map< TableDataFormat, StorageLocation > tableData;
}

with

public class TableData
{
	public String defaultTable;

        // The one below is obviously wrong but I don't know what to put there...
	public Map< TableDataFormat, StorageLocation > tableData;
}

Maybe on the JSON level the

"tsv": {
              "relativePath": "tables/transcriptome"
          }

needs to go into a field, e.g. called dataStores ?

[tischi]

What I did in the tischi branch works for me.

[constantinpape]

needs to go into a field, e.g. called dataStores ?

That doesn't make sense, we use the same layout
"tableData": {"tsv": {"relativePath": "...."}}
for the other tables (segmentation and region)

[tischi]

yes, but now you added another field into tableData, namely defaultTable.
So now tableData is not a simple map anymore.

[constantinpape]

yes, but now you added another field into tableData, namely defaultTable.
So now tableData is not a simple map anymore.

Ok, I see. (And always forget how annoying java is ;)).
We can wrap it another time and I am fine with the dataStore construct; this will also makes sense when we plan to extend this, e.g. for ome.zarr.

[tischi]

ok, so if you want you could merge the tischi branch :-)

[constantinpape]

I changed it to include the dataStore.
(I did not merge the tischi branch since I had to change all kinds of other things and did this via a script instead of manually changing the json)