Local city has all their control on NSRS2007. I'm trying to get through my head how to deal with this in star*net. Is it just as simple as pick NAD83/Zone 4601 and then feed it NSRS2007-based lats and longs? The NAD83 is the datum and the NSRS2007 is the epoch?
It's a pain in the processing. Using OPUS-RS and WSRN to get NAD83/CORS2002 and then transforming it to NSRS2007 was not as tight as just using the City's base stations & their fixed coordinates. Add to it that the job started on a not-quite-NAD83/91 local datum. It's like coordinate stew!
I suppose the end product that best matches the City's version will be to post process using their base station data again.
For the fieldwork, I just to get the RTN/GPS stuff to match the NSRS2007 published control. For my little square mile anyhow. Spending way too much time scratching my head over 0.35'! What would you do?
Not sure about star*net but it's not that simple in TBC. How are you transforming NAD83 (CORS96) 2002.00 to NSRS 2007? Remember that for the NSRS 2007 adjustment the CORS stations used for control on the West Coast were adjusted for velocities (HTDP) from the 2002.00 epoch to 2007.00.
Star*Net is just doing an adjustment. If you tell it NAD83 (whatever flavor), that gives it the dimensions of the ellipsoid. If you then fix NAD83 (NSRS2007) coords, that is the datum of your results. If you fix NAD83 (91/92), that is the datum. Even if you use NAD83 (86), it will work fine and give you NAD83 (86) as the adjustment datum. The ellipsoid parameters do not change between realizations of NAD83. In fact, you could use the same ellipsoid (GRS80) even if you were doing the adjustment on ITRF, as the difference in ellipsoids is very minimal.
However, it would not be wise to mix different realizations, like NSRS2007 and 91/92, and definitely not 86.
Now processing software (TGO, TBC, etc) is a bit different. Some do transformations (albeit small) when told that a seed coordinate is NAD83. In my opinion, this is wrong. How do they know what realization is being used? I prefer to enter a seed coordinate in ITRF, and let it use that. If I enter a seed coordinate in NAD83 (NSRS2007), that is probably OK unless my project covers a large area, in which case a small bias may occur.
Thanks John! I'm still trying to figure out the RTK side. What datum is the RTN sending the RTK corrections in? WGS84? ECEF? Then the rover applies the coordinate system to get you on a grid of some sort? If so, all I need is to load the NAD83/NSRS2007 coordinate system in the Leica and get moving? Doh! It will be interesting to test one network's published ground points against another's GPS positions.
EDIT -- just found this and it is answering my questions:
http://www.ak-aug.org/presentations/GIS_Jam_2011/Dennis__Ghost_in_the_Machine_WBK__ShortCourse.pdf
I used HTDP last time around, but running OPUS results thru that did not match the published ground control as well as using the City's base stations & holding their given NSRS2007 coordinates fixed.
Don't want to Hijack here but how does Star*Net handle RTN? Does it screw around with the Covariance Matrix? I don't have Max yet and I'm contemplating getting it.
Ralph
There is no transformation on the Leica rover side in real time UNLESS you have one enabled, if you are just applying the SPC grid parameters, then the rover is simply converting the broadcast geodetic positions to grid. The WSRN and ORGN are currently broadcasting NAD83(CORS96)(Epoch 2002.0). That will be changing (at least in Oregon) in the next few months when NAD83(2011)(Epoch 2010.0) will be broadcast.
The only "good" way to get onto positions other than NAD83(CORS96)(Epoch 2002.0) when using the RTN is to occupy points you want to hold surrounding your project and come up with a transformation set (Leica speak) calibration to others, the same as you would with an autonomous base situation. In fact, unless you want to use NAD83(CORS96)(Epoch 2002.0), you might mentally note that the RTN could just as well be unknown as far as you are concerned and the final result would still be the same.
I am working on a project right now using the ORGN, however the client wants to match existing NAD83(91) data, so I will come up with a transformation, in this case I am also running a base station that is occupying a couple of different early 1990's points on NAD83(91), so I will have the option of simply computing a static network using my base too, haven't finalized my thought process on which way I will roll in the end, BUT the RTN data is free and I have cell communications on the whole job, so why not collect RTN data too?
SHG
Thank You, Mr. Griggs! That answers the question completely. Time to study the manual for Leica's "Determine Coordinate System" onboard application. I will go shoot the city's control for this job and proceed. That will get me the square mile we are working in.
For the whole city I suppose I could shoot the control around the city limits and a few in the middle, and get an NSRS2007 localization for the whole city? What are the size limits for such a "localization" ?
It will either use the coordinates and the reported error ellipse or the deluxe version will use the vectors. Depends on what your rig records and which version of Star*Net.
What is "Max" ?
> It will either use the coordinates and the reported error ellipse or the deluxe version will use the vectors. Depends on what your rig records and which version of Star*Net.
>
> What is "Max" ?
Thanks,
Max= I meant "Pro", I have the license for "Standard".
What do you mean by Deluxe??
I just spoke to Sandy at Micro-Survey and he broke down the process for me.
I'm still trying to figure out how to do it in Survnet
Cheers,
Ralph
OK, "Max = "Deluxe" = my redneck synonym for "Pro" ! I think it's Latin for "of light", but with that extra "e" you will have to pardon my French.
> OK, "Max = "Deluxe" = my redneck synonym for "Pro" ! I think it's Latin for "of light", but with that extra "e" you will have to pardon my French.
No Worries!
LGO offers more options than on the controller alone, from the LGO help:
"Which approach to use
This question is almost impossible to answer since the approach used will depend totally on local conditions and information.
If you wish to keep the GPS measurements totally homogenous and the information about the local map projection is available, the Classical 3D approach would be the most suitable.
If you are unsure of the local height information but the position information is accurate and you wish to keep the GPS measurements homogenous in position, then the Stepwise approach may be the most suitable.
For cases where there is no information regarding the ellipsoid and/or map projection and/or you wish to force the GPS measurements to tie in with local existing control then the One-Step approach may be the most suitable. Alternatively if a large number of common points are available and a more accurate approximation is required the Interpolation approach can be used.
The Two-Step approach also treats position and height information separately which allows for position only control points to be used as well. Compared to the One-Step approach, information regarding the ellipsoid and map projection has to be known. The advantage is that this approach can be used for larger areas than the One-Step."
The one step most commonly used in the field on the controller is" restricted to about 10km square (Using 4 common points)" (direct quote from LGO help files).
Hope this helps.
SHG