I've only recently begun incorporating RTK into my work, and have run into an unexpected problem: I can't figure out how to bring multiple RTK-derived positions of a single point into a Star*Net adjustment. Although the Star*Net manual states that "any coordinate component entered with a standard error is considered an observation just like any entered angle or distance," the presence of multiple C records for a given point generates a "reassignment of coordinate values" error when the adjustment is run. Am I overlooking something simple?
> I've only recently begun incorporating RTK into my work, and have run into an unexpected problem: I can't figure out how to bring multiple RTK-derived positions of a single point into a Star*Net adjustment. Although the Star*Net manual states that "any coordinate component entered with a standard error is considered an observation just like any entered angle or distance," the presence of multiple C records for a given point generates a "reassignment of coordinate values" error when the adjustment is run. Am I overlooking something simple?
No, not in Version 6. I'm not sure how Version 7 handles the problem, but that feature of Version 6 is why I enter multiple OPUS solutions on the same point as GPS vectors of nominal zero length each with a different uncertainty.
Can't you export the RTK positions as vectors that can be imported into Star*Net?
> Can't you export the RTK positions as vectors that can be imported into Star*Net?
I can, but the workflow is substantially more complicated. I'm still feeling my way through this, so haven't settled on either field or office procedures.
The dataset I'm working with at the moment involves about a dozen control points throughout a small (700'x700') project that I measured conventionally but also got RTK positions on. The repeat RTK time separations range from a few seconds (not according those much value, just want to see) to a couple of days (probably more informative).
> > Can't you export the RTK positions as vectors that can be imported into Star*Net?
>
> I can, but the workflow is substantially more complicated.
Does that mean that the data collector format needs to be rejiggered into a format that can be imported, or is the problem even more general?
You'll recall that Star*Net can import GPS vectors with either covariances or standard errors and correlations.
> Does that mean that the data collector format needs to be rejiggered into a format that can be imported, or is the problem even more general?
Good question -- I haven't explored the Javad export formats much. I was thinking I'd have to export the raw observations, process them, then export the vectors, but maybe the receiver has the vector data all ready to go. RTK newbie speaking. 🙂
WE collect multiple shots using RTK with the point number followed by ".#"
002.1 would be the first shot on 002
002.2 would be the second shot on 002
etc.
In Star*NET, use the in-line command:
"ALIAS SUFFIX .1 .2 .3 .4"
to have Star*NET treat the vectors as multiple observations to a single point. If you have more than 4 shots, you would need to include additional suffix designations.
ALIAS has several other keywords that may work, depending on what your naming convention is.
This is in Star*NET v7.2.2.7
> > Does that mean that the data collector format needs to be rejiggered into a format that can be imported, or is the problem even more general?
>
> Good question -- I haven't explored the Javad export formats much. I was thinking I'd have to export the raw observations, process them, then export the vectors, but maybe the receiver has the vector data all ready to go. RTK newbie speaking.
Well, I'd expect that you'll find that importing the vectors will be much more robust than importing coordinates with uncertainties and worth figuring out how to do as efficiently as possible. BTW, if you forward the question to Javad tech support and their response is "nobody has ever asked this question before", please don't mention that on this message board. It will only serve to reinforce the worst stereotypes about RTK users.
> Well, I'd expect that you'll find that importing the vectors will be much more robust than importing coordinates with uncertainties and worth figuring out how to do ...
I second that. Import the vectors. The vector data includes covariance data. There shouldn't be any reprocessing involved. If there is no converter to parse the Javad format to StarNet that's a strike against the Javad, IMHO.
But if you have only coordinate values and standard errors......if the standard error for each retying of a point is always the same, the combination is merely a simple average. If the SE differs for each retie, the "averaging" is weighted. And the SEs are never the same.
> .... the presence of multiple C records for a given point generates a "reassignment of coordinate values" error when the adjustment is run. Am I overlooking something simple?
IF you hold the first tie of a point fixed (! ! !) and then hold the second tie of the same point, with slightly different coordinates, also fixed (! ! !) .... well... I think you can see that you are saying that the same point is in 2 different places at the same time, and that just can't be.
What you have to do is give each iteration of the point a standard error (try 0.01 0.01 0.01) which allows the software to "average" the various iterations to a single position.
But, as stated elsewhere, importing the vectors - preferably with covariance data - instead of the points is a much better option.
> What you have to do is give each iteration of the point a standard error (try 0.01 0.01 0.01) which allows the software to "average" the various iterations to a single position.
That's what I tried initially, but it generates the "reassignment of coordinate values" error, at least in v6.0.
> > What you have to do is give each iteration of the point a standard error (try 0.01 0.01 0.01) which allows the software to "average" the various iterations to a single position.
>
> That's what I tried initially, but it generates the "reassignment of coordinate values" error, at least in v6.0.
In Ver. 6, I think you're pretty much stuck with either generating the vectors to the point to enter into the adjustment or using a workaround method of entering the point coordinates with either covariance matrix or std error and correlations as a GPS vector with DX=0, DY=0, DZ=0. If you discover some alternate method, I'd be interested to hear about it.
I suppose you could enter the coordinates of repeat RTK guesses (with uncertainties), assigning a different Point ID to each and then enter the condition that the distance from each to the Point ID of the adjusted point was some very small number like 0.001 ft. with a DeltaH of similar size.
It is great to see my old friend Dean coming out from the lurking shadows.
I will have to remember to reach out to you for some hand holding the next time I venture into the world of least squares adjustments.
> I suppose you could enter the coordinates of repeat RTK guesses (with uncertainties), assigning a different Point ID to each and then enter the condition that the distance from each to the Point ID of the adjusted point was some very small number like 0.001 ft. with a DeltaH of similar size.
I just tried that one and found that it didn't work.
That is interesting that Star*Net has the command to allow one to use a suffix.
But, I will never understand why people don't call the point the same every time they occupy it? What is the advantage of calling a point something different every time it is used? I have found this to be a common practice, but do not understand the why of it.
> What is the advantage of calling a point something different every time it is used?
The one circumstance in which I find this useful is when I'm monitoring the point for movement. Otherwise, I prefer to use the same designation every time the point is positioned.
