Datum Dilemma In Justin v2.121.159.10

Kelly Bellis

ME PLS 2099
5PLS
Given: New Project created using datum NAD83(2011), ellipsoidal height system


If MCD5 is snapped to MCD5(CORS), why doesn't Justin show the correct coordinates?

REALLY NOT snapped to CORS mcd5.PNG



If MCD5(CORS) is related to NAD83(2011) epoch 2010.00, why does Justin show an epoch of 2005?

REALLY NOT snapped to CORS mcd5 epoch 2005.PNG



If MCD5(CORS) NAD83(2011) epoch 2010.00 is shown relative to where Justin shows MCD5, there is a gap produced; both horizontally (0.228 m), and vertically (0.007 m).

MCD5 is REALLY NOT snapped to CORS PROFILED.PNG


FWIW:
5-year plate shift.PNG

-5-year plate shift.PNG
 

Matt Johnson

Well-Known Member
5PLS
Kelly, I had previous asked a similar question and here is Alexey's response:

Don't mismatch different Justin categories - Recordset and Site. Recordset is a query from GNSS data file with agrement a Scenatio of import. Recordset has many properties. One of them is a coordinates which comes from standalone solution. Site item is intended for real ground point. So there could be unlimited quantity of Recordset(occupations) assigned to a Site. Site position could inherit standalone solution coordinates(Recordset), post-processed, adjusted, manual input, comes from RINEX header. So Site coordinates vary depend on type of project evalution. Recordset coordinates have been calculated after Import and do not change.
In example above you try to compare Recordset and Site coordinates.

Me: Is there a way to get the Recordset coordinates to match the Site coordinates? I am trying to get the vectors to be drawn from the CORS stations.

Alexey: Recordset is an object, Site is an object as well. They have a properties. One of the properties is coordinates. Objects are accessible thru project pane (left) and map pane (right) of main program window. Vector appears automatically after import GNSS data and creation Recordsets with overlaped time span. No way to create Vector manually.​
 

Kelly Bellis

ME PLS 2099
5PLS
MJ - thanks and yes, I saw Alexey Razumovsky's response in the forum posting. Maybe he will join this public discussion as his reply to your questions don't really address what I've asked and illustrated above. As a completely novice user of Justin, these problems are most likely user error and/or simply misunderstanding the terms and how they are being applied in the context of Justin.

For example, reference points ought to be just that; as published. Snapping is a term that one might assume means locking onto that published coordinate; however, this clearly isn't the case even though the screen capture shows this. It is also not clear to me why is CORS observation data being treated as an autonomous/ stand alone position. In other GNSS post-processing software, the user will individually instruct the software that a particular coordinate is to be held as a horizontal, a vertical, or both a horizontal and vertical control point. I've yet to discover how one might do this in Justin.

Regardless, in the Site Properties and Reference Properties screens above, neither are reflecting the published value.

project snapping properties.PNG
 

Alexey Razumovsky

Well-Known Member
JAVAD GNSS
5PLS
MJ - thanks and yes, I saw Alexey Razumovsky's response in the forum posting. Maybe he will join this public discussion as his reply to your questions don't really address what I've asked and illustrated above. As a completely novice user of Justin, these problems are most likely user error and/or simply misunderstanding the terms and how they are being applied in the context of Justin.

For example, reference points ought to be just that; as published. Snapping is a term that one might assume means locking onto that published coordinate; however, this clearly isn't the case even though the screen capture shows this. It is also not clear to me why is CORS observation data being treated as an autonomous/ stand alone position. In other GNSS post-processing software, the user will individually instruct the software that a particular coordinate is to be held as a horizontal, a vertical, or both a horizontal and vertical control point. I've yet to discover how one might do this in Justin.

Regardless, in the Site Properties and Reference Properties screens above, neither are reflecting the published value.

View attachment 1650
Kelly, I missed a question in time. Let's go step by step. I am going to answer a question
<<why doesn't Justin show the correct coordinates?>> I posted a picture that proves identical coordinates for 'Reference' and 'Site'. Isn't it? Reference coordinates are recalculated up to project 'Reference epoch' (project properties).
upload_2015-3-4_13-26-29.png
 

Kelly Bellis

ME PLS 2099
5PLS
OHMN.PNG


Datum that NGS uses: NAD83(2011)(EPOCH:2010.0000) - not WGS84 epoch 2005.0000

All continuously operating REFERENCE stations are tied to NAD83(2011)(EPOCH:2010.0000) including the Ohio Department of Transportation's control point you've selected; i.e. OHMN... as well as the one in my first post above, MCD5.

All OPUS SOLUTION reports are returned from NGS tied to the REF FRAME: NAD_83(2011)(EPOCH:2010.0000)
They are also returned tied to IGS08 (EPOCH:date_of_survey).

What am I doing wrong? Why doesn't Justin show the correct coordinates tied to the REF FRAME: NAD_83(2011)(EPOCH:2010.0000) ?

OHMN2WG84.PNG
OHMN.PNG
 

Alexey Razumovsky

Well-Known Member
JAVAD GNSS
5PLS
View attachment 1665

Datum that NGS uses: NAD83(2011)(EPOCH:2010.0000) - not WGS84 epoch 2005.0000

All continuously operating REFERENCE stations are tied to NAD83(2011)(EPOCH:2010.0000) including the Ohio Department of Transportation's control point you've selected; i.e. OHMN... as well as the one in my first post above, MCD5.

