You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Based on the discussions in projectmesa/mesa#513, we should use established libraries for data manipulation and querying and not try to ship own versions.
My idea would be to base the GeoSpace on a GeoPandas GeoDataFrame and internally just use the GeoPandas functions or PySAL.
@ljwolf can you confirm that if the data is stored in a GeoDataFrame we can just use PySAL functions for certain type of operations? Like in the link you posted
Would be sufficient to benefit from the speed ups? (Of course maybe with some output modification)
I agree that neighbordhood look-ups is something that will be very important for ABMs and it makes sense to go fort the fastest implementation. Do you know any other methods we should import form PySAL for significant performance (or other) improvements?
The text was updated successfully, but these errors were encountered:
I've taken a look at how you've used them, and this is exactly how I would've suggested!
There are a few other classes that we provide that do this kind of stuff, namely the KNN and the DistanceBand weights. I think in your case, both could be helpful, and it may make sense to allow users to apply any weighting function to model spatial proximity?
Not sure what's common in ABM, but we get users who use all of those weights (and some mixtures thereof) to express & encode spatial relationships in econometric models.
Not sure what's common in ABM, but we get users who use all of those weights (and some mixtures thereof) to express & encode spatial relationships in econometric models.
Problem is: I am not sure either. That's why I am leaning towards not implementing (too many) further functions. Neighbors should be pretty common, kNN probably also, but I am already wondering if it really makes sense to precompute kNN for all agents or maybe k is different for every agent? Or maybe one only wants to have kNN for few agents and precalculation would be overkill?
What I think here is that its maybe better to leave precalculation to users and just have a convenient access point to the geospace, so one could use something like pysal.weights.DistanceBand.from_array(GeoSpace.to_array()).
And populate GeoSpace only with a function to calculate DistanceBand (etc.) for a single agent, but mention the idea of precalculation in the docstring. What do you think?
Based on the discussions in projectmesa/mesa#513, we should use established libraries for data manipulation and querying and not try to ship own versions.
My idea would be to base the GeoSpace on a GeoPandas GeoDataFrame and internally just use the GeoPandas functions or PySAL.
@ljwolf can you confirm that if the data is stored in a GeoDataFrame we can just use PySAL functions for certain type of operations? Like in the link you posted
Would be sufficient to benefit from the speed ups? (Of course maybe with some output modification)
I agree that neighbordhood look-ups is something that will be very important for ABMs and it makes sense to go fort the fastest implementation. Do you know any other methods we should import form PySAL for significant performance (or other) improvements?
The text was updated successfully, but these errors were encountered: