Open Nowosad opened 10 months ago
- [ ] 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.
:100: agree with the rest.
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?)
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
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 theoutput
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)
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 theoutput
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
We should add Acknowlegements somewhere...
Please see 1st draft here: https://py.geocompx.org/preface#acknowlegements
Standardize order of package load in each chapter (e.g., geopandas first, etc.)
Good idea, done https://github.com/geocompx/geocompy/commit/341b2b3ca0112176bb7813884070c5eecc926a4a