> Okay, a serious question here...
>
> If State Plane Coordinates are so unsatisfactory for your work, that you have to “Modify” them, then WHY do you use them at all?
>
> Just seems odd to me...
> Loyal
In almost ever jurisdiction around here, our maps are required to be in SPC...but...
To over simplify, some engineers and reviewers dislike working in SPC. This means that in practice many (most?) firms pick a single known point, preferably one with a published SPC. There is then, only ONE point that is a State Plane Coordinate, the rest need to be scaled. Sounds silly right?
(But there are arguments for it...preserves ground distances that are the distances that things are actually built in, etc.)
Then, in order to hold and publish bearings that are the same as the plat you are working in (which is probably not in SPC), you also provide a rotation.
So, an "SPC" drawing is created, except all points except one need to be scaled and rotated.
It gets even better. Many jurisdictions really want a tie to two or more of their monuments with published SPC coordinates, and want you to use their coordinates. Sounds great, except they are often NOT tied to NGS monuments with any sort of precision.
(What they really want is not a tie to SPC, but they want a tie to their GIS.)
So, you have one published SPC coordinate that is a real SPC, except you can't plug that in your Network Rover and head out and hit it...
And you think that is ODD?
😉
Guess it depends on your definition of "odd"... Maybe it's the new sort of "normal"... 😉
Around here, one of the local jurisdictions created a requirement that all subdivision plats have "GPS Coordinates (NAD 83 State Plane Colorado South (US feet) North American Datum of 1992 coordinates) clearly shown for at least two (2) external boundary points and four (4) internal street centerline intersections."
As a result, we've seen plats with ground distances and coordinates that are supposedly "NAD 83 NAD 1992" (sic) State Plane coordinates. But the State Plane coordinates mysteriously inverse the same as the ground distances on the plats, even though the town is at nearly 5000 feet of elevation... Ah, how fun... 😛
Star*Net Ground Conversion
> GNSS Solutions has a really nice ground coordinate system generator...I haven't tried it with Star*Net
Star*Net's approach is very simple: under Project Options|Other Files there's a checkbox for Create Ground Scale Coordinate (GND) File:
Check the box, pick a format (they're customizable, so just about any delimited format can be set up), and click on the Settings button. That brings up the Ground File Settings dialog, which allows you to tailor the ground coordinates just about any you want:
I say "just about" because here's the one gripe I have about Star*Net: it doesn't allow you -- at least I've never figured out a way -- to apply an elevation constant. I often have projects that I constrain to the LLH values of published control, but after adjustment I want to shift the vertical to match a local datum. Right now I have to go to another application to accomplish that, when it would be easy to add an Elevation Constant to the Settings dialog that would do the same thing.
Maybe MicroSurvey will add that bit...
Where I work the engineers want everything on ground which they get because they run the place. Seems to be a popular request by engineering types. So we move everything to project coordinates, scale from the origin and translate the coordinates by adding 100,000 meters to everything. This has caused so many problems in the past I could write a book about it. Mostly because the people who use the project coordinates don't understand how they got that way, what they really are, or how to get them back to SP. Sometimes the metadata is lost so you can't get back. And then there is the problem of butting two projects together or trying to get everything to fit on a project over a few miles or one that has a few thousand feet of relief.
I understand the desire to work in ground coordinates rather than using a CGF but for a surveyor using GPS this is insanity. Also, everyone else in the world is on SPC/lat/long. What about all of those data sets (aerial, etc.)from the web that could be used to add value to your project? Are you going to make the conversion everytime you import a data set?
I don't know but I'm sure you can set up a project in CAD to use a CGF rather than use project coordinates. I keep my control in grid and use a CGF when I map or stake. Construction does not suffer and 1 in 20,000 in a lot boundary is acceptable by state code.
GPS/GIS is very hard for some to get their heads around, especially engineers, but we need to give up this "the world is flat" mentality ASAP. It costs too much.
Jim
Come on Jim when you stake your 12' freeway lane it will be one thousandth of a foot too narrow if you don't work in ground!
🙂 I know, I'm a bad surveyor.
Star*Net Ground Conversion
Email your suggestion to them.
Star*Net Ground Conversion
> Email your suggestion to them.
It was the first thing I did when I first learned that Ron had sold the company.
Thanks for the comments so far, some interesting takes on the issue.
On note I would like to interject here, is simply that GPS DOES NOT “work on THE Grid” (or even in Latitude/Longitude) UNLESS you tell the Data Collector to do so (and then it RETURNS [outputs] to the screen WHATEVER “grid” that you have selected/defined).
P.S.
JUST LIKE a Total Station (or Transit-tape/chain), GPS [Static/RTK) “measures” a “point to point” DISTANCE (and direction) ON (or along) THE SURFACE of the EARTH.
Loyal
Just trying to explain that RTK is not a coordinate generating machine is an uphill battle. RTK measures vectors of direction and distance just like your total station and then applies the dX-dY-dZ to the XYZ of the base station. RTK without the ability to reprocess the vectors later (say from a better coordinate for the base from OPUS) is like a Porsche with wagon wheels instead of tires.