Being Civil

Where to find coordinate system False Origin

The other day I had a customer asking what the False Northing and Easting was for a specific coordinate system in Civil 3D. Not knowing off the top of my head, and with some help from the Map Team (thanks Doug!), I discovered that this is fairly easy to find within Civil 3D. First we start off with the command ADESETCRDSYS, this will launch the Assign Global Coordinate System dialog which will allow you to select a coordinate system. Clicking on the Select Coordinate System button will launch another dialog which will give you the options to pick your category and the coordinate systems available in that category. For my example I selected NHHPF HARN (HPGN datum) New Hampshire State Planes, US Foot. You just need to select the coordinate system, and click on PROPERTIES in the lower left hand corner of the Select Global Coordinate System dialog box. The False Origins as well as the Projection Parameters will be displayed on the PROJECTION tab of the Global Coordinate System Properties dialog. 

New Commands for Editing Survey Figures

Now when Subscription Advantage Pack is out, our Subscription customers can begin to use some benefits from it. If you remember prior to the release of Subscription Advantage Pack you only had limited options when editing Survey Figure. This is the Figure Properties dialog prior to Subscription Advantage Pack release:

 

Updating Edited Figures to the Survey Database

There are some instances where you want to edit a Survey Figure and then push it back into your Survey Database.  This is easy to do and allows a lot of flexibility to the user.  However, if you break a Figure into two, and then try to update the two parts back to the Database, you will encounter this message:

If Jerry Seinfeld used Civil 3D, I could just hear him saying “What is the deal with this message?”  After all, you just used the Database, how can it not be available?!?

Description Key Wildcards

I have worked with many Land Surveyors over the years.  Each had their own method of doing things.  Methods that may seem odd to some, work completely for them and their field crews.  So when we got a request regarding Description Keys, using a method that I had never seen, I had alternatives to offer – but alternatives weren’t going to cut it. 

Keeping Those Settings Intact

Working in Product Support, we tend to hear some questions over and over (and over and over and over) again. One of my personal favorites is “My survey points aren’t located at the correct coordinates!” The first thing I check is the survey database settings for the distance being used, and most of the time I find that it’s set to International Feet instead of US Feet. This is understandable, as the default is International Feet. The problem is that most of the surveyors in the US use the US foot for recording measurements. The differences are small, but are definitely noticeable. So how can you set the distance to US feet and make that the default? Follow the link to find out how.

As-built Survey Work using Linework

A while back I wrote a post showing a preview of the new Survey functionality in 2010.  I believe that using automated linework is a great way of increasing productivity, decreasing costs, and reducing potential errors.  However, sometimes there can be a conflict between what field crews want to do and what the draftsman wishes they would do.  If the office chooses to avoid using linework, then the draftsman is forced to draw things manually based on crew’s notes.  Often, this is very unnecessary and means duplicate work is being done.  I want to show you a quick example of how using automated linework in the fieldcrew’s codes will take them the same amount of time, but will much quicker once the information is brought into the office.

Survey Linework Without Codes?

As I sit here waiting on my telephone repairman to arrive to fix my DSL line (where is that guy, anyway?) I have had some much needed (and forced, to my dismay) time to sit down and write a post for the blog. I have been thinking about survey features a lot lately, and trying to put together a good workflow for a big posting (possibly even a white paper) but decided that I’d scratch out this little gem while I was brainstorming.

So let me set the scene – you’re a bit curious about your capabilities with automated linework. You’ve always realized that it would greatly increase your workflow efficiency, but you’ve always skirted around it and never really jumped too deeply into it. Perhaps one day while you were waiting on the day’s point file to arrive, you had a little time and played around with some settings. You read a few articles and maybe created a few figure prefixes just for fun, then promptly got distracted and never implemented it with your field crews. Then one day you bring some field data into the survey database and all this random linework starts showing up, even though you know your crews aren’t coding out in the field. You freak out a tiny bit, close your drawing, re-convert the data, delete the survey database, re-import the data – and you still get the random linework! You then proceed to throw your mouse, but forgot that it wasn’t a cordless mouse, and it snaps back, smacks you in the forehead, and requires a trip to the emergency room. Well, I’m here to save on your medical bills and explain why that is happening – remember, safety first!

Reapplying Description Keys to Points

As I have been digging deeper and deeper into Civil 3D 2010, I have found a few hidden gems, and have been slacking just a tiny bit about sharing that information. Today’s post is a preview of something a small feature that will make a world of difference to some people. It’s not a very long and in-depth demo, just one screen shot, but I think you’ll like it anyway.

Have you spent a lot of time setting up description keys in your template only to find that your survey crew fat-fingers a point on the data collector and it doesn’t come in correctly? Have you repaired that point description only to find that it didn’t automatically pick up on the correct description key? This worked fine in Land Desktop, but description keys in Civil 3D have always only been applied at the initial import process. That is, until now. No further explanation needed, because a picture speaks a thousand words: