I can start by saying I know enough about GPS/Geodesy to know that I don't know enough.
Been working with static GPS observations in TBC tying to CORS stations and can't wrap my head around the inner workings. Here is my situation:
The CORS stations are using state plane coords NAD 83 (2011) 2010.00. When I process to these stations is it using the 2010.00 epoch published value or is it using time dependent velocities to update? It looks like it is using the 2010.00 epoch without updating. If that is so, shouldn't the CORS coords be updated to the new positions? Can I say that my new processed coordinate is on epoch 2015.xx without updating the CORS published value? I realize that I am only talking about a small shift in coordinate values.
I admit that it is a bit confusing talking about it and I hope my terminology was clear enough, I hope I made my questions clear. I am in California.
Any comments would be appreciated.
Beau_Immel, post: 327277, member: 8320 wrote: I can start by saying I know enough about GPS/Geodesy to know that I don't know enough.
Been working with static GPS observations in TBC tying to CORS stations and can't wrap my head around the inner workings. Here is my situation:
The CORS stations are using state plane coords NAD 83 (2011) 2010.00. When I process to these stations is it using the 2010.00 epoch published value or is it using time dependent velocities to update? It looks like it is using the 2010.00 epoch without updating. If that is so, shouldn't the CORS coords be updated to the new positions? Can I say that my new processed coordinate is on epoch 2015.xx without updating the CORS published value? I realize that I am only talking about a small shift in coordinate values.
I admit that it is a bit confusing talking about it and I hope my terminology was clear enough, I hope I made my questions clear. I am in California.
Any comments would be appreciated.
Beau
It would be incorrect to publish your data as "epoch 2015.xx" if the CORS coordinate you are using was NAD 83 (2011) 2010.00. If you want a near realtime coord use the IGS value.
It is not correct to use epoch 2010.00 either because of movement since?
That depends on what you are trying to accomplish. If you need to deliver what amounts to realtime coords., then you need to utilize the NGS program HTDP. If you use the NAD 83 (2011) 2010.00 coords. and report your results as such, then you will be correct.
I think you are thinking that since the CORS have moved they are no longer in the same location as reported in the NAD 83 (2011) 2010.00 position and you would be correct in an absolute sense, but in a relative sense, the CORS have not moved in relation to your project because the CORS and your project have moved together. This of course presumes your project is reasonably close to the CORS you are using and there haven't been any recent tectonic plate movement in your area.
Beau_Immel, post: 327289, member: 8320 wrote: It is not correct to use epoch 2010.00 either because of movement since?
The assumption is that your project site is moving right along with your CORS so the crustal motion can be discounted for all but the most rigorous of control. I work in a high velocity area and have never made special allowance for crustal motion. I suppose if you were near a known fault, such as San Andreas, that might be different.
All this movement does mean that it is still appropriate to set control monuments somewhere near your project site that can be checked into.
I am really just messing around trying to find out what I can accomplish and the reasoning behind it. Ultimately it seems like I would want current values. In California the land is moving all the time. I thought it was a bit of a stretch to think that the CORS sites move relative to each other?
Norman Oklahoma, post: 327298, member: 9981 wrote: The assumption is that your project site is moving right along with your CORS so the crustal motion can be discounted for all but the most rigorous of control. I work in a high velocity area and have never made special allowance for crustal motion. I suppose if you were near a known fault, such as San Andreas, that might be different.
All this movement does mean that it is still appropriate to set control monuments somewhere near your project site that can be checked into.
If the goal was to have the most current coords for NAD 83 what would be the best method?
Would it be crazy to come up with new time dependent coords for the CORS sites? And process using those new coords?
Thanks for the replies so far!
The most current coords for NAD 83 are the NAD 83 (2011) 2010.00 values. You can update those values using HTDP but be sure to note that in your report. You could also occupy your control points for several hours then send the data file off to OPUS. OPUS will return both the NAD 83 (2011) 2010.00 and the IGS current values.
Beau_Immel, post: 327308, member: 8320 wrote: If the goal was to have the most current coords for NAD 83 what would be the best method?
Would it be crazy to come up with new time dependent coords for the CORS sites? And process using those new coords?
You could apply velocities to your coordinates and quote up to the minute positioning. But that would be going above and beyond the call, so to speak. And your control would be obsolete the minute you publish it.
The common practice is to hold the NAD83(2011) epoch2010.00 coordinates on the CORS and so state the fact. I might point out that it is perfectly possible, and frequently appropriate, to hold NAD83(91) values on your control and work from that.
Beau_Immel, post: 327308, member: 8320 wrote: If the goal was to have the most current coords for NAD 83 what would be the best method?
Would it be crazy to come up with new time dependent coords for the CORS sites? And process using those new coords?Thanks for the replies so far!
Beau,
The best method to use in high velocity areas is to determine the current in position for each of your control stations utilizing HTDP. Even better you can use measured velocities if the CORS are old enough. You would then process your data on the current epoch. Once you have adjusted it is common to go back to the original datum with the use of HTDP. I think you want to publish your control on a common epoch. If I am not mistaken, I think this is what OPUS does.
The real joy comes when you have a major systemic episode in the middle of your campaign. I had it happen back around 2000 when I was awoken in my hotel room by a 7+ after a really long day.
If you live anywhere but the west coast I think this is really not required since the relative movement between CORS is negligible..
John1Minor2, post: 327311, member: 404 wrote: The most current coords for NAD 83 are the NAD 83 (2011) 2010.00 values. You can update those values using HTDP but be sure to note that in your report. You could also occupy your control points for several hours then send the data file off to OPUS. OPUS will return both the NAD 83 (2011) 2010.00 and the IGS current values.
I was thinking the same thing. Submit to OPUS to get the comparative data, and notate as needed.
John Putnam, post: 327377, member: 1188 wrote: Beau,
The best method to use in high velocity areas is to determine the current in position for each of your control stations utilizing HTDP. Even better you can use measured velocities if the CORS are old enough. You would then process your data on the current epoch. Once you have adjusted it is common to go back to the original datum with the use of HTDP. I think you want to publish your control on a common epoch. If I am not mistaken, I think this is what OPUS does.
If it is assumed that crustal motion between your project and control stations is minimal, why go through the trouble of moving your control to the current epoch to process, then back again when finished? I am not sure what will be gained with this process, besides inflating accuracy reporting (assuming you keep the "current" adjustment report stapled right behind the HTDP transformed coordinates).
If the crustal motion between your project and control stations are not negligible, i.e. you are in an active crustal motion area (as I am in So. Cal.), then other considerations must take precedence. I typically look at fault lines, and which CORS fall on which side relative to my job. I find that stations on the same "plate" (not a seismologist so bare with me), are better to use than ones that straddle a fault line, even if they are much further away. My thoughts are to use the epoch coordinates for you control as necessary without adjusting back and forth with HTDP, but select your control with seismic considerations.
If you do want to process the current epoch in California, the best utility is CSRC's SECTOR ( http://sopac.ucsd.edu/sector.shtml) which one could argue is an easily verifiable, and even quasi-"published" daily coordinate value for a given CORS.
I recently worked on a 40sq mile mapping project, which was bisected by the san andreas fault. The scope required final coordinates in Epoch 2011, with a network accuracy of 2cm hz... Yikes is right
I ended up computing the displacement of each control station (CORS) using SECTOR, then essentially used their deviation from the average shift of the project as control weighting constraints when running the Least sq adjustment. Not ideal, but it worked.
