when using setback operations the index of the edges changes in a unpredictable manner
I'm using setbackPerEdge to perform setback operations using a array. I use the edge indices from comp(fe){all: comp.index} to perform different operations dependent on the index I get back, which requires the indices of edges to not change, or change in a predictable manner.
When I use the setbackPerEdge after having used a shapeO (or setback operation to get the same result) the new leaf shape has it's edge indices permutated compared to the origin: here is an example where I have a rectangular shape as an initial shape(left) and as we go from left to right we first create an ) shape, then we apply setbackPerEdge a certain number of times as seen in the image bellow:
at each point I'm translating the shape and visualizing the edge indices of the new shape. As can be seen, the first application of shapeO maintains the edge index order - while adding the new ones at the centre. as soon as we start applying setBackPerEdge to this new shape the edge indices start to shift 0->1, 1->2, and so on.
If we do the same operations on a slightly different initial shape the indices shift in a different way as shown below, where 0->2 and then 2->0 in an alternating way
how do I maintain the indices consistant or keep record of how they change in a predictable manner so I can use them reliably?
The code to reproduce the example is shown bellow:
---
version "2022.1"
import Text:"/ESRI.lib/rules/General/Text.cga"
attr setbackArray = [0,0,2,1] #organized as [front, right, back, left]
attr originalNumEdges = size(edgeLabels)
edgeLabels = comp(fe) { street.front : 0 | street.right: 1 | street.left: 3 | street.back:2 } # to identify index used to query setbackArray for each edge
_edges = size(edgeLabels)
attr floorPlate = 12
@StartRule
plot-->
viewIndex(_edges, edgeLabels)
endShape
setback(
comp(fe){
street.front: floorPlate + setbackArray[0] |
street.right: floorPlate + setbackArray[1] |
street.back: floorPlate + setbackArray[2] |
street.left: floorPlate + setbackArray[3]
}
)
{
all= _footprint(_edges, edgeLabels) |
remainder: NIL
}
_footprint(numEdges, currentEdgeLabels)-->
print(numEdges)
t(50,0,0)
viewIndex(_edges, edgeLabels)
endShape
setback1(_edges, edgeLabels)
setback1(numEdges, currentEdgeLabels)-->
t(50,0,0)
print(_edges)
setbackPerEdge(setbackArray[currentEdgeLabels[comp.index]]){
all= NIL
|remainder:
viewIndex(_edges, edgeLabels)
endShape
setback2(0)
}
setback2(i)-->
case i>3:
NIL
else:
t(50,0,0)
setbackPerEdge( 0 ){
all= NIL
|remainder:
viewIndex(_edges, edgeLabels)
endShape
setback2(i+1)
}
viewIndex(numEdges, currentEdgeLabels)-->
comp(fe)
{
all:
[
case comp.index<originalNumEdges:
case currentEdgeLabels[comp.index] == 0:
# t(5, 0,0)
Text.Letters(comp.index + "- street front",1.5)
else:
# t(5, 0, 0)
Text.Letters("" + comp.index,1.5)
else:
NIL
]
}
endShape -->
color(0.8,0.8,0.8)
endShape.
Hi Martin,
I'll take a look at the edge attribute function to see if that can do the trick.
What I'm currently using this for is to be able to setback specific portions of the street facing edges so that the resulting shape will have 35% of the original edge and the rest with a specific setback. The way I'm doing it now is by using recursive rule that uses the splitAndSetbackPerimeter. I recurse through each street front edge and and apply the setback operation only on that edge and then move on to the next one. Bellow is a code example of the use of the splitAndSetbackPerimeter where I create a masked array to select the current edge and apply the setback and recurse to the next edge until all front edges are setback.
splitAndSetbackPerimeter(0, 0, currentEdgeMask(_edgeIndex))
{ startOffset: sb: NIL
|0.35 * frontFacadeLength(i): 0: NIL
|~1:sb: NIL
}
{remainder: setbackRecursive(
i+1,
frontEdges[i+1]+indexOffset #this indexOffset is how much the original index changes given the setback applied
)
}
The result of this rule can be seen bellow, where I'm outputting each step through the recursion:
In this case the indices change consistently, and I only need to handle the special case of when the setback is applied to an edge which has an index of 0, where if the setback operation happens anywhere other then the start, the edge that stays flush to the streetfront will be indexed at 0 (as can be seen in the image).
Now I wanted to create a hole inside the shape before running the procedure and that is when I ran into the issue of the inconsistency in edge indexing.
kind regards,
Mateo
