We currently have a street centerline polyline feature class where the street segments correspond to our pavement management database. Each segment has a unique ID that matches a record tracking pavement type/year. Segment breaks occur at intersections, but can also occur mid-block if a subdivision was built in multiple additions. We would like to start adding Left From/To and Right From/To fields to the street centerline feature class for geocoding purposes. I would like to be able to have a street segment start at an intersection and end at an intersection for address coding, but still keep the underlying multiple segments that correspond to the breaks in the pavement management database. Is there an easy way to do this? Do I need to have two seperate line files or is there way to have this in one feature class?
-
You could do it with an LRS. Although typically you'd have the single line feature, and then the pavement segments would be events. Over time, portions of the street could be repaved and don't want to keep splitting your features to attach those types of attributes.– Jay CumminsCommented Apr 24, 2014 at 21:03
1 Answer
I've actually looked at a similar situation myself, except we were looking at it the other way around (adding pavement info to our addressed centerlines). What we came up with was that there were a few options:
You could do an overhaul of your data entirely and convert the roads to a set of linear referenced lines, meaning they have M values in addition to X and Y. More info about linear referencing available at: http://resources.arcgis.com/en/help/main/10.1/index.html#//003900000001000000 Basically with that, you'd have one set of lines and you'd have a separate table saying what portions of that line are what type of pavement and such as that. But that would be managed in a table/tables that reference the line FC, with the geometry only being stored once in one spot.
Another option is you can maintain two separate FC's and create joins/related based on a unique segment ID field if necessary and/or do spatial joins regularly to get links between the two.
You could also maintain them within the same FC but basically maintaining them separately; having separate segments in the FC for address blocks and for pavement sections. You would need to add a field probably and use it to designate if each feature/segment is an addressing segment or a pavement segment. Doing that, you could technically maintain them as separate segments but still have them in the same FC for editing purposes. To view them separately in ArcMap you could use definition queries on that FC and such as that. HOWEVER, I would NOT recommend this method. This does NOT follow what I'd say are generally best practices for data organization. This also will get confusing with some ArcGIS GP tools and other features of the software as you can not use layerfiles or expression based queries everywhere. Also, you will not be able to use them as is for geocoding anyway, you would have to run an export on just the addressing segments out to a separate FC and use those as the input for a geocoder, so I don't know what benefit this could serve due to all the added confusion.
Finally, one option you may actually consider, that would keep them all in the same FC, but still be a bit more usable, would be to take a single road center line and just have it broken at every possible split (split at pavement breaks, split at address range brakes, etc. as necessary). Then, you would probably still need to add a field, but you could mark which segments are what (ex: LF 101, LT 129, RF 100, RT 128, Pavement Gravel, Block 100). Your geocoder could run against that just fine, but if for cartographic purposes or something you really wanted it addressed per block, you could then just run a dissolve by block and road name and the resulting FC would have one segment per block.
That list may not be comprehensive of your options, but I hope it at least helps give you some thoughts on starting points.
-
+1 For Linear Referencing which would be my preferred solution from the options you suggested.– PolyGeo ♦Commented Apr 24, 2014 at 21:19
-
@PolyGeo I agree, linear referencing is useful, especially for a streets department to maintain signs, pavement, lane markings, widths, etc... whatever else you may need. The down side is, either it can get a bit confusing when creating an event table for addresses (and maintaining that table with address ranges). Or, you can use the addresses as your M value, but then you have the issue of measuring pavement length in number of addresses. It's a good concept, but can be confusing when using multiple measurement systems unless built VERY carefully with extra tools to help.– JohnCommented Apr 24, 2014 at 21:32
-
Thanks for all the great information, I will look into linear referencing! Commented Apr 28, 2014 at 18:44