DOT RTN / VRS guru suggestions needed.

klsnbms, post: 417266, member: 146 wrote: I think the resultant elevation numbers from NYSRTN are Dynamic Heights and not Orthometric Elevations.

Whatever the source of the difference, I would think this agreement with dynamic to be a coincidence, not a real explanation.

Do they explain how the elevations are derived? GNSS has to find ellipsoidal height and then use a geoid model to get to orthometric. They would have to have made a conscious decision to do different computations for dynamic.

Bill93, post: 417279, member: 87 wrote: Whatever the source of the difference, I would think this agreement with dynamic to be a coincidence, not a real explanation.

Do they explain how the elevations are derived? GNSS has to find ellipsoidal height and then use a geoid model to get to orthometric. They would have to have made a conscious decision to do different computations for dynamic.

KeyNet had no real answers about the inter workings of the system. I think Trimble set it up and they just "administer" . Still haven't heard back from them.

ALL RTN's if in "sync" with NGS CORS will have a certain number of National CORS fixed to which the network operator adjusts their network. This will produce Latitude/Longitude and Ellipsoid Heights consistent with the NSRS. To that, if you apply GEOID12B you will get GNSS derived heights with the error of the derived ellipsoid heights plus geoid model in the mix, rarely will you get exactly the same values as published orthometric heights on solid BM's. I am aware some RTN's have tried to adjust or provide some means (custom geoid model or "adjusted" ellipsoid heights) to try and get orthometric heights that more closely match BM's over the coverage area, but by and large that isn't the case and thankfully so!

I know this is all basic stuff, BUT I think it is unrealistic to expect millimeter level orthometric heights from ANY GNSS derived height (some methods do produce better results than others however). With a RTN you add to the error model by mixing and matching antennas, antenna modeling and to some extent various vendor's software on the server end and it is a wonder anything works.

As is becoming obvious in this thread you also have folks selling subscriptions on a network that has no metadata associated with it and can't tell you the origin of the coordinates. Not picking on anyone here, I have run into the same elsewhere in the USA, but is becoming rarer.

I think it is just good professional practice to know how well ANY differential GNSS system performs in the real world, it is very likely they all give a decent difference from "base" to rover, but you still may need to transform the results to something more localized if you really want to fit the local control.

In the particular situation under discussion, I would expect antenna modeling/offsets and basis of the networks to be the primary factors causing grief, both out of control of the end user.

SHG

Shelby H. Griggs PLS, post: 417320, member: 335 wrote: ALL RTN's if in "sync" with NGS CORS will have a certain number of National CORS fixed to which the network operator adjusts their network. This will produce Latitude/Longitude and Ellipsoid Heights consistent with the NSRS. To that, if you apply GEOID12B you will get GNSS derived heights with the error of the derived ellipsoid heights plus geoid model in the mix, rarely will you get exactly the same values as published orthometric heights on solid BM's. I am aware some RTN's have tried to adjust or provide some means (custom geoid model or "adjusted" ellipsoid heights) to try and get orthometric heights that more closely match BM's over the coverage area, but by and large that isn't the case and thankfully so!

I know this is all basic stuff, BUT I think it is unrealistic to expect millimeter level orthometric heights from ANY GNSS derived height (some methods do produce better results than others however). With a RTN you add to the error model by mixing and matching antennas, antenna modeling and to some extent various vendor's software on the server end and it is a wonder anything works.

As is becoming obvious in this thread you also have folks selling subscriptions on a network that has no metadata associated with it and can't tell you the origin of the coordinates. Not picking on anyone here, I have run into the same elsewhere in the USA, but is becoming rarer.

I think it is just good professional practice to know how well ANY differential GNSS system performs in the real world, it is very likely they all give a decent difference from "base" to rover, but you still may need to transform the results to something more localized if you really want to fit the local control.

In the particular situation under discussion, I would expect antenna modeling/offsets and basis of the networks to be the primary factors causing grief, both out of control of the end user.

SHG

I am by no means expecting an exact match to published elevations but I am extremely concerned that our 2 GPS subscriptions give us a 0.3' elevation difference between each other. If it was 0.05' I'd not worry so much.

