Improve code style for get_umap_layout and get_rasterfairy_layout

[fr1ll]

To do:

• [ ] Refactor/encapsulate get_umap_layout
  • [ ] Merge process_multi_layout_umap with process_single_layout_umap
  • [x] Add ability in process_multi_layout_umap to handle labels
• [ ] Refactor/encapsulate get_rasterfairy_layout

[fr1ll]

Encompasses Refactor get_umap_layout to avoid need for process_multi_layout_umap #47

[CarloOtano]

Interesting to note that process_single_layout_umap uses cuml_ready. In addition it will use "label" (labels are not used if cuml_ready is used).

[fr1ll]

Yes, good point. My feeling is that umap is a small part of the runtime unless you run many umaps, so it's not of much use in process_single_layout_umap.

[CarloOtano]

Another interesting difference between process_single_layout_umap and process_single_layout_umap is that a model is saved for multi layout (pickled) but not for single layout.

It all has to do how they reuse cached embeddings:

• Single layout
  • Looks for existing layout (umap-.json)
• Multi Layout
  • Loads model (a pickled AlignedUMAP object)
  • Writes each layout

[CarloOtano]

I am porting the missing functionality from single layout to multi layout. I will then deprecate single layout and always use multi layout.

[CarloOtano]

Another interesting difference between process_single_layout_umap and process_single_layout_umap is that a model is saved for multi layout (pickled) but not for single layout.

It all has to do how they reuse cached embeddings:

* Single layout

  * Looks for existing layout (umap-<plot_id>.json)

* Multi Layout

  * Loads model (a pickled AlignedUMAP object)
  * Writes each layout

I need to understand better why the models are saved, loaded and updated on the multi umap layout. It looks like updating UMAP object is not as simple as updating an AlignedUMAP object.