easily select street segment(s) between two cross streets for editing

[KatherineHayman1]

Hello,
I am working with a massive streets database, in which each street is broken into segments at each cross street.  My work involves editing groupings of these streets at a time (for example, along "5th" from street A to street F) and while manual selection of those segments is certainly possible it is very tedious.  I have been using Select by Attributes as well as the find option. 

I was thinking a program that selected only the segments of "5th" between Street A and Street F would be fantastic, although I don't know if anything similar to this exists or if it would be relatively straightforward to write. 

Does anyone have any suggestions for automating/speeding this process?

[RichardFairhurst]

Here are some useful calculations for validating that LR Routes are simple.

Create a Long field called Parts and use the following advanced calculation to determine how many parts make up your route (I allow gaps when building routes so that I can cross minor jogs at intersections.  Branches always result in at least 3 parts to a route):

Parser: Python

Pre-Logic Script Code:
def Output(PartCount):
  return PartCount

Expression:
Output(float(!SHAPE.PARTCOUNT!))


Create a field of type Long called MMONOTONIC and use the following advanced calculation to determine the M Monotonicity of the LR Route (A value of 1 indicates measures are continuously increasing, which means the route has no branches and is simple.  Any other value indicates combinations of measures that are increasing, decreasing or unchanging, which means the LR Route has branches, full loops or other complex route configurations.  This is the value reported descriptively in the Identify Route Locations tool and you can create a domain that replicates those descriptions if you like):

Parser:  VB Script

Pre-Logic Script Code:
Dim Output As Long
Dim l As Long
Dim pCurve As ICurve
Dim pSegmentCollection As IMSegmentation3
Set pCurve = [Shape]
Set pSegmentCollection = pCurve
Output = pSegmentCollection.MMonotonicity

Expression:
Output


Once you have created routes you can get Rooute ID values and measures assigned to your intersection points by using the "Locate Features Along Routes" tool in the Linear Referencing toolbox.  Below is a sample of the fields I have in the intersection pair event table to use as joins and value transfers to subsequently derived event tables.  I use these fields for validation of the subsequent events and updating the derived events in response to changes in my routes, such as realignments, road renaming, etc.:

RID: VIA LOS VENTOS SWAP ' Route ID created by the Locate Feature Along Route tool.  In this case the Street name is VIA LOS VENTOS in the Southwest Area Plan (SWAP)
MEAS: 5023.8725 ' Measure created by the Locate Feature Along Route tool.
Distance: 0 ' Field created by the Locate Features Along Route tool.  Typically 0.
STNAMES: {LOS GATOS RD}{VIA LOS VENTOS}{VISTA DEL MAR} ' All names listed alphabetically
X_COORD: 6231383.346493 ' transferrred to subsequent events so offsets can be compared.
Y_COORD: 2315384.464358 ' transferrred to subsequent events so offsets can be compared.
X_Y_LINK: {6231383.3465}{2315384.4644} ' Useful relate value for when route name changes
WAYS_COUNT: 4 ' Number of Centerline segments that link at intersection
STNAME_WAYS: {1}{1}{2} ' number of segments associated with the STNAME field street order
POINT_ID: 26638 ' Numeric value representing the Point X/Y value
STNAME: VIA LOS VENTOS ' Primary Street Name often used as a relate
CROSS_NAME: LOS GATOS RD ' Cross Street Name often used as a relate
X_Y_ROUTE: {6231383.3465}{2315384.4644}{VIA LOS VENTOS SWAP} ' Best final join for the RID and Meas values.
PAIR_STNAMES: {VIA LOS VENTOS}{LOS GATOS RD} ' First level join field
X_Y_PAIR: {6231383.3465}{2315384.4644}{W CHURCH ST}{IOWA AVE} ' Best Final Join for the name pair value

The above X/Y point would have 6 entries in my intersection pair table so that I could relate to any combination and order of the three (3) street names that meet at the above intersection.

Typically my derived events have the following fields:


