SP Coordinates

I read that the NGS is way ahead of you working on a "new datum" that mixes in LLH along with good elevations.

The simple answer to your question is that no one but us and the folks making it would understand it, and it's a fair assumption based on the amount of incorrect use I see with SPC, that we really don't get it. So you'd have a new system that most couldn't/wouldn't work in that would get mucked up even more once we factor in the 11 dimension. 🙂

It's going to have to get pretty damn good and user friendly before I leave NAD83. It's really easy for me but I stay on the grid, never on the ground. Everything ties together nicely but I'm blessed with working near zone lines so my scale factors most of the time are so small that they become inconsequential.

Same with me I stay on the grid and have about 0.1' per 2000', also I am so close to sea level that is not a problem.

I just get tired of hearing 'we use state plane ground coordinates" and then trying to explain there is no such thing.

I feel your pain. 🙂

Isn't the real root of the problem

.... that all (as far as I know) commercial surveying and engineering software uses a simple plane (two-dimension) inverse calculation to determine distance and azimuth on a three-dimensional world?

(rant_on)

That's mathematically impossible!

It is also pretty absurd when everyone now has on their desk (or possibly in their pocket) more computing power than was used on the first lunar landing!

If the software used a rigorous inverse calculation (considering the elevations, the dimensions of the earth, and the projection parameters used to produce the coordinates) the output could be an accurate distance (probably at average elevation of the two end points - not too difficult to integrate DEM information if necessary to follow the profile of the line) and azimuth at midpoint of the line.

I have always looked at this whole issue (scaled coordinates, low-distortion projections, etc.) as the tail wagging the dog - everyone tweaks around the coordinates so the (inadequate) calculation method used to determine distance and azimuth can produce results that are "close enough".

Seems software buyers should be asking the software publishers why the software doesn't utilize a rigorous calculation method.

(/rant_off)

GB

The NAD83 SPC (or UTM) “grid” (and the corresponding coordinates thereon), are NOT expressed at the same “elevation.” The ONLY places “on the grid” that have common heights, are the “lines of exact scale,” and ANY two (or more) points that have the SAME Scale Factor.

The NAD83 SPC (or UTM) “grid” (and the corresponding coordinates thereon), are NOT directly related to “sea level.” NAD83 SPC (and UTM) coordinates are based on the NAD83 Ellipsoid (GRS80), NOT any “level” (orthometric) surface.

NAD83 SPC (or UTM) coordinates that are “scaled” to some height above the defined developed surface, are (essentially) parallel to THAT surface, but NOT necessarily parallel with the surface of the Earth in that particular area.

“THE GRID” is a “developed surface” (Cone or cylinder although in reality, the cylinder is NOT a true [perfect] cylinder due to flattening). This developed surface can then be “laid out flat” (so to speak) so that plane trigonometric functions/calculations can be utilized when manipulating the “grid coordinates.”

As far as a “standard XYZT” system goes, we already have several. NAD83 and ITRF. Out here in my neck of the woods, such a coordinate might look something like:

ITRF2005(SOPAC)
Epoch 2011.2491
X -1849361.38897 +0.000007555
Y -4498433.63173 +0.000002649 +0.000013560
Z +4114802.08816 -0.000001624 -0.000001864 +0.000013644

BTW, I posted a picture of this observation back in April.

Like Glenn stated (ranted) above, from there you can do whatever blows yer skirt up, SUBJECT of course to the limitations of the fancy software that you payed through the nose for!

Well...that's my rant for the day, time for a beer!
Loyal

Isn't the real root of the problem

> I have always looked at this whole issue (scaled coordinates, low-distortion projections, etc.) as the tail wagging the dog - everyone tweaks around the coordinates so the (inadequate) calculation method used to determine distance and azimuth can produce results that are "close enough".

This part of your rant triggered one in me.. 🙂

Suffice it to say that LDPs are NOT the same thing as the scaled coordinates stuff, nor are they an "inadequate" calculation method. In fact, they use EXACTLY the same sort of mathematics as State Plane systems.

GOOD point Richard

I missed that "LDP" reference.

The IS a big difference!

Not only that, a properly MAINTAINED LDP, does NOT [necessarily] move around as a function of TIME or realization changes to NAD83, and SPC/UTM Coordinates DO. Hmmmm, that was a bit of an oversimplification, but essentually true.

Loyal

You don't have a clue do you?

Scale factors are applied to distances. They are NOT applied to coordinates.

You NEVER multiply the coordinate by the scale factor.

There are an infinate number of points that have the same X,Y values and the Z values change. You can have the same X,Y at the elipsoid (probably underground), at the ground surface, or 1000' in the air. It is because of this that you need to apply a scale factor to distances to accomodate height differences and different locations within the grid - or distance from the lines of exact scale.

