Datum Dilemma In Justin v2.121.159.10

Alexey Razumovsky

Well-Known Member
Staff member
5PLS
#21
<<5) In general, and in all places, reported values should be clearly stated that they are shown in Project datum, what that datum is, including the epoch of the project.>>
Good idea. We will add an option to generate extended report.
 

Matt Johnson

Well-Known Member
5PLS
#22
Across all the project Justin shows coordinates referenced to project epoch. We have never used HTDP transformation to epoch 2010 to view coordinates at any forms, tables, charts. There is only one case when we use HTDP. It's a OPUS friendly report. Justin is not a coordinate calculator. It was inteneded for post processing GNSS data. We offer Coordinate System Editor software for complicated coordinate transformation.
Thanks, this explains a lot of what I was seeing. How are coordinates transformed to NAD83(2011) in Justin before the OPUS report?
 

Alexey Razumovsky

Well-Known Member
Staff member
5PLS
#23
Thanks, this explains a lot of what I was seeing. How are coordinates transformed to NAD83(2011) in Justin before the OPUS report?
Basically, we store coordinates in database as ITRF08(WGS-84). OPUS report: 1. HTDP tranformation to get NAD83(2011). 2. Projection transformation to SPCS83(UTM).
 

Shawn Billings

Shawn Billings
5PLS
#26
I agree completely, Alexey, and I believe processing with ITRF is superior to any other method, because the GPS satellite orbits are in ITRF. Where I disagree with the current implementation (if I understand it correctly) is that you have places in Justin that are displaying NAD83(2011) coordinates (such as the site properties screen capture above) that apparently does not use HTDP to determine those coordinates. Any place in the software that depicts NAD83(2011) coordinates should be using HTDP to determine those coordinates from the ITRF coordinates in the database. This is consistent with the work our friend, Vladimir Prasolov, is doing with J-Field right now. With J-Field, not having HTDP is less of an issue because the NAD83(2011) control coordinates are entered manually, generally speaking, or we are receiving corrections from RTN that are already in NAD83(2011), so it is seldom that we rely on the absolute accuracy of the transformation from ITRF to NAD83(2011). This will become important in the future, with new adjustments or realizations of NAD83. So it is good that Vladimir is doing this. However, with Justin, we are importing positions for CORS as ITRF, relying on Justin to make the correct transformation to NAD83(2011) for us.
 

Kelly Bellis

ME PLS 2099
5PLS
#27
Well said Shawn. I would only add, this will become ever increasingly important to all of us on the planet (not limited to users of Justin) as we become more conscious of plates moving and sea levels rising.
 

Matt Johnson

Well-Known Member
5PLS
#28
Yes I would agree with Shawn. The problem I ran into is that I would set the map to display NAD83 2011 or SPC. When the coordinates on the map didn't match what I expected them to be because they weren't transformed with HTDP it was confusing and I thought I was doing something wrong.
 

Alexey Razumovsky

Well-Known Member
Staff member
5PLS
#29
I agree completely, Alexey, and I believe processing with ITRF is superior to any other method, because the GPS satellite orbits are in ITRF. Where I disagree with the current implementation (if I understand it correctly) is that you have places in Justin that are displaying NAD83(2011) coordinates (such as the site properties screen capture above) that apparently does not use HTDP to determine those coordinates. Any place in the software that depicts NAD83(2011) coordinates should be using HTDP to determine those coordinates from the ITRF coordinates in the database. This is consistent with the work our friend, Vladimir Prasolov, is doing with J-Field right now. With J-Field, not having HTDP is less of an issue because the NAD83(2011) control coordinates are entered manually, generally speaking, or we are receiving corrections from RTN that are already in NAD83(2011), so it is seldom that we rely on the absolute accuracy of the transformation from ITRF to NAD83(2011). This will become important in the future, with new adjustments or realizations of NAD83. So it is good that Vladimir is doing this. However, with Justin, we are importing positions for CORS as ITRF, relying on Justin to make the correct transformation to NAD83(2011) for us.
To avoid in the future misunderstanding of NAD83 coordinates which appear in some form we are going to emphasize the NADs distinguish.
 

