Typically an 'evergreen' article is one that you can write, put in a drawer and pull out anytime to fill empty space in a publication.
In this case, here are two articles that (unfortunately) just keep coming back in style:
From 2 October 2013:
?ÿ [ Seven Free Alternatives to OPUS GPS Post-Processing During U.S. Federal Government Shutdown?ÿ]
From 'The American Surveyor' sometime in March 2015:
?ÿ [ Link ]
?ÿ [ If the link does not work:?ÿ
?ÿ]
Note: If you are using Javad equipment, DPOS is a great alternative. I did not list it in either article because it did not exist when then articles were written. But it does exist now.
I won't say anything more, I don't want to trigger Mr. Harness's 'Politics' filter.?ÿ
???
Note: If you are using Javad equipment, DPOS is a great alternative.
A DPOS sever has been opened up to temporarily allow RINEX files from any receiver to be submitted and processed while OPUS is shutdown.?ÿ It is available for anyone to try at?ÿ https://dpos-dev.javad.com/jca/#/dpos/upload .?ÿ New users will just need to register for a free account.
A very generous gesture on the part of Javad.?ÿ A couple of notes:
1.?ÿ Data from CORS that are owned by NGS appears to be unavailable, but co-op stations (e.g. the PBO network in California) don't appear to be affected.?ÿ Your location may not be in range of stations with available data.?ÿ I'm not sure what the range cutoff is, but I got a couple of "No CORS in range" errors when I selected a distant network.
2.?ÿ The server appears only to be accepting RINEX files dated this year (*.18o) (and maybe *.19o?).?ÿ Not an unreasonable limitation, under the circumstances, but I wouldn't think the server would get overloaded even if older files were allowed.
I guess the ftp servers are down as well. I can't seem to access them or I have an old link.
I just accessed the ftp data for yesterday:
ftp://www.ngs.noaa.gov/cors/rinex/2018/dec26
Had I any GPS work this week, I have available more than 9 nearby CORS and could even do an OPUS-RS myself if I wanted to dig out my old RSGPS software. It was two computers ago that I did any of that. It was always easier to use my post processing software, I just would just bring in my OPUS-S/RS positions as a check.?ÿ
Paul in PA
Mark's article is a wonderful resource. One of the limitations of some of the processing services is that they output in the current epoch of the latest realization of ITRF which is a couple of meters from NAD83. DPOS applies HTDP to the ITRF position to give a true NAD83 position. I am unsure how other services address this.
A very generous gesture on the part of Javad.
And good advertising.
1.?ÿ Data from CORS that are owned by NGS appears to be unavailable, but co-op stations (e.g. the PBO network in California) don't appear to be affected.
The Iowa DOT network and Missouri DNR stations appear to be included.
?ÿYour location may not be in range of stations with available data.?ÿ I'm not sure what the range cutoff is, but I got a couple of "No CORS in range" errors when I selected a distant network.
Did you explore the difference between JUSTIN and GIODIS processing on the Javad site??ÿ I just encountered this and don't know the details.
- - - - - - -
I just tried DPOS to compare to the OPUS-S rapid orbit solution I ran on Christmas, and DPOS gives 7 mm south, 3 east, 24 mm up from OPUS - not bad agreement.?ÿ
It also shows smaller uncertainty values than OPUS, 3, 4, 4 mm versus?ÿ 7, 4, 22 mm.?ÿ Are those pk-pk for the five stations (including the three used by OPUS)??ÿ Is DPOS really that much better, or does it have better data than OPUS did 2 days ago?
A very generous gesture on the part of Javad.?ÿ A couple of notes:
1.?ÿ Data from CORS that are owned by NGS appears to be unavailable, but co-op stations (e.g. the PBO network in California) don't appear to be affected.?ÿ Your location may not be in range of stations with available data.?ÿ I'm not sure what the range cutoff is, but I got a couple of "No CORS in range" errors when I selected a distant network.
2.?ÿ The server appears only to be accepting RINEX files dated this year (*.18o) (and maybe *.19o?).?ÿ Not an unreasonable limitation, under the circumstances, but I wouldn't think the server would get overloaded even if older files were allowed.
Jim,
were you using US CORS or IGS for the network?
DPOS is using 2x the signals and depending upon your epoch rate, it may be using 6x more epochs of data.
were you using US CORS or IGS for the network?
I tried CORS (US), Oregon (US) and Dagestan (Russia) (just for fun).?ÿ CORS (US) is the only one that worked, likely because I have a lot of PBO stations in the area.
I noticed a minor problem in the DPOS detailed report.?ÿ It appears they compute back azimuth between stations as forward azimuth+180, which is seriously wrong over those distances.?ÿ The forward az from CORS to my point matched NGS FORWARD to 0.0001 second on one mostly east-west line.?ÿ The back az was 15' 43+" off.
2.?ÿ The server appears only to be accepting RINEX files dated this year (*.18o) (and maybe *.19o?).?ÿ Not an unreasonable limitation, under the circumstances, but I wouldn't think the server would get overloaded even if older files were allowed.
The list it gives when you click on the box is .jps, .18o, .19o, .20o, .21o, .22o, .23o, .24o, .25o
A long way into the future but little history.
A very generous gesture on the part of Javad.?ÿ A couple of notes:
1.?ÿ Data from CORS that are owned by NGS appears to be unavailable, but co-op stations (e.g. the PBO network in California) don't appear to be affected.?ÿ Your location may not be in range of stations with available data.?ÿ I'm not sure what the range cutoff is, but I got a couple of "No CORS in range" errors when I selected a distant network.
2.?ÿ The server appears only to be accepting RINEX files dated this year (*.18o) (and maybe *.19o?).?ÿ Not an unreasonable limitation, under the circumstances, but I wouldn't think the server would get overloaded even if older files were allowed.
Jim, you might try using the Giodis engine instead of the Justin engine. The Giodis engine is designed for long baselines (up to 2000km) while Justin is suited for shorter baselines (less than 600km).
I guess all of the links to tools one might need for intg and htdp in the How-To article won't work because they are on an NGS server
I just put a copy of the NGS tools that I use here:
?ÿ https://ig8g.com/out/NGS/index.html
Specifically:
?ÿ [ GEOID12B and Intg ]?ÿ
and
?ÿ [ HTDP ]
The NGS ftp server is still working, so you can still get current versions of data sheets:
?ÿ [ Datasheets ]
?ÿ
I guess all of the links to tools one might need for intg and htdp in the How-To article won't work because they are on an NGS server
I just put a copy of the NGS tools that I use here:
?ÿ https://ig8g.com/out/NGS/index.html
Specifically:
?ÿ [ GEOID12B and Intg ]?ÿ
and
?ÿ [ HTDP ]
The NGS ftp server is still working, so you can still get current versions of data sheets:
?ÿ [ Datasheets ]
?ÿ
Time to bump this to the top...
You can get HTDP (and other good stuff) using Mark's links above.
The HTDP User Guide explains a lot!
Loyal