Map book, data driven pages for a polyline: Grid Index vs Strip Map??

6813
12
04-26-2011 10:41 AM
DaniellePapineau
New Contributor II
I need some help in creating a map book.  My project area is a pipeline that curves, turns, and has extensions coming off it, sometimes relatively parallel to major line.  I've tried using the grid index and the strip map index tools to designate/reference my pipeline and have found pros and cons to both, but neither tool functions the way I need it to.

The strip map index follows the pipeline, but the polygons created are angled.  If I were to put this together as a map book, I'd have a lot of overlapping that is not desired.  The grid index doesn't provide a "best fit" to my line and yields extra polygons.  I know I can move and delete the polygons for a better fit to my line, but then I can't Calculate Adjacent Fields, etc. because now that I have moved the polygons, they don't neatly line up (plus the page name/number no longer follows any logical manner). 

I've been trying to learn this process from the example in the Help menu, but my project area is so much different, it's been frustrating trying to adapt it to my needs.  Another issue is that I'm working in a State Plane coordinate system and the Help example uses UTM.  It also requires a "Calculate UTM Zone" tool which is used in the Data Driven Pages as a Spatial Reference.

Basically, I need to create a map book with an index layer that follows along the pipeline, much like the grid index, but with a "best fit" to my line.  And it needs a spatial reference. 

Up until now, I've been setting up bookmarks and manually adding match lines.  I'd pdf each bookmark separately (sometimes 80+ bookmarks/pdf'd maps) and change the map number as needed.  I would really like to be able to use this new functionality in ArcMap 10 (dynamic text included).

It doesn't seem that it should be as complicated as I'm finding it to be.  Any help would be greatly appreciated.
Tags (2)
0 Kudos
12 Replies
JimCunningham
New Contributor
Danielle,

Thank you kindly.  No need to send me samples, though.  I have (generally) used the same methods that you have employed.  Rather than match lines, I had an inset which followed the route of the large scale map, with each page having true north in the same direction (i.e. "up").  But recently I was provided a sample that almost assuredly used a data driven pages strip map index, and opted to use the 'Angle' attribute so that the general orientation of the route was shown (west-to-east).  In this instance (which my three attachments demonstrate above), the north arrow rotates, and match lines are shown.  It is the placement of these match lines - and how they work - that has me curious.

At this point, I will likely revert to what has worked in the past, and simply not use match lines.  At least, I will not use match lines as they are shown in my sample.  Still, I would love to have this solved, as it seems that it should not be that complicated.

Thank you again for your input.

Jim
0 Kudos
T__WayneWhitley
Frequent Contributor
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
0 Kudos
JimCunningham
New Contributor
Wayne,

I am only now getting back to this forum to check on any updates.  I appreciate your detailed feedback and may attempt your approach some time soon.  In the end, I ended up not using match lines at all.  Rather, I had an inset locator map that served the same purpose.  The match line issue was something that I wanted to resolve primarily because it had me stumped.  I must admit, it still has me a bit confounded.  It was not essential for the client.  But that doesn't mean that I don't want to figure it out.

Again, I will attempt to tackle it with your method.  No need to send a Python script - if the method works, I will likely try to put one together myself.  It would be good practice for me!

Thanks again, Wayne.

Jim
0 Kudos