Luke J. Crawford, post: 417325, member: 11382 wrote: I am by no means expecting an exact match to published elevations but I am extremely concerned that our 2 GPS subscriptions give us a 0.3' elevation difference between each other. If it was 0.05' I'd not worry so much.

Shelby H. Griggs PLS, post: 417320, member: 335 wrote: ALL RTN's if in "sync" with NGS CORS will have a certain number of National CORS fixed to which the network operator adjusts their network. This will produce Latitude/Longitude and Ellipsoid Heights consistent with the NSRS. To that, if you apply GEOID12B you will get GNSS derived heights with the error of the derived ellipsoid heights plus geoid model in the mix, rarely will you get exactly the same values as published orthometric heights on solid BM's. I am aware some RTN's have tried to adjust or provide some means (custom geoid model or "adjusted" ellipsoid heights) to try and get orthometric heights that more closely match BM's over the coverage area, but by and large that isn't the case and thankfully so!

I know this is all basic stuff, BUT I think it is unrealistic to expect millimeter level orthometric heights from ANY GNSS derived height (some methods do produce better results than others however). With a RTN you add to the error model by mixing and matching antennas, antenna modeling and to some extent various vendor's software on the server end and it is a wonder anything works.

As is becoming obvious in this thread you also have folks selling subscriptions on a network that has no metadata associated with it and can't tell you the origin of the coordinates. Not picking on anyone here, I have run into the same elsewhere in the USA, but is becoming rarer.

I think it is just good professional practice to know how well ANY differential GNSS system performs in the real world, it is very likely they all give a decent difference from "base" to rover, but you still may need to transform the results to something more localized if you really want to fit the local control.

In the particular situation under discussion, I would expect antenna modeling/offsets and basis of the networks to be the primary factors causing grief, both out of control of the end user.

SHG

I think the lack of data associated with the VRS may be an issue. I am by no means a VRS how/why expert but it seems that there nis a lack of provable data associated with it unlike the NYSNet in which you have all mount point information. I believe that their is also a disconnect between displayed (local) accuracy and real positional accuracy with VRS. When it creates the station close to you, the baseline is suddenly short and displayed RMS values reflect that, not accounting that the virtual base was created from what could be a very long baseline. Like being in exactly the wrong spot.

Luke J. Crawford, post: 417327, member: 11382 wrote: I think the lack of data associated with the VRS may be an issue. I am by no means a VRS how/why expert but it seems that there nis a lack of provable data associated with it unlike the NYSNet in which you have all mount point information. I believe that their is also a disconnect between displayed (local) accuracy and real positional accuracy with VRS. When it creates the station close to you, the baseline is suddenly short and displayed RMS values reflect that, not accounting that the virtual base was created from what could be a very long baseline. Like being in exactly the wrong spot.

I always wondered how VRS/RTN's work with NAVD88, sounds like they have issues, it's good that you are checking into it. Keep us all informed what you discover.

I have not seen any problems with Keynet, but I have not used it in the area the original poster mentioned. I did discover a problem years ago in Maine, where a DOT run station had a height that was way off, several decimeters if I recall correctly.

