Working with LDPs

I suggest starting by studying the Oregon DOT LDP documents. There is a lot in there that will help you along.

As for setting up in Autocad experiment with MAPCSCREATE. Instructions here would be too lengthy,  but crashing around and breaking things in trash C3D drawings should get you moving..

Best of luck, Tom

I work in the Oregon LDP for my area for nearly everything. I'm always working with NEZ coordinates, not importing LLH to data collectors. I do frequently use LLH positions for control points in my StarNet adjustments because that facilitates switching back and forth between the LDP and State Plane when necessary.  

I work with a single LDP zone. I have very rarely had to switch to another. Once loaded - and in recent years these zones have come pre-loaded in all the software I use -  it is operationally no different from using an SP zone. I can see that using a different zone for every project would get to be a PITA, real quick.

The key to making LDP's useful is to make them "official" so they appear in common engineering/GIS computer programs. As Norman relates Oregon has number of them and this will result in users being able to click on them to proceed with data sharing. I've found that creating my own doesn't work well with other users of my data. 

Often, I would be faced with township sized projects, so naturally I would pick a line of Longitude splitting the township and base an LDP TM projection with that Longitude being the CM and the Scale Factor calculated to "lift" the surface above NAD83 to simulate ground. There is an important reason to simulate ground and "true north" with an LDP since retracing the PLSS needs to be true northish and surface distances; that's how it was originally surveyed. Then most property surveys would follow as land was divided. 

It's the convergence using state plane that's usually the vexing issue to deal with concerning property surveys. Some are so extreme that it tilts the surveys visually as they are plotted. The distances have always been the trivial data to correct for. 

Look for input screens that ask for data like this Well Known Text file for Alaska Zone 4:

PROJCS["Transverse_Mercator",
GEOGCS["GCS_North_American_1983",
DATUM["D_North_American_1983",
SPHEROID["GRS_1980",6378137,298.257222101]],
PRIMEM["Greenwich",0],
UNIT["Degree",0.017453292519943295]],
PROJECTION["Transverse_Mercator"],
PARAMETER["latitude_of_origin",54],
PARAMETER["central_meridian",-150],
PARAMETER["scale_factor",0.9999],
PARAMETER["false_easting",500000],
PARAMETER["false_northing",0],
UNIT["Meter",1]]

@mightymoe I'll ruminate on what you're laying down. Big part of the problem I'm facing in I have several of these 'unofficial' LDPs that I'm encountering and the nuts and bolts of setting them up in the controller and CAD correctly and getting them to work as intended is what's vexing me. I have a .prj file for one of them, but not the other two that I believe originated with DOT. I don't want to wiggle into these things for some quick and dirty solution. I guess it's one of those you don't know what you don't know issues. I've got a fairly good grasp on the math involved in setting up a TM projection with a false northing and easting, Central Meridian, SF and so forth. It's getting them 'official' in the programs that I'm using so that it works as intended with too much second thought. I don't want to find out at some point later that I've been doing it all wrong. Something as simple as taking an OPUS LLH and converting it to seed coordinates to establish a network for a job and getting this into a controller or post processing software so I can double difference vectors and get LDP crds that I can have faith in. Nuts and bolts stuff. Get one step goobered up and you know, garbage in, garbage out.

Actually, any property located set of coordinates can be retrofitted with an LDP. A few minutes with the programs will get you there. We started doing that instead of calibrating years ago with surface coordinates that were given to us without the metadata. If you can't fit an LDP around the coordinates then it's a busted set. 

That being said, they should have given you all the metadata needed to project it using the same set of data they used. 

If you have the .PRJ file for one of the LDPs, you should be able to upload it to the controller either directly from a computer or from a USB drive. Once it's there and selected, the controller should convert LLH to plane coordinates with complete confidence.

Somewhere, there's instructions for the upload either in the controller user manual or online.

Out of curiosity, can you copy and paste the .PRJ as text in a post?

