nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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?

Find more posts tagged with

Accepted answers

All comments

KatherineHayman1

Nothing at all?

JeffreyBarrette

I wish I had something for you. You may want to try the editing forum.

http://forums.arcgis.com/forums/116-Editing

Jeff

RichardFairhurst

This is not an easy interface to create and it would have to be done all in custom code. There are a lot of possible points of failure for user input that have to be validated before a result can be returned. For example, you must validate that the street name is correct, and that both cross streets exist along that street before you can get the line segment that represents that description. You also may have to resolve ambiguous situations where two or more identically named intersections exist and one must be chosen.

Beyond that I would say that at a minimum you would need a dissolved network of streets using your street name and an intersection point layer that could be searched for cross-streets (See this thread for one possible method of doing that). If you used ArcObjects, the minimum interfaces needed would include the ICurve.QueryPointAndDistance Method to find the percent or distance along a selected dissolved street line defining the location where each intersection fell along the dissolved street and the ICurve.GetSubcurve Method to get the portion of the dissolved street that fell between the two points. Then you would need to do a small buffer of that subcurve with the ITopologicalOperator.Buffer Method and finally do a selection of your original lines that were completely contained by that buffer and had the correct street name. I don't think Python could handle the interface or the operations, so you would have to look at what it takes to create add-ins using Visual Studio 2008 (Express or higher), which is not simple going forward at 10.1.

The interface could not keep current if your edit session actually changed street names or the network connectivity of your original line network and such changes would require periodic rebuilds of the dissolved lines and intersections to allow you to get accurate results. But periodic rebuilds are required by Network Analyst and Geometric Networks as well.

The above assumes that the network has no or very few roads that branch. Streets that branch (i.e., three or more lines with the same street name meet at the same point) will generally give bad results with the above interface. So if you typicaly have parallel segments of road representing one-way travel on a single street going around a divider that meet at the ends of the divider, you will have many problems and many ambigous intersection choices that complicate this idea to the point that I do not recommend attempting it.

While I have not designed an interface that specifically does what you want, I did create one for doing linear referencing events that was more involved than what you need, since it had to handle offsets from an intersection (i.e., find the portion of A St that is between 235 feet East of 1st St and 545 feet West of 5th St). Let me know if you want to pursue this idea now that I have given you an idea of what it involves.

TomMagdaleno

While I have not designed an interface that specifically does what you want, I did create one for doing linear referencing events that was more involved than what you need, since it had to handle offsets from an intersection (i.e., find the portion of A St that is between 235 feet East of 1st St and 545 feet West of 5th St). Let me know if you want to pursue this idea now that I have given you an idea of what it involves.

Richard, thanks for the post.
I am looking for some code that will do offsets from an intersection and create a point along a line. For example a traffic collision on Easy St 100 ft North of the intersection with Daily Dr. I have seperate columns for Primary street, cross street, distance and direction. Do you have code I could tweak to make it work?

RichardFairhurst

Richard, thanks for the post.
I am looking for some code that will do offsets from an intersection and create a point along a line. For example a traffic collision on Easy St 100 ft North of the intersection with Daily Dr. I have seperate columns for Primary street, cross street, distance and direction. Do you have code I could tweak to make it work?

Your basic configuration of the data is what I normally have, but I also include an intersection distiguisher field to help me know what intersection to choose when multiple locations have the same street name pair [I prefer this to making the cross-street something like Daily Dr. (S)].

Actually, I don't use the interface any more and even when I did, it would just be an extension of the data set I use today. I have a series of scripts that builds LR Routes, Intersection points and an event table of every intersection name pair with Route ID and Measure. I have a series of join fields in the intersection pair table that allow me to transfer data about the intersection to other event tables so I can reference either a relative or absolute position for the intersection (that way I can use the table as either X/Y events or LR Route Events).

I find the intersection pair table helps me to QC my field data, since misspelling of street names is very common and the most time consuming aspect of geocoding. I always preserve the original misspellings and add fields to hold my corrected spellings or alternative intersection descriptions when the intersection described is not available and I translate it to another intersection reference.

