-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs(custom-pu-grid): initial hld #526
Conversation
This pull request is being automatically deployed with Vercel (learn more). marxan-storybook – ./app🔍 Inspect: https://vercel.com/vizzuality1/marxan-storybook/FVf8FPN1mxc4rL9fHwF9qwJwJPCx marxan – ./app🔍 Inspect: https://vercel.com/vizzuality1/marxan/3fkFF3FU9f3rzxvnpyunMFxzebBQ |
@mbarrenechea would you want to declare how frontend team wants to process with uploading / fetching status? (don't mind current setup if you want) Feel free to commit to LLD.md |
* once set, shape cannot be changed or removed from project | ||
* only `FeatureCollection` with `Polygon` features can be uploaded | ||
* custom planning unit grid geometry belongs to given project | ||
* custom planning unit grid geometry has a type of `irregular` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Irregular
is not for user-uploaded data, is for another kind of PU grid that will not follow a regular shape (i.e. River basins), and we will provide it in a future phase of the project. (Instead, please provide the options to the user)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@aagm what should then be the type then? if this is a new type, what possible implications it has?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The user should provide the type and the 3 we have should be kept (we should also expand it with from_shapefile: [square, hexagon, irregular, from_shapefile]
) and match the enum in the API planning_unit_grid_shape
( [square, hexagon, irregular, from_shapefile]
),
What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added in 99dbd8f
@mbarrenechea
the last one is just a proposition how we could implement it for such cases, however we can keep using |
@mbarrenechea having no response, implemented it with the second option (add to |
ID returned from request can be ignored. In the future, it may be used to | ||
fetch status of the job directly. | ||
|
||
# Getting status of the processing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it may get out of sync with the code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other than that and ensuring jobs and api events work similar within all processing bits i think it could be merge.
* project with custom planning unit grid geometry cannot use other shape types | ||
* uploaded shapefile will be processed asynchronously | ||
* until processed, any action on project/underlying scenarios shouldn't be | ||
allowed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
allowed | |
allowed | |
## Processing requirements after a successful user upload of a Custom planning grid: | |
* From the boundaries of it, we need to generate a custom planning area. | |
* When a scenario is created we need to attach the custom grid with the scenario (need to expand current flow). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
as a corollary (ish) of the first of the suggested additions here, we also set the bbox for the project - worth making it explicit here, I think
# Key assumptions | ||
|
||
* shape can be re-uploaded as long as there are no scenarios created yet | ||
* only `FeatureCollection` with `Polygon` features can be uploaded |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am very concerned if they end up with irregular shapes that need multipolygons. Also, we need to ensure this feature collection really represents a grid or a surface.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, thats why we have the spike-task for everything related to real validation of the shape being "greed grid"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
* only `FeatureCollection` with `Polygon` features can be uploaded | |
* only `FeatureCollection` with `Polygon` features can be uploaded, and this must be validated on upload | |
* shapefiles will be rejected if they do not comply with the condition above, and possibly other conditions to be identified before implementation | |
* conditions that may not be expediently validated should be clearly documented (as part of user documentation) |
would the above allow us to move forward?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hotzevzl not sure if this should really be validated there (would rather pin-point to geoprocessing and it may be heavy)
9c103e9
to
9b7c731
Compare
https://vizzuality.atlassian.net/browse/MARXAN-252
Next steps: