Monday, May 31, 2010

Interesting Intersections I've crossed

This week I ran into two interesting examples of alignments that just didn't play well with the automated intersection design tools.

Case 1- The Loop:
It isn't unusual for an alignment to cross itself, however the intersection tool won't recognise the crossing location.  Of course, the easy answer is to split it into 2 alignments. However, I wanted to build the intersection the pre-2010 way, manually creating curb return profiles and corridor regions the "old fashioned" way to see if I ran into any hiccups. 

I was worried that C3D might get confused with the whole "Target nearest to offset" thing in the corridor parameters, however this ended up building without  problem.  The most difficult part was getting the right OSNAP for throwing on the station label at the intersection (as seen in the screen cap).  I used trial and error until I got what I wanted.

One of the big things you need to remember in creating manual intersections is to make sure your crowns match. 

To manually lock a PVI just jump into the profile geometry editor. Use the select PVI to make sure you're locking the correct one and set the Lock option in geometry to True.

Case 2 - Two Ts:
This scenario came to me this week from a client.  Two J-shaped subdivision roads T into each other.  The first intersection builds without a hitch. The second intersection will not go so well.  In my client's case it was creating wacky profiles (deleting vertical curves and locking the profile at the first intersection).  When I tried it myself, I got the message, "The primary road for this T-junction will result in a circular dependency with the existing intersections."  In other words, Civil 3D gets just as confused as the friend who you tell, "Pick me up at the intersection of Jefferson and 3rd Ave..."  Which one?!

Your best bet for fixing this case is two split one of the alignments into two.  Of course you could do this one the pre-2010 way as well.

Hope this info comes in handy someday.

Friday, May 21, 2010


Only a few more days left to vote for my classes at AU:
Vote for your favorite classes...don't make me bribe you with candy!

Civil 3D Craft Project: Migrating Eagle Point Field Codes

Are you an Eagle Point user migrating to Civil 3D?
Are you a Civil 3D user who just hates the squirrely behavior of the description key editor?

If you answered YES to any of the above questions, I have some good news for you.  I've developed a method of getting Eagle Point field codes over to Civil 3D without having to retype any of the names.  You can also use this technique for typing in your description keys in a spreadsheet and migrating them over, thus avoiding the annoying editor. 

(If you find this process too tedious and want me to do it for you, donate $50 bucks (see button right) and email me the exported EP codes.  I'll send it back to you as a DWG from which you can move the completed Description keys.)

DISCLAIMER:  The Description Key, Format and layer columns go across without a hitch.  When the process is all done, you still need to set your styles for marker and point label. 

What you will need:
  • Eagle Point
  • Civil 3D
  • Any version of Microsoft Access
  • Any version of Excel
  • A copy of the "dummy" Land Desktop file and my handy-dandy converter spreadsheet available HERE.
1) In Eagle Point, go to System then Node (Field Code) Library

2) Click the Manage Field Codes button.
3) Click Export.  Save the file pretty much anywhere (as long as you remember where you put it).  Give the file a full name such as Export-to-C3D.csv.

4) Double-click your new CSV file and let it open in Excel.
5) Copy your information from columns A through Q.
6) Open up the spreadsheet EP_Convert.xlsx
7) Make sure you are on the worksheet tab called Eagle_Point
8) Click your cursor in cell A2 (the first blank one), and paste.
9) Switch to the worksheet tab called Default. 

Your Eagle Point information is now in the correct format for bringing into an Access table. 
10) Save the Excel file.

12) Close up all your Excel files.  Fire Up Access by double clicking the Default.mdb.

13) If Access prompts you to update the database to the latest format, click yes.    If a conversion errors table is created, delete it.

 If it doesn't prompt you, just be glad and move on to the next step.

14) Go to External Data.  Click Excel.

15) Browse for the EP_Convert.xlsx file that contains your stuff.
16) Toggle on "Append a Copy of the records to the table DESKEYS".  Click OK.

17) IMPORTANT: Make sure the worksheet Default is highlighted.

18) Click next until the import finishes.   Access should automatically recognise the column headings. 

Double click the table DESCKEYS to check out the new data you imported. If you want to add or modify your codes this would be a good place to do so.

19) Save the MDB as a 2000 format file. 

20) Put the database (mdb) file in a folder called DescKey.  Put the DescKey folder in a folder called Cogo. Put the Cogo folder in a folder called EP Import.

21) Fire Up Civil 3D (yay! Finally!) Open up the template where you want these keys to reside. 
22) Go to Insert tab > Land Desktop.  Browse to the folder one level up from wherever you put the EP Import folder. You know you are in the right spot when EP Import is listed in the Project name.  Click OK.

23) If you did everything correctly, Civil 3D will pop up a message that says "Description Keys migration completed!"
24) Click OK.
25) Lastly, you'll need to get to work setting styles in the description key editor, but that's easy!

Friday, May 07, 2010

'Nother Non-techincal Quickie

I've changed my comment policy to allow ANYONE to comment.  Previously I required a Google account. 

I'm still moderating comments and reserve the right to reject stuff - but for all of you who have emailed me with comments - this one is for you!

Of course, I always do enjoy your email messages and I do respond to them as time permits.

Have a great weekend!