Snapping with attribute rules

By Koya Brown

Recently, I saw this example from parcel fabric to connect lot lines and snap to control for accuracy when editing. The use case was, essentially, when drawing parcels per their metes and bounds, preserve the COGO measurements while making sure the lot lines connect to the points. More generically, the rule can be expanded to allow snapping of a line with more than two vertices or specifying a subtype.

For example, I have a device feature class that has three subtypes: switch, transformer, and fuse. And I only want the line to snap to the nearest switch. In this case, I use the attribute rule to help me do that. Or, maybe, you want to ensure a connection between a manhole and a sewer line.

I repurposed the snapping with attribute rule by expanding the use case. Now, the new rule accounts for a polyline instead of a segment. Also, I change the logic of the rule to connect to the closest vertex. Instead of the nearest first vertex. Lastly, the expanded rule will allow specifying subtypes. I explore all of the changes to the snapping rule here.

Snapping

Snapping is an aid that uses snap agents to control for accuracy while editing and it is configurable. It is often enabled, by the user, when you set up your editing workspace before you start an edit session. This is useful when you have high volume editing workflows that require connectivity between features.

For example, connecting points and lines. Hence, the workflow here uses attribute rules instead of the snap agents. Because it works everywhere and minimizes room for error.

Polyline versus segment snapping

The original design of the attribute rule was for a line with two vertices (or segment), a start and end point. However, I wanted to be able to use the rule regardless of the number of vertices. There is a condition set to evaluate the geometry, do a count, and filter all two-point lines. Additionally, the polyline JSON has the paths of the line with the starting and ending vertex.



if ((Count(Geometry($feature).paths[0]) == 2) &amp;&amp; (vertex != null)){ //if the line is a 2 point line (not a curve or polyline) AND the nearest vertex is not empty
    var x1 = TEXT(Geometry($feature).Paths[0][0].x); //start X coordinate of $feature
    var y1 = TEXT(Geometry($feature).Paths[0][0].y); //start Y coordinate of $feature
    var x2 = vertex.coordinate.x; //target X coordinate
    var y2 = vertex.coordinate.y; //target Y coordinate
    if ((x1 == X2) &amp;&amp; (y1 == y2)) return; // safe guard for small lines not to try to snap on their own start point (which is where another line might end)
    
    var dist = sqrt(Pow((x2-EndX),2) + Pow((y2-EndY),2)); // the distance between the end vertext of $feature and the nearest vertext
    if (dist &gt; tolerance) return; //must be smaller than set tolernace
    //if we got here all that is left is update the geoemtry of $feature :-)
    var SR = Geometry($feature).spatialReference; //spatial reference of the line
    var polylineJSON =  { //create a JSON representation of the updated line
        "hasZ":true,
        "paths":[[[x1,y1],[x2,y2]]],
        "spatialReference":SR
        };        
    return Polyline(polylineJSON); //return the Polyline to update the SHP field       
}

Construct polyline

To make the rule more generalizable, these constraints would need to be removed, which means being able to accept all polyline edits from an editor. There are two considerations to change this: the construction of the polyline and the nearest vertex.

In constructing the polyline, I create a variable for the new path. Then loop through each path by its index position, to push each individual path to the new path variable. With one exception, skipping the last path. The last path will now be the updated end point. To get the end point value, I use the target vertex coordinates, which is much like the original attribute rule. This process results in the path parameter needed for the Polyline function.


var newPath = [];  //variable to store the new path

