Select to view content in your preferred language

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

8220
29
07-20-2011 01:39 PM
KatherineHayman1
Emerging Contributor
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?
0 Kudos
29 Replies
KatherineHayman1
Emerging Contributor
Nothing at all?
0 Kudos
JeffBarrette
Esri Regular Contributor
I wish I had something for you.  You may want to try the editing forum.

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

Jeff
0 Kudos
RichardFairhurst
MVP Alum
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.
0 Kudos
TomMagdaleno
Frequent Contributor
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?
0 Kudos
RichardFairhurst
MVP Alum
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).
0 Kudos
TomMagdaleno
Frequent Contributor
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}",
0 Kudos
RichardFairhurst
MVP Alum
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.
0 Kudos
RichardFairhurst
MVP Alum
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.
0 Kudos
TomMagdaleno
Frequent Contributor
That is very impressive Richard.  I'll take a look at it and see if I can make it work for me too.
0 Kudos