For many Polyline feature class data models a pair of fields or a set of four fields hold values that are dependent on the directional orientation of the line. Examples of direction dependent pairs of fields include fields describing the left and right side of the line, such as the LEFT_FID and RIGHT_FID fields in the output of the Polygon to Line tool when the keep neighboring polygon information option is checked and Road Centerlines address fields holding city and zip code values for the left and right side of the line. Field pairs can also be associated with the From and To ends of the line, which are direction dependent, such as fields for the X and Y values defining the ends of the lines. An example of a set of four fields that are direction dependent upon both the left and right side of the line and the from and to ends of the line include Road Centerline fields for the Left From, Left To, Right From and Right To house number values of address ranges.
A common problem arises when for any reason the directional orientation of the geometry of all or part of these lines needs to be flipped using the Flip Lines geoprocessing tool or the Flip modify feature editing tool and any of these direction dependent values needs to be flipped to match the new orientation. There is no easy out of the box way to do that.
Using a geoprocessing approach to this problem involves creating either temporary fields or a temporary joinable copy of the table records to perform the flip/swap of these attributes, since the values of at least one of the fields needs to be temporarily preserved in a location that is separate from the pair of fields being flipped/swapped. If a temporary field is created, three separate field calculations in a very specific order have to be performed to accomplish the flip/swap of just one pair of field values. If a temporary joinable copy of records to be flipped is made, two calculations need to be done for each pair of fields. And the selection of features that had their geometry flipped must be preserved at every step in order for the whole process to be done successfully.
This entire problem is ideal for a tool that would include a field pair mapping parameter, like the ArcGIS Pro Calculate Geometry tool. And numerous geoprocessing tools have been specifically designed to handle storage of data in memory or in temporary workspaces to remove the burden of managing these operations from the user. This interface would let the user perform all value flip/swap operations in a single run and be so much easier to set up and execute than anything else currently offered.
A sample field mapping for performing a Swap is shown below:
Swap Field 1 | Swap Field 2 |
LEFT_FID | RIGHT_FID |
LEFT_FROM_NO | RIGHT_TO_NO |
LEFT_TO_NO | RIGHT_FROM_NO |
LEFT_CITY | RIGHT_CITY |
LEFT_ZIP | RIGHT ZIP |
FROM_X | TO_X |
FROM_Y | TO_Y |
The tool would move every value held in one of these pairs of fields into either memory or a temporary workspace and then perform the swap of values between the two fields.
So, for example, for every record the LEFT_FID, LEFT_FROM_NO, LEFT_TO_NO, LEFT_CITY, LEFT_ZIP, FROM_X and FROM_Y values would first be temporarily stored in memory.
Then move the RIGHT_FID value to the LEFT_FID field, the RIGHT_TO_NO to the LEFT_FROM_NO field, the RIGHT_FROM_NO value to the LEFT_TO_NO field, the RIGHT_CITY value to the LEFT_CITY field, the RIGHT_ZIP value to the LEFT_ZIP field, the TO_X value to the FROM_X field and the TO_Y value to the FROM_Y field.
Next, move the LEFT_FID memory value to the RIGHT_FID field, the LEFT_FROM_NO memory value to the RIGHT_TO_NO field, the LEFT_TO_NO memory value to the RIGHT_FROM_NO field, the LEFT_CITY memory value to the RIGHT_CITY field, the LEFT_ZIP memory value to the RIGHT_ZIP field, the FROM_X memory value to the TO_X field and the FROM_Y memory value to the TO_Y field.
Finally, perform any memory and temporary workspace clean-up for the user.
This whole set of operations being done one step at a time by the user is prone to errors, since it involves a minimum of either 16 steps or 21 steps all of which involve working with very similar field names that can easily be confused or difficult for the user to keep track of. Even using the Calculate Fields tool, which has a field mapping, it can be confusing, because the operation involves a minimum of three separate steps that each involve numerous field with very similar names that have to be performed in an exact order.
The interface set up above is much easier to understand than any manual workflow I could describe and once the tool is developed and debugged these operations become standardized and will be performed infallibly and with easy repeatability once the user configures the field map correctly for a given Polyline feature class. This tool would naturally follow or precede the use of the Flip Lines geoprocessing tool as a separate step for the same feature selection. Having this tool in combination with the Flip tools would allow the user to make simple modifications to the field map if they only want to swap a subset of these attributes because they know that the other attributes are oriented correctly with the flipped geometry already and may have been the cause of the geometry flip in the first place.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.