Once the opus/cors sites came back on I was able to check them against an old bench. The marks along this run don't show up doing an NGS search, so it's lucky I have the old runs in my book of local control. They may be difficult to get from the NGS.
Of course the data is in NGVD29 so the first thing is to convert them using VERCON.
Once the data was processed it looks like both OPUS and CORS are slightly low, about 0.15'. Not too bad to 3rd order bench marks run over a mountain range.
There is a data sheet in the area but the elevation for that point when reduced was off 5' so I'm throwing it out. Holding the bench marks looks like the best solution to use NAVD88, OPUS/CORS runs about the same low on local 1st order bench marks. The disturbing thing is when I calculate a solution using the south CORS point and the north CORS point I get a difference of .2' between them for ellipsoid height.
MightyMoe, post: 329389, member: 700 wrote: ... the data is in NGVD29 so the first thing is to convert them using VERCON.....
A VERTCON conversion is only an approximation based on data the NGS has in its database. If there are few NGS monuments in the area, the modelled conversion is going to be sloppy.
I'd either hold the CORS/OPUS or hold the local monument depending on the needs of the project. But I wouldn't try to make one be the other.
Norman Oklahoma, post: 329413, member: 9981 wrote: A VERTCON conversion is only an approximation based on data the NGS has in its database. If there are few NGS monuments in the area, the modelled conversion is going to be sloppy.
I'd either hold the CORS/OPUS or hold the local monument depending on the needs of the project. But I wouldn't try to make one be the other.
Yes, I'm holding the local monument.
CORS/OPUS has never produced very good elevations that I've ever seen in this area.
As far as using vertcon, it matches all the 29 to 88 conversions in the area, so it's kinda a distinction without a difference. Is it correct? who can say for sure, but it is working here so I'm using it, no one can possibly say it's wrong unless they want to make a very extensive level run up and over the mountains.
What I am sure of is that the CORS do not match each other, so they CANT be "right".
MightyMoe, post: 329389, member: 700 wrote: The disturbing thing is when I calculate a solution using the south CORS point and the north CORS point I get a difference of .2' between them for ellipsoid height.
It'd be interesting to see if the CORS-to-CORS vector follows the difference in published CORS heights. If it does, there might be a problem with the local data.
Jim Frame, post: 329459, member: 10 wrote: It'd be interesting to see if the CORS-to-CORS vector follows the difference in published CORS heights. If it does, there might be a problem with the local data.
years ago I did exactly that between those points, then one to the north was destroyed and another took it's place, now the one to the south was also removed and a new one was started up.
Back then it would show a .2' difference, not sure if the two new ones do, I assume they would.
There is about 250 miles between them so .2' isn't a big deal, it's just when you try to push it local it becomes an issue. I will use the new local cors site for elevations when I do use cors, it has been vexing for local surveyors cause they can't get it to match the historical points. For me, I just hold the bench marks and let the cors number keep bouncing. But I must say, elevation control using CORS is getting much better.
