network ring bug

[dfolch]

In the case of a ring road with no intersections, the Network builder fails. The traceback is not informative to the user. This is a rare case, so is a low priority.

[dfolch]

Here is the troublemaker shapefile. unconnected_ring.zip

[chiragvartak]

The above mentioned shapefile is not the only one that causes problems. I managed to reproduce the error in at least the files Polygon.shp and 10740.shp. (Figure below). There might be more.
I found another recurring error: 'Point' object has no attribute 'vertices', when I tried to create a Network with the shapefiles: baltim.shp, burkitt.shp, crimes.shp, schools,shp, juvenile.shp. Again, there might be more. (Should I create a new issue regarding this?)
Also, I feel it would be great to have a method that would give us a list-of-all-files-with-a-specified-extension, given a list-of-names-of-folders in pysal/examples. Something like:
pysal.examples.get_files(L=['10740', 'geodanet'], ext='shp')
which would then return:
['10740.shp', 'crimes.shp', 'schools.shp', 'streets.shp']
Thus, doing pysal.examples.get_files(L=pysal.examples.available(), ext='shp') would give us all the shapefiles and thus testing a function on all of them could be easily done!
(So, create a new issue regarding this too?)
Thoughts, anyone?

[sjsrey]

I think the idea of getting a listing of files by type is an interesting one - maybe creating a separate issue from the network thread here would be a good way to start. We could then flesh out the ideas more fully under that issue.

[sjsrey]

@chiragvartak the extraction of the network works on a polyline shape file, while a points shape file is then used to snap the points onto the network.

We probably should be more explicit in the argument types as currently the signature is vague on the shapefile type.

[chiragvartak]

The docstring of extractgraph says:

Using the existing network representation, create a graph based representation, by removing all nodes with neighbor incidence of two.

What is the reason behind doing this? Why aren't we representing the shapefile as a graph as it is?

[ljwolf]

When using a polyline shapefile as a network, sometimes you can remove some nodes without changing the resulting topology. I think the original implementor, @jlaura, saw it'd be helpful to keep both the raw polyline set read in from the file, as well as a simplified representation with the same topology.

Also, just to be clear, the errors you're noticing in constructing a network from something like baltim.shp is because baltim.shp does not describe a network. Neither does Polygon.shp, but there's probably some more graceful way we could bail out in these cases.

[jlaura]

@ljwolf is correct that this is going to be a question of storing not just a single representation (potentially).

For example, assume that we read in the raw polyline shapefile and convert to a networkx style graph. This is no longer a road network representation, but a reduced topological representation. That might be great for things like djikstras due to performance (assuming that the true distance is attributed to the topological edge). What about doing point snapping and edge counts? The original shapefile is one potential representation, as is the topological representation, as are a myriad of other representations (equal edge segmentation / aggregation over the original shapefile to attempt to standardize edge lengths for example).

In relation to #746, the issue is going to be how to manage different representations of the network and maybe guess at the appropriate realization to use for a given metric.

[chiragvartak]

Okay, I get it. But now it presents me with another problem. Presently one thing that is being done to simplify the topology is to remove the bridge nodes i.e. nodes with 2 neighbors. But a ring has all nodes with 2 neighbors! Hence, all nodes are removed. The code is doing exactly what is was designed to do but perhaps not what it was intended to do.
Any suggestions on how to handle this?
Also, I've fixed the code to make it more robust, like handling cases where a 'shape' has multiple parts, etc. Create a pull request w.r.t that?

[jlaura]

What about pre-processing the full topology to identify cycles. Then apply
the remove the incidence two logic to the non-cycles.

Question: Should a ring be reduced to a point given the current logic?

On Tue, Mar 1, 2016 at 10:19 AM, chiragvartak notifications@github.com
wrote:

Okay, I get it. But now it presents me with another problem. Presently one
thing that is being done to simplify the topology is to remove the bridge
nodes i.e. nodes with 2 neighbors. But a ring has all nodes with 2
neighbors! Hence, all nodes are removed. The code is doing exactly what is
was designed to do but perhaps not what it was intended to do.

Any suggestions on how to handle this?

Also, I've fixed the code to make it more robust, like handling cases
where a 'shape' has multiple parts, etc. Create a pull request w.r.t that?

—
Reply to this email directly or view it on GitHub
#655 (comment).

[chiragvartak]

@jlaura With the current logic, the cycle is supposed to be reduced to nothing. But it doesn't happen.
So, I fixed it and the modified code applies the following logic: A cycle is ignored (actually, it is processed and reduced to nothing) and the other non-cycles are processed properly. I guess this should be alright?

[dfolch]

I don't think an isolated ring should be removed entirely. Similarly, I don't think an isolated line should be removed either. We might consider a point (@jlaura) or a triangle. A triangle has the least number of vertices of something looking like a ring. In the north of the Waverly data (Waverly.zip) is a self intersecting road. I think the loop part of this gets reduced to a point under the current code in master.

[jlaura]

@dfolch Agreed that removal is not appropriate. The question is, what is appropriate. I could see an argument for a point, line, or triangle. Do we have any references how this is handled in the literature?

[jGaboardi]

@dfolch @ljwolf @jlaura @chiragvartak
Here is a gist notebook describing and demonstrating the 'loop road' issue.
Millstream Road

[jGaboardi]

Waverly.zip

[jGaboardi]

This issue is resolved with pysal/spaghetti#185. For a demonstration of the new functionality with unconnected_ring.shp see resolved-unconnected_ring.ipynb.