Two options of code review
This is a reasonable summary of the workflow at 2024-03-08
Mission : map all the trees in Nebraska in 2010, 2016, 2020 using ~1m NAIP imagery.
Improve a wonky workflow?
See flowcharts/flowworkflow.drawio file for details (tab 2024-03-01_workflowUpdate)
The moral of the story is this current effort requires
- manually setting parameters in a python config file and running a python script
- running a few r script (best part :) )
- running a jupyter notebook to visually eval results before exporting to GEE Asset
- evaluating results in GEE
- export from GEE web interface (likely more processing methods being added here in the near future )
- potentially more image aggregation effort in R
It looks terrible, but there are legitimate reasons for all this platform/language hopping
Still I think there potential for some serious wins in ease of use by aggregating some or all of these steps into a more single source workflow. (RMD) feels like the winner.
Python specific review
Before this project I use to think people arguing about the quality of a specific language or making claims about one being better then the other was a silly practice. While I still understand that logic and I think it's true, it's been very hard for me as a primary R programmer to adapt to the python development experience. So I expect that there are silly gems of poor python logic hidden throughout this code based.
While the workflow is producing the expected results I would feel much more confident in the process with a second set of eyes evaluating the execution of the python code. This includes functions in the 'agroforestry' sub folder, 0_developingTraingingdata.py and 1_applyModel.ipynb
Two options of code review
This is a reasonable summary of the workflow at 2024-03-08
Mission : map all the trees in Nebraska in 2010, 2016, 2020 using ~1m NAIP imagery.
Improve a wonky workflow?
See
flowcharts/flowworkflow.drawiofile for details (tab 2024-03-01_workflowUpdate)The moral of the story is this current effort requires
It looks terrible, but there are legitimate reasons for all this platform/language hopping
Still I think there potential for some serious wins in ease of use by aggregating some or all of these steps into a more single source workflow. (RMD) feels like the winner.
Python specific review
Before this project I use to think people arguing about the quality of a specific language or making claims about one being better then the other was a silly practice. While I still understand that logic and I think it's true, it's been very hard for me as a primary R programmer to adapt to the python development experience. So I expect that there are silly gems of poor python logic hidden throughout this code based.
While the workflow is producing the expected results I would feel much more confident in the process with a second set of eyes evaluating the execution of the python code. This includes functions in the 'agroforestry' sub folder, 0_developingTraingingdata.py and 1_applyModel.ipynb