ITRS2014/IGS08 for base coordinates?

I use a Euref CORS to try and make sure that my base coordinate are as spot-on as I can get them. However, I am in doubt if I do it correctly.

I input the IGS08 position from EUREF ( ). I have also tried the ITRF14, but this position + velocities equal the IGS08 position.

I then use this position as base coordinates in RTK lib, and process my static point. According to Openstreetmap and Google maps, that places my point within cm’s of where it really is.

Does this method work, or am I just lucky in this instance?

Only thing i can comment is, dont trust google or any mapservice based on photos. Those can be way of or dead on, but you dont know for sure.

Try a different base and see if it produces a similar result

Nice idea! I’ll try that.

I can vouch for this as well, I tried using JOSM (Openstreetmap) editor with different base maps Bing, ERSI world imagery, Mapbox and Digital Globe and they all off by varying amounts. Also at cm level It’s difficult to see where is correct anyway.

Sorry to hijack this thread, I’ve found that swapping around in RTKplot Base and Rover the base of the Rover doesn’t agree with the Base - if you follow my meaning, its weird that they don’t agree ?

Alright, so,
Used 3 EUREF stations:

  • BUDP, 80 km baseline
  • SMID, 126 km baseline
  • WARN, 133 km baseline

BUDP -> SMID, 2 mm difference
BUDP -> WARN 9 mm difference
SMID -> WARN 5 mm difference

Using the IGS08 weekly position for all basestations. RMS did increase quite a bit with the additional distance, but at it’s worse, a combined 0.0228 m using WARN.

I’m a happy camper!

Next questions is now, are my findings in IGS08/ITRF2014 or WGS84? :S

1 Like

Are you using Rinex headers for this? Or precise known coordinates for both rover/base swap combinations?

Rinex headers - thinking about I answered my own question :grinning: !

1 Like

From my findings they correspond with each other IGS08 and WGS84 - but don’t take my word for it.

1 Like

Is there any way to automate downloading of precise coords rather than copy & paste, I’ve found the .SNX files but I’m not sure they are that precise.

There probably is. Maybe EZSurv got that figured out, now that they are charging that much.
At least they got auto-downloading of obs, nav etc.

The RTK- and PPK-algorithms will always just calculate the baseline (a 3D vector) between the base-antenna and the rover-antenna. It will then link one end of that vector to the base-antenna-coordinate and therefor can calculate the position of the rover which is at the other end of that vector (baseline). It will of course take antenna-height of base and rover into account.

That way the rover-coordinate will always be in the same coordinate system in which the base-antenna-coordinate is defined.

So it’s up to you in which coordinate system you want your own base and therefor your rover-surveys to be.

Here in Austria I normaly use ETRS89 coordinates because those coordinates don’t really change over time since the coordinate system is fixed to the eurasian-plate.

One thing to bear in mind is that the coordinate-system in which the base-antenna-coordinate is defined must be using the WGS84 datum (GRS80 ellipsoid).

I looked up the EUREF link and didn’t find the same coordinates for IGS08 and ITRF14

1 Like

This was what I was arriving at but can anyone confirm? I found a few good articles on the latest realization.

When using the HDTP tool from NGS here is option box.

Maintaining the same epoch as to not account for plate velocity I get the following output. The coordinates are identical at input and output.

However, it is my experience in the United States that NTRIP corrections are in NAD83. If the above is true when should we expect NTRIP corrections to also be in the latest realization? Utilizing NTRIP services would be a whole lot nicer for me in the U.S. if IGS08/IGB08 is the same as WGS84(G1762).

This topic was automatically closed 100 days after the last reply. New replies are no longer allowed.