Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reimplementSpatialImplicit measures with Graph #228

Open
knaaptime opened this issue Jul 13, 2024 · 7 comments
Open

reimplementSpatialImplicit measures with Graph #228

knaaptime opened this issue Jul 13, 2024 · 7 comments

Comments

@knaaptime
Copy link
Member

this will be a major improvement but a major change. Currently SpatialImplicit indices can accept either a W or a pandana.Network (which have different arguments). It's very easy to make a pandana-backed Graph, so these will now only accept Graphs. The first step is wrapping the network-->graph logic into a little utility function. That could live in lib, like the xarray builder, but also might make sense to move more of the network stuff into spopt. Any thoughts @jGaboardi @martinfleis

@jGaboardi
Copy link
Member

I really need to decide what to do with spaghetti... It has been languishing for years now12 , but I haven't had the time or mental space to figure out what to do with it. Ideally, all network-type stuff would happen in 1 package, but I'm not sure how feasible that would be without a major overhaul to several packages....


Footnotes

  1. https://github.com/pysal/spaghetti/discussions/195

  2. https://github.com/pysal/spaghetti/discussions/403

@jGaboardi
Copy link
Member

re: moving stuff to spopt -- I don't think that's the right place.

@martinfleis
Copy link
Member

I would keep it among other builders in lib. I would consume it in momepy and I think that having all builders on the Graph would greatly improve their visibility.

If you want all network stuff in one package, keep in mind we also have access.

@knaaptime
Copy link
Member Author

agree a weights builder would make sense in lib. My thought was it would be useful to have some other network utilities like these somewhere in the pysal stack (especially for tests and such if a builder will live in lib). And anything backed by pandana feels fundamentally like routing; despite its description (regionalization, optimization, routing), spopt doesn't have any routing (I think?). (though now that I'm looking closer, I see 'routing' has been replaced by 'transportation-oriented solutions' :P)

@martinfleis
Copy link
Member

We also have (some) analogous functions interfacing networkx in momepy.

@knaaptime
Copy link
Member Author

i need to play with momepy again... those are cool!

i'd be happy to send those utils to momepy if that's best, though they don't feel particular morphometric. I hate to propose a new package, but would it make sense to think about a successor to spaghetti that consolidates some of this stuff (and maybe provides a path forward for you to pick and choose what you want to keep from before james?). Not sure that's an ideal path, just a thought

@martinfleis
Copy link
Member

i'd be happy to send those utils to momepy if that's best

I am not sure about that, just wanted to flag that the pandana stuff is not the only one to consider.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants