This tip involves a subject that is a bit more theoretical than most, and hopefully you will be able to wrap your head around this back and forth exchange and find it useful to some degree. The user's question and comments are in italicized black and Mark's answers are in green. There is also additional information at the bottom of the tip for you under Additional Notes.
Hey Dude, first, I was given a template that is intended to place 2 lanes of pavement. It places 14' of pavement to each side of the baseline: 12 feet of lane plus 2 feet of shoulder with full depth pavement.
I want to add a point that represents the edge of travel way (ETW) and then set the pavement edge (EP) 2 feet outside that. I'm adding points called ETW_L and ETW_R. I constrained each to be offset from the centerline. I constrained each to Vector-Offset between the centerline and the edge of pavement.
The EP points as provided were constrained horizontally and slope from the CL (14' and 2%), and I wanted to change those so they were constrained to the ETW, instead of the CL.
When I reset the horizontal constraint on the EP point to be derived from the near ETW, I get the message: "ERROR: The first constraint could not be placed because: Invalid Parent - Causes recursive constraints".
The workaround is that on the ETW, I needed to change the Vector-Offset to Slope, and use the same CL and EP points to establish the slope. At that point I don't get the recursive constraint message anymore on the EPs. This workaround isn't a great deal of work, but surprising, as it is not obvious.
In the end, I suppose I'm wondering if this is a software error, or it is something that I'm doing. Do you have any insight on this? - Derk
Here is the Zen Dude's response:
Derk, in my opinion I wouldn't say this is a software error. Theoretically speaking, if the EP has the Parent of both constraints tied to the ETW (in essence making the location of the EP controlled by the position of the ETW), then it would seem correct that you can't then tie the slope or Horizontal of the ETW to the relative position of the EP (or vice versa) That creates two moving targets. That's the recursive piece. Why don't you create a NULL Point and tie it to the ETW's and then define your EP from the NULL Point? That way the constraints aren't cross-talking. ... I'll qualify this post slightly with the fact that I'm saying this while using InRoads SS2, not OpenRoads SS4.
I really think that this is a bug. Or, perhaps it's better to say it is surprising to see this error raised. If it isn't a bug, it might be helpful to know why it behaves this way for vector-offset and another way for slope.
Using the vector-offset constraint on the ETW and setting the parents to CL and EP raises the recursive constraint error. Using the slope constraint on the ETW and setting the parent to CL and locking the slope to follow the slope between CL and EP does not raise the recursive constraint error.
I'd always considered vector-offset (when the offset given is 0) to be shorthand for using the slope constraint, so to me they should yield identical performance and identical errors. If you can explain to me how my understanding is fundamentally flawed, I'm all ears.
Okay, first, just try to diagram out what you are trying to do, and you'll see there is more to it.
The recursive condition is caused by the ETW being controlled by the position of EP and at the same time the EP is attempting to be controlled by the position of ETW. You can see the circular reference on the right side between the last two template points.
And while you might have always considered that a V-O constraint with the Offset = 0.00 is shorthand for a Slope Constraint, it's not, otherwise it wouldn't exist (or have two Parents instead of one), so there is obviously more to that constraint that you are not considering. That's the "fundamental flaw". In InRoads SS2-speak, for example, placing two PI's with the Curve Set tools can create a tangent, but the Horizontal Element command to place a Fixed Line does the same thing with two points ...therefore are they essentially the same command? No, they're not ...even though the results are similar. One method is much more sophisticated than the other. And you might also know this 'recursive' limitation exists in Target Aliasing too.
I'm sure Bentley could probably program the software to address this in the constraints by developing some sort of priority in the calculation of the point locations relative to the "Constraint network". For instance, Excel has the capability to address circular calculations by defining a finite number of iterations. But that would just add even more complexity to the software, and it's not something that can't be solved with a NULL Point.
Additional Notes:
Also read this on LinkedIn: (where Chuck Rheault and I talked about this recursive situation)
(The body of that post is captured here for your convenience in case you are not a member of this LinkedIn group.)
Q: Recursive constraints in templates??? I thought recursive constraint means - if I have 2 points in template ,say A & B and if A is constraint to B then B cannot be constraint to A because it will be recursive constraint. But I think there is more to this. Can anyone please throw some more light on this topic???
Mark Ditko posted - Jimmy, you're right in what you said and that's a good guideline (and maybe the most important one.) I'm sure I can come up with a clean way of stating an exact rule or specific wording that would completely describe this if I thought about it enough, but the general concept can be understood by just defining the words. "Recursive" means drawing back on itself, referring back to itself, or calling on itself for direction or input. A similar problem exists with Excel and is called a "circular reference". "Recursion" is where the solution to a big problem (or variable) depends on solutions to other instances of the same problem (or variable) in smaller scenarios. Mathematically this is used to find an answer to a larger problem, but programmatically it's probably more like heartburn. There may be other recursive situations that could be created in template construction like defining the position of a point relative to a Vector-Offset from two points and then trying to also define its position using some conflicting constraint. (Sounds like a fun way to burn some time ; ) It's probably a good thing that each point can only have 2 constraints or this might be a bigger mess for some users that don't understand this. It makes me think of using the Dynamic Settings and Intervals during Vertical Alignment layout. You can toggle on too many Dynamics which creates a mathematical equation that can't be computed and has no answer. With those tools, one of the Dynamic settings simply fails to influence the result in order for something to happen. Those layout tools could have been programed to slap you on the wrist like this and say something similar.
Charles Rheault posted - Mark hit the nail on the head - it is very much like Excel formulas that require another cell to evaluate but that cell is looking for the initial cell to determine its formula. In templates, the circular references can be harder to spot. Generally, template points get restrained from the center out and from the top down. This is not required but it is how most points get defined. I have had the software refuse to allow me to set a constraint and found it hard to find the problem, but I have never found the software to be wrong. Sometimes, Point B relies on Point A and Point C relies on Point B and Point D relies on Point C, and some design decision requires you to move point A based upon point D and that is not allowed. If there was some way to display a decision tree for all points Horizontal and vertical location, it would be easy to see where the problem is, when it happens. Maybe someone can develop an XML report to do just that.
Enjoy!!
Civilly yours,
- zen
There is only one Mark Ditko. We need him for future training. I think he could help iron out some of the problems in the department. 
