(apologies that this take so long to log to GitHub)

@ResidentMario Thanks for logging this. Hopefully this will be something I can get started on in the next several months. It will be super exciting to have this functionality included in libpysal/spaghetti. In the meantime, if you have any ideas or contributions feel free to start a PR or post more thoughts in here.

@ljwolf @sjsrey @weikang9009 @knaaptime @renanxcortes @slumnitz
In terms of network allocation methods, would having something like Line Voronoi Diagram generation make more sense in libpysal.cg or directly in spaghetti? My thought is probably in libpysal.cg. However, once I am graduated I want to also add the method for allocating populations to networks I propose in my dissertation. Whether this makes more sense in its own package or as part of spaghetti is something I would like to discuss/get other's opinions on. Any input is welcome.

@ResidentMario Thanks for logging this. Hopefully this will be something I can get started on in the next several months. It will be super exciting to have this functionality included in libpysal/spaghetti. In the meantime, if you have any ideas or contributions feel free to start a PR or post more thoughts in here.

@ljwolf @sjsrey @weikang9009 @knaaptime @renanxcortes @slumnitz
In terms of network allocation methods, would having something like Line Voronoi Diagram generation make more sense in libpysal.cg or directly in spaghetti? My thought is probably in libpysal.cg. However, once I am graduated I want to also add the method for allocating populations to networks I propose in my dissertation. Whether this makes more sense in its own package or as part of spaghetti is something I would like to discuss/get other's opinions on. Any input is welcome.

Yes, @jGaboardi, I think too that it probably makes more sense on libpysal.cg, since it already has the Voronoi polygon generation in https://github.com/pysal/libpysal/blob/master/libpysal/cg/voronoi.py

I mean... we could add voronoi_lines, for example in this script.

If it's any incentive, I wrote a hacky single-use package called streetmapper to solve the problems that came up in this project for me. Once these features land in spaghetti, I'd love to rework that code to use these algorithms instead, and write an expository blog post on the subject in the style of Eli's "Neighborhood Segregation Dynamics" blog post. 🙂

@ResidentMario streetmapper looks very interesting. Would you be able to include a rudimentary notebook demonstrating functionality?

I could upload something to the notebooks/ directory, yes.

Yeah, or even just a link to something (this is something for my own curiosity). The explanation and docstrings of streetmapper are super interesting. I would love to see a use case.

Hi @jGaboardi, you weren't the only person to ask me this question, so I figured it was worth the time to write up a short blog post explaining how the streetmapper module works and my motivation for writing it: "Bringing together building, block, street, and point data".

This post links to the polished blog post with the analysis I used this library for as well as the repo with all of the raw code I wrote. Some of the use cases of having this point-to-line-to-adjacent-polygon algorithm on hand included:

• Does street trash volume vary significantly between businesses?
• Does street trash volume vary significantly with business type?
• Is street trash volume correlated with Yelp! ratings?
• Is street trash volume correlated with Yelp! stars?

openvoronoi

We may want to explore:

• migrating this to pysal/libpysal for inclusion in cg/voronoi
• implementing higher-order Voronoi diagrams with
  • momepy
  • geonetworkx

#380

I think that this is already implemented in momepy. Or at least most of it.

import momepy
import geopandas
from shapely.geometry import box
from mapclassify import greedy
from libpysal import examples

path = examples.get_path("streets.shp")
gdf = geopandas.read_file(path)

# fill study area with tessellation
study_area = box(*gdf.total_bounds).buffer(50)

tess = momepy.Tessellation(gdf, 'ID', limit=study_area)
ax = tess.tessellation.plot(figsize=(12, 12), edgecolor='w')
gdf.plot(greedy(gdf, strategy="largest_first"), ax=ax, categorical=True, cmap='Set2')

# limit to 150 feet from network geometry
tess = momepy.Tessellation(gdf, 'ID', limit=momepy.buffered_limit(gdf, 150), segment=10)

ax = tess.tessellation.plot(figsize=(12, 12))
gdf.plot(greedy(gdf, strategy="largest_first"), ax=ax, categorical=True, cmap='Set2')

It is not properly documented, but it should do what you are looking for.

@martinfleis this is another great example for your push to standardize the network instances.

Which reminds me that on one end of the conversion pipeline should be non-graph geodataframe. Since the example above is using gdf, not graph.

@martinfleis let's revisit this in the not-to-distant future.

My proposal is to move generic voronoi algos from momepy to libpysal.cg and document it all there. Those could potentially also take a graph as an input, but we first need the standard of storing edge geometries in a graph.