.prj saved as .txt

Nice projection. I've run some points through DNRGPS, the old quirky package from the Minnesota Department of Natural Resources. Here are the results:

The first one checks to see if it can compute its own origin. The second one verifies that it's computing in feet. By hand, it works like this: .00001*60*6076 = 3.6456. Compare that to the 3.6558 distance to the origin and we know that we have feet. (degree distance * 60 nautical miles per degree *6076 feet in a nautical mile)

The Easting for UW7863 is negative, so the western limit for positive Eastings is between 150.23 degrees West and 150.9 degrees West. That's 23 miles or so at that latitude, but it shrinks as you go north.

A further check would be to calculate the distances between the two NGS points on both State Plane and this LDP. They won't be the same because of the different scale factors, but they should be close.

Getting it into the controller will likely require entering it into the office software first, making it available to controllers.

This operation is not for the faint of heart. Best of luck; it will turn out fine.

Be careful with the survey software. In DNRGPS, the False Easting, Northing are interpreted to be in Survey Feet. According to this 5-year old Trimble video, those numbers would have to be converted to meters in Trimble CSM. If entered as they are, CSM would multiply them by .3048..... That would make coordinates much smaller.

Working with Trimble’s Coordinate System Manager

@mathteacher Thank you, very helpful in getting my head wrapped around this subject. One of the chief causes of my anxiety with these is proving them out to myself so I'm not a getting a phone call that I've butchered something. Looking over all of the various plats and exhibits I need to rely on, some of which provide meta data on the LDP, but mostly not, the one thing they all lack uniformly is a Basis of Coordinates statement that I can use to convert an LLH to the LDP coordinates to assure myself everything is working correctly. Your help is much appreciated. 

Cheers. Willy

My pleasure. Once you get the .prj installed, you'll be able to calculate lat/lon (and maybe height, depending) from plane coordinates. That should get you great confirmation in the field.

If you want to, send me a couple of points in plane coordinates and I'll let DNRGPS calculate the lat/lon.

Good luck!

Test post.

Got some static time in on these yesterday and set some new project control. Now to see how well I can match up.

You should be right on top of them.

qwerty

@mathteacher Close but not perfect. I’m using WGS 84 and they were using NAD83 values. It’s close enough though that I’m feeling a bit more relaxed and I can play around with things. I did long enough static obs I can also get Opusrs solutions. Between Opus, CHCNAV and Global Mapper, I can start to build some confidence in this LDP business. Thanks for the encouragement!

WGS84 via 7-parameter Helmert

These likely won't match perfectly. I used a +towgs84 string that converts HARN points to WGS84/ITRF. It looks like this 

+towgs84=1.004,1.910,0.515,0.0267,0.00034,0.011,0.00062

Your modern software may need something else. Also, this assumes that the points are HARN.

Anyway, you're way ahead of the curve. Find the right conversion string, put it where your software wants it, and go surveying.

Here's the full modified .prj. My DNRGPS uses an older version of Proj4 which your stuff seems to be compatible with also. However, there are later versions that require different formatting for this type of modification. My version requires that te towgs84 string be added in the geoid definition.

Change the name "PMRail_GRS80" to something else so as not to overwrite the original and to separate and de the two

PROJCS["PMRail_GRS80",
GEOGCS["GCS_GRS_1980",
DATUM["D_GRS_1980",
SPHEROID["GRS_1980",6378137,298.257222101],
TOWGS84[1.004,1.910,0.515,0.0267,0.00034,0.011,0.00062]
],
PRIMEM["Greenwich",0],
UNIT["Degree",0.017453292519943295]
],
PROJECTION["Transverse_Mercator"],
PARAMETER["false_easting",100000],
PARAMETER["false_northing",500000],
PARAMETER["latitude_of_origin",61],
PARAMETER["central_meridian",-150],
PARAMETER["scale_factor",1.000004],
UNIT["Foot_US",0.30480060960121924]
]