for (var p in paths){
	var path = paths[p];
	var ct = count(path)
	var skipPt = ct-1
	console(ct)

	for (var pt in path){
		// Process individual path here
		if(pt != skipPt){
				console(pt)
		push(newPath, path[pt])
		}
	}
push(newPath, targetXY) //add the new endpoint

//there are additional steps after this will to close the for loop

First Nearest vertex

The original example a chain operation of First and Intersect returns the first feature in the FeatureSet followed by the NearestVertex function. A limitation of this is that the line will not snap to the closest vertex due to the First function used in the chain operation. Because it will snap to the nearest vertex of the first feature returned in the FeatureSet. Meaning, if I have two points within my tolerance distance, it will snap to the first feature vertex returned not the closest one.

Closest vertex

To make the rule more flexible, the chain operation does not use the First function to get the devices. Alternatively, to identify devices for evaluation, I find the minimum distance between the features. So, I return all the devices within the search distance. Next, check the distance of each device to the last vertex of the line. This allows the line to snap to the closest device.


var closestDevices = Intersects(devices, Buffer(lastVertexGeom, searchDistance, searchUnits));
var minDistance = Infinity; 
var closestDevice;

for (var d in closestDevices){
    var deviceDistance = Round(Distance(d, lastVertexGeom, 'feet'),3);
    if (deviceDistance &lt; minDistance){
        minDistance = deviceDistance;
        closestDevice = d; 
    }
}

Make the attribute rule extensible

Making the attribute rule extensible, in a sense, allows editors to modify parameters needed for evaluation and accounts for potential failures. Here, I use a table to store the parameters that users can modify to suit their editing experience. This alone does not make the rule extensible.

To make it extensible, meaning, the rule will not fail if the values in the table are null: I add a logical condition. The expression will use default values if the configuration table is empty. Therefore, editors can set their search distance, the distance units, and a subtype. This will be discussed in the next section. If these values are not set by the editor, the rule will automatically use default values.


//make rule extensible
var snappingconfig = First(FeatureSetbyName($datastore,'snappingconfig',['*'], false));
var searchDistance;
var searchUnits;
var subtypeCodes; 

var defaultDistance = 2;
var defaultUnits = 'feet'; 
var defaultSubtype = 0; 


if (IsEmpty(snappingconfig)){
    searchDistance = defaultDistance;
    searchUnits = defaultUnits;
    subtypeCodes = defaultSubtype;
} else {
    searchDistance = snappingconfig.SearchDistance; 
    searchUnits = snappingconfig.SearchUnits; 
    subtypeCodes = snappingconfig.Subtype; 
}

Specify subtypes

Subtypes can be applied to a rule as part of the Attribute Rules view configuration. But I use the FilterBySubtypeCode function. And the value comes from the editors’ input into the snapping configuration table.

Let’s say, I have a rail line and will snap to the closest switch that has a subtype code ‘0’. This value will be put into the configuration table and passed as a parameter. The chain operation will get the table and filter the table by the subtype code. By adding the parameter, to the snapping configuration table, it allows the attribute rule to be both specific and flexible.


//Filter by subtype and Set 'Points' to the fully qualified table name
var devices = FilterBySubtypeCode(FeatureSetbyName($datastore,'ev_Device',['*'], true), subtypeCodes); 

//Get closest device
var closestDevices = Intersects(devices, Buffer(lastVertexGeom, searchDistance, searchUnits));
var minDistance = Infinity; 
var closestDevice;

for (var d in closestDevices){
    var deviceDistance = Round(Distance(d, lastVertexGeom, 'feet'),3);
    if (deviceDistance &lt; minDistance){
        minDistance = deviceDistance;
        closestDevice = d; 
    }
}

Final output

You now know how to make an attribute rule more generalizable by making a few modifications to expand the rule’s applicability. I also showed how using a configuration table helps to create a more dynamic rule. Additionally, you can enable editor flexibility by allowing input parameters like feature subtype.

For more tips, check out the Esri Community blog article on authoring attribute rules and configurations best practices.


//The full attribute rule used in GIF
//make configuration table extensible for snapping parameters to closest vertex

var geom = Dictionary(text(Geometry($feature)));
//console(geom)
var paths = geom['paths'];
//console(paths)
var lastPath = paths[-1];
//console(lastPath)

var t = lastPath[-1];
//console(t)

//var lastVertexGeom = Geometry(lastPath[-1]);

var lastVertexGeom = Geometry($feature).Paths[0][1];
//console(lastVertexGeom);

//make rule extensible
var snappingconfig = First(FeatureSetbyName($datastore,'snappingconfig',['*'], false));
var searchDistance;
var searchUnits;
var subtypeCodes; 

var defaultDistance = 2;
var defaultUnits = 'feet'; 
var defaultSubtype = 0; 


if (IsEmpty(snappingconfig)){
    searchDistance = defaultDistance;
    searchUnits = defaultUnits;
    subtypeCodes = defaultSubtype;
} else {
    searchDistance = snappingconfig.SearchDistance; 
    searchUnits = snappingconfig.SearchUnits; 
    subtypeCodes = snappingconfig.Subtype; 
}

//Filter by subtype and Set 'Points' to the fully qualified table name
var devices = FilterBySubtypeCode(FeatureSetbyName($datastore,'ev_Device',['*'], true), subtypeCodes); 

var closestDevices = Intersects(devices, Buffer(lastVertexGeom, searchDistance, searchUnits));
var minDistance = Infinity; 
var closestDevice;

for (var d in closestDevices){
    var deviceDistance = Round(Distance(d, lastVertexGeom, 'feet'),3);
    if (deviceDistance  searchDistance) return; //must be smaller than set tolernace

var SR = Geometry($feature).spatialReference; //spatial reference of the line
var polylineJSON =  { //create a JSON representation of the updated line
    "hasZ": true,
    "paths":[newPath],
    "spatialReference": SR
    };
//console(newPath)
//console(polylineJSON)
//console(count(newPath))
return Polyline(polylineJSON);
}

Article Discussion:

0 Comments

Oldest

Newest

Inline Feedbacks

View all comments