I'm in the San Francisco Bay Area, which is a tectonically active area. I'm looking to subscribe to a real time network (Leica SmartNet) but in this area they update their broadcast Epoch every six months or so. So if I go out with my rover right now, I'm receiving Epoch 2016.xxx data. I want to get my projects on something that is repeatable for others, like NAD83(2011) Epoch 2010.00. Leica is telling me to perform a localization on each project - but what if I just want to set some flypoints for a project on NAD83(2011) Epoch 2010.00? I don't always need or even have local control (e.g. monuments in subdivisions). How do I get on Epoch 2010? Do a static session on each flypoint and use OPUS? (Seems time consuming, and overkill). Do I localize on surrounding NGS monuments, which could be tens of miles in each direction? Is there a way to check into a few published monuments and apply an average shift at my site? I know I can do that in the office software, but how can I get that into my controller? Any advice is appreciated. I'm so used to having a base station which I'm in control of, this RTN stuff is new to me.
Thanks,
Ed
So I talked to a couple of local guys, and confirmed that around here you simply have to localize to get on NAD83(2011) Epoch2010.00. Could be either passive control (NGS monuments) or run your own static control with OPUS around the site.
What I do is export g-files for each RTN vector, then import the g-files into Star*Net and adjust. That allows me to control the RTN base position, which I can input as any epoch I want.
I back in the local broadcast CORS position, I also use the vertical numbers I want, I don't know if you can do that with a RTN, but it works well to get to an older EPOCH horizontally. This keeps me from introducing a calibration and makes the CORS verticals work to NAVD88.
Jim Frame, post: 426483, member: 10 wrote: What I do is export g-files for each RTN vector, then import the g-files into Star*Net and adjust. That allows me to control the RTN base position, which I can input as any epoch I want.
I'll confess that I don't follow that. But it sounds like that would only help after collecting data in the field, and would not allow me to actually set any points using the Epoch2010 coordinates. In any case, I'll stick with the process I understand. Thanks.
MightyMoe, post: 426489, member: 700 wrote: I back in the local broadcast CORS position, I also use the vertical numbers I want, I don't know if you can do that with a RTN, but it works well to get to an older EPOCH horizontally. This keeps me from introducing a calibration and makes the CORS verticals work to NAVD88.
That's what I did when I had a base station, but now I'm going to be using an RTN. Sometimes I really don't like 'progress'.
EdWidy, post: 426494, member: 10963 wrote: But it sounds like that would only help after collecting data in the field, and would not allow me to actually set any points using the Epoch2010 coordinates.
Correct, it's a post-processed workflow. I do have the option to shift the RTN base coordinate while in the field, but I've never had a need to use it.
I have a step-by-step write-up on how to adjust a UNAVCO PBO site in Carlson SurvCE. It involves localization, but you can do it in the office without occupying any points. I think that a similar workflow would work just fine in any other collector tool.
Link: https://blog.ashgps.com/2014/08/19/892/
The problem with PBO real time data is I think that most the sites just have a 30 point average from the day they were installed. There is no attempt to broadcast corrections with any frame. But it is not a big deal to OPUS a solution and force the base position.
M
You have to compute the transformation in order to check the localization. Why not do it ahead of time?
If the control is GPS derived and the RTN is of course, it should be a shift and not a rotation. I would figure out that shift and put it into the DC. If you are using Trimble I know that works well, all you need to do is put in the N,E,H shift. I would much rather do that than calibrate,,,,,,,,,,,yuck!!!!
Go to a number of control points and you should find a fairly consistent shift, I've used that before and been very happy with the results, you want to take your time doing the process, using HARN points with long occupation times would be a good start.
Calibration rotates, elongates, shortens, tilts and you have no control over the process, with a shift you have the projection parameters protected and you know exactly what is happening cause you are in control of what numbers are being used.
I don't know about Leica, but with Trimble I'd just bring the job into TBC and change the coordinates of the RTN base point to the 2010.00 epoch.
I find it curious that they're doing that. I realize that you're in a highly dynamic area, but most surveyors value consistency and repeatability over up-to-the-minute TDP. That's why NGS is staying with 2010.00 and the LSU Gulfnet RTN is conforming to NGS.
Thanks for all the help everyone. My first preference was to apply a simple shift to the coordinate system so that I didn't introduce any rotation or scaling errors. I gave it a whirl, but at first glance it doesn't seem to be working out for me. That would also save me the time of having to set multiple control points surrounding the site with OPUS (static) and localize to that. One static point would theoretically do it - but I'd verify with two others. I'll take another crack at it next week when I have some more free time.
That is unfortunate; I feel the shift option is the best solution for these Epoch issues. Possibly the velocities in the costal areas are too chaotic to allow that to work. There is even a shift given by a local city to allow you to get from the new local CORS station to the old city control which is NAD83(86) and has a 2' shift.