Scott Zelenak, post: 357033, member: 327 wrote: If the localization carries all the distortions of the SPC system how can it be affine?
I grasp the LDP concept but the lightbulb over my head isn't lighting up for the affine localization.
I need some coffee...
It's affine between SPC and localization. The distortion is introduced by SPC and carried over in the localization.
Then I'm not grasping its purpose.
Isn't the idea to remove, or at least minimize, the distortions?
'Account for distortions' would probably be a better way of looking at it. Every projection type has distortions. Localization can minimize the magnitude of these distortions over a small area, but the distortions are never really removed. Furthermore, the remedy is static while the distortions are not. Change location or elevation and the accounting is no longer valid because the distortions are different while the localization parameters remain the same.
Scott Zelenak, post: 357036, member: 327 wrote: Then I'm not grasping its purpose.
Isn't the idea to remove, or at least minimize, the distortions?
Scott Zelenak, post: 357036, member: 327 wrote: Then I'm not grasping its purpose.
Isn't the idea to remove, or at least minimize, the distortions?
Scott, what Nate is doing is state plane,,,,,,
For a small area he wants his distances to be "close" to ground so he is applying a scale factor to multiply the distances from the state plane number to a ground number.
All the stuff about 50000, 50000 at the base is really just playing with state plane numbers.
Page 1 with the "local coordinates" is set with the state plane projection, it is projected to state plane numbers, at the base the program does a simple subtraction to produce the 50000, 50000 number. Most GPS programs have this option.
Then the scale factor is applied from that point.
This results in bearings that are state plane and distances that simulate ground distances-they won't be perfect, but "close".
I'm guessing that this is a boundary, I'm also guessing that Nate will produce a plat without anyone seeing his "local coordinates".
If that is the case all his stated metadata needs to say is that bearings are state plane and distances are adjusted to surface by multiplying the state plane distances the Datum Adjustment factor of 1.00015 or something like that. He can also state that distances are adjusted to surface by dividing the state plane distances by the combined scale factor of .99985 which some like better, although most programs express this factor as a number larger than 1.
Simply put Nate has a modified state plane coordinate system, he is not doing a LDP.
Mr Moe, that is true.
I did not quite know how to say that, as succinctly.
But the mechanism, for doing this, is interesting, because it LEAVES my SPC intact, and it is in the data collector, as an expression, of the job, for computational purposes. Press a few buttons, and you are in pure SPC, a few more, and you are back local. Another feature that this allows, is if you set PAGE 0 current, (SPC) then, you can go manually enter pure SPC from another project. Then, go back to your LOCAL page, and there that coord is, in YOUR local system.
N
Loyal, post: 356963, member: 228 wrote: That's the KEY Tom!
Unfortunately, the "metadata" (how he done it) is often missing, and even when it IS there, it doesn't always WORK.
A properly defined LDP is one button away from Lat/Lon OR SPC/UTM, without all of Alphabet Soup manipulations of the Project Coordinates (which all too often LOOK like SPC/UTM coordinates[but are not]).
Loyal
Loyal,
I have heard you talk about LDPs for a long time, and I must confess I don't know exactly what that is or how you go about generating it. I know you don't support the way I do things, but it is just what I know and it makes sense. (I have found errors with other's work when they attempted to publish their metadata and showed that they didn't really understand what they were doing.)
The only thing I will say, regardless of what system you use, is if you tie into someone else's work you should always check distances between existing monuments and make sure you have an understanding of what they (the other surveyor) did. (I have even seen someone "calibrate" to someone else's faulty work and scale factor, and perpetuated the same problems throughout a major boundary survey).
Nate, doing what you are will produce some hairy metadata.
The subtraction numbers will need to be shown to at least 3 or 4 places, so you will have a number like -1,475,233.3345, and your latitude and longitude at your scale point to at least 5 or 6 places, you you will get a number like 40-25-13.227556N, also your computer will probably express your scale factor with 9 decimals places and you will need to probably do so.
You can avoid that kinda thing by picking your own numbers, if you want, you can use a subtraction of say 1 million, and you can set your origin point anywhere nearby for the scale factor, say 40d30'00"N and 90d20'00"W or an even state plane grid coordinate; you can pick your own scale factor- .999851 or 1.000149 however your computer needs it expressed.
This can help keep track of metadata, however you won't get the 50000, 50000 number at the base. 🙁
The advantage of doing this is keeping records easier for all the numbers and it can be set-up with the job before leaving the office, the disadvantage is you can't pick your exact base coordinate. Although to me I don't see that as an issueB-)
I always use 9 places.
N
Ok.
I had the SPC and LDP concepts, now I've got the localization concept.
I'm a construction guy so I NEED not to have any distortion.
I can get away with a tangent plane system over an area of limited extent.
It's got it's own distortion problem, but on the scale I function at, it's not an issue. At least to me.
Thanks for clearing up the localization concept.
I don't use GPS so the education is appreciated.
Nate The Surveyor, post: 357068, member: 291 wrote: I always use 9 places.
N
Many do.
Adam, post: 356877, member: 8900 wrote: I see no problem with holding one point as true SPC and scaling from this point without adding an offset as long as you clearly state on the plat what you did.
If you best fit grid projection coordinates to the ground by means of a project combined factor then why would you want them to look line a grid projection coordinate. Grind and ground coordinates are like apples and oranges. Why paint the orange red so you can compare them? What benefits do you gain by using these pseudo grid coordinates versus truncating them. The converted pseudo grid coordinates are equal to grid at only one point and you are just fooling yourself if you think otherwise. In might look good on a lot survey but on a mile long road project it will fall to pieces.
From my experience working with GPS and grid projects, which at this point is well over 20 years, on engineering projects the meta data is usually lost and you are left to wonder if the point is a true grid value or scaled to the ground. Here is an example of the meta data from a project we are currently working on. We are providing as-built mapping on 18 miles of commuter rail and this is what I got for existing control. At least on this project I know I'm not working in grid coordinates but I still do not have the data to convert it back to grid.
Yes the "metadata" can be lost or be beyond the comprehension of the surveyor.
It is widely misunderstood in this country. Not so many huge project so it is often forgotten and is generally not a problem as long as 1 surveyor does the whole job.
Typical conversation.
Are those OS coords on the drawings?
Yes
Did you use a scale factor in the instrument?
No, all distances are unadjusted from the instrument.
So the coordinates are local?
No they're based on OS.
So where's the origin?
Oh I don't know we'll have to find out... (please go away and let me try to find someone who understands what you are talking about...)
I have seen the 40mm error in a 100m backsight be wrongly identified as the old Leica prism constant error.
Please, please truncate, or otherwise distinguish, ground or local coordinates from the original projection.
John Putnam, post: 357099, member: 1188 wrote: If you best fit grid projection coordinates to the ground by means of a project combined factor then why would you want them to look line a grid projection coordinate. Grind and ground coordinates are like apples and oranges. Why paint the orange red so you can compare them? What benefits do you gain by using these pseudo grid coordinates versus truncating them. The converted pseudo grid coordinates are equal to grid at only one point and you are just fooling yourself if you think otherwise. In might look good on a lot survey but on a mile long road project it will fall to pieces.
From my experience working with GPS and grid projects, which at this point is well over 20 years, on engineering projects the meta data is usually lost and you are left to wonder if the point is a true grid value or scaled to the ground. Here is an example of the meta data from a project we are currently working on. We are providing as-built mapping on 18 miles of commuter rail and this is what I got for existing control. At least on this project I know I'm not working in grid coordinates but I still do not have the data to convert it back to grid.
It does depend on the size of project, and I don't use this method for any large project spanning miles. I insert photo's and other data into drawings that are referenced to state plane coordinates. I state on my deliverables all the metadata to retrace my work.
I find much less confusion if the coordinates are simply multiplied.
The JAVAD sequence shown above is a torturous series of events that need a boatload of explanation to get the coordinate you want.
Look at this thread, it was painful to find out what page 1 means.
Simply taking the state coordinate and multiplying it by the DAF produces the same results. A one step process.
And it produces coordinates that are no where near state plane anyway.
Thinking they are is more on the surveyor.
Without metadata I don't assume anything about a coordinate. And even then I don't trust them until they are verified.
MightyMoe, post: 357108, member: 700 wrote: I find much less confusion if the coordinates are simply multiplied.
The JAVAD sequence shown above is a torturous series of events that need a boatload of explanation to get the coordinate you want.
Look at this thread, it was painful to find out what page 1 means.Simply taking the state coordinate and multiplying it by the DAF produces the same results. A one step process.
And it produces coordinates that are no where near state plane anyway.
Thinking they are is more on the surveyor.
Without metadata I don't assume anything about a coordinate. And even then I don't trust them until they are verified.
Nate's description of pages is how he uses them, but it's not necessary. You have several coordinate systems, you put one on then you put another on, at will, according to your needs at the moment. No need for pages. Since everything is lat/long, this is not a problem. Put on this projection and coordinates are shown in State Plane. Put on that projection and coordinates are shown in UTM. The pages concept really represents subprojects - a means of subdividing a project. Pages can have the same coordinate system. Pages can have different coordinate system. I typically use pages to divide my imported points and my survey points. You could use them to divide types of points (boundary, control, topographic, utilities, etc.) Or you can put everything in one page. The pages aren't necessary to take advantage of the various coordinate systems. Nate finds this to be easier for his work, but it's not necessary.
In the Javad software, you can use a standard projection, you can use an LDP, or you can use a projection with transformation parameters applied (which is a localization or local coordinate system). The local system can contain any one or more of seven parameters found in a seven parameter transformation. One of those parameters is scale. The local system can also contain translation, which is what Nate does to keep his scaled local system coordinate values at 50k, 50k instead of being in the range of State Plane. He could also apply a rotation if he wanted to be oriented to something other than the underlying projection. The underlying projection can be any projection (State Plane, UTM, LDP, etc.)
At any time, Nate can switch the project coordinate system from his local system to State Plane. He can export his points and linework in either system. Neat!
And he can process his base station data within the receiver through DPOS and get an automatic adjustment from an autonomous base position to a bona fide NAD83 position, along with every point he located from that base. He can also allow the software to recomputed the localization so that the specified point at 50k, 50k still has a Nate Coordinate System of 50k, 50k.
Suppose Nate's 50k, 50k system was computed on a pre-DPOS position and then recomputed after DPOS. Would it be fair to characterize the result like this:
The ruling in the field that the location of Nate's point (50k, 50k) is at SPC (E1, N1) has been overturned. Please set the location of Nate's (50k, 50k) to SPC (E2, N2) and calculate new SPC coordinates for any other points that Nate identified.
red flag and all, Teach. 🙂
Adam, post: 357107, member: 8900 wrote: It does depend on the size of project, and I don't use this method for any large project spanning miles. I insert photo's and other data into drawings that are referenced to state plane coordinates. I state on my deliverables all the metadata to retrace my work.
Adam,
It does matter, the scaled coordinates are not grid. They just look like it and that is where the problem is. It might fit your need to overlay an image but only until the distortion becomes larger than the pixel size. As for the metadata, just because you include it in on your deliverables does not mean that it makes it onto the engineering drawings. Even worse, the next surveyor on the project is not supplied with the data when hired to expand your project. I've been that second surveyor more times than I can count and 9 time out of 10 it is a problem.
John Putnam, post: 357142, member: 1188 wrote: Adam,
It does matter, the scaled coordinates are not grid. They just look like it and that is where the problem is. It might fit your need to overlay an image but only until the distortion becomes larger than the pixel size. As for the metadata, just because you include it in on your deliverables does not mean that it makes it onto the engineering drawings. Even worse, the next surveyor on the project is not supplied with the data when hired to expand your project. I've been that second surveyor more times than I can count and 9 time out of 10 it is a problem.
I have no control over what engineers do John. Thats poor work on their end. I provide every engineer I work with a plat of whatever it is and expect them to reference my plat or even better insert it into the plan set.
Adam, post: 357144, member: 8900 wrote: I have no control over what engineers do John. Thats poor work on their end. I provide every engineer I work with a plat of whatever it is and expect them to reference my plat or even better insert it into the plan set.
They don't include it because they don't understand it. So I think there is something to be said for helping the next surveyor down the line not get caught out.
Our design engineers had to redesign a section of the works because between them and the original surveyors they mixed up the concepts "aligned to OS grid" and "OS grid".
This would not have happened if the coordinates were truncated.
Luckily I spotted it before it became a big fight afterwards.
I have many many more examples where the wrong scale was used for these exact reasons. Generally they got over it on site.
