refactor gis cell init to accept kwargs#320
Conversation
|
Thanks for the PR! I fixed another CI issue in 9567bdf, so CI should display the state of the example models again. It seems to fix the main issue, however, this does expose a new issue: Is that also related to this PR? Further, can we do anything about this change being breaking to user models (see mesa/mesa-geo#299 (comment))? |
|
Yes this warning was introduced in mesa/mesa-geo#299. Since cells don't move, I intend to make their Could you point me to the failed github action / tests? |
|
This is interesting. It's probably because there's a deprecation warning from mesa-geo on I can remove the deprecation warning, since it conflicts with base agent class in Mesa. In the future for Mesa-Geo it might be better not to treat cells as agents (that is, not part of |
@quaquel can/should we remove this? |
Not for 3.5 because of semver, but yes in 4 were it will be replaced with the Locatable protocol. No idea how that will work downstream for either agent or cell. We might just have a generic LocatableAgent class. |
7622fa5 to
0e3467f
Compare
This PR updates constructors of raster cell subclasses, from for example
to
This is mainly due to changes to raster cell constructor from mesa/mesa-geo#299, where we deprecated
cell.indicestocell.rowcol, and addedcell.xy. In addition, when we initialize cells when creating a raster layer, this is how cell constructor is called now (link to code):where
cell_clsis the user-defined subclass of raster cell, such as theLakeCellabove.By putting all parameters but
modelinto**kwargs, this PR demonstrates how to subclass mesa-geo's raster cell class in case there are further changes to constructor API in the future.