In my dervative event tables I add matching join fields, starting with the primary and cross street pair in the format of "{EASY ST}{DAILY DR}", The intersetion pair table tells me if this is a unique name pair or if multiple intersections have this name pair (in which case it has additional fields to identify if the particulal record is either the most E/W, N/S or 1/2/3... when more than two identically named intersections exist).

For the Offset, I add a field to hold a multiplier of 1 or -1 to trranslate the compass direction into a compatible LR direction of offset. Typically E and S use a multiplier of 1 and N and W use a multiplier of -1 based on the way I constructed the routes. To get the offset measure, I add the base intersection measure I got from my intersection pair table to the distance of offset from the field data multiplied by the offset multiplier.

I have found this set up to be very flexible and it work most efficently when I am processing 1,000 records or more. I have also used this method to position signage, which additionally must account for the sign facing with a separate side offset and rotation.

If I were to build an interface based on LR methods, it would still use these underlying feature classes and tables. What sort of LR network data do you have at this point and how clean is it topologically for your intersections?

You may want to look at Crossroads or other commercially available software for collision data conversion if you are using State supplied data, since it aids in the conversion of the State data and has the ability to project collisions on a projection beyond the actual centerline ends (something LR data does not do).

TomMagdaleno

My Topology is good, I have cleaned off alleys and unnamed streets. I haven't created much in Linear Referencing yet.
I have a point feature class with my intersections in the format "{EASY ST}{DAILY DR}",

RichardFairhurst

My Topology is good, I have cleaned off alleys and unnamed streets. I haven't created much in Linear Referencing yet.
I have a point feature class with my intersections in the format "{EASY ST}{DAILY DR}",

Since you have not created any Linear Referencing routes, you can build a script to generate them in ModelBuilder. I recommend a script if you have a large number of lines to agregate (over 20,000), since I found I had to process blocks of Centerlines in groups about that size and append them together to get decent performance out of the Create Routes Tool. I have a separate ROUTE_NAME field in my Centerline layer which becomes the Route ID in the Create Route Tool. You can make the route ID any Unique value (numeric or string) as long as it agregates the lines that you want joined together.

You should also include in the Model the environmental settings for M Resolution and you Feature Class extent if you need to append multiple outputs together like I do. Letting the tool generate custom extents or M resolutions makes repeatability in future runs more difficult for tracking route changes. A sample of the environmental settings I use in my exported Python script are as follows:

# Set the Geoprocessing environment...
#gp.XYTolerance = "0.003280833333333 Feet"
#gp.XYResolution = "0.000328083333333 Feet"
#gp.XYDomain = "-118608900 -91259500 2954993346592.94 2955020695992.94"
#gp.outputCoordinateSystem = "PROJCS['NAD_1983_StatePlane_California_VI_FIPS_0406_Feet',GEOGCS['GCS_North_American_1983',DATUM['D_North_American_1983',SPHEROID['GRS_1980',6378137.0,298.257222101]],PRIMEM['Greenwich',0.0],UNIT['Degree',0.0174532925199433]],PROJECTION['Lambert_Conformal_Conic'],PARAMETER['False_Easting',6561666.666666666],PARAMETER['False_Northing',1640416.666666667],PARAMETER['Central_Meridian',-116.25],PARAMETER['Standard_Parallel_1',32.78333333333333],PARAMETER['Standard_Parallel_2',33.88333333333333],PARAMETER['Latitude_Of_Origin',32.16666666666666],UNIT['Foot_US',0.3048006096012192]]"
#gp.extent = "6129957.88366199 2098700.9515318 7097398.14694032 2341052.42516121"
gp.MTolerance = "0.001"
gp.MResolution = "0.0001"
#gp.MDomain = "-100000 900719825474.099"

In my model I first create a layer on my Centerlines and then do a Select by Attribute to subselect a set of Centerlines to aggregate into routes. Since my County covers many areas I have assigned an area plan field to cluster roads in an area, that way I don't append Main St at one end of my County with a completely unrelated Main St on the other end. My selections use these area plans for building my routes.

After you have built your first set of routes, you can look for anomolies like three-way branches, which can mess up your measures. I assign new Route_Names to break minor branches from the main route branch. (I have special fields for handling roads that separate into parallel one-way segments and then remerge into two-way segments so I can build separate unbroken eastbound/westbound or northbound/southbound routes).

There are special calculations for getting the monotonicity (continuity of measures) value and the parts that made up the route that help to simplify the routes. Simple routes are easier to use than complex routes.

Anyway, I am out of time but will post the calculations I use in the model for route analysis. I add the fields and calculations in the model structure as well (another reason to create a model).

I hope this helps.

RichardFairhurst

I just thought I would upload an example of what can be achieved with the Linear Referencing methods I am using. Attached is a sample of some of the 44,000 Traffic Control Device points I have geocoded. Every sign on the map was placed by translating the cross street references of the field crews to one of my intersection route and measure values and then adding the specified offset in the direction recorded in the field. The addition of a side offset and rotation based on the sign facing together with the appropriate symbology for the sign helps present the information understandably. Each point can be clicked for more information, such as installation date, inspection date and repair requests. Also each sign has a hyperlink to Google so the sign can be checked in street view.

Traffic_Control_Example.jpg

TomMagdaleno

That is very impressive Richard. I'll take a look at it and see if I can make it work for me too.

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.

TRIAL.gdb.zip

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.

LinearReferencing2.jpg

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.

RichardFairhurst

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.

Where you are going opposite of my approach is that you are trying to make the cross-streets tie to roadways segments or routes and not to intersections or points and therefore are multiplying routes. I tie my cross-street names to intersections or points and not to road segments or routes and therefore multiply my points.

My approach allows me to use any intersection of a road as a reference relative to any other point along that road, no matter how many intersections the road has, which is the real world way things work. If I tell you to go 3,000 feet south of ARNELL RD_PONDEROSA DR, I could just as easily say 2,000 feet south of ARNELL RD_PICKWICK DR if those two intersections are 1,000 feet apart. Police will use either to mean the same thing, so your model needs to allow for either description.

Therefore I have at the same point for any two cross-streets two points. The intersection of ARNELL RD_PONDEROSA DR_ has a measure relative to ARNELL RD, while the intersection of PONDEROSA DR_ARNELL RD has a measure relative to PONDEROSA DR at the exact same point. These two points in the exact same place tie me to two different routes that cross in the same place. I then use the same principal of combining the street names at the intersection that you want to use for your Routes and can join to the intersections for calculations the same way that you want to do it with Routes.

So just switch your thinking away from the Route and apply it to the intersection. After all we use the expression "reference points" and "points of reference", not "reference segments" and "segments of reference".

My model has been applied to over 70,000 different event points and line segments, and I may have only typed in 12 measure in all that time apart from a calculation. I have also found that I have only had to inspect and fix less than 5% of everything I create to be certain it was created the correct way. Most of my features are created without me looking at them and check out when I do look at them or when other look at them (I have not personally looked at everyone of the 44,000 signs I have created, but when I do I can activate my hyperlink to streetview and see the sign within 5 feet of the position I calculated most of the time).

Offset direction (north/south or east/west) are just handled by multiplying the offset by 1 or -1. If you built your Route from the upper-left you can predict that north and west are a multiplier of -1 about 90% of time and south or east are a multiplyier of 1 about 90% of the time if your roads are at all cose to being built on a grid. You can use the normal angle of the intersection point (generated as an option of an LR Event point layer) to find anomolies based on the intersection angle. An SQL expression can test for anomolous angles relative to your normal expectation. Typically on diagonal roads where the user may say north/south but GIS says east/west or loop roads where I have two intersections of the same name pair and I have to figure out which end of the road is meant.

TomMagdaleno

Ahh, I see the light! Forget about the routes, and just use the intersection points. That makes sense. What if the intersection is at a 45 degree angle or I have curvealinear streets? The offset may be NW. Will the offset know to follow the segment? I want the point in the middle of the road, side doesn't matter. I'll start looking into this tomorrow. Thanks again!

RichardFairhurst

Ahh, I see the light! Forget about the routes, and just use the intersection points. That makes sense. What if the intersection is at a 45 degree angle or I have curvealinear streets? The offset may be NW. Will the offset know to follow the segment? I want the point in the middle of the road, side doesn't matter. I'll start looking into this tomorrow. Thanks again!

