I am looking for the best way to process years of continuous data on our base station and to develop a time series plot of x,y,z.
PAGE-NT can batch plot, but I would need to mine the single CORS and broadcast emphemeris for years of data.?ÿ The issue is that the results come in a combined.sum file and it would be thousands (approx. 1000 days or 2000 - 12 hr files) of cut and paste processes to get that data into a way to compare x, y, z.?ÿ Also for QA the whole process would need to be repeated to reference another CORS?ÿ
OPUS projects cannot batch, but can process the base station in relation to specific multiple CORS to get an averaged position, but that means thousands of emails and still cut and past process.
Trimble RTX is a magic black hole that just spits back results, but does look like I can batch, but I really have no input on the results.
Trimble Business Center can process all the data, but I would still need to mine the CORS, much like PAGE-NT.?ÿ I believe this is the closest i can get to the easy button.?ÿ?ÿ
?ÿ
My goal is to have a survey tech sit there and process dump the data and organize it in a useful format, so the simpler the better.
?ÿ
I would appreciate any advice or recommendations.
?ÿ
Brad
I don't have a magic bullet, but I'll offer these notes:
You're going to have to figure out how to deal with CORS movement, as well as the movement of your own base station.?ÿ What I've done for longitudinal projects in which relative movement is paramount?ÿ is pick a set of relatively stable CORS in my region and fix their positions.
My experience with TBC is that it bogs down with large numbers of files.?ÿ Simple things like changing antenna heights or reference points becomes an annoying game of waiting for the application to respond.
Thanks for those notes:
The base station is fixed on a pole with a concrete base, so height will always be zero.?ÿ
I did upload over 2200 12 hour .T01 files to TBC and the program is not responding.
Here the fixed plate (North American Plate) isn't very fixed.?ÿ We are drifting approximately 1' every 10 years northwest (relative to ITRF).?ÿ I've seen some really confused engineers (and surveyors) on why their SPC doesn't match the location of a point.?ÿ Also, we are moving tenths of feet for every geoid iteration.?ÿ So a campus projection is quickly outdated.?ÿ ( https://sf.curbed.com/2018/3/8/17096206/san-francisco-sinking-sea-level-rise-climate-change)
?ÿP181 & P222 have long term series plots with typical horizontal movement of North: -10mm and East: +5mm.?ÿ Both of these values are what I would consider survey accuracy.?ÿ The Up: has a 40 mm swing which is the primary area of focus.?ÿ I am hoping to get useful data to see how consolidation of the underlying bay mud is occurring and if seasonal fluctuations impede this consolidation.
I planned on analyzing the data in IGb08 epoch 2005.00.?ÿ This way the drift of the CORS can be compared with the solved base position and any movement beyond the CORS movement will be known.
It's looking more and more like data mining NGS for RINEX, orbits and broadcast data and processing these to a single CORS.?ÿ?ÿ
I guess I should reach out to the NGS advisor on this one.
?ÿ
Thanks again,
Brad
?ÿ
I think I would process every X number of days rather than all of the data. For example, if you have all 24 hours files, maybe process every 7 days??ÿ?ÿ
I would definitely consider RTX. Otherwise you are relying on the stability of CORS station(s) which might not be so stable. In addition to the pdf, it also sends an xml file back, this can be parsed to read the pertinent data, which is what I do.?ÿ?ÿ
?ÿ
WOW, fascinating science project (what blast).
I know how I would do it, and it would take me quite a while just to set it up, not to mention the processing and analysis of the results.
Similar to what John mentioned above, I would NOT try and process "every day," but deal with weeks instead. Probably along the lines of creating 47 hour 59 minute files centered on GPS Midnight between Sunday & Monday for each week (1000 files would end up being about 143 files).
I would be tempted to wait for the NGS to get the CORS into igs14 (if possible), and use OPUS_Static for the processing.
CORS selection would be CRITICAL, and I would stick with the igs14 (or igs08) solution at the mean epoch of each ~48hr observation (Sunday Midnight).?ÿ
From there you would have some solid data to play with, that hasn't been manipulated by modeled (HTDP) velocities. Due to the use of linear velocities on the CORS by the NGS, there would still be some significant noise in the data, but you may be able to model some of that out yourself.
I as understand the new igs14 solution (maybe erroneously), the igs used non-linear velocities in this latest igs solution.
Just my 2 bits.
Loyal
John great suggestion, it seems like RTX will give me the desired results.
Loyal as a comparison, I have been uploading the RINEX files to OPUS projects and will compare the results.
From the RTX, transformed to NAD 83 and over the course of 26 months, my base station has moved northwesterly 65?ø, 0.27 feet and sank 0.07'.?ÿ?ÿ
Using the same initial point and the predicting velocity, my base has moved an extra 0.05' over that time span and sank almost the full 0.07'.
Brad
Right now it appears we are moving faster than the surrounding CORS, which is what has been observed.
.01' per month, that is fast!!
And yes, that really confuses engineers,,,,,,,,,and surveyors. At least some of them.