Alexey Razumovsky

Well-Known Member
Staff member
5PLS
#30
Yes I would agree with Shawn. The problem I ran into is that I would set the map to display NAD83 2011 or SPC. When the coordinates on the map didn't match what I expected them to be because they weren't transformed with HTDP it was confusing and I thought I was doing something wrong.
It's not possible to set Justin map to display NAD83 2011 or SPCS. Could point any GIS software which use above mentioned projections for cartographic window?
 

Matt Johnson

Well-Known Member
5PLS
#31
It's not possible to set Justin map to display NAD83 2011 or SPCS. Could point any GIS software which use above mentioned projections for cartographic window?
Here is what I am referring to:

upload_2015-3-5_13-11-54.png

The Justin map appears to be in the Ohio North SPCS

upload_2015-3-5_12-56-43.png

but the coordinate values are about 20 cm away from what is on the data sheet for this CORS station.

I think GNSS Solutions supports importing of internet data and SPCS in map and cartographic windows.
 

Alexey Razumovsky

Well-Known Member
Staff member
5PLS
#32
Here is what I am referring to:

View attachment 1691
The Justin map appears to be in the Ohio North SPCS

View attachment 1690
but the coordinate values are about 20 cm away from what is on the data sheet for this CORS station.

I think GNSS Solutions supports importing of internet data and SPCS in map and cartographic windows.
We show map in a projection assigned to Ohio North zone on NAD83 datum. Data sheet shows additionally transformed coordinates. Above I have said that we are going to correct a title to avoid a misunderstanding. To my mind if GNSS Solution calculate map coordinate with HTDP transformation it's not good because we have recalculate on the fly screen positions for a thousands points. It will hang drawing. Are you sure that GNSS Solutions really support SPSC with HTDP in map window.
 

Matt Johnson

Well-Known Member
5PLS
#33
We show map in a projection assigned to Ohio North zone on NAD83 datum. Data sheet shows additionally transformed coordinates. Above I have said that we are going to correct a title to avoid a misunderstanding. To my mind if GNSS Solution calculate map coordinate with HTDP transformation it's not good because we have recalculate on the fly screen positions for a thousands points. It will hang drawing. Are you sure that GNSS Solutions really support SPSC with HTDP in map window.
I'm not sure how GNSS Solutions is calculating the coordinates on the map. If it causes performance issues then I don't see HTDP is necessary for the map just as long as everything is labeled clearly and correctly.
 

Shawn Billings

Shawn Billings
5PLS
#35
Over relatively small areas the translation values would not change very much. Perhaps you could determined the delta N, delta E, expressed as State Plane for the center of the map between ITRF and NAD83. Then apply those deltas to all coordinates shown in the map. It would become a simple add/subtract, much less complicated math.

The errors in this would be lost in the scale resolution for big map areas, and the errors would be very small for small map areas.
 

Matt Johnson

Well-Known Member
5PLS
#36
Over relatively small areas the translation values would not change very much. Perhaps you could determined the delta N, delta E, expressed as State Plane for the center of the map between ITRF and NAD83. Then apply those deltas to all coordinates shown in the map. It would become a simple add/subtract, much less complicated math.

The errors in this would be lost in the scale resolution for big map areas, and the errors would be very small for small map areas.
I was thinking about this same idea earlier too.
 

Alexey Razumovsky

Well-Known Member
Staff member
5PLS
#37
Over relatively small areas the translation values would not change very much. Perhaps you could determined the delta N, delta E, expressed as State Plane for the center of the map between ITRF and NAD83. Then apply those deltas to all coordinates shown in the map. It would become a simple add/subtract, much less complicated math.

The errors in this would be lost in the scale resolution for big map areas, and the errors would be very small for small map areas.
I am just practically ready to meet a demand about all in Justin.