Getting junctions at intersections of edges despite 'End Point' Connectivity Policy

2810
4
02-13-2012 06:44 AM
Highlighted
New Contributor
Hello,

I am hitting what seems to me a bug. I have an edge class A. When I build a network from it with the connectivity set to 'end points', I get what I expect: edges that cross in their middle do not generate a junction. When I intersect A with something else to create a subset B, building the same network results in the creation of a network with unexpected junctions at the intersection of those same edges.
It so happens that when building B I am also getting the following message for 4 edges:

SourceName: streets_island, ObjectID: 41868, The edge feature is too small to participate in snapping and may not be connected to other features.

However, having further cleaned set B into a set C to remove or edit the offending edges, I am getting a network that doesn't generate any error message but still doesn't respect the connectivity policy.

Has anyone got any explanation for this behaviour?

Thanks a lot,

Guillaume
Tags (2)
Reply
0 Kudos
4 Replies
Highlighted
New Contributor
To make the problem reproducible, I have managed to interesect my data set even more to make it small and still have the problem I described.
The geodatabase attached with this message contains the edges and the built network.
If you look at the junction located at (-73.601234  45.528790), it should not be there if as I understand it the 'end point' connectivity policy means that junctions should only be created where edges meet at their ends.

Thanks,

Guillaume
Reply
0 Kudos
Highlighted
New Contributor III
To make the problem reproducible, I have managed to interesect my data set even more to make it small and still have the problem I described.
The geodatabase attached with this message contains the edges and the built network.
If you look at the junction located at (-73.601234  45.528790), it should not be there if as I understand it the 'end point' connectivity policy means that junctions should only be created where edges meet at their ends.

Thanks,

Guillaume


The problem is that your street data consists of multipart geometries.  The network dataset build algorithm handles multi part geometries by placing system junctions at the beginning and end of each part.  Elevation fields only apply to the beginning and end of the entire multipart geometry, not to the beginning and end of individual parts (which are internally given a Z elevation value of null).  The connectivity you see is correct in light of the multipart shape data in your dataset.

You can run multipart to single part GP tool to convert your shapes into single parts but this tool will not preserve your cost values (the cost of the output shape will be a duplicate of the first part in the original shape).

I hope that this clears up the behavior you are seeing.

Doug
Reply
0 Kudos
Highlighted
New Contributor
The problem is that your street data consists of multipart geometries.  The network dataset build algorithm handles multi part geometries by placing system junctions at the beginning and end of each part.  Elevation fields only apply to the beginning and end of the entire multipart geometry, not to the beginning and end of individual parts (which are internally given a Z elevation value of null).  The connectivity you see is correct in light of the multipart shape data in your dataset.

You can run multipart to single part GP tool to convert your shapes into single parts but this tool will not preserve your cost values (the cost of the output shape will be a duplicate of the first part in the original shape).

I hope that this clears up the behavior you are seeing.

Doug


Hi Doug and thanks very much for your reply.

I am new to ArcMap and was unaware of the issue of multipart geometries.
One thing which I find hard to explain though is that it was working as expected on a larger dataset. This one was derived from it by doing an intersection. Could this have transformed some single part lines into multipart ones well within the intersection polygon? And from what I read these multipart lines cannot share a common point so that would mean that they are physically separated?

I would like to dig into this a bit more but I am unable to find a tool that would allow me to inspect my features to understand what their parts are. I found some page about using the "data reviewer" extension but I don't have access to it right now. Do you know of any other way I could get a grasp on the single/multi part aspect of my features?

Thanks again for your help,

Guillaume
Reply
0 Kudos
Highlighted
New Contributor
Hi Doug and thanks very much for your reply.

I am new to ArcMap and was unaware of the issue of multipart geometries.
One thing which I find hard to explain though is that it was working as expected on a larger dataset. This one was derived from it by doing an intersection. Could this have transformed some single part lines into multipart ones well within the intersection polygon? And from what I read these multipart lines cannot share a common point so that would mean that they are physically separated?

I would like to dig into this a bit more but I am unable to find a tool that would allow me to inspect my features to understand what their parts are. I found some page about using the "data reviewer" extension but I don't have access to it right now. Do you know of any other way I could get a grasp on the single/multi part aspect of my features?

Thanks again for your help,

Guillaume


I have been trying to understand this with the tool Multi to Single (this is the only way I have found to find out if a line is a multipart or not - by examining the output of the process) and what I found is that indeed, intersecting my feature class of single lines does produce multi-lines. Doesn't make much sense to me but there must be a good reason for that.
It does explain my problem completely though. I will have to find another way of filtering my features that doesn't break things into multiple parts.

Thanks again,

Guillaume
Reply
0 Kudos