I highly recommend a look at a sneak preview of what the Oregon DOT is doing:

Oregon Coordinate System proposal

Based upon the excellent work of Michael Dennis, it is one of many documents avaialble by a Google search that illustrates the benfits of an LDP.

They are not difficult to set up and solve a myriad of data exchange problems when 'reluctant geodesists' are involved.

> I highly recommend a look at a sneak preview of what the Oregon DOT is doing:

I have set up the "Portland" LDP zone in my TSC2 and performed jobs with it. RTK yields coordinates with scale factors so small that they can be ignored. I've also set up Star*Net with the LDP zones, no problem. Works great.

Richard

I did not say that there was anything lacking in the math used to generate coordinates via low-distortion projections - my suggestion of calculational inadequacy pertains to the methods customarily used to determine distances and directions between points defined by coordinates, regardless of the projection used.

We all agree that the low-distortion projections use rigorous mathematics to generate coordinates. Every geodetic-software package I have seen allows users to define custom projections that use good and proper math to generate grid coordinates (using "grid" to refer to the projection surface defined by the projection parameters being used by the low-distortion projection or whatever projection is being employed - not as shorthand to always refer to a statutory State Plane / UTM / whatever projection usually secant to the ellipsoid).

But ultimately you are still projecting the three-dimensional world onto a two-dimension grid surface and settling for "good enough". If the low-distortion projections solved all the problems they could be called "zero-distortion" projections, which they are not and never will be.

The projection surface of a low-distortion projection is close in elevation to ground elevation in the area of interest and likely the projection origin is closer horizontally to the area of interest so the scaling and rotation are (usually) less than with the published and/or statutory projections.

The problem comes from the software used to determine the distance and direction between the points described by those coordinates.

If the software (not the geodetic software but the software that annotates the lines on a plat, for instance) uses the oversimplified plane inverse to determine the distances and directions between points, then you will always have a scaling difference due to elevation change and location of the points within the projection. You will also have the convergence issue, which is mainly a function of the latitude and the east-west distance from the meridian of the projection origin. This is fine as long as you remember that the lines are annotated with grid distances and directions (remembering that "grid" refers to the projection surface of whatever projection is being used - not necessarily the State Plane / UTM projection).

Sure, you can then add a little scaling and maybe a little rotation, but ultimately it all ends up with someone determining that it is "close enough".

If there is some commercial software that does a rigorous three-dimensional inverse, I have not seen it and would like to know what it is.

There have been some routines from the BLM (such as CSTUF utility in the Cadastral Measurement Management package) that do a rigorous 3-D inverse, so mayhaps some commercial software publisher has produced something similar, I dunno.

BTW, (as Earl Burkholder has been suggesting for the past couple of decades or so) when working with ECEF (earth-centered earth-fixed) coordinates like the ones Loyal offers below, it is trivial to calculate an accurate three-dimensional distance between two points - all you do to get the slope distance is take the square root of the sum of delta_X_squared plus delta_Y_squared plus delta_Z_squared. Then that slope distance can be converted to a horizontal distance as needed.

To do the same using projected grid coordinates you should at least acknowledge that except in special cases the grid scale factor of a line is constantly changing as you move across the projection surface. Add to this the likely factor of elevation change. So in almost every case the combined scale factor of the two points will be different. One "good enough" simplification is to average the combined scale factors of the two points and apply that factor to the 2-D inversed distance. Or, to be a little more accurate, some NGS publications recommend adding up the scale factors of the two points along with the scale factor of the line's midpoint and dividing that all by six. Maybe little better but still a compromise.

GB

Richard

I suppose the biggest problem I have with what you are saying is that things like ECEF coordinates and a rigorous 3D inverse in such a system generally mean far less to us humans than something like a grid projection. A bearing and distance mean far more to us humans than an ECEF vector, and the distortion in our grid projection is generally either irrelevant or can be corrected for.

For some tasks, a grid projection may not be appropriate, and we may instead use a cadastral Lat/Long/Elev sort of system. But such a system involves much more complex math, and for most work, we can get by just fine using a grid projection. In general, I'd view the grid projection as preferable to a cadastral system, and a cadastral system preferable to an ECEF system.

It would drive me crazy if my equipment tried to talk to me in ECEF terms, instead of terms I understand.

Thanks, it's going to take awhile to read but it looks like a real nice job by the guys that wrote it. I wonder if anyone in Texas is working on something similiar?

You don't have a clue do you?

Thanks Dave

I'm sure that is a problem where you work but I would have to drive 100 miles to get 100 feet of elevation change so not too big a concern for me.

I also know concrete shrinks when cured but I still layout a proposed 30' wide pavement 30' from bc to bc.

Dave

"Scale factors are applied to distances. They are NOT applied to coordinates."