Streets at 45 degree angles and curvilinear streets (at least S curves with an intersection in the middle of the S and loops that intersect the same street twice) are problematic to interpret no matter what. People in the field will make their best guess on 45 degree streets and usually pick something opposite of a nearby east/west or north/south street, which the model cannot "see". Or else they do not pay attention to the fact that there are two street intersections with the same name. Of you don't know if they are describing the S relative to its overall direction or its local direction at the intersection. Whether you have a Thomas Bros or a GIS model, those descriptions remain ambiguous without more information.

If your orientation is built from the upper left than NW (-1) and SE (1) are not a problem. For NE and SW you have ambiguity that may require looking at the overall trend of the route to make your best guess. The angle of the intersection can give you a clue, since it rarely is exactly at 45 degrees.

The offset always follows the line as long as it is within the bounds of the line's measures. If it is really ambigous sometime I just try a multiplier and if it throws an error by being off the line, try the other direction. If a measure is too low or too high to fall in the Route's measures, you can generate an Error field when you create the Event layer that tells you there is a problem. When nothing seems to work, I just temporarily enter the known intersection measure from my intersection table so I can use the record to zoom to the intersection and then look the road over before applying the offset multiplier. I also have a field for making adjustment to the offset distance so that I keep the event on the line (say it overshoots by 5 feet, I will shorten it in the modified offset field).

I also calculate the From and To measures of the Route so I can join to it and see that a measure value is too high. Too low is usually negative, so it is easy to figure out. If it is just -20 feet or so then I may just adjust the offset by 20 (very typical in cul-de-sac bulbs).

Anyway, now you are getting the idea.

TomMagdaleno

I also calculate the From and To measures of the Route so I can join to it and see that a measure value is too high. Too low is usually negative, so it is easy to figure out. If it is just -20 feet or so then I may just adjust the offset by 20 (very typical in cul-de-sac bulbs).

Richard,
How do you calculate the values of from and to? It seems like the LR route information is embedded in the line and only works with the identify tool.

RichardFairhurst

Richard,
How do you calculate the values of from and to? It seems like the LR route information is embedded in the line and only works with the identify tool.

You use a Python calculation. For the From measure it is: !shape.firstpoint.M! And for the To measure it is: !shape.lastpoint.M!

TomMagdaleno

Richard, I'm doing mine a little differently, I don't have From and To lines, everything is point based.

Here is my issue. I created multiple points at each intersection with every possible combination of street names. For example if I have 3 streets coming together my intersection would be made up of 6 points. That way no matter how my primary and secondary street is written, it will join to this intersection and get this XY. I perform the join then calculate the measures into my event table. Then I add or subtract their distances from the intersection from those measures.

FULTON ST_HARTNELL ST
FULTON ST_PICKWICK DR
PICKWICK DR_FULTON ST
PICKWICK DR_HARTNELL ST
HARTNELL ST_PICKWICK DR
HARTNELL ST_FULTON ST

The problem is when I go to �??locate features along route�?� it doesn�??t know which measurement to apply to which point. I uncheck "Keep only the closest route location" So my output looks like this�?�

[ATTACH=CONFIG]11654[/ATTACH]

This won�??t work. The street name on the left in the "Concan" field is the Primary Street and needs to match the RID, so Fulton and Hartnell should be at 450.9697 ft. The problem is that it may join to my table with 0 or 1977.0115. So I have to go through 5720 records to clean up the whole city. This will take weeks!

linref.PNG

RichardFairhurst

Richard, I'm doing mine a little differently, I don't have From and To lines, everything is point based.

Here is my issue. I created multiple points at each intersection with every possible combination of street names. For example if I have 3 streets coming together my intersection would be made up of 6 points. That way no matter how my primary and secondary street is written, it will join to this intersection and get this XY. I perform the join then calculate the measures into my event table. Then I add or subtract their distances from the intersection from those measures.

FULTON ST_HARTNELL ST
FULTON ST_PICKWICK DR
PICKWICK DR_FULTON ST
PICKWICK DR_HARTNELL ST
HARTNELL ST_PICKWICK DR
HARTNELL ST_FULTON ST