If I were running a VRS I would be processing the CORS on daily basis to check the positions (one reason is to make sure an antenna doesn't move either horizontally or vertically) and also I would periodically go out with a rover unit and occupy published positions. One fairly simple way to do this would be to submit the 24 hour files to Trimble RTX, which is a PPP service. Or submit to OPUS. And I would do all of this on ITRF and THEN convert to NAD83 (2011).

The way they should be doing it is to constrain their network rigidly to National CORS. This means looking at time series, because we all know that some CORS "drift" off of their published positions for whatever reason, and NGS is loathe to update published coordinates unless a certain tolerance is exceeded. I definitely do NOT believe they should have anything other than TRUE ellipsoidal heights at their CORS and in their solutions. How could they not? Well, if they try to fit local benchmarks, the only way to do that is to produce "pseudo-ellipsoidal" heights that, when combined with a geoid model, will match the BM's. Note that VRS's do not "broadcast" ortho heights, the solution obtained is an ellipsoidal height. This, combined with a geoid model (GEOID12B) will get close to NAVD88 (hopefully). Of course there are areas where GEOID12B gets closer than others. In my mind a better way to deal with any inaccuracies in the geoid model is to create a local model.

We recently observed a point in southern VA using Keynet (station in VA) and the NC VRS network (station in NC), agreement was about 1 cm in all three dimensions. Keynet probably uses the NC station in their solution, and perhaps NC uses the Keynet station, but I would think the same would apply at the border between Keynet and NYDOT network. Even though they are different brands (Leica vs Trimble), I would hope that different operators would share data at the fringes in order to make things seamless as possible. I will say that I have seen strange (i.e. pathological) behavior at the edges of VRS networks.

So, I would hope (and expect) that Keynet is using true ellipsoidal heights. If that is the case, then I believe the only explanation (assuming NYDOT is also using true ellipsoidal heights) is an HI problem, or, more specifically, a "where is it measured to" problem.

And, dynamic heights have NOTHING to do with this. I look forward to hearing the reason for the discrepancy. Hopefully Luke will post whatever he finds out.

John Hamilton, post: 417336, member: 640 wrote: I have not seen any problems with Keynet, but I have not used it in the area the original poster mentioned. I did discover a problem years ago in Maine, where a DOT run station had a height that was way off, several decimeters if I recall correctly.

If I were running a VRS I would be processing the CORS on daily basis to check the positions (one reason is to make sure an antenna doesn't move either horizontally or vertically) and also I would periodically go out with a rover unit and occupy published positions. One fairly simple way to do this would be to submit the 24 hour files to Trimble RTX, which is a PPP service. Or submit to OPUS. And I would do all of this on ITRF and THEN convert to NAD83 (2011).

The way they should be doing it is to constrain their network rigidly to National CORS. This means looking at time series, because we all know that some CORS "drift" off of their published positions for whatever reason, and NGS is loathe to update published coordinates unless a certain tolerance is exceeded. I definitely do NOT believe they should have anything other than TRUE ellipsoidal heights at their CORS and in their solutions. How could they not? Well, if they try to fit local benchmarks, the only way to do that is to produce "pseudo-ellipsoidal" heights that, when combined with a geoid model, will match the BM's. Note that VRS's do not "broadcast" ortho heights, the solution obtained is an ellipsoidal height. This, combined with a geoid model (GEOID12B) will get close to NAVD88 (hopefully). Of course there are areas where GEOID12B gets closer than others. In my mind a better way to deal with any inaccuracies in the geoid model is to create a local model.

We recently observed a point in southern VA using Keynet (station in VA) and the NC VRS network (station in NC), agreement was about 1 cm in all three dimensions. Keynet probably uses the NC station in their solution, and perhaps NC uses the Keynet station, but I would think the same would apply at the border between Keynet and NYDOT network. Even though they are different brands (Leica vs Trimble), I would hope that different operators would share data at the fringes in order to make things seamless as possible. I will say that I have seen strange (i.e. pathological) behavior at the edges of VRS networks.

So, I would hope (and expect) that Keynet is using true ellipsoidal heights. If that is the case, then I believe the only explanation (assuming NYDOT is also using true ellipsoidal heights) is an HI problem, or, more specifically, a "where is it measured to" problem.

And, dynamic heights have NOTHING to do with this. I look forward to hearing the reason for the discrepancy. Hopefully Luke will post whatever he finds out.

I'd imagine VRS to VRS would be closer than VRS to fixed mount points (near or max) as the NYSDOT system is. We're processing directly to their CORS stations via the NTRIP server. Since this involves a true baseline length and not a line to a virtual station (shortened) it seems differences would be more apparent. Yesterday I took both units (GS16 & R8)to a site in NYC where the R8 on KeyNet could pull from the KeyNet Trimble points in NJ and it matched the NYSNet within .03'V. Maybe a base antenna offset issue or just coincidence. Considering the DOT here uses the NYSNet on construction projects I'd like to think that the system is all sorted. Assumptions...

I had a recent project near Philadelphia where the scope called for me to do long static obs on 5 existing stations, and tie in 6 BM's, and then adjust the VRS observations horizontally to OPUS-DB solutions of the five and vertically to NAVD88 elevations on the benchmarks. There was a definite E-W trend in the benchmarks. I can't say whether that is in the leveling or in the geoid model, but it was definitely there, as shown in the map below:

One of the five stations I did 5 hour static on was a station that had been bluebooked in 1998 by a private company for the Turnpike Commission. The elevation of the OPUS solution missed the published by 0.59 m (1.94 feet). I got a warning email from OPUS admin that something was wrong. We then VRS'd it and did a fast static obs, all agreed. It was obvious that whoever did the work in 1998 had a bad HI (probably a 2 foot bust, maybe they used to 30 cm extensions), and it was not caught because there was not another independent occupation of the station. And I verified that it had not been disturbed or moved. Horizontally the VRS occupations of the suspect mark agreed 1.6 cm versus published and 0.005 m versus OPUS solution.

The point is that you cannot always count on published elevations to be better than what is obtained with VRS.

No answers from KeyNet. Think we will be switching to Leica SmartNet for out of state work.

I did have a few problems this week with Keynet, in two very different locations (different states). I was having a lot of "switching to new base" messages, where it would not get all the way to 180 epochs, but it would switch over to a different base and start over, or it would say "no base data". The latter message MAY have been due to my failing cell phone which I was using as a hot spot, not sure if that was a coincidence. I was in an area of good cell service. The phone totally died (won't power up) at the end of the day yesterday, fortunately after I completed my work which was 250+ miles away from home. I could have switched over to the sim card in the R10 if the phone would have died during the job, nice to have that as a backup.

But, the results were good. Just had problems collecting it.

John Hamilton, post: 417758, member: 640 wrote: I did have a few problems this week with Keynet, in two very different locations (different states). I was having a lot of "switching to new base" messages, where it would not get all the way to 180 epochs, but it would switch over to a different base and start over, or it would say "no base data". The latter message MAY have been due to my failing cell phone which I was using as a hot spot, not sure if that was a coincidence. I was in an area of good cell service. The phone totally died (won't power up) at the end of the day yesterday, fortunately after I completed my work which was 250+ miles away from home. I could have switched over to the sim card in the R10 if the phone would have died during the job, nice to have that as a backup.

But, the results were good. Just had problems collecting it.

We have that issue often as well.

I've had very good results using Geoid 09-12b, as long as I hold NAVD88 elevations and Ignore ellipsoid heights generated by CORS/OPUS. My last elevation certificate had a 1st order bench mark within a few hundred feet of the house. I tied to it from control that was on a high hill a mile north of the hours, this is a tri station without any kind of published elevation beyond trig-levels.

The elevation on the tri station came from Geoid09 applied to a HARN/Bench Mark 10 miles to the south. Our check to the bench mark near the house was .01' low. This isn't unusual. I would hope that any VRS/RTN that sells itself as NAVD88 would take a lot of time checking into and adjusting somehow to the elevation control that they say they are using. Otherwise, a base/rover would be the only thing I would use when needing elevations.

I would expect to see elevations in the cm range.

I was told the recent problems with connections were due to the high winds that went through the east coast and damaged a number of stations. As tehy come back online (repaired) the problems should go away. Hopefully true.

John Hamilton, post: 417336, member: 640 wrote: I have not seen any problems with Keynet, but I have not used it in the area the original poster mentioned. I did discover a problem years ago in Maine, where a DOT run station had a height that was way off, several decimeters if I recall correctly.

If I were running a VRS I would be processing the CORS on daily basis to check the positions (one reason is to make sure an antenna doesn't move either horizontally or vertically) and also I would periodically go out with a rover unit and occupy published positions. One fairly simple way to do this would be to submit the 24 hour files to Trimble RTX, which is a PPP service. Or submit to OPUS. And I would do all of this on ITRF and THEN convert to NAD83 (2011).

The way they should be doing it is to constrain their network rigidly to National CORS. This means looking at time series, because we all know that some CORS "drift" off of their published positions for whatever reason, and NGS is loathe to update published coordinates unless a certain tolerance is exceeded. I definitely do NOT believe they should have anything other than TRUE ellipsoidal heights at their CORS and in their solutions. How could they not? Well, if they try to fit local benchmarks, the only way to do that is to produce "pseudo-ellipsoidal" heights that, when combined with a geoid model, will match the BM's. Note that VRS's do not "broadcast" ortho heights, the solution obtained is an ellipsoidal height. This, combined with a geoid model (GEOID12B) will get close to NAVD88 (hopefully). Of course there are areas where GEOID12B gets closer than others. In my mind a better way to deal with any inaccuracies in the geoid model is to create a local model.

We recently observed a point in southern VA using Keynet (station in VA) and the NC VRS network (station in NC), agreement was about 1 cm in all three dimensions. Keynet probably uses the NC station in their solution, and perhaps NC uses the Keynet station, but I would think the same would apply at the border between Keynet and NYDOT network. Even though they are different brands (Leica vs Trimble), I would hope that different operators would share data at the fringes in order to make things seamless as possible. I will say that I have seen strange (i.e. pathological) behavior at the edges of VRS networks.

So, I would hope (and expect) that Keynet is using true ellipsoidal heights. If that is the case, then I believe the only explanation (assuming NYDOT is also using true ellipsoidal heights) is an HI problem, or, more specifically, a "where is it measured to" problem.

And, dynamic heights have NOTHING to do with this. I look forward to hearing the reason for the discrepancy. Hopefully Luke will post whatever he finds out.

The ARP (antenna reference point) on both of our antennas is set to the bottom of mount. When I swapped heads during the test runs I spun one off, the other on without touching the tripod or tribrach. The HR in collectors was the same and tripod height was unknown. Was just a comparison of the 2 RTN services, not it's truth to 88 ortho.

It may be that the "as measured to" or phase center at the base stations is the issue. NYSNet is a 0 offset or "NULLANDVOID" to eliminate these issues. I can't get a clear answer as to what the phase center is on the KetNet Trimble antennas. The variance is very obvious when working in areas that KeyNet can't connect to their own stations and use other networks.

Luke J. Crawford, post: 417946, member: 11382 wrote: The ARP (antenna reference point) on both of our antennas is set to the bottom of mount. When I swapped heads during the test runs I spun one off, the other on without touching the tripod or tribrach. The HR in collectors was the same and tripod height was unknown. Was just a comparison of the 2 RTN services, not it's truth to 88 ortho.

It may be that the "as measured to" or phase center at the base stations is the issue. NYSNet is a 0 offset or "NULLANDVOID" to eliminate these issues. I can't get a clear answer as to what the phase center is on the KetNet Trimble antennas. The variance is very obvious when working in areas that KeyNet can't connect to their own stations and use other networks.

KeyNet obviously does not want to assist you you a timely manner.

We suggested this earlier. But, have you tried post processing the static data from the subject KeyNET CORS? Then compare the results with the RTN data?

Is the Base used by KeyNET part of UFCORS?
Can you download static data from the KeyNET CORS?
Can you provide the RAW base coordinate sent from KeyNET to your controller?

I suggest you at least send a few hours data for an OPUS check. If you have Post Processing software, I suggest processing it yourself or have someone else do it for another comparison. If you provide this information here, we can help.

leegreen, post: 417950, member: 2332 wrote: KeyNet obviously does not want to assist you you a timely manner.

We suggested this earlier. But, have you tried post processing the static data from the subject KeyNET CORS? Then compare the results with the RTN data?

Is the Base used by KeyNET part of UFCORS?
Can you download static data from the KeyNET CORS?
Can you provide the RAW base coordinate sent from KeyNET to your controller?

I suggest you at least send a few hours data for an OPUS check. If you have Post Processing software, I suggest processing it yourself or have someone else do it for another comparison. If you provide this information here, we can help.

I don't think KeyNet can assist. I do not know if they have data avaliable for downloads either but even if they did there is no way to know what points the VRS was created from.
No post processing software.

You are correct, Trimble may not try to assist you in a timely mannor. I'm just asking you to help me, help you.

I don't know about Trimble software. With Topcon Magnet Field the geographic coordinate (LLH) of the base is stored in the raw data.

I have not worked with VRS either. Maybe it only creates a coordinate of the initial point your rovers started from. We could at least process the closest CORS base in the network for a test.
Can you tells us the closet KeyNET CORS?

Then we can check for the static data.

With you paying for the service, it may be only available to you. I am not a paying subscriber, therefore I may not have access. But until you can tell me the name of the CORS station, I can't begin to help.

I converted a .job file from last week to .jxl (xml format). Here are a few of the records:

The "base":

PAWG

FromBase
KeyedIn
Normal
false