From d6fb1ed3695500f22e75234059d4bb35a7ca6297 Mon Sep 17 00:00:00 2001 From: Tim Welch Date: Fri, 27 Dec 2024 07:29:58 -0800 Subject: [PATCH] docs: sampleProject fixes, upgrade nits --- website/docs/tutorials/sampleproject.md | 25 +++++++++++++-------- website/docs/tutorials/upgrade.md | 30 +++++++++---------------- 2 files changed, 27 insertions(+), 28 deletions(-) diff --git a/website/docs/tutorials/sampleproject.md b/website/docs/tutorials/sampleproject.md index 05072e6e9..0d9ffe109 100644 --- a/website/docs/tutorials/sampleproject.md +++ b/website/docs/tutorials/sampleproject.md @@ -272,6 +272,16 @@ Language translation is a multi-part process: This process is covered in more detail in a separate doc. +### Download Project Data + +Download a data package prepared for FSM to your project space and unzip it: + +```bash +wget -P data/src https://github.com/user-attachments/files/18030075/FSM_MSP_Data_Example_v2.zip +unzip data/src/FSM_MSP_Data_Example_v2.zip -d data/src +rm data/src/FSM_MSP_Data_Example_v2.zip +``` + ### Generate Examples With a working geoprocessing function and report client already in place, you're ready to generate example sketches for testing them. We'll use the same `genRandomPolygon` script as before. But let's look closer at how we figured out the bounding box extent of the Micronesian planning area. First, use ogrinfo to inspect the Micronesia EEZ polygon data layer in your data package. @@ -284,6 +294,11 @@ Deep in its output you will see a `geometryFields` property, which contains the ```bash ogrinfo -so -json data/src/eez_withland_mr.fgb | jq -c .layers[0].geometryFields[0].extent +``` + +Output: + +```bash [135.31244183762126,-1.1731109652985907,165.67652822599732,13.445432925389298] ``` @@ -597,15 +612,7 @@ Next you will create a coral reef report that uses the reef extent dataset. Here ### Import Data -To access this datasource, first download a data package prepared for FSM to your project space and unzip it: - -```bash -wget -P data/src https://github.com/user-attachments/files/18030075/FSM_MSP_Data_Example_v2.zip -unzip data/src/FSM_MSP_Data_Example_v2.zip -d data/src -rm data/src/FSM_MSP_Data_Example_v2.zip -``` - -Now import the datasource to your project. +Now import a datasource to your project. ```bash npm run import:data diff --git a/website/docs/tutorials/upgrade.md b/website/docs/tutorials/upgrade.md index 60b2df349..581bdb72a 100644 --- a/website/docs/tutorials/upgrade.md +++ b/website/docs/tutorials/upgrade.md @@ -131,29 +131,17 @@ These migration guides are a supplement to the [release notes](https://github.co ### 6.x to 7.x -There are so many changes that the suggested way to migrate is just to initalize a fresh 7.0 project, and then migrate your assets over. If you do this: - Migration examples: - [bermuda-reports](https://github.com/seasketch/bermuda-reports-next) which created a new git repository and left the [old one](https://github.com/mcclintock-lab/bermuda-reports) behind. -#### Unstable Testing - -If you are testing out a new `unstable` image you will need to pull using that tag instead: - -```bash -docker pull seasketch/geoprocessing-workspace:unstable -``` +#### Running Multiple Versions of Geoprocessing Workspace -Then, when restarting your VSCode devcontainer, choose the `unstable` version. +The latest version of the `geoprocessing-workspace` will only work with geoprocessing 7.x projects. This is due to a change in how GDAL produces flatgeobuf files. If you suddenly see errors of `"Not a FlatGeobuf file"` when trying to read your file, this is likely the reason. -If you get an error when starting unstable, make sure that you have a .env file in your `local-dev-unstable` directory. You need to have one there, just as in the top-level stable devcontainer directory. +In order to continue to develop older 6.x and lower geoprocessing projects at the same time, you will need to start your devcontainer using the `local-dev-pre-7x` environment. This is pinned to an older version of the docker image - `seasketch/geoprocessing-workspace:sha-69bb889` -#### When Using Geoprocessing Less Than 7.0 - -The latest version of the `geoprocessing-workspace` will only work with geoprocessing 7.x projects. This is due to a change in how GDAL produces flatgeobuf files. If you suddenly see errors of `"Not a FlatGeobuf file"` when trying to read your file, this is likely the reason. In order to continue to develop older 6.x and lower geoprocessing projects you will need to start your devcontainer using the `local-dev-pre-7x` environment. This is pinned to an older version of the docker image - `seasketch/geoprocessing-workspace:sha-69bb889` - -#### Convert code to ESM +#### Migrate Code To ESM As you migrate functions and report components from a pre 7.0 project to a 7.x project you will need to migrate your code to the format required by Node for ESM code. You will also need to make it Node 22 compliant. @@ -163,7 +151,7 @@ Here's a summar of the changes required. VSCode should give you hints along the - NodeJS when using the ES Module engine now requires explicit paths to code files. No longer can you import a module from a directory (e.g. `import foo from ./my/directory`) and expect it will look for an index.js file. You have to change this to`import foo form ./my/directory/index.js`. `__dirname` built-in must be changed to `import.meta.dirname` -#### Migrate asset imports +#### Migrate Asset Imports `require` is no longer allowed for importing images and other static assets. Vite expects you to import the assets [directly](https://vitejs.dev/guide/assets#importing-asset-as-url) as urls. SizeCard.tsx is one component installed by default with projects that will need to be updated. @@ -192,6 +180,10 @@ At this point, VSCode will complain about your image import, it doesn't support // https://vitejs.dev/guide/features.html#client-types ``` +#### Migrate Preprocessing Functions + +[Preprocessing functions](https://github.com/seasketch/geoprocessing/blob/dev/packages/template-blank-project/src/functions/clipToOceanEez.ts) should be upgraded to the [newest form](https://github.com/seasketch/geoprocessing/blob/v7.0.0/packages/template-ocean-eez/src/functions/clipToLand.ts). + #### Other Changes - Any .js file in your codebase may need to be changed to have a .cjs extension to make Node happy. @@ -222,7 +214,7 @@ const projectClient = new ProjectClientBase({ export default projectClient; ``` -#### Migrate styled-components +#### Migrate Styled Components - If you have report components that use styled-components for its styling, you will need to change all code imports of `styled-components` from @@ -244,7 +236,7 @@ The solution is to switch to using `transient` prop names, or component prop nam - https://jakemccambley.medium.com/transient-props-in-styled-components-3105f16cb91f -#### Stop importing directly from @seasketch/geoprocessing in report clients +#### Stop Importing Directly From @seasketch/geoprocessing - Report client code must no longer import from geoprocessing libraries top level entry point `@seasketch/geoprocessing` or you may see a "require is not defined" error or other errors related to Node specific modules not found. The solution is to switch from for example: