R stop working when add boundary penalties

[cliu229]

R stop working when add boundary penalties

[jeffreyhanson]

Hi,

Thanks for providing all script and data - that's very helpful! My first guess would be that the penalty value you're using might be too high? Looking over the script, it seems like you're trying a value of 300? May I suggest trying a smaller number like 1e-4 or 1e-6? This is because having a relatively high penalty value (depends on the range of cost values if min set problem) can slow down the solver a lot. For a detailed guide on calibrating the penalty value, please see this vignette: https://prioritizr.net/articles/calibrating_trade-offs_tutorial.html#blended-approach

[jeffreyhanson]

Hmm, looking into this a bit more, I think the reason might be because your planning units are highly detailed, irregular polygons. Before prioritzr can begin solving an optimization problem with the boundary penalties, it needs to do some geoprocessing to work out the shared boundary length between each pair of planning units. This step seems to be taking a while on my computer, so this might be where your computer is getting stuck.

[jeffreyhanson]

Could you please try running the following code and seeing how long it goes? This is the code used to generated the boundary matrix data that is subsequently used for the optimization. Here, we'll use a non-default option (because it doesn't always seem to work on macOS for some reason) that can speed things up a lot:

library(sf)
library(prioritizr)
d <- read_sf("planunits.shp")
m <- boundary_matrix(d, TRUE)

[ricschuster]

It looks like both vector datasets have topological errors when I check them in QGIS. That might be a possibility to cause issues.

The other thing I wanted to mention is that you could try the QMarxan QGIS plugin (https://www.aproposinfosystems.com/en/solutions/qgis-plugins/qmarxan-toolbox/) to generate the boundary file. This could be faster than the boundary_matrix function or at least worth a try.

[jeffreyhanson]

Ah - yeah, topological errors could definitely cause issues - thanks @ricschuster! You could try fixing it with sf::st_make_valid() (you might need to convert from SpatialPolygonsDaraFrame to sf object classes to get it to work). Yeah - excellent idea - if you create a boundary data file using the QMARXAN, you can import it into R (e.g. using readr::read_csv() I think) and then use it (e.g. like add_boundary_matrix(.... data=qmarxan_boundary_data))

[ricschuster]

You are welcome and great to hear that its working for you now. Please feel free to always raise issues with us.

[cliu229]

To make it easier to describe my problem clearly, I've attached my data layers folder, and Rscrip, hope it's useful!
tif.zip
script.zip

[cliu229]

Thanks Jeff,
I really appreciate your quick reply, I agree that my penalty value was set inappropriately. I will try the values you suggest.

and also I agree that it may be that my planning unit is an irregular watershed unit. Because I tried your boundary_matrix() function above, but the result is the same as before, it stops again(I am using window11), so I might need to try to set the planning unit to the same shape. Like a 1km hexagon?

Thank you again for your help！

Chang

[cliu229]

In fact, when I redivided the planning units and divided the study area into 9358 identical 1km hexagons and recalculated the cost of each unit, I stopped at the same place again when I tried to run the same code as before. Here I attach my new hexagonal planning unit.
newpu.zip

Can I still use the results for my dissertation if I don't use the penalty value? or should I say set the penalty value to 0?

[jeffreyhanson]

Sorry for my slow response - I'm at a conference at the moment. Yeah, using a different planning unit layer would be the easiest/fastest fix for this. It might be possible to keep your other planning unit layer, but I think it could be a bit complicated to get it working. I'd definitely like to update prioritizr (in time) to be able to handle your layer quickly and I have an idea that might work - but I won't be able to get to this for another 2 weeks or so. So, if you need something ASAP, I'd recommend using a hexagon/grid spatial layer for the planning units.

[jeffreyhanson]

Hmm, I'm trying to use the hexagon grid cells and it's taking ages to generate the boundary matrix on my computer - I would have expected it to run faster with only 10k planning units. If you really want boundary stuff and need results ASAP, you could try using raster based planning units - that should definitely work.

Nah, you don't neccesarily need to use boundary penalties for prioritizations. It depends on the overall goal of the prioritization. If you're trying to identify a set of priority areas for real-world implementation, they can make the priority areas a bit more clumped which can help make them more practical for implementation. If you're trying to see how different factors (e.g., data, approaches, methods, assumptions) alter the set of priority areas, then you probably don't want to include them so you can clearly see exactly how different factors affect the results. Does that help? I'm happy to provide more specific advise if you don't mind sharing a bit more about the aims/objectives of your project?

[cliu229]

Thank you Jeff! And thank you ricschuster! Thank you for catching the topology error problem!!! This is so exciting, I tried fixing the topology error in ArcGIS with the Repair Geometry command, and when I imported it again to run in R, it worked immediately! Thanks again for your professional and patient help!