Transformation Tab - tragic mess?

[Sinc]

Visitors to the Swamp may be familiar with my attempts to use the Transformation tab in Civil-3D. I'm just curious if anyone here has been able to actually use the thing. My discoveries are that the whole thing is a mess.

First off, I am assuming this is the tab that is designed to help convert between the Coordinate Zone (e.g., State Plane Coordinate System) and Project or Ground coordinates. The documentation is quite sparse, but I get this impression from some of the various settings - i.e., an Elevation and Grid scale factor, etc. However, as far as I've been able to tell, the whole thing is improperly implemented.

Let me start at the beginning, and define a few terms, so we're all on the same page. In particular, the difference betweeen Grid, Ground, and Project coordinates. Grid coordinates are coordinates that use the Coordinate Zone specified in the Drawing Settings - e.g., a State Plane Coordinate System (SPCS). Ground Coordinates are the coordinates arrived at by dividing the Grid Coordinates by both the Grid and Elevation scale factors for that point, and every point in a project may potentially have different Grid and Elevation scale factors. Project Coordinates are arrived at by creating a "combined scale factor" from the average Grid and Elevation scale factors for the entire site, and dividing the Grid Coordinates by this combined scale factor.

For any given project, it may be useful to convert between Grid and Ground, or it may be useful to convert between Grid and Project. But in any given project, we would only ever do one of those. We would never come up with both Ground and Project coordinates for the same point. Either this project has a combined scale factor and we are using Grid and Project coordinates, or it works the way the SPCS was originally intended, with potentially a different scale factor for every point, depending on its location and elevation, and we are using Grid and Ground coordinates. So sometimes it is useful to just refer to "Local Coordinates", which may be either Ground or Project coordinates, depending on the project.

Now to get back to the Transformation tab. Let's start with the Elevation Scale Factor. First off, when I turn that on, I see that my points get a "Grid Northing" and "Grid Easting" that is basically the "Northing" and "Easting" multiplied by some scale factor. From the direction of the transformation, it appears that the "Grid Northing" and "Grid Easting" are my Grid coordinates, and the "Northing" and "Easting" are my Local coordinates (either Ground or Project). However, Latitude and Longitude are evidently being calculated from the Northing and Easting, aka the Local Coordinates. This is incorrect - Lat and Long should be calculated from the Grid Coordinates. So we already have one error.

Now lets look at what this Elevation Factor is really doing. The Help says that it "relates the distances on the geoid to the distances on the ellipsoid." Well, they lost me - conversion between Geoid and Ellipsoid only occurs when reducing GPS observation data, and is not applicable here. But I think they just used the wrong term - I think they meant to say "Ground surface" or "Topographic surface" or "Surface of the Earth" instead of "Geoid". Improper terminology in the help doesn't make this stuff any clearer, but in the grand scheme of things, we can overlook that, because there is far worse on the horizon...

There is an option on the Transformation tab for keying in the default elevation. Great, I think, this appears to be the setting for when I'm using Project Coordinates, and I can key in the average elevation of my Site here. But when I do that, I get elevation corrections that are far larger than any elevation correction I've ever seen. It is not the correct value. And keying in 0 for this elevation would logically result in no elevation correction, since my SPCS is set at roughly sea level. But I still get a rather large elevation scale factor applied. Basically, this option appears to calculate the wrong value, and it cannot be used.

As for using the SPCS the way it was originally intended, with a different elevation scale factor for every point? Well, that appears to be completely missing from Civil-3D, and is not even an option.

OK, so the Elevation Scale Factor is completely useless. How about the Grid Scale Factor?