You obviously never worked on a UDOT project (that's how they do it).

REGARDLESS or whether or not you apply the CAF (Combined Average Factor) to the coordinates OR the distances, you still end up with CRAP! Some of the CRAP is more readily identifiable as CRAP than the other CRAP, but it's still CRAP!

Reminds me of the adage about polishing turds...

I have stated REPEATEDLY that IF [true] SPC (or UTM)coordinates (AND distances) ain't git'n it done for ya, then you SHOULDN'T be using them in the first place.

🙂
Loyal

Richard - I believe we're on the same page

ECEF coordinates don't mean a durn thing to me either, but my computer loves 'em!

I agree completely that a well-suited projection and simple plane inversing is completely sufficient for most work, especially computationally intense tasks such as road design, etc.

The problem comes when you try to figure out how far to stretch that compromise.

A city lot? No problem - no one will ever find the difference, or even suspect that it exists.

A thirty-acre subdivision? Who will ever look for it?

How about an entire township? We all know townships that have thousands of feet of elevation change, so maybe we need to do something different. May even want to do something better even with just a couple hundred feet of elevation change because then the "distortion" is getting up to around 10 ppm.

And what about the bearings for that township? Say you're at 47 degrees north in central Montana - the convergence at that latitude changes about 56 arc seconds per mile east-west. It hardly seems right to be ignoring almost an arc minute per mile east-west, especially if you're annotating bearings to the arc second.

Sure, the math is more complex for a rigorous solution. But isn't that what computers are for? They can do it without breaking a sweat!

And, best of all, if the calculation is done in a rigorous manner one won't have to determine if the "distortion" is irrelevant - it won't be there!

I looked over the Oregon Coordinate Reference System information mentioned below by Scott Partridge, and it appears that their distance criterion is 10 ppm (1:100,000). I did not see any discussion of directions, which is fine. A few arc minutes of missed convergence will never make any difference on a road design, except when someone notices that the project bearings do not jive with the PLSS bearings. I suppose the right-of-way folks can handle that.

Remember, even though your GPS equipment does not talk to you in ECEF coordinates, that is what it is using as it does its work. When GPS has something to show us, in most situations it gracefully provides the information in lat/long or northing/easting.

What I am suggesting is similar - simply a calculation method that would accept eastings, northings, and elevations; do its calculations in a rigorous process considering the projection parameters used to produce the eastings and northings; and return distances and bearings that accurately reflect the 3-D world. What it uses in between (maybe even ECEF coordinates) would not have to ever appear to the user, just like you never see the ECEF coordinates your GPS uses every second it operates.

Maybe Jerry Wahl will chime in on this, he was one of the authors of Geodetic Aspects of Land Boundaries and the PLSS Datum that includes some great information.

GB

It isn't magic, though

It seems to me that that the colored maps of scale distortion in that Oregon publication Scott linked above are pretty much designed to deceptively present the results. They show the LDP to be more of a cheap trick than practical magic.

If you look at the huge blue areas as really equivalent to the red, i.e. the parts of the mapping area where the absolute value of scale distortion is greater than 50 ppm, the picture tells the story. Every other part of the map is colored by range of absolute value aside from those where the distortion is larger in absolute value than 50 ppm.

It's only in the small, green "islands" that scale distortion is held to less than 20 ppm, which seems a pretty thin accomplishment. Obviously, the Low Distortion Projections are pretty much Nearly Level Terrain Projections.

Glenn

I agree with you pretty much 100%

In fact, I think the new BLM Manual (2009) talks about the “PLSS Datum,” which for all practical purposes is pretty much what you are driving at.

The PROBLEM is simply that “True” (Geodetic) Bearings, and “True” Distances (at the mean elevation of the ends of EACH line) DON'T “close” the figure in any commercial software that I have ever seen (which you clearly stated in you first post).

Like you are saying, there ISN'T ANY fricking reason for this BS limitation in software that costs THOUSANDS of dollars to buy, and THOUSANDS MORE to maintain (current versions of).

Unfortunately, it's going to take MORE than just better software, it is going to REQUIRE more education and/or understanding for Surveyors, Engineers, GIS'ers, and the legal community in general. It is ALSO going to REQUIRE heights (ellipsoidal or orthometric) on EVERY “point.” That isn't really a big deal to me, we get that value as part of the initial observation, but some folks refuse to return this data in (or on) there final product (the 2+1'ers I call them).

Datum, Epoch, XYZ, (and maybe Covariance Matrix), and we have it ALL...Done, finished, wrapped and stacked.

Loyal

> I wonder if anyone in Texas is working on something similar?

In Texas, you could design a different projection for every county and try to merge those counties that the metropolitan areas spread over into one projection. What would that really get you to have to deal with literally hundreds of different projections across the State?