Open ericbroda opened 2 weeks ago
Hi @ericbroda,
Also FYI @xbarra and @NickKellett.
Good initiative to add to the docs. As discussed, I think next step is to check what goes where, In https://physrisk.readthedocs.io/en/latest/ we currently have
Docs are now using .ipynb apart from a bit of glue logic. I think that is also good to encourage contributions as most people happy to write a notebook.
Thanks, Joe
Hi @ericbroda; hi @NickKellett,
By the way, I'm also writing more on hazard indicators storage. This includes the current Zarr set-up, but I also want to write this to include your spatial indexing work. The flow is that:
Would you have a half-pager or so I can integrate there on the spatial indexing part (I think we can then expand on that later)?
I think to start with I want to cover the main idea (i.e. which DB are we using, how it works with sparsity and how the smart look-up works.
Thanks, Joe
hi @ericbroda, @xbarra,
After (in-person) feedback, the above plan for sections seems a good place to start, so I restructured; please see updated here: https://physrisk.readthedocs.io/en/latest/ Please take a look, especially at the user guide part to check structure is OK. I also moved to ReadTheDocs theme by the way, mainly as seemed to do better job for table display.
Thanks, Joe
Is your feature request related to a problem? Please describe.
This is a request to create/enhance documentation
Describe the solution you'd like
Problem Statement: The model developer experience today requires significant knowledge of the inner workings of the physrisk code base and the various data formats
The Goal: Documentation and utilities should be available to allow personnel with reasonable experience (python, modelling etc) to quickly ("in 5 minutes or less"):
Describe alternatives you've considered
Current methodology documents are well established. Recognizing the methodology is somewhat complex, it is expected that the code that implements this methodology by its nature will be also be complex. This complexity is currently addressed by creating:
This is the current approach, but more needs to be done achieve our goal.
Our request is to augment existing documentation efforts and create/structure our documentation (and supporting utilities) into several guides, each targeted at specific (common) user groups:
Additional context
No additional context noted