I stumbled across this page that Sinc wrote:
Sinc was a genius. He had a rare gift for teaching.
The above is from an AU presentation Sinc made. It's from a file, CustomCoordinateSystems.pptx, that I don't know how to put in this post. I can e-mail the file to anyone interested.
I hope these PNG's show up.
As always, I have piles of questions. How do you keep Grid and Ground projects straight? Since Legal Descriptions are usually surface measurements, is there any need to publish whether or not your dimensions are grid or ground? How do you normally work back and forth between Project (Ground) coordinates for layout and the Grid coordinates of the design?
Dave
Astute surveyors that apply GPS properly can manage the data. However, then you add civil engineers and GIS people to the equation that only want to fill in the blanks in their software for datum and things get wonky. Try explaining to a PE that his Autocad is wrong.
Seriously though Sinc, was the first to explore the grid to ground corrections available in Civil 3D. These features were undocumented, and that is why they had him teach at AU.
If you have questions, I believe Paul from PA on this board is good at explaining.
Yes. You should document whether your distances are grid or horizontal surface distances. There are many techniques for handling the database side of things. I've come to prefer low distortion projections. It's like state plane only the zones cover smaller areas with smaller (ie insignificant scale factors). Then I label a dew corners with doc but I'm basically just using spc as an addressing system and not a datum for field measurements as it was originally intended. There are pros and cons to this as well. But for me the cons are outweighed by the pros.
Not Me? Not An Expert?
Having worked in coastal areas of New Jersey, I learned early on to sketch out my project ellipsoid geoid when it comes to scale factor. Coastal areas included areas where the geoid was below the ellipsoid, so I was always cautious. I had to convince myself that those numbers were right, they always were. But when you were in an area the day before where values had an opposite sign caution is a good thing.
One other thing I learned was that certain GPS data could be used with grid traverse data unadjusted. GPS vectors are actually ground vectors, as post processing software starts out calculating antenna to antenna (in XYZ), then converts to ground (XYZ), then converts to SPC or Lat Lon with an elevation. One of my first quality checks is to compare the GPS vector with my slope traverse vector, then compare the horizontal and the vertical differences. That is one reason I always carry vertical on traverse points, even if all sideshots do not have an elevation. As a rule my antenna heights were always about a foot higher than my instrument and rod heights, sufficiently small in the scope of things to ignore in the first round.
Conversely when bringing OPUS coordinates into a project they are always entered as Lat/Lon/Ellip in metric, converted in my software to SPC/Ellip metric, compared to OPUS and then the last step SPC/Ortho in USSfeet. From there it goes into my survey cogo. After years of this I am confident enough to forego the expanded OPUS in USSfeet and have not gotten to customizing my OPUS profile to add it back in. Main reason is that I always print my OPUS and prefer less paper.
I am not an expert, just cautious, consistent and confident.
One other thing to consider is that SPC can only follow the ellipsoid in only one direction. Orthogonal to that direction the SPC is above/below/above the ellipsoid as one crosses the reference lines.
Paul in PA
> Then I label a dew corners with doc but I'm basically just using spc as an addressing system and not a datum for field measurements as it was originally intended.
Then I label a few corners with spc but I'm basically just using spc as an addressing system and not a datum for field measurements as it was originally intended.