dmyhill, post: 347983, member: 1137 wrote: Yes. I think that most of us, in our processing software use the LSA, whatever it looks like, after deciding what to hold as our control. This likely leads us to preferring multiple baselines, simply because it helps us analyze our results, not to mention increasing our confidence. The extra step of exporting to StarNet is fine, if your post processing software doesn't support conventional measurements.
Okay, there clearly is a disconnect in this discussion if so many posters are unaware of the possibility of using conventional measurements between control points positioned by GPS as a condition to improve the accuracy of the GPS-derived positions. That was sort of the point of the thread to show by a real world example what is easily possible when conventional measurements and GPS vectors are simultaneously adjusted in combination.
In the example I mentioned, the one fixed control point was the CORS antenna about 7.7km distant. Everything else was adjusted using the standard errors of observations and, in the case of the GPS vectors, the covariances of the vector components. The conventional measurements provided a very good check on the GPS vectors as well as a condition by which they were adjusted.
Paul in PA, post: 347953, member: 236 wrote: What Kent appears to be emphasizing is that he likes to do least squares combining his individual GPS positions and his traverse points. I find that usually unnecessary as by using multiple GPS receivers my GPS software performs an LS adjustment without any specific input from me. If I can overly the GPS with my traverse within my tolerance I am done, GPS has confirmed I have met certain conditions of accuracy. Depending on the complexity of my traverse I may elect to hold my GPS elevations over my traverse elevations as I compare the care used in the field work. In some cases I may hold GPS over traverse points in some areas but not the whole project, especially if I am still adding to my work.
So what I get out of that is that you don't think that you can make conventional measurements that are sufficiently good to use as conditions for adjusting GPS vectors. In the example I posted the average distance between control points was probably about 360 ft. If a surveyor finds measuring angles and distances between control points about 360 ft. apart a challenge, he or she may have skipped a few classes, but that doesn't mean it isn't easy to do.
Again Kent is missing the point, multiple CORS are used to get different possible combinations of common satellites that you do not have with a single CORS.
When the CORS antennas are tracking all in view, what satellites are you thinking won't show up in the record of any CORS site? None? A CORS antenna is a much different case than the base receiver that may be occupying a point with less than horizon-to-horizon sky view and the two situations should not be treated as identical, obviously as I think some posters are doing.
dmyhill, post: 347982, member: 1137 wrote: And even though it strikes you as unlikely, in practice it has been the case.
My suspicion would be that you are adjusting two highly correlated vectors to a common point as if they are actually independent vectors. Of course they aren't if they both use exactly the same observations at the rover/unknown point, but if you treat them as such it will make the results appear to be better than they are.
If one is going to do that, the very best way of testing the reality of the results is simply by connecting them by high-quality conventional measurements and adjusting a traverse run through the GPS points, using the supposed uncertainties in the GPS vectors to weight the GPS points as conditions in the adjustment.
My money will be on the GPS points turning out to be not as excellent as believed from just the statistics of the GPS-only adjustment.
Kent McMillan, post: 348046, member: 3 wrote: So what I get out of that is that you don't think that you can make conventional measurements that are sufficiently good to use as conditions for adjusting GPS vectors. In the example I posted the average distance between control points was probably about 360 ft. If a surveyor finds measuring angles and distances between control points about 360 ft. apart a challenge, he or she may have skipped a few classes, but that doesn't mean it isn't easy to do.
When the CORS antennas are tracking all in view, what satellites are you thinking won't show up in the record of any CORS site? None? A CORS antenna is a much different case than the base receiver that may be occupying a point with less than horizon-to-horizon sky view and the two situations should not be treated as identical, obviously as I think some posters are doing.
In general my traverse measurements are more precise than my GPS, however I see little need to adjust my GPS since my positional tolerances are well within the acceptable range.
CORS antennas do track all in view but that does not mean all satellites are in fact in view. I have dealt with sufficient CORS in eight states to know that quite a few do not have an ideal sky view. So yes I may see a variance in satellites, I'll admit now less so than in the past. I have a CORS that is less than 8 miles from home, yet OPUS-RS has chosen not to use it for quality reasons more than 90% of the time. OPUS-RS chose not to use a CORS within a few miles of my submitted TX files in this thread. I do not know why, but I accept that they know more than I.
You on the other hand assume you know more than the OPUS operation.
Whatever receiver I consider my base I treat with more respect than any one of the CORS because it is within my area of survey. I may well have other receivers that I have OPUS-S or RS solutions for but they are used only for reference.
Were you to use the accepted OPUS logic you would solve your menagerie of positions from 3 CORS then use LS to mean the positions and not the vectors. Positions are what we resolve in surveying, then we report the vectors between those positions as bearings and distances with elevations being a separate issue.
Paul in PA
Paul in PA, post: 348107, member: 236 wrote: In general my traverse measurements are more precise than my GPS, however I see little need to adjust my GPS since my positional tolerances are well within the acceptable range.
That really makes no sense at all if you admit that you are able to measure the directions, distances, and height differences between control points positioned by GPS more accurately conventionally than you are able to derive them via GPS. Is the problem really that you don't have the means to adjust both GPS and convention at the same time?
The large advantage to the method described in my example is that one does use the conventional measurements to improve the GPS-derived positions and derive directions, distances, and height differences between control points that are considerably better than can be had via GPS for any reasonable effort.
Paul in PA, post: 348107, member: 236 wrote: In general my traverse measurements are more precise than my GPS, however I see little need to adjust my GPS since my positional tolerances are well within the acceptable range.
CORS antennas do track all in view but that does not mean all satellites are in fact in view. I have dealt with sufficient CORS in eight states to know that quite a few do not have an ideal sky view. So yes I may see a variance in satellites, I'll admit now less so than in the past. I have a CORS that is less than 8 miles from home, yet OPUS-RS has chosen not to use it for quality reasons more than 90% of the time. OPUS-RS chose not to use a CORS within a few miles of my submitted TX files in this thread. I do not know why, but I accept that they know more than I.
You on the other hand assume you know more than the OPUS operation.
Whatever receiver I consider my base I treat with more respect than any one of the CORS because it is within my area of survey. I may well have other receivers that I have OPUS-S or RS solutions for but they are used only for reference.
Were you to use the accepted OPUS logic you would solve your menagerie of positions from 3 CORS then use LS to mean the positions and not the vectors. Positions are what we resolve in surveying, then we report the vectors between those positions as bearings and distances with elevations being a separate issue.
Paul in PA
I don't spend a lot of time using OPUS for a number of reasons, but when I do it has never sent me a solution from one CORS, even one very close.
I suppose since you can request the CORS you want you could maybe try request only a particular one.
Never tried that.
But there are more important reasons to use more than one point for fixed control on a static survey than just the atmosphere or CORS shifting.
As we all know there are more than one set of numbers attached to any CORS and a downloaded file from a CORS station can come with it's own autonomous position which has been known to be set as the point processing is done from.
The coordinate can be imputed into the processing engine incorrectly, the wrong realization of the coordinates might be attached.
Because of these reasons using two or three base points will eliminate much of the blunders and errors, and if the control is published it can be checked to confirm that the correct numbers were used, the correct realization, and the correct units, say us survey feet vs. international feel.
Nothing is foolproof, but this is how static rules came about, chose to follow them if you wish or not.
It seems that you are a stickler for them and I try to be, but just like Kent I will sometimes use the one point CORS processing, I just don't do control that way.
MightyMoe, post: 348127, member: 700 wrote: But there are more important reasons to use more than one point for fixed control on a static survey than just the atmosphere or CORS shifting.
[...]
The coordinate can be imputed into the processing engine incorrectly, the wrong realization of the coordinates might be attached.
Because of these reasons using two or three base points will eliminate much of the blunders and errors, and if the control is published it can be checked to confirm that the correct numbers were used, the correct realization, and the correct units, say us survey feet vs. international feel.
Okay, so the reason you'd want to use more than one CORS site to derive NAD83 coordinates is to satisfy yourself that you entered the coordinates of the CORS antenna correctly? I'd think that any surveyor would be entering the latitude, longitude, and ellipsoid height of the CORS antenna directly from an NGS data sheet and sticking the same data sheet in the file. There is no US Feet vs. International Feet issue with geographic positions and the ellipsoid height will be in meters.
I can see that if a surveyor is running an entirely push-button operation and never examining the coordinates of CORS sites, he or she might get really nervous about what was being produced and want to have all sorts of checks. For the rest of us, comparing three numbers to the values used in an adjustment doesn't strike me as impossibly burdensome.
Kent McMillan, post: 348119, member: 3 wrote: That really makes no sense at all if you admit that you are able to measure the directions, distances, and height differences between control points positioned by GPS more accurately conventionally than you are able to derive them via GPS. Is the problem really that you don't have the means to adjust both GPS and convention at the same time?
The large advantage to the method described in my example is that one does use the conventional measurements to improve the GPS-derived positions and derive directions, distances, and height differences between control points that are considerably better than can be had via GPS for any reasonable effort.
Why would I want to adjust my GPS to match my traverse? It is not that I cannot, but it is not worth the effort. GPS tells me where I am, my traverse does the heavy lifting from there. When I am into many acres I may rely on GPS for elevation differences. If I am relying on GPS to close my traverse, I may mean the difference for elevation, but not for anything else.
Paul in PA
Paul in PA, post: 348157, member: 236 wrote: Why would I want to adjust my GPS to match my traverse? It is not that I cannot, but it is not worth the effort.
Using Star*Net, it actually takes no more effort to adjust conventional measurements with GPS vectors than it does to adjust either one separately. The obvious advantage is that the two are independent classes of observations that validate and improve each other and the whole.
The drawback, of course, is that one has to have realistic estimates of the standard errors of the conventional measurements. Presumably, a surveyor will already have those if he or she is performing an LSA on them.
Kent McMillan, post: 348134, member: 3 wrote: Okay, so the reason you'd want to use more than one CORS site to derive NAD83 coordinates is to satisfy yourself that you entered the coordinates of the CORS antenna correctly? I'd think that any surveyor would be entering the latitude, longitude, and ellipsoid height of the CORS antenna directly from an NGS data sheet and sticking the same data sheet in the file. There is no US Feet vs. International Feet issue with geographic positions and the ellipsoid height will be in meters.
I can see that if a surveyor is running an entirely push-button operation and never examining the coordinates of CORS sites, he or she might get really nervous about what was being produced and want to have all sorts of checks. For the rest of us, comparing three numbers to the values used in an adjustment doesn't strike me as impossibly burdensome.
Part of the job, in the client's handbook, and what is expected for control surveys.
Cut corners however you wish, but adding another fixed point (or two, or three) is a trivial matter, and not up for negotiation.
And yes CORS are also in the handbook. The latest version discusses NAD83 (2007)
Kent McMillan, post: 347821, member: 3 wrote: This may be contrary to what the engineers at the DOT are telling you, but static surveying can be done perfectly well from one point. I think you probably have situation in mind where the coordinate system of the control points has some ill-defined relationship to ITRF and you need at least two points to solve that relationship.
In the case of a CORS antenna, there is, of course, no such problem and, in any event, the effect of non-identity of NAD83 and ITRF over vectors under 10km in length is trivial for any conceivable DOT-type purpose. I'm a bit surprised that this is news in any way.
My reaction to a one CORS network is that the user is precluded of several benefits:
1 a control network dependent on a single CORS cannot be fully/properly adjusted. to start from GPS/GNSS then transform into terrestrial measurements (standard projections), there needs to be a transformation DX DY DZ SCALE RX RY RZ for a typical seven parameter transformation, not to mention the fourteen parameter transformation that is sometimes used. how else can one get from ITRF to NAD83? a control network COULD be used from a single CORS, but the adjustment report should indicate that it is minimally constrained. we DO know that a minimally constrained adjustment is a good start to checking measurements for large residuals, etc. but it is only a part of the process.
2 without a minimum of three CORS, the user is precluded from any kind of accurate scaling, not to mention atmospheric/iono modeling
3 without enough control stations (as above), the user will likely not really know if their distance meter might be experiencing phase drift. yes, there are the on site vectors with the user's own receivers, but this all appears to be minimally constrained and not a robust/fully constrained adjustment, if you're smelling what i am stepping in
Moe Shetty, post: 348192, member: 138 wrote: My reaction to a one CORS network is that the user is precluded of several benefits:
1 a control network dependent on a single CORS cannot be fully/properly adjusted. to start from GPS/GNSS then transform into terrestrial measurements (standard projections), there needs to be a transformation DX DY DZ SCALE RX RY RZ for a typical seven parameter transformation, not to mention the fourteen parameter transformation that is sometimes used. how else can one get from ITRF to NAD83? a control network COULD be used from a single CORS, but the adjustment report should indicate that it is minimally constrained. we DO know that a minimally constrained adjustment is a good start to checking measurements for large residuals, etc. but it is only a part of the process.
I'm sorry, but that's just strange. The relation of the ITRF to NAD83 is well defined and the CORS sites have both NAD83 and IGS08 positions published. Wanting to use several CORS sites to reverse engineer the relationship of NAD83 to the ITRF is simply odd.
2 without a minimum of three CORS, the user is precluded from any kind of accurate scaling, not to mention atmospheric/iono modeling.
So, over distances of under 10km, what sort of "scaling" are you expecting to do? Effectively none?
3 without enough control stations (as above), the user will likely not really know if their distance meter might be experiencing phase drift. yes, there are the on site vectors with the user's own receivers, but this all appears to be minimally constrained and not a robust/fully constrained adjustment, if you're smelling what i am stepping in
Sorry, but none of that is true. If it is part of the National CORS Network, the CORS antenna will have a very good ellipsoid height determined that, when transferred to the project control, in turn gives them very good ellipsoid heights. The computation of ground distances between control points with known latitudes, longitudes, and ellipsoid heights is quite straight forward. For exactly that reason, the GPS vectors from a CORS antenna to various control points are perfectly good observations that can be adjusted in combinations with conventional observations such as angles, distances, and zenith angles or height differences.
That example that I posted of a conventional traverse network with GPS vectors from a CORS antenna to various points was highly redundant with 228 observations and 117 unknowns. I think what I have to conclude is that far too many surveyors are pretty much in the dark about the advantages of the simultaneous adjustment of GPS vectors and conventional measurements. I should put this on as a Continuing Education seminar.
Good morning, Kent. Prior to writing any new techniques concerning combined adjustments, consider the following:
The technique of starting with a free, or minimally constrained adjustment is a valid test to check for consistency internally.
The fully constrained adjustment is the widely published and generally accepted way of testing and adjusting a network.
A free, or minimally constrained network is generally going to deliver impressive results in your case, above. The fully constrained network adjustment should be applied to actual projects. Minimally constrained proves a point in a mock up such as yours posted above, yes, but when I am making bread I finish the recipe, because dough doesn't taste very good and butter won't melt in it.
Kent is mainly concerned the relative precision of his project control. If he were more concerned about network accuracy using more CORs would be more important.
Mark Mayer, post: 348330, member: 424 wrote: Kent is mainly concerned the relative precision of his project control. If he were more concerned about network accuracy using more CORs would be more important.
Yes, Mark, I am hoping that is true.
Was someone able to get you good resources for the foundation monitoring project?
A Corps of Engineers document was linked that should be helpful. It's certainly extensive. We have been slammed at work this month so my progress has been limited.
Mark Mayer, post: 348330, member: 424 wrote: Kent is mainly concerned the relative precision of his project control. If he were more concerned about network accuracy using more CORs would be more important.
Actually,,,,,,,,,,I don't think that's what Kent is saying,,,,,,,,,
But, I could be wrong,,,,,,,,,,it's difficult to really tell
Moe Shetty, post: 348327, member: 138 wrote:
The technique of starting with a free, or minimally constrained adjustment is a valid test to check for consistency internally.The fully constrained adjustment is the widely published and generally accepted way of testing and adjusting a network.
A free, or minimally constrained network is generally going to deliver impressive results in your case, above. The fully constrained network adjustment should be applied to actual projects.
I'm sorry, but if you consider a network with as much redundancy as exists in the one I posted as "minimlally constrained" you're using words to mean whatever you want them to mean. The network that I posted is a redundant framework of conventional measurements that gave excellent measurements of the figure formed by the series of control points indicated that were positioned via GPS vectors, three of which were repeated on two different days. The orientation of the conventional network was derived from the adjustment with the GPS vectors weighted by their uncertainties.
What seems to be giving you fellers problems is the idea of using GPS vectors from a single CORS site to determine the positions of things. Apparently, the superstition is that somehow a CORS antenna could just be anywhere and the only way to know for certain is to check it against some other CORS antenna. Considering that this is done daily by NGS in monitoring the National CORS network (of which the CORS site I used is a part), that premise doesn't stand scrutiny well. The other idea was that somehow different CORS antennas would have different satellites in view and that would greatly improve the results. The CORS antenna I used produced clean data from all of the satellites in view, which isn't exactly surprising for a major CORS site.
There are two CORS sites in Austin, TXAU and SAM1. NGS publishes values of network accuracy for TXAU (1.16cm 95% confidence) and does not for SAM1 as the latter is basically an auxilliary station positioned in relation to TXAU. As a point of curiosity, why would using a CORS site without any published estimate of network accuracy give any improved estimate of network accuracy?
What posters are proposing is similar to adjusting a benchmark elevation by a level run from a primary, first-order benchmark to a third-order benchmark. The reason given is that somehow that is what they think gives the best results.
Your network is minimally constrained relative to the NSRS - the CORS. It is not minimally constrained internally, of course.