PRIMARY: VIA LOS VENTOS
CROSS: LOS GATOS RD
DIST: 100
DIR: W
FACING: E ' FACING representing the direction of travel of a driver on the road looking at the sign, not the sign itself in my data.
PAIR_STNAMES: {VIA LOS VENTOS}{LOS GATOS RD} 'First level join or relate to intersection pair table
INT_X_Y: {6231383.3465}{2315384.4644} ' FROM X_Y_LINK. Useful as a relate
INT_X: 6231383.346493 ' Intersection X value from X_COORD.  Useful for validating offset.
INT_Y: 2315384.464358 ' Intersection X value from Y_COORD.  Useful for validating offset.
X_Y_PAIR: {6231383.3465}{2315384.4644}{W CHURCH ST}{IOWA AVE} ' Best Final Join for the name pair
X_Y_ROUTE: {6231383.3465}{2315384.4644}{VIA LOS VENTOS SWAP} ' Best final join for the RID and Meas values.
INT_MEAS: 5023.8725 ' From Meas value of the intersection
OFFSET_MULT: -1 ' Multiplier for offset representing the direction of offset.
OFFSET_DIST: 100 ' Repeats or adjust absolute offset distance so that it stays on the route
ROUTE_ID: VIA LOS VENTOS SWAP
EVENT_MEAS: 4923.8725 ' Actual measure of derived event.  Equals INT_MEAS + OFFSET_MULT * OFFSET_DIST
CL_X: # ' Calculate Geometry on an event without a side offset.  Can be compared to INT_X to make sure offset went in correct direction.
CL_Y: # ' Calculate Geometry on an event without a side offset.  Can be compared to INT_Y to make sure offset went in correct direction.
SIDE_MULT: 1 ' Multiplier representing side offset direction related to FACING
SIDE_DIST: 30 ' Holds value of Side offset distance.  Recaled as SIDE_MULT * ABS(SIDE_DIST)
INT_ANGLE: # ' Calced from LOC_ANGLE (the event angle) when event is at Intersection Measure.  Tells you angle of your route at the intersection to help predict offset.
CALC_ANGLE: # ' Calced from LOC_ANGLE (the event angle) when event is at Offset Measure. Tells you angle at final event location to help predict side offset.
ROTATION: # ' Calced to give final rotation of FACING relative to the CALC_ANGLE value with 90 degree adjustments.  I have a calcuation for doing this.
EVENT_X: # ' Use Calculate Geometry to get final event location X coordinate.  Can be compared to CL_X to make sure side offset went in correct direction.
EVENT_Y: # ' Use Calculate Geometry to get final event location Y coordinate.  Can be compared to CL_Y to make sure side offset went in correct direction.

I hope this helps.

[RichardFairhurst]

Just another note:

Usually Engineers build Routes from the Lower Left to emulate stationing, so that Route measure typically increase from West to East and from South to North.  Addressing often is oriented from the Upper Left.  For routes that go diagonally oposite of the primary chosen orientation you may have to flag those Centerline and build a route in the other direction.  For example, if you chose Lower Left as the primary, then a diagonal route that runs from Northwest to Southeast you should flag that route for building from the Upper Left.  If not it will often build in a wierd way from the middle of the Route to each end.  My Centerlines have a field called BUILD_DIR to help me select these routes for a special build.

[TomMagdaleno]

I'm still learning about all this, but my current understanding is that if I have a street segment named "Easy St" and it meets  "Main St" at a T and has a court half way up the steet on the side called "Dwight Ct" then I would need routes for

{Easy St} {Main St} -
{Easy St} {Easy St} -the broken line where it meets Dwight Ct
{Easy St} {Dwight Ct}

Would I also need to stack a line or add a column and have these street names transposed so that I could do the opposite direction?

[RichardFairhurst]

I'm still learning about all this, but my current understanding is that if I have a street segment named "Easy St" and it meets  "Main St" at a T and has a court half way up the steet on the side called "Dwight Ct" then I would need routes for

{Easy St} {Main St} -
{Easy St} {Easy St} -the broken line where it meets Dwight Ct
{Easy St} {Dwight Ct}

Would I also need to stack a line or add a column and have these street names transposed so that I could do the opposite direction?

Actually, that is not correct.  My original Centerline are not routes and have no measure data associated with them.  My routes are derived from them by running the Create Routes tool in the Linear Referencing toolset on a ROUTE_NAME field that holds a value that may be shared by many related Centerlines.  All Centerlines named Easy St that are logically related will have the same ROUTE_NAME value, so that they will build into one connected route.  In my case it would be something like "EASY ST SWAP", where SWAP represents an area plan for distinguishing an Easy St in that portion of my County from another Easy St in another area of my County.  I choose the predominant area plan assocatiated with a street and do not change the area plan assigned to a set of the Centerlines that should connect, even if they technically cross an area plan boundary, since continuity of logically related Centerlines in a route is more important than any other consideration.

You would run the Create Route tool in the Linear Reference toolset to create a route for Easy St from one end to the other, a route for Main St from one end to the other, and a route for Dwight Ct from one end to the other, regardless of how many streets they intersect or what streets they intersect.  The routes hold the measure for any position along the route and have no awareness of cross streets at all.  You may have to create a special naming convention for the RouteID where multiple widely separated streets have common names like Main St, so that you can distinguish a Main St in one area from another and not have them connected across vast distances (which would be meaningless if they will never connect or directly interact).  The Route only needs to be built in one direction to aggregate a standard set of two-way centerlines for any given street that does not branch.  No two Routes should have the same RouteID.  That ID must be unique for each route and the route should connect as many Centerlines as you could reasonably travel along (which may include minor gaps if there are offsets across an intersecting street).

The point class of intersections is where you get your first set of events that give you your reference points, not the routes.  I first build a standard intersection point class that holds all of the intersecting street names associated with a given intersection point and get the X/Y data for the intersection point.  It does not matter if the intersections fall at the beginning of the route, the end of the route, or somewhere in between the two ends of the route.

Now that you have those two feature classes, you run the Locate Features Along Route tool so that your intersection points get the RouteID and Measure values of the Routes they fall along.  You should use the setting that lets the point get data from all routes that touch the point.  The resulting point event table now holds the fixed X/Y position of the intersection from the original point class input to the tool and the relative route and measure data of an LR event that also represents that same position as a distance along the route.

When this completes you run a second model process to generate all of the possible cross street combinations from the Locate Features Along Route result into a new table.  It is created by a series of selections, calculations and append operations (two street names intersecting will typically generate two records for each street combination (which is typically in the standard result of the Locate Features Along Route output), three street names will generate 6 records (4 records need to be derived and appended), and 4 street names will generate 12 records (10 records need to be derived and appended)).  This is the event table that gives you all of the intersection reference data you need for creating subsequent events tables that will include offsets.

[GideonDalrymple]

Greetings all.

I apologize for posting in this thread. No one has replies since I posted my own thread.

I am in desperate need of some help. I work at an electricity company am I am trying to set up an electric distribution geometric network. I created it successfully and set up what I think are the right connectivity rules.

There is a situation where two different circuits occasionally run on the same pole (Point A in the pic) or one line terminates perpendicular to another line from a different circuit at the same pole.

Can someone please assist me in getting the circuits in green and purple to flow freely to their ends even if they seem to intersect at point A?

I have attached the sample geodatabase that i'm working with.

My email address is dalrympleg@gmail.com

Regards
Gideon.

[RichardFairhurst]

Greetings all.

I apologize for posting in this thread. No one has replies since I posted my own thread.

I am in desperate need of some help. I work at an electricity company am I am trying to set up an electric distribution geometric network. I created it successfully and set up what I think are the right connectivity rules.

There is a situation where two different circuits occasionally run on the same pole (Point A in the pic) or one line terminates perpendicular to another line from a different circuit at the same pole.

Can someone please assist me in getting the circuits in green and purple to flow freely to their ends even if they seem to intersect at point A?

I have attached the sample geodatabase that i'm working with.

My email address is dalrympleg@gmail.com

Regards
Gideon.

Gideon:

I don't use geometric networks and the original topic of this thread (and what it has evolved into) do not require a geometric network to work.  Geometric networks have unique properties that require insights from those that use them to help solve your problem.  So I am afraid I cannot help you.  What forums have you posted this problem under before?  You need to reach the audience of Utility specialists to help give you an answer.

[GideonDalrymple]

I Understand. I have posted there but to no avail. "sigh"

[TomMagdaleno]

Richard,
  Thanks for your help so far.  I have most of my data formatted but I am still confused on how I will identify the routes from a listing of Primary St, Cross Street and Direction. 

I had a few problems:
1.  How do I create a route that is not strictly increasing? 
If I create two routes on the same line that are increasing in opposite directions then it will work.   
My idea is to have at least two names for each segment because each street could be described as being south or north of its cross street.  See attached image.  Arneill will have two different route IDs.  This way I can simply concantonate the primary st, direction and cross street from the table I receive from the police dept and it will find my route.  I plug in the distance and I have my collision point.
2.  This creates a lot of manual work.  I will have to Create Route on each street manually to see what direction they go and make a route on them.  Then I will have to create the names.

[RichardFairhurst]

Richard,
  Thanks for your help so far.  I have most of my data formatted but I am still confused on how I will identify the routes from a listing of Primary St, Cross Street and Direction. 

I had a few problems:
1.  How do I create a route that is not strictly increasing? 
If I create two routes on the same line that are increasing in opposite directions then it will work.   
My idea is to have at least two names for each segment because each street could be described as being south or north of its cross street.  See attached image.  Arneill will have two different route IDs.  This way I can simply concantonate the primary st, direction and cross street from the table I receive from the police dept and it will find my route.  I plug in the distance and I have my collision point.
2.  This creates a lot of manual work.  I will have to Create Route on each street manually to see what direction they go and make a route on them.  Then I will have to create the names.

I looked at your graphic and am not sure I know what the call out lable refers to.  If it is a subsection of the line between the north and south intersection, that is not how I create my routes.  My routes would not break at any intersection and would have measures that normally start at the north or west and continue to the south or east.

So I would have 8 Routes total on the map that you created.  One for Ponderosa Dr, one for Pickwick Dr, one for Arnell Rd, one for Fulton St, one for Pheasant Hill Rd, one each for the unlabeled Cul-de-sacs, and one for Hartnell St at the 3 way intersection with Fulton St and Pickwick Dr.

You always want strictly increasing routes, period.  That is the definition of a simple route and that is always your goal.  You also do not need routes going both directions to assign positions that go in opposite directions.  Measure direction along an LR Route is just a function of adding or subtracting measure values relative to a known fixed measure at a reference intersection.

For example, if the reference measure on Ponderosa Dr at its intersection with Arnell Rd is 1,000 feet (meaning that it is offset 1,000 feet from the beginning of the line at the west end of Ponderosa Dr), then to go 100 feet west of that intersection you subtract 100 feet (1,000 - 100 = 900) and to go 100 east of that intersection you add 100 feet to the intersection measure (1,000 + 100 = 1,100).  All of those measures would have a Route ID of Ponderosa Dr and each of those positions can be on the same Route.

If your concern is with direction of travel of a vehicle, that is a separate field and is represented by a side offset, not a measure offset.  Vehicles travelling both eastbound and westbound can be described as being on Ponderosa Dr 100 feet west of Arnell Rd, but the eastbound vehicle is on the right or south side of the line and the westbound vehicle is on the left or north side of the line if the line's measures increase from west to east.  The side offset is again just a positive or negative number relative to the one line.  You do not need lines going in opposite directions to deal with direction of travel.

Your approach won't work because at some point you will get an offset distance that crosses an intersection and your Route will not be able to accomodate that position.

[TomMagdaleno]

I did ESRI's intro to Linear Referencing course and it was working with trails data with about 14 trails.  It wasn't much help, making an event table consisted of typing in the trail number for the route you want to place a point on.  I want to be able to do some kind of calculation to create my route name.  So I figure I concantonate the primary, direction and secondary street and that will be my route name.

I guess my concern is how do I reliably and repeatibly find a particular intersection.  The labeled section of centerline refers to the two different discriptions I could have from the police department that would be describing the same piece of road. 
So my concern is with new event tables I receive on a quarterly basis.  How will I know and match up the police description of the street segment (i.e. Primary St = Arneill, Secondary St = Ponderosa, distance 100 ft, direction South) matching up with what I have. 
  I like the idea of having single segments, or even single segments between intersections and for example subtracting from the total if it is south and adding if it is North, but I would think I would need to program something to know the total measure of each segment and know a particular description of it means it should subtract from the total and not add.