All OPUS SOLUTION reports are returned from NGS tied to the REF FRAME: NAD_83(2011)(EPOCH:2010.0000)
They are also returned tied to IGS08 (EPOCH:date_of_survey).

What am I doing wrong? Why doesn't Justin show the correct coordinates tied to the REF FRAME: NAD_83(2011)(EPOCH:2010.0000) ?

View attachment 1666 View attachment 1665
CORS station coordinates in catalog refer to epoch 2005(IGS08). We recalculate IGS08 coordinates to project reference epoch with velocities, than we are appling HTDP to transform coordinates to NAD83(2011) to 2010 epoch. OPUS does the same.
upload_2015-3-4_17-25-17.png
 

Matt Johnson

Well-Known Member
5PLS
I can see Site properties and Reference point on a map, but can not see Site snapped to Reference point.

Ok when I snap the Site to the Reference point they match but the coordinates don't match what is the data sheet for that site:

upload_2015-3-4_9-39-13.png


Where are the coordinates coming from when we chose 'Make reference point' from the CORS site?
 

Shawn Billings

Shawn Billings
5PLS
It could be that regional velocities aren't being applied (ie HTDP) and only the ITRF>NAD83 14 parameter transformation is being used in Justin

Alexey is correct though, that OPUS does all processing with ITRF coordinates and at the end, transforms the result (which is in ITRF) to NAD83. This makes sense because the GPS satellite orbits are ITRF.
 

Alexey Razumovsky

Well-Known Member
JAVAD GNSS
5PLS
Ok when I snap the Site to the Reference point they match but the coordinates don't match what is the data sheet for that site:

View attachment 1669

Where are the coordinates coming from when we chose 'Make reference point' from the CORS site?
Justin coordinates correspond to project epoch(click Properties in the bottom on attached Reference properties picture. Datasheet coordinates refer to NAD83 2011 realization epoch 2010. They must be different.
 

Matt Johnson

Well-Known Member
5PLS
Justin coordinates correspond to project epoch(click Properties in the bottom on attached Reference properties picture. Datasheet coordinates refer to NAD83 2011 realization epoch 2010. They must be different.

The grid coordinates shouldn't change with epoch input though should they?
 

Matt Johnson

Well-Known Member
5PLS
What coordinates - Sites, Reference points or cursor? Justin stores all coordinates as latitude, longitude and height in WGS-84.

The Reference point SPC grid coordinates, they should match the NAD83(2011) SPC's on the data sheet since SPC are referenced to NAD83(2011). Also I would think the CORS site SPC's should match the data sheet.
 

Kelly Bellis

ME PLS 2099
5PLS
CORS station coordinates in catalog refer to epoch 2005(IGS08). We recalculate IGS08 coordinates to project reference epoch with velocities, than we are appling HTDP to transform coordinates to NAD83(2011) to 2010 epoch. OPUS does the same.

Is there a way to see Justin's IGS08 epoch 2005.000 catalog value for OHMN?
If the Reference Properties screen for Point name OHMN(CORS) is showing that catalog value, then
1) It should be labeled more clearly as such
2) It is in this case a different value than what GeoCalc is telling us (see 2-step procedures below).
3) Should be transparent; i.e., not seen by the user if they have defined their project as NAD83(2011)
4) Justin's Project Properties, Coordinate Systems tab needs to have additional defining field: Project epoch
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.


index.php


Step 1)
IGS2015 TO 2005.PNG



Step 2)
IGS2005 TO NAD83(2010).PNG


NGS DATASHEET FOR OHMN (DI1860)
index.php
 

Kelly Bellis

ME PLS 2099
5PLS
The Reference point SPC grid coordinates, they should match the NAD83(2011) SPC's on the data sheet since SPC are referenced to NAD83(2011). Also I would think the CORS site SPC's should match the data sheet.

MJ, could we please, for the time being restrict the conversation to datums and leave projections out of the mix? While I concur with your thinking that grid coordinates ought to be matching, bringing scale factors, central meridians, convergence angles and geoids and everything else related to SPCS into the discussion about geodetic datums, epochs of datums and HTDP transformations is distracting.
 

Matt Johnson

Well-Known Member
5PLS
MJ, could we please, for the time being restrict the conversation to datums and leave projections out of the mix? While I concur with your thinking that grid coordinates ought to be matching, bringing scale factors, central meridians, convergence angles and geoids and everything else related to SPCS into the discussion about geodetic datums, epochs of datums and HTDP transformations is distracting.

I don't think it is a problem with datums, it seems to be more than that. As Shawn pointed out maybe there is a transformation that is wrong or being missed somewhere.
 

Alexey Razumovsky

Well-Known Member
JAVAD GNSS
5PLS
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.
 

Alexey Razumovsky

Well-Known Member
JAVAD GNSS
5PLS
Is there a way to see Justin's IGS08 epoch 2005.000 catalog value for OHMN?
If the Reference Properties screen for Point name OHMN(CORS) is showing that catalog value, then
1) It should be labeled more clearly as such
2) It is in this case a different value than what GeoCalc is telling us (see 2-step procedures below).
3) Should be transparent; i.e., not seen by the user if they have defined their project as NAD83(2011)
4) Justin's Project Properties, Coordinate Systems tab needs to have additional defining field: Project epoch
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.


index.php


Step 1)
View attachment 1674


Step 2)
View attachment 1675

NGS DATASHEET FOR OHMN (DI1860)
index.php
upload_2015-3-5_11-50-38.png
 
Top