This turned out to be a very interesting problem - it took me a little bit just to understand the problem. Jim, this is what I understand after reading your posts and looking at your attachments -- your stipulations are:
1- You want to use DDP, in conjuction with 'match lines' pertaining to a pipeline.
2- These match lines are to be displayed on the page at the same relative location (on the page, that is).
3- The match lines do not rotate in concert with the north arrow but rotates relative to the page, i.e. pivots about a point on the pipeline.
Stipulation 3 was the stretch for me in understanding the problem...but it dawned on me after looking at your example. It's been awhile since I've looked at engineering drawings I guess. Essentially the match lines give you quick reference, that if you were to 'line up' 2 consecutive pages, the match lines would match up almost like crosshairs as you rotate the pages relative to the north arrow orientation, while centering at the intersection of the match lines and pipeline segments. Makes sense now, and that's very clever....suppose it goes without saying (although I'm saying it anyway) these type drawings will 'match' well only if the same scale.
I'd like to point out that the drawings you provided, Jim, appeared to be a relatively small scale so I'm not sure how accurate the match lines were. However I will say that it is fairly obvious now that for the match lines to be generated in the same relative page location, this generation is linked to how the pages themselves were constructed...hence how the DDP index grid was created. So I ran a test with the Strip Map Index Features tool with the parameter "Percentage of Overlap" = 0 which I thought should yield a point intersection on the 'trunk line' of the pipeline where this 'pivot point' should lie. Not sure of this tool's algorithm, but it simply doesn't work that way, at least not that cleanly.
I worked out something more exacting which 'reverse engineers' the overlapping index grid, deriving the match lines by 'decomposing' a point intersecting 'inner grid' as noted in brief above --- I haven't had time to flesh it out, but it really isn't all that complex. This could be optimized I'm sure, but this is basically what I did at least to test the concept (and much of this could be better accomplished with a Python script):
- With a test pipeline segment (1 long polyline, single-part), got the start point using Feature Vertices to Points...
- Buffered the point output, distance is the desired page width...
- Used intersect with point output, buffer output with the orig test line - regardless of how long the actual segment is, this yields a straight-line distance from the orig starting point.
- Loop to buffer each succeeding point output and intersect down to the end of the line... (this part of the process could be made more efficient as it produces redundant multipoint output)
- Connected the points with Points To Line.....(the points must be Appended to a common fc 1st)
- ...argh, it's a single line -- split into line segments with Split Line At Vertices (again, not very efficient -- scripting this will be faster and more efficient, eliminating or altering some of these steps).
- Created a flat end buffer on the individual equally segmented lines....now these are the true pages with 0 overlap at the pipeline - these page edges will be the new match lines...
- To output match lines, buffer the points appended to the common fc (1/2 the desired match line length), and use this to Clip the flat end buffer output (may have to convert to lines 1st).
Then, with the match lines derived from the essentially an 'inner' grid in the above process - the 'outer' grid of overlapping pages can be generated by:
- Buffering the flat end buffer from above (this will give you the page overlap and ability to 'view' the match lines)
- Since this will give you round corners, you can further process this buffer and use Minimum Bounding Geometry with geom type RECTANGLE_BY_AREA to give you the customary page corners.
It's convoluted I know, but it may be worth scripting this and pull out all the stops you'd encounter trying to piece this together with only a Basic licence. However this should give you the cleaner and more accurate output than what the Strip Map Index Features tool will enable you to get....based on your need to construct reliable match lines, of course.
Hope this helps a little, sorry for the long post...like I said - interesting problem! If I have more time later, would you like a script tool? I think it would actually be easier to make than to have to remember the minute detail having to run this all with the individual system geoprocessing tools. I have worked in utilities, produced a few map books, so I understand the potential implications of having this capability!
Enjoy,
Wayne