Convert UTM to SPC?

corpscon will do it

Just Google ngs toolkit and you'll be all set.

Sent from my SM-G900P using Tapatalk

Start a project in TBC with the correct UTM zone then import the points. After they are imported change the coordinate system to the correct SPC zone and it should convert them to the zone.

This will get UTM to Lats/Longs

http://www.ngs.noaa.gov/TOOLS/utm.shtml

Then this will get you from Lats/Longs to SPC

http://www.ngs.noaa.gov/cgi-bin/spc_getpc.prl

This will be a tedious process if you have more than a couple points to convert so one of the other software solutions will probably be better.

I would convert in TBC as noted above. Corpcon will work but may give a bogus scale factor (if you need one). Civil 3D is still unpredictable when switching coordinate systems...

Thanks all. I tried to use TBC like you all described above before posting this question. It kept giving me an error about elevations (I was not provided with elevations, so I keyed in a ballpark number).

I even looked at Corpscon before posting and just overlooked the UTM option. I ended up using the NGS tools this time. I will keep trying with TBC because that was my original idea.

Thanks again!

thebionicman, post: 362374, member: 8136 wrote: Corpcon will work but may give a bogus scale factor

I think in a thread last year we demonstrated that Corpscon 6 gives the correct factor if and only if the output is chosen to be NAVD88. Do you have other evidence on the topic?

corpscon

there must be a Geoid naming issue somewhere, cause TBC is the really simple way to do it

The UTM points have to have some kind of elevation on them before thy can be converted to LLh in TBC. I just did this on tens of thousands of points, the steps to follow are:

• Put a reasonable elevation on the points
• Set up a TBC project with UTM zone, NAD83 as underlying datum, and a geoid model
• Import the points, then export them back out as LLh (make sure you pay attention to the format)
• Create a new TBC project with US State Plane 83 and the same geoid model
• Use the Test function in the Import Format editor and bring in the LLh point file, ensuring that it's being read correctly.
• Export the points to PNEZ or whatever

You can't just import the points to a UTM project and then change the coordinate system, because all the point records will still be UTM numbers.

Lee D, post: 362503, member: 7971 wrote: The UTM points have to have some kind of elevation on them before thy can be converted to LLh in TBC. I just did this on tens of thousands of points, the steps to follow are:

• Put a reasonable elevation on the points
• Set up a TBC project with UTM zone, NAD83 as underlying datum, and a geoid model
• Import the points, then export them back out as LLh (make sure you pay attention to the format)
• Create a new TBC project with US State Plane 83 and the same geoid model
• Use the Test function in the Import Format editor and bring in the LLh point file, ensuring that it's being read correctly.
• Export the points to PNEZ or whatever

You can't just import the points to a UTM project and then change the coordinate system, because all the point records will still be UTM numbers.

That's weird!

UTM (and SPC for that matter), can (or should) be easily computed [back and forth to LL] with or without an Ellipsoid Height, OR with an Ellipsoid Height of ZERO. I don't understand WHY TBC wants the additional data (height). Obviously an Ellipsoid Height is required to go from LLH to [geocentric] XYZ, but that's another issue.

:-S
Loyal

You could use zero it probably wouldn't matter. You just need some value so that TBC can convert UTM to LLh. I just always try to use something reasonably correct.

In TBC, you can transform your points under the Project Settings > Coordinate System > Datum Transformation and clicking Change. I haven't tested to see how accurate it is but for the purpose of exbert's needs, it should be more than adequate.

And yes, TBC won't do anything without a height. I insert something around the rough project height. It's pretty simple with a CSV in Excel.

Again, you can just change the coordinate system for SURVEY DATA that is based on geodetic coordinates. But imported grid points have coordinate records only; changing the coordinate system won't work.

Just to be clear...you cannot go directly from UTC to SPC, you must first go to lat/long. Corpscon disguises this extra step, and is the way I would do it.

In TBC you can go directly from UTC to lat/long IF you're talking about points that were surveyed with GPS and IF the coordinate records are all Global or Local (not Grid). But that's because you're already dealing with points that have LLh as their basis.

For me it was easier to use TBC because I use it every day, I never use Corpscon, and I was dealing with tens of thousands of points.

Lee D, post: 362563, member: 7971 wrote: You could use zero it probably wouldn't matter.

That's correct, it wouldn't matter, if the software does what it should do. In fact, that would be a good test of the math implemented in the software; do two calculations with the same lat/lon but with different elevations.

Having to enter an elevation is not a bad thing because it does give you pause to consider exactly what you're doing.

Theoretically I guess you wouldn't need an elevation at all to go UTM to SPC; I just assumed that because TBC works in ECEF Cartesian that it would want an ellipsoid height, if I get some time I may test that. The points I converted were all survey points so they had elevations on them.

The method I described is not changing the coordinate system. It's a transformation. I just checked it against Corpscon. I imported a CSV (number, northing, easting, elevation), not a job file, into a blank TBC project using UTM 17N and used the datum transformation to PA South. I picked a few points from the same CSV and converted them in Corpscon. The same to the thousandth. Am I missing something?