The problem is when I go to �??locate features along route�?� it doesn�??t know which measurement to apply to which point. I uncheck "Keep only the closest route location" So my output looks like this�?�

[ATTACH=CONFIG]11654[/ATTACH]

This won�??t work. The street name on the left in the "Concan" field is the Primary Street and needs to match the RID, so Fulton and Hartnell should be at 450.9697 ft. The problem is that it may join to my table with 0 or 1977.0115. So I have to go through 5720 records to clean up the whole city. This will take weeks!

No it won't take weeks. It will take two minutes. If this is in a File Geodatabase write a query that reads:

"Concan" Like CONCAT("RID", '_%')

That will select your primary street. Now export that set. It should be what you want. I have to do this also, but it takes only little time and I don't care if the computer works for its living.

You should not use underscore "_" as your separator, since it is the single character wildcard in file geodatabases. I am not sure how to write a query on a file geodatabase that takes that character as a literal value in a LIKE statement. Don't use parenthesis "()" (used by all languages), straight brackets "[]" (Field Calculator field delimiter and sometimes SQL character sets), percent "%" (File geodatabase multi-character wildcard), ampersand "&" (VB Script Concatenator), star "*" (Access multi-character widcard) or question mark "?" (Access single-character wildcard), for the same reasons in that these are special characters in SQL or the field calculator and confuse the join and/or the route event layer, or make it hard to write query logic. The above will be confused if you had two streets that are only different in the characters that follow the shorter name. It may occur rarely in a City, but it might happen (in a County or State it occurs too often). A comma would be a better sperator and would would in that special case with:

"Concan" Like CONCAT("RID", ',%')

That is why I use curly brackets "{}". They aren't special characters used in SQL or anywhere else and do not confuse queries, break joins or fail for event layer creation. For me to do a similar query that will not be confused if two streets are only different in the characters that follow the shorter name I do:

"Concan" Like CONCAT(CONCAT('{', "RID"), '}%')

RichardFairhurst

Actually now that I think about it I don't create the pairs first. I run the Locate Features operation on a single point with the names in alphabetical order. It then creates 3 events at the intersection you mention with three different primary names and three different measures. Then I go through a set of queries and appends to match the primary street and its measure and create the pairs with the two secondary streets. It takes only 3 query and append operation if there are any cases of 4 different street names coming together at a single intersection (those 3 appends of 4 records each generate the 12 unique combinations that occur at 4 name intersections). My approach just means I create fewer records and no wasted records as opposed to your method (which is significant, since the Locate Features operation takes a long time with 90K intersections), but either approach can get to the same outcome.

5,720 records is nothing. I can deal with that in two days tops once I find a logical pattern. (I have visually inspected 7,000 records out of 20,000 in the last two days to validate an automated conflation of one line set with another and made correcting edits to about 10%)

TomMagdaleno

Richard,
It works now! Thank you so much for your consulting help these last few months! I have been struggling with this project in my free time and it finally works! Its down to about 5% errors instead of 40%.

RichardFairhurst

Richard,
It works now! Thank you so much for your consulting help these last few months! I have been struggling with this project in my free time and it finally works! Its down to about 5% errors instead of 40%.

While you cannot mark this thread as answered, since you did not start it and it began before the new forum options existed, you can assign one or more of my answers with points. That will help my MVP standing and guide others to the parts of this thread that were most useful to you. Glad I could help.

By the way, what kinds of errors still exist? I assume they are things like someone describing an intersection that does not exist or is not included in your network, or that they misspelled one or more street names, or that they said to go west of an intersection that is at the west end of the road, or they said go 400 feet westerly of an intersection that is only 300 feet from the west end of the road, or that they used an intersection name pair that exists in two places and the join picked the wrong one, etc. Basically, is the error due to human error, inaccuracy and ambiguity? That is a never ending complication of data collection.

The other note is that this system will work for other kinds of data. For example, traffic counts, traffic signals, and traffic signs work as points if described relative to a single intersection. Pavement conditions of road segments, road construction and improvement projects, and speed limit zones work as lines if you have limit descriptions relative to the two ends. I have created all of these and more with my system. I hope you have similar success as you master this approach.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.