I am brainstorming about possible ways to at least partially automate splitting of an address ranges. I know that a numeric domain can have a split policy that applies a geometry ratio to the field value with that domain. This does no good for the actual from or to house numbers themselves, but it can give a good effect if there was an additional field for the house number range separating the from and to house numbers for each side of the road. When the line split this value would automatically change to show the geometric proportion of house numbers that would apply to each side of the split line. I would use a double field for the range, and during the house number update I would correct the range for any rounding and odd/even adjustments my house number reassignment process made. After the process finished the range would always hold an even integer value for each side.
Assuming I did not want to program an edit listener (which I don't), I could alternatively set up a second flag field with a domain that resets to a default value when a line is split. An automated process could select features with this flag to adjust the actual from and to house numbers and then set it to a non-default value to indicate the split had been processed.
Another field could store a hard coded ObjectID value that would not change when a split occurred. This would let an automated process group all of the split segments that originally formed one segment and that had not yet been processed to correct the house numbers. After processing the ObjectIDs would be updated to the current ObjectIDs assigned after the split to further indicate the lines had been processed.
The tricky part is that the lines have to be chained back together in their pre-split order to understand how to adjust the house numbers. The lines also have to indicate if they had a different pre-split orientation if any of the line segments had been flipped prior to the house number processing. If the line was a route with M coordinates the interpolated M values created by the split and preserved despite the flip could be used to chain the features back together and determine the original orientations of the segments. A flag indicating if the house numbers increased with or against the measures could have been assigned and could be validated and updated when the house number were processed. Unfortunately in my case my base Centerlines do not have M values and adding M values is not an option. But the orientation flag could still be assigned to the Centerline relative to a separate route feature that was derived from the Centerlines.
I am fairly certain that if all of these inputs were in place I can work out the math to assign the whole number odd or even house numbers that do not overlap and that are oriented correctly for each road side using a cursor driven operation.
Two main challenges remain that I do not have a clear idea of how I should deal with them. What do I do when a Centerline realigns and what do I do to determine that a centerline only flipped? The default value flag would not automatically reset for either of these edits and a route built from the centerlines would not necessarily show any change or retain its original orientation relative to the centerlines.
I have yet to test the Roads and Highways Extension. If I end up using that extension it appears the route synchronization process could be managed by its tools. However, I currently automate my route creation process right now and have alternative processes that can validate affected event measures without using the extension. The Road and Highways Extension seems pretty manually intensive compared to what I now do. It appears you are required to select each centerline segment in a route one by one in order to have it construct a route correctly with the tools provided. I have never had to do anything like that in my route creation or maintenance processes. So unless I can find some way to make it link to routes generated by the Create Routes tool instead I am not sure if I will end up using it.
Anyway, these are my thoughts and I am interested in knowing if anyone else has tackled automation of house number range reassignments using edit listener extensions, the Roads and Highways extension, or any other tools or scripts that I have not identified.
Assuming I did not want to program an edit listener (which I don't), I could alternatively set up a second flag field with a domain that resets to a default value when a line is split. An automated process could select features with this flag to adjust the actual from and to house numbers and then set it to a non-default value to indicate the split had been processed.
Another field could store a hard coded ObjectID value that would not change when a split occurred. This would let an automated process group all of the split segments that originally formed one segment and that had not yet been processed to correct the house numbers. After processing the ObjectIDs would be updated to the current ObjectIDs assigned after the split to further indicate the lines had been processed.
The tricky part is that the lines have to be chained back together in their pre-split order to understand how to adjust the house numbers. The lines also have to indicate if they had a different pre-split orientation if any of the line segments had been flipped prior to the house number processing. If the line was a route with M coordinates the interpolated M values created by the split and preserved despite the flip could be used to chain the features back together and determine the original orientations of the segments. A flag indicating if the house numbers increased with or against the measures could have been assigned and could be validated and updated when the house number were processed. Unfortunately in my case my base Centerlines do not have M values and adding M values is not an option. But the orientation flag could still be assigned to the Centerline relative to a separate route feature that was derived from the Centerlines.
I am fairly certain that if all of these inputs were in place I can work out the math to assign the whole number odd or even house numbers that do not overlap and that are oriented correctly for each road side using a cursor driven operation.
Two main challenges remain that I do not have a clear idea of how I should deal with them. What do I do when a Centerline realigns and what do I do to determine that a centerline only flipped? The default value flag would not automatically reset for either of these edits and a route built from the centerlines would not necessarily show any change or retain its original orientation relative to the centerlines.
I have yet to test the Roads and Highways Extension. If I end up using that extension it appears the route synchronization process could be managed by its tools. However, I currently automate my route creation process right now and have alternative processes that can validate affected event measures without using the extension. The Road and Highways Extension seems pretty manually intensive compared to what I now do. It appears you are required to select each centerline segment in a route one by one in order to have it construct a route correctly with the tools provided. I have never had to do anything like that in my route creation or maintenance processes. So unless I can find some way to make it link to routes generated by the Create Routes tool instead I am not sure if I will end up using it.
Anyway, these are my thoughts and I am interested in knowing if anyone else has tackled automation of house number range reassignments using edit listener extensions, the Roads and Highways extension, or any other tools or scripts that I have not identified.