prioritizr / prioritizrutils Goto Github PK

The package includes the boilerplate for the add_connected_constraint but it does not actually implement this constraint--it just returns an error.

For reference, the formulation for the connected constraint is detailed in section 2.3.2 in Billionnet 2013.

The default branch of this repository is being moved from master to main. This issue will be closed when the default branch has been changed.

For help and guidance with updating the default branch of your local or forked copy of this repo, please see Renaming the default branch.

Search for files that may potentially reference master.

^{ID: 91e77a361e4e}

Create an add_neighbors_constraint(x) to ensure that selected planning units have at least x neighbors that are also selected.

This constraint is discussed in section 2.3.2 in Beyer et al. 2015

Hi all,

I've been working on the back-end for prioritizr (now in this repo) and I feel like it's now at the stage where it would be good to get some feed back on it.

It doesn't pass CRAN checks and haven't written a vignette yet, but all the examples run and the unit tests pass.

The main help pages describe how to initialize a problem, how to add an objective to it, how to specify what type of decision is made for each planning unit (eg. binary), how to add constraints to the problem (eg. blm stuff), and how to specify how the problem should be solved.

I've used the proto R package for creating classes (similar to what ggplot2 does) so I'm hoping it will be fairly easy for people to contribute more functionality to the package (eg. constraints). The source code for the add_*_decision functions contain some simple examples .

I haven't added the functionality to support data.frame inputs yet (as discussed in prioritizr/prioritizr#4), but it shouldn't be too tricky to implement it in the future.

The current version of this package does not behave as expected. Adding constraints to an object will result in the same constraints being added to copies of the object.

Consider the following code:

p <- problem(sim_pu_polygons, sim_features)
p1 <- p %>% add_locked_in_constraint('locked_in')

At the moment, both p and p1 will have the locked in constraints added to them. This is clearly undesirable.

I'm not sure about what the best solution is.

One option is to implement a copy function, something like:

p <- problem(sim_pu_polygons, sim_features)
p1 <- copy(p) %>% add_locked_in_constraint('locked_in')

Or, instead of implementing all the classes as proto classes, use S3 or S4 classes for classes that don't need dynamic methods (ie. methods that can be defined at run-time, eg. the Parameter, ConservationProblem, etc classes), but keep the the proto classes for classes that need dynamic methods (eg. Target, Constraint, Objective) so that it is easy to add extra functionality to the package.

Any other ideas?