Cookbook chapter 2 #47
Conversation
|
Thanks, I'll look at this next week. I'm wondering though whether we should simply merge this with "chapter 1"? |
That's a hard question. While discoverability would improve, I think that having chapters is a good way to compartmentalize all the different functions and use cases that are flying around. Additionally, the examples sometimes reuse previous code, which I think becomes less clear with growing chapter size. |
|
The issue is that the space in the menu is limited and I should not add multiple chapters into the menu. It could still be two chapters in a single document, maybe? The TOC is generated anyway on the left side... |
|
so this isn't a didactic issue, it's a menu design issue :D do you want to revise now or after I merge the chapters? I will have to make some changes. |
|
Yes, more or less. For now, I'd propose to make two chapters, but have them on the same page for now. Would be great if you could do it in this PR. |
| </template> | ||
| </CodeSwitcher> | ||
|
|
||
|  |
There was a problem hiding this comment.
Should we use the figures and captions as in the data cube intro? I think they look nicer and have linked captions :-)
<figure>
<img src="./datacubes/dc_flat.png" alt="Datacube flat representation: The 12 imagery tiles are now laid out flat as a 4 by 3 grid (bands by timesteps). All dimension labels are depicted (The timestamps, the band names and the x, y coordinates).">
<figcaption>This is the 'raw' data collection that is our example datacube. The grayscale images are colored for understandability, and dimension labels are displayed.</figcaption>
</figure>
There was a problem hiding this comment.
Yes good idea! I also thought about adding some more images to chapter one. Am I assuming correctly that I should then delete some from chap 2 (e.g. the NDVI one, not really needed) as to not overload the one document that's gonna come out of this?
There was a problem hiding this comment.
Per default this renders the examples a bit bigger than needed. Is there a way to access textwidth? When I hardcode width to some percent of the page it doesn't scale well with zooming into the page.
There was a problem hiding this comment.
We need to find the sweet spot here. As long as images are compressed good enough, I leave it up to you to decide :)
There was a problem hiding this comment.
I'll think about it, should be doable in CSS without any change from your side. So just use the figures and I'll try to solve that they don't upscale.
|
I just realized that the images are rather large (also for the urk image and some getting started images). I think we should try to stick to a maximum of roughly 500kb per image. Maybe it's better to compress them all as JPEG files? |
|
Copy that. Will take care of it tomorrow. |
|
Tested it with a getting started image: Reduced from 1,8 MB PNG to 0,3 MB JPEG with those settings:
Compressed the existing images, but not the ones in this PR. Note to me: Squash this PR later to get rid of the large files in the git history. |
|
Thanks, very well written (although I added a lot of comments about minor things). |
Co-authored-by: Matthias Mohr <[email protected]>
Co-authored-by: Matthias Mohr <[email protected]>
|
Now another issue with TOC arises: only one |
|
I think there's a config option, let me check... |
|
Try to add this at the start of the markdown file: |
|
doesn't seem to work. maybe because of local server instead of via web? |
|
Seems we need to set another config option globally, I'll take care of it after merging. |
|
Good work!
|
|
Thanks!
|
Chapter 2 is ready for review 🎉
Things that still need to be done:
Any opinions and reviews are very welcome!