Richard:
FIRST, I realize that you already know all of this stuff, but because other folks [who might not] will be reading this blurb, I have included some numerical examples and various editorial comments that support my own SUBJECTIVE opinions and conclusions.
Second, I have also used custom ellipsoids in the past, and I AGREE that it CAN be done quite successfully, I just think that there are EASIER (i.e. less complex) ways to accomplish essentially the same net result.
The vast majority of the LDP(s) that I work with are Transverse Mercator projections, and most of the rest are Single Parallel Lambert Projections (there are a few Oblique Transverse Mercator Projections too). That said... Here goes:
If I want my “developed surface” (grid) to be at say 5400 feet NAVD88, I simply generate a Central Meridian (or Parallel) scale reduction value that is greater than ZERO... which of course makes it a “scale inflation” value. To get to 5400 feet in my area (N= ~18m), that would be a scale factor of ~1.000 255 (I generally run it out to 9 decimal places, but past 7 does mean much).
Metadata example:
Projection: Transverse Mercator
Datum: NAD83(2011) Epoch 2010.0000
Central Meridian: 112°00'00.00000” West
Origin Latitude: 40°00'00.00000” North
Scale Reduction: 1.000 255 Unitless
False Northing: 500,000.000 Feet
False Easting: 50,000.000 Feet
Developed Surface ~5,400 Feet NAVD88
Geoid Height (N) -18.0 Meters
Linear Units: U.S. Survey Feet
Projection: Single Parallel Lambert
Datum: NAD83(2011) Epoch 2010.0000
Central Meridian: 112°00'00.00000” West
Standard Parallel: 40°00'00.00000” North
Scale Reduction: 1.000 255 Unitless
False Northing: 50,000.000 Feet
False Easting: 500,000.000 Feet
Developed Surface: ~5,400 Feet NAVD88
Geoid Height (N) -18.0 Meters
Linear Units: U.S. Survey Feet
Both of these projections will return NAD83(2011) Grid Coordinates with Projection inducted scale factors between 1.000 001 and 0.999 999 (1ppm developed surface [grid] to 5400 NAVD88) for a swath 16 miles wide (East-West_Transverse Mercator or North-South_Lambert). This of course DOESN'T negate the effect of topographic variance from 5400 NAVD88, which is still going to add/subtract 1ppm per 21 feet of elevation change.
Although the computed “scale factor” within the “zone” limits is less than intuitive (1.000 256 to 1.000 254), it still equates to +/- 1ppm relative to developed surface and the 5400 NAVD88 “contour” (subject of course to undulations in the geoidal surface, which will impart a few more [or less] ppb [parts per billion] depending on where you are at).
The point being...a NAD83(2011) Epoch 2010 geocentric XYZ transforms to a NAD83(2011) Epoch 2010 Latitude, Longitude, Ellipsoid Height, transforms to a NAD83(2011) Epoch 2010 LDP Grid Coordinate (and back and forth) WITHOUT any additional mathematical games. So your LDP is in FACT a NAD83 coordinate system.
Therefore, I can directly enter an OPUS NAD83 XYZ or Lat/Lon/Eh and get an accurate LDP Grid value AND use the NGS Geoid model too. The same goes for HPGN/HARN/FBN points, or any NAD83(2011) XYZ, LLH, LDP, SPC or UTM coordinate.
The same can NOT be said when using a custom Ellipsoid.
If I generate a Custom Ellipsoid that approximates the 5400 NAVD88 contour for this area (retaining the GRS80 Flattening) I get something like:
a = 6,379,767.254m
b = 6,358,377.102m
Okay, now ASSUMING a NAD83(2011) geocentric coordinate of:
X = -1,833,321.194m
Y = -4,537,629.184m
Z = 4,079,062.241m
That returns a NAD83(2011) Lat/Lon/Eh of:
Latitude = 40°00'00.00000N
Longitude = 112°00'00.00000W
Ellip. H. = 1,628.000m (~5400/3.2808333... -18)
BUT... if you use a the above custom ellipsoid (“scaled” to ~1628m), and the same NAD83(2011) geodetic [XYZ] position, you get:
Latitude = 40°00'00.17443N
Longitude = 112°00'00.00000W
Ellip. H. = 0.002m
Which equates to a difference in Latitude of about 17.7 FEET.
In my opinion, that CREATES an unnecessary level of complexity AND the potential for MAJOR CONFUSION into the whole proposition. So long as one doesn't mix NAD83 XYZ, NAD83 LLH, and Custom WHATEVER values improperly, this isn't a problem, but how many folks REALLY understand what's going here?
The KEY (IMO) to working with Low Distortion Lambert Projections, is to abandon the Two-Parallel version (except of course where you can still use NAD83), and adopt the Single Parallel version. Most all software that I have seen lately supports this projection, and it just seems like the path of least resistance to me.
As a side note... Mike Potterfield once said that... “using a custom ellipsoid to solve an LDP, is like using an H-Bomb to kill a fly.”
[somewhat paraphrased]
I obviously agree with that sentiment.
Loyal
I read the comment from a couple days ago. You've obviously been mulling this one over since. Thanks for taking the time to address the reality (simplicity) of the transformation process. The solutions to the problems are too often made more complex than the problem itself.
JBS
Suggestion: To maximize benefit per effort expended see the following link.
If you have any questions, just let me know.
:good: :good:
John. Earl, Shelby
J.B.
Thanks John...P.S. Where's my RINEX files from the Intergalactic Kegger last Year??? 🙂 And YEAH, I'm still recovering from last Wednesday 🙁
Dr. Burkholder:
Thanks for the link to you latest Paper, it is a good argument as always, and worth serious consideration. I have been following your Don Quixote(ish) quest for a more robust spatial expression of geodetic data for many years. You are speaking to the choir in my case.
Unfortunately, it ain't a gonna happen UNTIL the GPS/COGO/CAD gorillas get on board, and support that paradigm (which I don't see happening anytime soon). In the mean time, LDP(s) are the weapon of choice for many of us.
Most (if not all) GPS (and even Total Station) Data Collector software suites support user defined Coordinate Systems (LDPs), and there is no shortage of standalone (or integrated) software packages that do as well (even many CAD applications).
That certainly DOESN'T mean that LDP(s) are the BEST way to go, just that 'they” are what we have to work with right now. The day will come however!!!
Shelby;
Thanks buddy, and it was great chatting with you earlier this week. What was it? 1982 that we were looking for bearing trees on Porcupine Mountain?
Correction:
"(I generally run it out to 9 decimal places, but past 7 does mean much)"
Should have read:
(I generally run it out to 9 decimal places, but past 7 doesn't mean much).
Loyal
Some day I hope to grow up and be a real Surveyor like Loyal 🙂
:good:
Loyal,
Thank you for that analysis. I would like to learn more about both, and have found much material on the internets, but do you reccomend a particular publication?
I'm a late learner in geodetic matters but quite willing to do some deep reading to make sure I do not inappropriatlly act.
Dean (beer in hand but still lucid)
Loyal clued me in years ago, been quite simple ever since. Just keep all yer data in true X, Y & Z (geodetic) and project it any way you like. Mostly I use the transverse Mercator and apply a scale factor to make the grid read out equal to ground at some average project elevation. For small projects (say a township if the elevation doesn't vary too much) I just inverse the elevation factor from a point at the origin and average project elevation to get my scale factor. Simple and works great.
John. Earl, Shelby
> Shelby;
> Thanks buddy, and it was great chatting with you earlier this week. What was it? 1982 that we were looking for bearing trees on Porcupine Mountain?
Yep, 1982!
SHG
John. Earl, Shelby
It just occurred to me that I have met in person 50% of the posters on this thread if I count myself. Pretty small world! Not just met, but shared meals, worked on projects together, spent the night and so on! I truly have made some great friends over the last 30 years or so.
SHG
John. Earl, Shelby
:good: :good: :good:
> Some day I hope to grow up and be a real Surveyor like Loyal 🙂
Dang, Dave...
I'm still adjusting the declination on my K&E (German) Compass
DDSM:beer: