Connecting linear features in different field books

Cliff, for the life of me I don't know why people use a workflow where different fieldbooks are used for a single project. OpenRoads is like InRoads where Fieldbooks can't talk to each other. That's the problem with a workflow like that. And I've seen it as a 'standard' workflow for several DOTs. In my world, all the data for a single project should belong in one fieldbook, end of story. But, if push came to shove and I HAD to do what you are asking here's how I would do it. First, I don't know who familiar you are with OpenRoads Survey, but there are three types of Linear Data - Dynamic Link Linears, Point List Linears and Graphical Linears. The first two are Ruled to the survey shots. the last one is just a graphic that can be added to the fieldbook to make it believe that it was field collected. Go to the Drawing tools and just draw a line snapping to each point where you want to close the gap. (Normally, you could use a JPT code to do this IF both shots were in the same fieldbook). After the graphic line is drawn, then pick a fieldbook ... C or D ... Right-click in the Explorer on "All Linear Features" and you'll see Add Graphic Linear Feature. Select that option and follow the prompts. After it's added, go to its Properties and change the filed code. But my recommendation is NOT to work with multiple fieldbooks like this. ... if there is something that I've explained here that doesn't quite make sense ... hunt down a good training class or manual. ORD Survey is not like InRoads Survey so in my opinion, Training is a requirement. ...a s well as well-defined workflows.

There are plenty of legitimate reasons for having multiple field books. Enhanced control of building terrain models is one example.  Example: It makes sense (to me at least) that I would have a different field book for bridge deck. Thus I can easily exclude the bridge deck from terrain model.  Yet, I still need to connect the roadway edges of pavement to a point on the bridge. 

Unfortunately, you will find various inefficiencies baked in when you try to avail yourself of the power of field books.  One example is the inability to join linear features as you wish to do here.  In my example above, my choices are to put the bridge deck into the same field book as everything else, make duplicate points merely so I can join my EOP to the bridge, or leave a gap in the EOP. 

Because of said inefficiencies then most people use only a single field book.  

My 2 cents: your expectations are reasonable and intuitive.  Perhaps some day the oversights will be corrected.  

Robert, my 'single fieldbook' statement was really directed toward combining any field files where interconnectivity is required. Since fieldbooks have never talked to each other (InRoads and now ORD), my workflow has always been to use a single fieldbook. Your example of a Bridge deck is unique and can warrant a separate fieldbook, sure, but generally speaking, in my opinion, a single fieldbook is the way to go in most cases.

Thank you for your comments, gentlemen. You both have verified my question. 

Zen Dude is right on the money about single field book workflows. I always combine field books when creating final deliverables and merged survey submittals. The issues seem to go away when the project is handled by a single field book. 

As a warning I would not use the Export - Import Field book routines from the ribbon in any sort of merge workflow. It has subtle issues that seem to accumulate into big trouble the more the tool gets used.

Take care,

Cliff