State Planes in Civil 3D

As if we needed further proof that Autodesk is out of touch with surveying.

Choose carefully if using Civil3D 2014 or 2015 as it is our experience that when you move to a different projection certain drawing features such as contour lines and alignments get left behind. The support contact seemed to think this was okay!

Over the years I've dealt with numerous datums, reference frames and projections. Any more it's mundane stuff for Surveyors. One would hope it would be easy to recognize the two datums referenced in the names. I suspect the rest are simply repetitions to make it easier to find a zone using the various popular naming conventions. The alternative would be to (further) alienate users by insisting they use the exact name set by statute (or some other reference)...

:good:

This has nothing to do with AutoDesk. Those are all zones created by NGS... check with them for definitions.

Jim,

Correct me if I'm wrong, but aren't all State Plane Zone Definitions set by each State's Legislature? The Arizona Legislature has a definition of each of its 3 zones for both NAD27 and NAD83. So what is a HARN definition, and what differentiates it from the NAD83 definition?

Dave

B Man,

"...insisting they use the exact name set by statute (or some other reference)..."

Wouldn't that be the point of using a Projection set by law? I can't find anything in C3D's Help Section to explain these multiple names.

Dave

I am careful to use precise language in professional correspondence. That being said there are numerous common names and syntax in use. It is possible to make a point or relay a concept without using a precise legal term. Sometimes it's just easier to let people use what they are comfortable with. Is it right? No, but it sells software...

Dave, as noted above, this is all NGS induced. They invented all this gobbledygoo k to help something, certainly also to confuse even surveyors There's more datums d'jour than you likely have mosquitoes now.

I would back up, take a breath, and never use any 3rd party software (auto crud for example) to process anything it has no business processing. Get your coordinates from your GPS software, and be happy, then just import the end result.

My suspicion is that at least one is linked to a particular datum transformation.

> Arizona West Zone, Int. FT (or use HARN/AZ.AZ-WIF)
> HARN/AZ Arizona State Planes, West Zone, International Foot
> NAD83 Arizona State Planes, West Zone, International Foot

#2 is probably set up to automatically use the Arizona HARN grid file if a request is made to convert to/from HARN from NAD83 (the 1986 version).

The HARN/AZ.AZ-WIF name comes from a definition file. I was able to find an earlier version online via Google, so you might dig around in the install to see if you can find it. The version I found was a csv file. Mentor software was mentioned so the different names could be from merging two software packages--like the original AutoCAD name and a different naming convention from the Mentor software.

B-Man,

Street Slang typically uses, say, 20 different names for the same vulgar act. But at least everybody understands that the different names are just to throw some style into our language, and not to name 20 fine distinctions.

What I'd like to KNOW is if those different names are in fact different coordinate systems. They might be for the different versions of NAD83, and that would be important to know.

Dave

Wayne,

"I would back up, take a breath, and never use any 3rd party software (auto crud for example) to process anything it has no business processing. Get your coordinates from your GPS software, and be happy, then just import the end result."

Not my style. I'm more of a "never give up, never surrender" type of guy. I mean to understand this if I have to knock on the door of Autodesk's CEO.

Dave

I'm with mkennedy. the underlying transformation (grid files) may differ from one system to the other. If you use the same one every time, probably not an issue, but using them interchangeably may result in some issues.

Melita,

"My suspicion is that at least one is linked to a particular datum transformation."

I think you're right. But how do you check a transformation without completely re-inventing the wheel? (Those calcs are tough!) I don't have a clue where to look to find a definition file.

Dave

I Found A Definition File

Melita,

OK, I found one definition Here:

PROJCS["NAD83(HARN) / Arizona West",
GEOGCS["NAD83(HARN)",
DATUM["NAD83_High_Accuracy_Reference_Network",
SPHEROID["GRS 1980",6378137,298.257222101,
AUTHORITY["EPSG",7019]],
TOWGS84[0,0,0,0,0,0,0],
AUTHORITY["EPSG",6152]],
PRIMEM["Greenwich",0,
AUTHORITY["EPSG",8901]],
UNIT["degree",0.0174532925199433,
AUTHORITY["EPSG",9122]],
AUTHORITY["EPSG",4152]],
PROJECTION[Transverse_Mercator],
PARAMETER[latitude_of_origin,31],
PARAMETER[central_meridian,-113.75],
PARAMETER[scale_factor,0.999933333],
PARAMETER[false_easting,213360],
PARAMETER[false_northing,0],
UNIT["metre",1,
AUTHORITY["EPSG",9001]],
AXIS[X,EAST],
AXIS[Y,NORTH],
AUTHORITY["EPSG",2763]]

Dave

I Found A Definition File

A lot of software packages that support datum transformations will set a default transformation to a particular geographic coordinate reference system (datum) and/or projected coordinate system (really linked to the underlying GeoCRS). Some that do this also set up transformations to convert to/from WGS84. In the definition that you posted, the relevant bit is this:

TOWGS84[0,0,0,0,0,0,0]

It's a 7 parameter Bursa-Wolf / position vector transformation (3 translations, 3 rotations, scale difference based on 3D geocentric / XYZ coordinates). Since all the parameters are zeroes, it's a null transformation.

There could still be transformation handling occurring at a 'higher' level. For instance, you use this definition but then decide to reproject the data to a NAD27-based state plane zone. The software will probably use NADCON or allow you to pick NADCON as the method of conversion.

EDIT UPDATE: To test what a software package is doing, you find another package and see if you can get them to match. For instance, use CORPSCON or the NGS converters. If the test results don't match, try to break down the operations into each component. For instance, if I was converting between NAD27 California 5 and NAD83 HARN California 5, I would try

NAD27 California 5 to NAD27 (inverse projection)
NAD27 to NAD83 using NADCON (transformation)
NAD83 to HARN using the appropriate CA HARN grid
NAD83 HARN to NAD83 HARN California 5

Melita

I Found A Definition File

The csv file I was referring to previously is here, and dated 2008, so it's relatively old in software terms! Here's one of its definitions:

CS_NAME: AZ83-WIF
        DESC_NM: NAD83 Arizona State Planes, West Zone, International Foot
          GROUP: SPCS83I
         SOURCE: Calculated from AZ83-W by Mentor Software
           EPSG: 2224
           SRID: 2224
        DT_NAME: NAD83
           PROJ: TM
           UNIT: IFOOT
          PARM1: -113.75
        SCL_RED: 0.999933333333333        # calculates to 1:15000
        ORG_LAT: 31.0
          X_OFF: 700000.0
          Y_OFF: 0.0
        EPSG_QD: 1
        MAP_SCL: 1.0

To my eye, there's no obvious link to a default transformation.

I hadn't noticed, David, that the definition you quoted is from http://www.epsg.io. That's an academic website based from the EPSG Geodetic Parameter Registry.

Disclosure: I'm on the subcommittee that manages this registry.

Melita

I Found A Definition File

Melita,

"...find another package and see if you can get them to match."

Thank you. That sounds much easier than spherical trigonometry and charts and tables.

Dave

I Found A Definition File

The library of coordinate systems available within Civil3d is actually part of the ACad Map system that Civil3d is built on. The MAPCSLIBRARY command will open up this library and allows you to see all of the detailed information about each one. You can also copy and edit these definitions.

One of the other details that is available through this dialog is the EPSG code for each system. I have started to include that code number in brackets whenever I make reference to the coordinate system in my drawing notes etc. This helps to ensure that others can determine which system I'm using. For example if you google EPSG 3157 you'll find information about the particular flavour of UTM coordinates I'm using.