feat(custom-pu-grid): custom pu grid geometry

[kgajowy]

• unpacking shapefile and adding geometries - feat(custom-pu-grid): custom pu grid geometry #525 (this)
• exposing endpoint to submit & api events - feat(custom-pu-grid): custom pu grid geometry - api use case & events #527
• exposing endpoint to get the request status - feat(project): include project-related jobs in status #528
• updating project planning_unit_grid_shape - feat(custom-pu-grid): set project grid shape once geometries were set #529

[vercel]

This pull request is being automatically deployed with Vercel (learn more).
To see the status of your deployments, click below or on the icon next to each commit.

marxan – ./app

🔍 Inspect: https://vercel.com/vizzuality1/marxan/DahoHLajqxJDvDcD5WsMz8csogW9
✅ Preview: https://marxan-git-feat-marxan-252-custom-pu-geometry-grid-vizzuality1.vercel.app

marxan-storybook – ./app

🔍 Inspect: https://vercel.com/vizzuality1/marxan-storybook/HW8MPLgX6VRKYVJDFPyG8ZDEhEsB
✅ Preview: https://marxan-storybook-git-feat-marxan-252-custom-945531-vizzuality1.vercel.app

[aagm]

In terms of validation, it is part of the characteristic of a grid that their members are adjacent geometries. in order to validate it, they should not intersect with each other, but every single geometry should be intouch (connected) with at least one. If we want to do that validation with javascript, i think turf will allow you to intersect and check if the result is a line in order to ensure that they only share borders.

[aagm]

type should be inputted from the FE

[kgajowy]

Well, it's a pity we haven't mentioned this in requirements.

Are we sure this makes sense? Allowing user to provide whatever shape they want and marking the as "hex" (which isn't correct, right?) may lead system to produce unexpected results.

[aagm]

The user will upload their custom planning grid, which could be a regular (square, hexagon, triangles...) or an irregular one( whatever continuos group of geometries that can represent basins, parcels...).
For those regulars, the main difference with the ones we create is related to the grid upper left corner origin. If we want to be agnostic to the type we can make use of the same categorization in the enum planning_unit_grid_shape and mark them as from_shapefile.
But marking it as irregular is just wrong. What do you think?

[kgajowy]

@aagm I think following #526 (comment) at this very moment would be fine. (in future we can make the validation/checks also instead asking for a type, we will need to verify it anyway so we can also deduce it, right?) Nevertheless, as long as it isn't that much concern for this moment, from_shapefile sounds fair enough for current state.

[kgajowy]

updated in 0503960

[kgajowy]

In terms of validation, it is part of the characteristic of a grid that their members are adjacent geometries. in order to validate it, they should not intersect with each other, but every single geometry should be intouch (connected) with at least one. If we want to do that validation with javascript, i think turf will allow you to intersect and check if the result is a line in order to ensure that they only share borders.

Can we validate this assumption with postgis?

would https://postgis.net/docs/ST_IsSimple.html be fair enough (not sure about mentioned tangency) - checked, seems like not, as touching edges make it "invalid"

https://postgis.net/docs/postgis_usage.html#eval_spatial_rel

[hotzevzl]

In terms of validation, it is part of the characteristic of a grid that their members are adjacent geometries. in order to validate it, they should not intersect with each other, but every single geometry should be intouch (connected) with at least one. If we want to do that validation with javascript, i think turf will allow you to intersect and check if the result is a line in order to ensure that they only share borders.

Can we validate this assumption with postgis?

would https://postgis.net/docs/ST_IsSimple.html be fair enough (not sure about mentioned tangency) - checked, seems like not, as touching edges make it "invalid"

https://postgis.net/docs/postgis_usage.html#eval_spatial_rel

not something I have much experience with, but I would be surprised if this wasn't the case, and it would be much more preferable than doing this at the API layer. We can deal with this in a separate validation story, if effectively needed.