JOSS paper

[evetion]

As part of my PhD I would like to create a JOSS paper for this package. While the current form is fine, ideally we would polish it a bit for further ease of use.

• Users can query specified variables from granules (Master file structure for each granule Type could reduce code significantly and add flexibility ? #58)
• ?

@alex-s-gardner Any thoughts on more functionality? Do we need further postprocessing, plotting, cleaning etc?

[alex-s-gardner]

• Having visualization work well with GeoMakie and Tyler would be nice. Maybe these are just examples but I'm sure the users would appreciate it.
• we never really converged on H52Table. I liked it's flexibility for adding new products as the algorithm is highly generic.
• The most powerful aspect of SpaceLiDAR is easily getting all of the lidar data in a consistently formatted tabular format... I don't the package should deviate far from that.
• if you wanted to expand it, the most welcomed feature would be to add additional datasets that are fundamentally point observations of height like SWOT and CryoSat-2
• any chance you'd want to move from "[Material for MkDocs]" to "[DocumenterVitepress.jl]" for homogenization across the JuliaGeo ecosystem?
• depreciate https://app.gitter.im/#/room/#evetion_community:gitter.im if it's not being watched.

[evetion]

Thanks, these are excellent points!

• Having visualization work well with GeoMakie and Tyler would be nice. Maybe these are just examples but I'm sure the users would appreciate it.

Good point, we should check we can plot these granules/resulting tables, maybe even interactively with GeoMakie. We probably don't need to depend on it, just make sure GeoInterface works correctly, and create better documentation.

• we never really converged on H52Table. I liked it's flexibility for adding new products as the algorithm is highly generic.

Agreed, that's why I put it in the list above, I would like to converge on such a design.

• The most powerful aspect of SpaceLiDAR is easily getting all of the lidar data in a consistently formatted tabular format... I don't the package should deviate far from that.
• if you wanted to expand it, the most welcomed feature would be to add additional datasets that are fundamentally point observations of height like SWOT and CryoSat-2

Agreed. I don't expect to implement these myself. But if they share similar HDF5 files it might be easier to implement them once we have implemented the generic HDF5Table design. Especially if they're also on NASA EarthData.

• any chance you'd want to move from "[Material for MkDocs]" to "[DocumenterVitepress.jl]" for homogenization across the JuliaGeo ecosystem?

Do you think we need to? The mkdocs is indeed an outlier, precisely because I was unhappy with the default Documenter scheme. Vitepress is a bit like mkdocs, with even better default styling for a nice frontpage. They share a top bar, which was my main goal to have.

• depreciate app.gitter.im#/room/#evetion_community:gitter.im if it's not being watched.

Good point, I'll remove it.

[alex-s-gardner]

• any chance you'd want to move from "[Material for MkDocs]" to "[DocumenterVitepress.jl]" for homogenization across the JuliaGeo ecosystem?

Do you think we need to? The mkdocs is indeed an outlier, precisely because I was unhappy with the default Documenter scheme. Vitepress is a bit like mkdocs, with even better default styling for a nice frontpage. They share a top bar, which was my main goal to have.

It's certainly not a need, just a nice-to-have. JuliaGeo packages are looking pretty slick theses days with a uniform look and interface that users are already familiar with how to navigate the docs.