JN: general review (2023-10-21)

[Nowosad]

1. Repo README should be cleaned and updated (e.g., micromamba steps seem to be outdated). Maybe it would be good to simplify it and only keep one or two supported ways to reproduce the book (e.g., codespaces and mamba)?
2. Installation of the expected packages and also how to download the example datasets must be explained in the book (a new chapter 1? or at the beginning of the existing chapter 1?)
3. Also, maybe it would be good to add some place (e.g., some chapter or appendix?) to explain the datasets used in the book?
4. In general, I think it would be good to have one intro and one outro chapter (about ideas, not code). The intro chapter could contain, for example, motivation for the book, what's geocomputation, but also mention some general Python and data science in Python resources...
5. The outro chapter could contain, for example, (a) a summary of the book, (b) further steps (e.g., Cloud computing), (c) more GIS/Python resources (e.g., we could move the list of the book from the preface to the end).
6. Maybe the outro chapter could contain suggestions for a few larger projects (3-5 test yourself ideas) (think of them as large exercises, but for the entire book content, not separate chapters).
7. We should add Acknowlegements somewhere...
8. Saving some outputs messes up with git (e.g., output/world.gpkg) -- maybe we can uneval these chunks?
9. Geocompr mentions and shows examples of STAC and Postgis in chapter 10 (https://r.geocompx.org/gis#other-bridges). Given the structure of this book -- would it not be better if we show it in the I/O chapter? Some inspiration can be taken from https://loreabad6.github.io/posts/2023-10-17-stac-across-languages/
10. Standardize order of package load in each chapter (e.g., geopandas first, etc.)

[Robinlovelace]

1. Repo README should be cleaned and updated (e.g., micromamba steps seem to be outdated). Maybe it would be good to simplify it and only keep one or two supported ways to reproduce the book (e.g., codespaces and mamba)?

That plus pip for people who don't want a Python package manager would be my suggestion.

💯 agree with the rest.

[Robinlovelace]

#204 and associated new issue #205

[michaeldorman]

Saving some outputs messes up with git (e.g., output/world.gpkg) -- maybe we can uneval these chunks?

Following @Robinlovelace 's idea we are using eval:false for these cases, but this is problematic because we're losing track of whether the code works fine... Maybe there is another solution? (I guess we can't exclude the output directory from Git because it's used in the code and then GitHub actions won't work, right?)

[michaeldorman]

Geocompr mentions and shows examples of STAC and Postgis in chapter 10 (https://r.geocompx.org/gis#other-bridges). Given the structure of this book -- would it not be better if we show it in the I/O chapter? Some inspiration can be taken from https://loreabad6.github.io/posts/2023-10-17-stac-across-languages/

This is a good idea, I'm not familiar with STAC but will be happy to include a PostGIS example. If there is a way to secretly store a password as part of the repository then we can use our own server

[Nowosad]

Saving some outputs messes up with git (e.g., output/world.gpkg) -- maybe we can uneval these chunks?

Following @Robinlovelace 's idea we are using eval:false for these cases, but this is problematic because we're losing track of whether the code works fine... Maybe there is another solution? (I guess we can't exclude the output directory from Git because it's used in the code and then GitHub actions won't work, right?)

Hm.. I think eval:false in just this case should be fine (writing does not seem to be a function that changes a lot in time). @michaeldorman you maybe could also add a hidden chunk that is evaluated that saves the data into some temporary folder and then removes the folder -- this way you could be sure that the function works without messing with git... (just an idea)

[michaeldorman]

Saving some outputs messes up with git (e.g., output/world.gpkg) -- maybe we can uneval these chunks?

Following @Robinlovelace 's idea we are using eval:false for these cases, but this is problematic because we're losing track of whether the code works fine... Maybe there is another solution? (I guess we can't exclude the output directory from Git because it's used in the code and then GitHub actions won't work, right?)

Hm.. I think eval:false in just this case should be fine (writing does not seem to be a function that changes a lot in time). @michaeldorman you maybe could also add a hidden chunk that is evaluated that saves the data into some temporary folder and then removes the folder -- this way you could be sure that the function works without messing with git... (just an idea)

That's a good idea! Noted to self to check it out

[michaeldorman]

We should add Acknowlegements somewhere...

Please see 1^st draft here:
https://py.geocompx.org/preface#acknowlegements

[michaeldorman]

Standardize order of package load in each chapter (e.g., geopandas first, etc.)

Good idea, done 341b2b3