Well, again, this seems to treat the Northing and Easting as Local Coordinates, while the Grid Coordinates go into the Grid Northing and Grid Easting. However, again, that means the Lat and Long are being incorrectly calculated. So we can key in the INVERSE of our grid scale factor here, and everything is OK. Now, though, the Northing and Easting are the Grid Coordinates, and Grid Northing and Grid Easting are Local coordinates, which is a bit confusing. But this appears to be the only conditions under which this tab even remotely starts to return the correct values. And instead of using the Grid Scale Factor in this field, we can actually just turn off the Elevation Scale Factor (which doesn't seem to work, anyway), and key in the inverse of the Combined Scale Factor in this field. This gives us Grid coordinates in the points' Northing and Easting, and Project Coordinates in the Grid Northing and Grid Easting. There is still something to be desired, though, as there does not appear to be any way to inverse between the Project Coordinates and get a Ground Distance, or any way to label a Ground Distance on the plans, or anything. So having these Project Coordinates in the drawing is somewhat useless, but at least they are correct. And you can always create a csv export of your points with their ground coordinates, should you want to. And, for projects that use Project Coordinates, you can use this option to import Project Coordinates, and automatically scale them to fit the Grid linework in the drawing. Of course, if you are using the SPCS in the way it was originally intended, it would be incorrect to try to use this option to convert between "ground" and SPCS coordinates, so you can get yourself into trouble, but there is some limited application if you are using Project Coordinates.

Unfortunately, once again, the Grid Scale Factor does not appear to have an option that allows us to use the SPCS the way it was intended. In the SPCS, the grid scale factor is a function of either the Latitude or Longitude of the point, depending on which type of projection was used to create the SPCS. This option also appears to be completely missing from Civil-3D. Basically, Civil-3D doesn't seem to understand what's going on with the SPCS.

However, there ARE a few other option on this tab, but they seem to be completely worthless. For example, there is a "Computation" method. The first option - unity - should really not be there. It is the equivalent of turning off the Grid Scale Factor, so for consistency, there should be a checkbox for turning off the grid scale factor, just like there is for the elevation scale factor. A computation method of "unity" is unnecessarily obtuse. But that's a minor thing. The next method, "User-Defined", is useful for when we want to use Project Coordinates. The next two, however, I have not been able to make heads nor tails out of. "Reference Point" makes no sense. And the "Prismoidal Formula" is the RECOMMENDED option, according to the Help, but I can't even figure out what it's supposed to be used for. When I look in the help, I see the formula for converting between Grid distances and Geodetic distances. This formula has no place at all in coordinate tranformations! Why is it even an option, let alone the "recommended" option? And of course, the option we need for using the SPCS the way it is intended - which would probably be something like "Use Coordinate System", since the factor is a function of the way the SPCS was created, in conjunction with the Lat or Long of the point in question - well, that option doesn't exist.

And of course, I haven't even mentioned that, once again, we get hit by the BIG problem (possibly the BIGGEST) that plagues Civil-3D in many, many, many places - the lack of a Project. Right now, the Coordinate System is set in the Drawing Settings, as well as the Survey Database Settings. When we create a new drawing, it takes on the coordinate system from our template. Well, we happen to live in a place where we work in two different coordinate zones, with basically half of our projects in each zone, so we have a problem. We SHOULD be able to create a new Project in C3D, and BEFORE we create any drawings or survey databases in the project, we should be able to specify project-wide settings such as Coordinate Zone, and whether we want to do this project with a combined scale factor or using SPCS coordinates the way they were intended, and a slew of other settings from Standards (in C3D, this mostly amounts to which template(s) should be available for starting new drawings) to Name of the Client. Instead, every time we create a drawing, we must stop and think "OK, what coordinate system is this drawing supposed to be in?" And if someone ever forgets to set the Coordinate Zone properly, we might have trouble. Probably not a lot of trouble right now, anyway, because this setting doesn't seem to be used for much in C3D except for sun angles and conversion from Northing/Easting to Lat/Long. But still, it seems to be asking for trouble if we end up with projects where some drawings say we're in one zone, and some drawings say we're in another zone.

This last point will become tragically important if Autodesk ever implements Grid coordinate systems properly. By rights, we should be able to create two different inverse values. When we inverse between any two points, we should be able to inverse either between the Grid coordinates, or the Local coordinates. When inversing between Local coordinates, everything is "normal", returning the distance we would measure if we physically went ou there with a tape measure or EDM. However, when inversing between Grid coordinates, we should be using that "Prismoidal Formula" mentioned earlier. This difference has significant impact throughout Civil-3D, especially when we consider that a project may be designed in either Grid Coordinates or Project Coordinates.

I'm guessing that this issue has caused little concern so far because the SPCS is still so widely-misunderstood, even among professional Surveyors and Engineers. Similarly, it appears to me that Civil-3D has it completely mixed up, to the point where there will be many serious repurcussions if/when it is fixed. But now that GPS is getting more-common, and the size of projects is getting larger and larger, it will become more and more important that people understand and properly-utilize the SPCS, and the SPCS and similar systems will start to be used more and more. I do not think it is an option to ignore this problem, and it MUST be fixed. If not, I expect this issue will start to crop up more and more in the coming years, creating more and more problems, until we hit the point where there is SO MUCH pressure to fix it, that Autodesk will be forced to. And the longer this fix is postponed, the worse it will be.

[Anonymous]

Sinc:

Good luck on getting to the bottom of this. Hopefully someone will respond
in some matter. The only thing that I have ever heard of in regard to the
Prismoidal Formula was in calculating volumes, normally earth excavation.

Bill


wrote in message news:5813163@discussion.autodesk.com...
Visitors to the Swamp may be familiar with my attempts to use the
Transformation tab in Civil-3D. I'm just curious if anyone here has been
able to actually use the thing. My discoveries are that the whole thing is
a mess.

[Anonymous]

This post is long overdue. I’ve been under the impression that the weird implementation of coordinate systems had something to do with the way things were done in America, but obviously this is not so.

In different countries things are done differently. From my working experience in South Africa, Germany, the United Arab Emirates and Australia, Civil3D’s implementation or functionality fits none of these systems properly.

South Africa: The System used is a Gauss Conform System, every odd line of longitude is the origin of a coordinate system. This means the projection scale factor is never really that large, is of opposite sign to the sea level correction and is simply taken care of by applying scale factors to the field measurements and calculating in the projection system direct, this is the only coordinate system used. Some high precision large sites like power stations one would set up a local system, but this is rare, the scale factor is lot large enough to materially affect volumes and quantities. So generally there would only be one coordinate system in use. In this scenario, the Civil3D system is a bit useless as one cannot display the grid coordinates in the status bar or use them directly in cad functions, so I would use the Northings and Eastings (Y,X), completely ignoring the transformation tab functionality. With GPS surveys I normally did a site calibration.

Germany: The Gauss Krueger coordinate systems are 3 degrees wide, but because of the higher latitudes the systems are no larger, and the scale factor hence is also not an issue. Local systems are used simply because the cadastral surveys all local. But similar conditions would apply as with South Africa.

The United Arab Emirates gets too hot to think straight.

Australia: Here we have the 6 degree wide UTM system, which has large scale factors approaching 400ppm or 400mm per km in the centre and on the edges, rapidly increasing if you stray any distance over the edge. This means that generally one is forced to work in a local system to keep some reasonable relationship between calculations and what’s on the ground. All I’ve use the transformation tab for really is the set up a conversion between GPS measured data and my calculations. It is not feasible again to work with the Grid Northings and Eastings as an “active” or “current” system because they don’t display in the status bar, and the move and copy functions for example don’t access these (or only in a tedious way).

I have never applied elevation scales as we are pretty close to sea level. I did once turn it on with elevation at zero, got a nonsense result and switched it of quickly. Sinc is right, the calculations are bull, and the result is it gives me a constant uneasy feeling about the reliability of the rest of the transformation computations. Unprofessional, Autodesk, really unprofessional.

After doing heaps of check calculations I now understand what using a reference point to calculate a scale factor for the site does. I think this function is OK, but the actual scale factor computed or applied by Civil3D SHOULD BE CONFIRMED in this dialog instead of presenting a greyed out 1.0000000 (?!); and also which way it is being applied. The way it is now I have this doubt every time whether Civil3D is actually calculating the scale factor and applying it in the right way or is it just using unity, and end up every time grabbing another bit of software and checking the scale factor between inverses done in both systems, as a mistake with this scale factor from the start of a project is really bad news.

Sinc, I don’t quite follow that bit about the longitude and latitude being calculated from the local coordinates. I would think that Civil3D is deriving the conversion between the local Northings and Eastings to Grid Northings and Eastings from the reference point coordinates together with the scale and rotation settings, and deriving the Lon Lat values from the grid coordinates?

My single biggest problem is not being able to see the grid coordinates in the status bar and not having some way of making them “current” for the everyday copy, move and other commands that use coordinate input. One is basically being forced to work in a local system only, which makes setting up a projection datum of any sort a waste of time unless one needs the conversions for importing or exporting data. Using the transparent commands doesn’t accommodate scale entering coordinate differences, and setting up a UCS isn’t the answer because it cannot accommodate the elevation and projection scale factors rigorously and it is an unnecessary duplication that could lead to mistakes. Currently all design work can only be done in a “Local” system which can be set the same as a projection system, but then what’s the point? I took me a while to understand that the Northings and Eastings could only represent a local coordinate system, but that’s perhaps because I’m partially thtoopid.

We often have the problem where a design is given to us in “MGA Zone 56” coordinates, but the design engineers don’t understand that the control coordinates given to them are on a flat projected surface and not on the ground, and when the construction points are set out using the design coordinates, different distances would be measured on the ground. The easy way out is just to adopt one point on site as a datum and work around it with a scale factor of one in a “pseudo” projection system, and hope that no one else ever connects to the survey from another site. At the moment Civil3D contributes to the problem rather that addressing it.

The programming of the geodetic functions needs vetting by a competent geodesist, both for correctness of the actual calculations and the usefulness of the functions provided. Message was edited by: Hans Moller

[Anonymous]

Sinc
From the Transformation Tab help for sea level scale factor I get

"Specifies whether to apply the settings for curvature correction to survey data so that measured horizontal distances are reduced to the distances at the mean seal level (geodetic distances). "

Mean seal level: this is probably why the elevation corrections are coming out wrong. What level do seals swim in? I'll do some research....

[Anonymous]

Seeing the complexity that is introduced into a project when working with
grid coordinates, what is the incentive to build a project on a projected
coordinate system?

wrote in message news:5813163@discussion.autodesk.com...
Visitors to the Swamp may be familiar with my attempts to use the
Transformation tab in Civil-3D. I'm just curious if anyone here has been
able to actually use the thing. My discoveries are that the whole thing is
a mess.

First off, I am assuming this is the tab that is designed to help convert
between the Coordinate Zone (e.g., State Plane Coordinate System) and
Project or Ground coordinates. The documentation is quite sparse, but I get
this impression from some of the various settings - i.e., an Elevation and
Grid scale factor, etc. However, as far as I've been able to tell, the
whole thing is improperly implemented.

Let me start at the beginning, and define a few terms, so we're all on the
same page. In particular, the difference betweeen Grid, Ground, and Project
coordinates. Grid coordinates are coordinates that use the Coordinate Zone
specified in the Drawing Settings - e.g., a State Plane Coordinate System
(SPCS). Ground Coordinates are the coordinates arrived at by dividing the
Grid Coordinates by both the Grid and Elevation scale factors for that
point, and every point in a project may potentially have different Grid and
Elevation scale factors. Project Coordinates are arrived at by creating a
"combined scale factor" from the average Grid and Elevation scale factors
for the entire site, and dividing the Grid Coordinates by this combined
scale factor.

For any given project, it may be useful to convert between Grid and Ground,
or it may be useful to convert between Grid and Project. But in any given
project, we would only ever do one of those. We would never come up with
both Ground and Project coordinates for the same point. Either this project
has a combined scale factor and we are using Grid and Project coordinates,
or it works the way the SPCS was originally intended, with potentially a
different scale factor for every point, depending on its location and
elevation, and we are using Grid and Ground coordinates. So sometimes it is
useful to just refer to "Local Coordinates", which may be either Ground or
Project coordinates, depending on the project.

Now to get back to the Transformation tab. Let's start with the Elevation
Scale Factor. First off, when I turn that on, I see that my points get a
"Grid Northing" and "Grid Easting" that is basically the "Northing" and
"Easting" multiplied by some scale factor. From the direction of the
transformation, it appears that the "Grid Northing" and "Grid Easting" are
my Grid coordinates, and the "Northing" and "Easting" are my Local
coordinates (either Ground or Project). However, Latitude and Longitude are
evidently being calculated from the Northing and Easting, aka the Local
Coordinates. This is incorrect - Lat and Long should be calculated from the
Grid Coordinates. So we already have one error.

Now lets look at what this Elevation Factor is really doing. The Help says
that it "relates the distances on the geoid to the distances on the
ellipsoid." Well, they lost me - conversion between Geoid and Ellipsoid
only occurs when reducing GPS observation data, and is not applicable here.
But I think they just used the wrong term - I think they meant to say
"Ground surface" or "Topographic surface" or "Surface of the Earth" instead
of "Geoid". Improper terminology in the help doesn't make this stuff any
clearer, but in the grand scheme of things, we can overlook that, because
there is far worse on the horizon...

There is an option on the Transformation tab for keying in the default
elevation. Great, I think, this appears to be the setting for when I'm
using Project Coordinates, and I can key in the average elevation of my Site
here. But when I do that, I get elevation corrections that are far larger
than any elevation correction I've ever seen. It is not the correct value.
And keying in 0 for this elevation would logically result in no elevation
correction, since my SPCS is set at roughly sea level. But I still get a
rather large elevation scale factor applied. Basically, this option appears
to calculate the wrong value, and it cannot be used.

As for using the SPCS the way it was originally intended, with a different
elevation scale factor for every point? Well, that appears to be completely
missing from Civil-3D, and is not even an option.

OK, so the Elevation Scale Factor is completely useless. How about the Grid
Scale Factor?

Well, again, this seems to treat the Northing and Easting as Local
Coordinates, while the Grid Coordinates go into the Grid Northing and Grid
Easting. However, again, that means the Lat and Long are being incorrectly
calculated. So we can key in the INVERSE of our grid scale factor here, and
everything is OK. Now, though, the Northing and Easting are the Grid
Coordinates, and Grid Northing and Grid Easting are Local coordinates, which
is a bit confusing. But this appears to be the only conditions under which
this tab even remotely starts to return the correct values. And instead of
using the Grid Scale Factor in this field, we can actually just turn off the
Elevation Scale Factor (which doesn't seem to work, anyway), and key in the
inverse of the Combined Scale Factor in this field. This gives us Grid
coordinates in the points' Northing and Easting, and Project Coordinates in
the Grid Northing and Grid Easting. There is still something to be desired,
though, as there does not appear to be any way to inverse between the
Project Coordinates and get a Ground Distance, or any way to label a Ground
Distance on the plans, or anything. So having these Project Coordinates in
the drawing is somewhat useless, but at least they are correct. And you can
always create a csv export of your points with their ground coordinates,
should you want to. And, for projects that use Project Coordinates, you can
use this option to import Project Coordinates, and automatically scale them
to fit the Grid linework in the drawing. Of course, if you are using the
SPCS in the way it was originally intended, it would be incorrect to try to
use this option to convert between "ground" and SPCS coordinates, so you can
get yourself into trouble, but there is some limited application if you are
using Project Coordinates.

Unfortunately, once again, the Grid Scale Factor does not appear to have an
option that allows us to use the SPCS the way it was intended. In the SPCS,
the grid scale factor is a function of either the Latitude or Longitude of
the point, depending on which type of projection was used to create the
SPCS. This option also appears to be completely missing from Civil-3D.
Basically, Civil-3D doesn't seem to understand what's going on with the
SPCS.

However, there ARE a few other option on this tab, but they seem to be
completely worthless. For example, there is a "Computation" method. The
first option - unity - should really not be there. It is the equivalent of
turning off the Grid Scale Factor, so for consistency, there should be a
checkbox for turning off the grid scale factor, just like there is for the
elevation scale factor. A computation method of "unity" is unnecessarily
obtuse. But that's a minor thing. The next method, "User-Defined", is
useful for when we want to use Project Coordinates. The next two, however,
I have not been able to make heads nor tails out of. "Reference Point"
makes no sense. And the "Prismoidal Formula" is the RECOMMENDED option,
according to the Help, but I can't even figure out what it's supposed to be
used for. When I look in the help, I see the formula for converting between
Grid distances and Geodetic distances. This formula has no place at all in
coordinate tranformations! Why is it even an option, let alone the
"recommended" option? And of course, the option we need for using the SPCS
the way it is intended - which would probably be something like "Use
Coordinate System", since the factor is a function of the way the SPCS was
created, in conjunction with the Lat or Long of the point in question -
well, that option doesn't exist.

And of course, I haven't even mentioned that, once again, we get hit by the
BIG problem (possibly the BIGGEST) that plagues Civil-3D in many, many, many
places - the lack of a Project. Right now, the Coordinate System is set in
the Drawing Settings, as well as the Survey Database Settings. When we
create a new drawing, it takes on the coordinate system from our template.
Well, we happen to live in a place where we work in two different coordinate
zones, with basically half of our projects in each zone, so we have a
problem. We SHOULD be able to create a new Project in C3D, and BEFORE we
create any drawings or survey databases in the project, we should be able to
specify project-wide settings such as Coordinate Zone, and whether we want
to do this project with a combined scale factor or using SPCS coordinates
the way they were intended, and a slew of other settings from Standards (in
C3D, this mostly amounts to which template(s) should be available for
starting new drawings) to Name of the Client. Instead, every time we create
a drawing, we must stop and think "OK, what coordinate system is this
drawing supposed to be in?" And if someone ever forgets to set the
Coordinate Zone properly, we might have trouble. Probably not a lot of
trouble right now, anyway, because this setting doesn't seem to be used for
much in C3D except for sun angles and conversion from Northing/Easting to
Lat/Long. But still, it seems to be asking for trouble if we end up with
projects where some drawings say we're in one zone, and some drawings say
we're in another zone.

This last point will become tragically important if Autodesk ever implements
Grid coordinate systems properly. By rights, we should be able to create
two different inverse values. When we inverse between any two points, we
should be able to inverse either between the Grid coordinates, or the Local
coordinates. When inversing between Local coordinates, everything is
"normal", returning the distance we would measure if we physically went ou
there with a tape measure or EDM. However, when inversing between Grid
coordinates, we should be using that "Prismoidal Formula" mentioned earlier.
This difference has significant impact throughout Civil-3D, especially when
we consider that a project may be designed in either Grid Coordinates or
Project Coordinates.

I'm guessing that this issue has caused little concern so far because the
SPCS is still so widely-misunderstood, even among professional Surveyors and
Engineers. Similarly, it appears to me that Civil-3D has it completely
mixed up, to the point where there will be many serious repurcussions
if/when it is fixed. But now that GPS is getting more-common, and the size
of projects is getting larger and larger, it will become more and more
important that people understand and properly-utilize the SPCS, and the SPCS
and similar systems will start to be used more and more. I do not think it
is an option to ignore this problem, and it MUST be fixed. If not, I expect
this issue will start to crop up more and more in the coming years, creating
more and more problems, until we hit the point where there is SO MUCH
pressure to fix it, that Autodesk will be forced to. And the longer this
fix is postponed, the worse it will be.

[Sinc]

>> Seeing the complexity that is introduced into a project when working with grid coordinates, what is the incentive to build a project on a projected coordinate system?


Surveying on most projects takes advantage of the fact that, over short distances with small elevation changes, we can ignore the curvature of the Earth. However, on a long project such as a highway or long tunnel, or on a project that has a dramatic elevation difference from one side to the other, the actual shape of the Earth can become important. Thus the grid systems.

Designing in a grid system isn't actually any more complex, it just has ramifications, because the grid distance is not the same thing as the ground distance. Unfortunately, a lot of engineers who "design in grid" forget this fact, and we as surveyors have regularly needed to "clean up" after them when they mix things up.

The grid systems were designed in such a way that the grid coordinates can be treated much as if they were normal Cartesian coordinates on a grid. There are just a couple of additional complications, and they can be solved by simple arithmetic. The alternative would be to use Geodetic coordinates, and that would REALLY be a lot more complicated.

[Sinc]

>> Sinc, I don’t quite follow that bit about the longitude and latitude being calculated from the local coordinates. I would think that Civil3D is deriving the conversion between the local Northings and Eastings to Grid Northings and Eastings from the reference point coordinates together with the scale and rotation settings, and deriving the Lon Lat values from the grid coordinates?


Oh, yes, it does. That's a relief - at least that part is OK, then.

I think I got confused because I was looking at point values in Panorama. It appears that the values in Panorama do not update when changes are made to the Drawing Settings, so I think I just got the wrong impression. I was changing scale factors, but it wasn't changing the Lat Long, so I thought the Lat Long was tied to the local coordinates. Once I started forcing the Panorama to update, I saw the Lat Long is actually being calculated correctly.

And yes, I have verified that it is actually returning the correct Lat and Long, at least in the Colorado Central zone. But I can still not get the Elevation Scale Factor to return anything even remotely correct.

However, there are still all the other issues.

Since, for large projects, the design should be done using Grid Coordinates and Grid Distances, Civil-3D does not really support the use of State Plane at all, despite appearances. There is no way to use Grid Coordinates and Distances for creating alignments and profiles, and labeling distances, and so forth. And it doesn't really support a true grid-to-ground conversion on the Transformation tab, so there's no way to get the variable scale factors and use the SPCS in the way it was designed to be used.

[Sinc]

I think it's just another error.

The Elevation Scale Factor is actually used to get from the ground elevation down to the elevation of the Grid system, which is usually "mean sea level". However, I know of at least one SPCS that is located at 800 feet above sea level. This might just be another error in the documentation, or it might go deeper. No way to really tell, because this Elevation Scale Factor seems to return nonsense results, anyway.

[Anonymous]

In the old days a project was surveyed using conventional instruments that
inherently established project coordinates that were ground based. With the
GPS the instruments work in geodetic coordinates and transform them into
grid coordinates or whatever. Can't the software and hardware provide the
engineers with data in ground based coordinates? Forgive my ignorance as I
am not trained in surveying but it seems there should be a way to get around
the need to transform coordinates between grid and ground as they did in the
past.

wrote in message news:5813417@discussion.autodesk.com...
>> Seeing the complexity that is introduced into a project when working with
>> grid coordinates, what is the incentive to build a project on a projected
>> coordinate system?


Surveying on most projects takes advantage of the fact that, over short
distances with small elevation changes, we can ignore the curvature of the
Earth. However, on a long project such as a highway or long tunnel, or on a
project that has a dramatic elevation difference from one side to the other,
the actual shape of the Earth can become important. Thus the grid systems.

Designing in a grid system isn't actually any more complex, it just has
ramifications, because the grid distance is not the same thing as the ground
distance. Unfortunately, a lot of engineers who "design in grid" forget
this fact, and we as surveyors have regularly needed to "clean up" after
them when they mix things up.

The grid systems were designed in such a way that the grid coordinates can
be treated much as if they were normal Cartesian coordinates on a grid.
There are just a couple of additional complications, and they can be solved
by simple arithmetic. The alternative would be to use Geodetic coordinates,
and that would REALLY be a lot more complicated.

[Anonymous]

There is nothing to stop a surveyor setting up a local ground system for a site. The problem starts when connecting survey data over a large area. Life would be a lot simpler if the earth was flat, but it isn't, it isn't even a sphere or a perfect ellipsoid. If you want to do local setouts that's fine, if you want to eventually show your site on a map (GIS) you have a problem with a local system. Or when you do tunnel surveys as Sinc was trying to explain.

Establishing a coordinate system has little to do with the instruments used. In South Africa most surveys were established on a national grid since the late 1940s, long before GPS. The problem is in the choice of projection system, some are good for making 1:50000 or smaller scale maps, others are better for surveying to ground accuracy. Whatever you do you end up taking measurements off a curved surface and distorting them to fit on a flat surface so you can use coordinates to calculate data and do designs. If these distortions are large then the projection used is impractical and a bad choice. Unfortunately in many countries the choice was made for the sake of making maps, the need for mapping to ground accuracy for GIS is a more recent development. In South Africa the choice was based on the concept of having a continuous cadastral system, so a projection was chosen where the distortions are small enough on the ground to have minimal effect on everyday requirements. I don't know what happens in America, the Australian system is not the best choice, hence one has to set up local systems all the time to avoid working with large scale factors. This is not a problem and is normally "hidden" from clients, but clients (engineers) have to understand at some point that one cannot continue indefinitely from a datum point while keeping on assuming the earth is flat.

Putting data on a national coordinate system was too hard in the old days for both measurements and computations, thats why most work was done locally. These days its almost ridiculously easy in comparison, and therefore surveys tend to be done more rigorously with the aim that surveys over a widespread area can be fitted together, especially for ground accuracy GIS systems. Survey wise this introduces whole new concepts that a lot of people don't digest very well. Including Civil3D at the moment.

[Anonymous]

Civil3D at the moment is not set up at all so that projection coordinates or Grid coordinates can be used for design purposes. All design has to be done in "world coordinates", which is a local system that can be tied to a global coordinate system on a site by site basis. Took me a bit to come to that conclusion, I'll admit.

[Anonymous]

I just wanted to thank Sinc and Hans for the posts. There's quite a bit of
good info in both of your comments and I appreciate you posting them.

I've had some conversations with folks about how that tab should not be used
unless you fully understand the ramifications of doing so. Your info seems
to confirm that.

Quick thought on the overall subject: Is that tab actually more for just a
'plant grid' type scenario, and not really for full transformations? I
realize that there is much more implied, but maybe it just isn't fully
there. (Yeah, I know, that's another subject......didn't mean to start that
one.)

Thanks again to both of you for the posts.

wrote in message news:5813163@discussion.autodesk.com...
Visitors to the Swamp may be familiar with my attempts to use the
Transformation tab in Civil-3D. I'm just curious if anyone here has been
able to actually use the thing. My discoveries are that the whole thing is
a mess.

[Anonymous]

I guess my question was directed more toward the matter of using an
established coordinate system such as state plane vs using a local system
specific to the project. While using established systems makes it easier to
integrate data from various sources, it adds complexity to the project
system. I am thinking it is more prudent to work in a local system and
require all project data to be tranformed to the local system rather than
trying to transform the project into fit an established system. If there is
a need to add the project data to a mapping system whether internally or to
a client or service, that could be done externally. Just wondering what your
thinking is on this.

wrote in message news:5813591@discussion.autodesk.com...
There is nothing to stop a surveyor setting up a local ground system for a
site. The problem starts when connecting survey data over a large area. Life
would be a lot simpler if the earth was flat, but it isn't, it isn't even a
sphere or a perfect ellipsoid. If you want to do local setouts that's fine,
if you want to eventually show your site on a map (GIS) you have a problem
with a local system. Or when you do tunnel surveys as Sinc was trying to
explain.

Establishing a coordinate system has little to do with the instruments used.
In South Africa most surveys were established on a national grid since the
late 1940s, long before GPS. The problem is in the choice of projection
system, some are good for making 1:50000 or smaller scale maps, others are
better for surveying to ground accuracy. Whatever you do you end up taking
measurements off a curved surface and distorting them to fit on a flat
surface so you can use coordinates to calculate data and do designs. If
these distortions are large then the projection used is impractical and a
bad choice. Unfortunately in many countries the choice was made for the sake
of making maps, the need for mapping to ground accuracy for GIS is a more
recent development. In South Africa the choice was based on the concept of
having a continuous cadastral system, so a projection was chosen where the
distortions are small enough on the ground to have minimal effect on
everyday requirements. I don't know what happens in America, the Australian
system is not the best choice, hence one has to set up local systems all the
time to avoid working with large scale factors. This is not a problem and is
normally "hidden" from clients, but clients (engineers) have to understand
at some point that one cannot continue indefinitely from a datum point while
keeping on assuming the earth is flat.

Putting data on a national coordinate system was too hard in the old days
for both measurements and computations, thats why most work was done
locally. These days its almost ridiculously easy in comparison, and
therefore surveys tend to be done more rigorously with the aim that surveys
over a widespread area can be fitted together, especially for ground
accuracy GIS systems. Survey wise this introduces whole new concepts that a
lot of people don't digest very well. Including Civil3D at the moment.

[Sinc]

This topic is too complex to explain in a DG post.

I'm working on a white paper on the subject, and I'll post a link when it's done.

[Sinc]

Yep, that's the core failure that I'm trying to point out.

In order to use the grid systems in the way they were designed - as a way to coherently design a project that covers a large area of the Earth, but without the complexity of using Geodetic techniques - it MUST be possible to design in the Grid system.

OTOH, to use Project Coordinates - the usual preference unless the project is so large that a grid system is necessary - we must be able to design in the Local system.

This disconnect strikes to the very core of Civil-3D. And to a large extent, the problem also ties into the horrible design flaw called "the Vault". In order to really solve this problem, the engineers at Autodesk must stop mixing Project Management, Model Data Management, and Document Management into one problem that is only addressed "in the Vault".

[Anonymous]

A very interesting topic thanks to "sinc" and Hans. Should I hold my breath
while waiting for even an acknowledgement from one of the "deskers"?



Bill

[Sinc]

>> Quick thought on the overall subject: Is that tab actually more for just a 'plant grid' type scenario, and not really for full transformations?


I'm not sure I understand your question, because I'm not entirely sure what you mean by "plant grid scenario", but I think I understand... I'll try to answer, and let me know if I'm off-base...

I think a big part of the problem is that at least two, and probably three, different and unrelated tasks were all muddled together on this tab.

The first task is GPS data reduction. That's where the Geoid becomes important, and the ellipsoid height is important. That has absolutely nothing to do with any sort of coordinate transformation, but I think it's how the term "Geoid" got mixed-in with the documentation. We can completely ignore anything to do with GPS data reduction and ellipsoid height for the purposes of this tab.

The second is the conversion between Grid and Project coordinates, or between Grid and Ground coordinates. This is the apparent purpose of this tab, since it has things like "Elevation Scale Factor" in it. However, it only really works for those projects where you are using a combined scale factor to get between Project Coordinates and Grid. This tab does not support the Grid systems in the way they were designed - with a floating scale factor that is potentially different for every point in the project.

The third topic is that of coordinate transformation between two different local systems. This can also be thought of as the task performed by a "GPS Site Calibration". This is really a completely separate issue from converting between Grid and Project, or Grid and Ground, and should be handled completely separately. The fact that some aspects of this third function are also included on the Transformation tab is another indication of how badly this tab is improperly-designed.

[Anonymous]

I definitely should have thought about word choice on that one, particularly
given the subject. I was speaking of the third.

I think I'll make this thread required reading for anyone attempting
anything in the transformation tab.

wrote in message news:5813959@discussion.autodesk.com...
>> Quick thought on the overall subject: Is that tab actually more for just
>> a 'plant grid' type scenario, and not really for full transformations?

The third topic is that of coordinate transformation between two different
local systems. This can also be thought of as the task performed by a "GPS
Site Calibration". This is really a completely separate issue from
converting between Grid and Project, or Grid and Ground, and should be
handled completely separately. The fact that some aspects of this third
function are also included on the Transformation tab is another indication
of how badly this tab is improperly-designed.

[Sinc]

I suppose I should clarify something about that third option.

Converting between two local systems is something that frequently comes up when using Project Coordinates. It would not come up when using State Plane Coordinates in the way they were originally intended, but it comes up frequently when using a combined scale factor for calculating Project Coordinates.

The most-common application is to truncate the coordinate values, so they are shorter. For a couple of reasons, State Plane coordinates tend to be rather large. It is very common to truncate leading digits from the Project Coordinates, so what used to have seven digits before the decimal now has four or five.

This does two things. One, it makes it easier to deal with the coordinates. Long coordinates are annoying, and shorter ones are nicer. The other is that it makes it pretty much impossible to mix up the State Plane and Project coordinates. This adds some "safety factor" that helps prevent careless errors. (These shorter coordinates would be more-appropriately called the "Project Coordinates", so I should probably come up with some better terminology. But I don't want to confuse the issue, so I'll keep using the term "Project Coordinates" to mean the ones we get by dividing the Grid Coordinates by the combined scale factor.)

The other possible reason is that a site already has an assumed coordinate system, and we want to equate this alternate assumed system to the State Plane. In this case, we might have a Rotation parameter and a Translation parameter for converting between the "Project Coordinates" and this assumed system. We also may need a unit conversion parameter, if the two coordinate systems are not in the same units. But typically, all we need is a rotation parameter and translation parameter.

In any case, this later transformation only occurs between our Project Coordinates and our alternate assumed coordinate system. It does NOT occur between Grid and Project coordinates - we use the combined scale factor to get between those two values. And if we are using the State Plane Coordinate system in the way it was designed, with a floating scale factor, this sort of transformation does not even apply. Since the scale factor varies for every point in our project, we would not be able to take our Ground coordinates and apply any sort of sane transformation to them. But this should be OK, since if we are using State Plane Coordinates for our project, we also should not need to apply any sort of additional transformation to them.

[Anonymous]

Well, sinc, once again I want to sincerely thank you. You confirmed
something that has been troubling me for a couple of years and has nothing
at all to do with Civil3D. I don't deal with surveying on a daily basis
anymore, so I take it on faith that things are being handled properly. (I
have enough to worry about it.) Your posts in this thread are a huge help
to my sanity.

I'll be looking forward to your white paper. Please do post to this NG, if
possible, when it is done.

wrote in message news:5814293@discussion.autodesk.com...

The other possible reason is that a site already has an assumed coordinate
system, and we want to equate this alternate assumed system to the State
Plane. In this case, we might have a Rotation parameter and a Translation
parameter for converting between the "Project Coordinates" and this assumed
system. We also may need a unit conversion parameter, if the two coordinate
systems are not in the same units. But typically, all we need is a rotation
parameter and translation parameter.

In any case, this later transformation only occurs between our Project
Coordinates and our alternate assumed coordinate system. It does NOT occur
between Grid and Project coordinates - we use the combined scale factor to
get between those two values. And if we are using the State Plane
Coordinate system in the way it was designed, with a floating scale factor,
this sort of transformation does not even apply. Since the scale factor
varies for every point in our project, we would not be able to take our
Ground coordinates and apply any sort of sane transformation to them. But
this should be OK, since if we are using State Plane Coordinates for our
project, we also should not need to apply any sort of additional
transformation to them.