Apply offset correction to tropo coefficients

[jonathanmuller]

Tropo coefficients are offset by a hard-coded value as mentioned in the definition.
Put aside the fact I struggle with the way the sentence is written (should we add, remove, or is it already included ?), the following fields could be corrected with the offset, or an expended version could be provided with the offset.

SF043 -> add 2.3m
SF045 -> add 0.252m
SF048 -> add 0.252m

Details :

ID 1	Name	# bits	Range	Resolution	Special values	Notes	My comment
SF043	Area average vertical hydrostatic delay	8	+/-0.508m	0.004m	None	The average vertical hydrostatic delay (reduced to a reference height of 0 m on the ellipsoid) within the area offset from 2.3m	The delay ... within area offset of 2.3m ... what does that mean. Just adding 2.m to the field parsed value seem to give realistic results
SF045	Small troposphere coefficient T00	7	+/-0.252m	0.004m	None	The small size coefficient of the troposphere zenith delay polynomial offset by 0.252m.	The note seem to imple it's already offset of 0.25m, but I suppose we need to add 0.25m in fact, to have a positive value ... ?
SF048	Large troposphere coefficient T00	9	+/-1.020m	0.004m	None	The large size coefficient of the troposphere zenith delay polynomial offset by 0.252m	Same as above. Also in revision control they say "Added offset to large troposphere coefficient (SF048) to match the offset on the small troposphere coefficient (SF045)." which still suggest we should subtract (which seems the wrong way to me)

What's your opinion on that, should be base parsed value include those offset, should this be a different field, do I even understand it correctly ? (English is not ma native language)

[semuadmin]

Hi @jonathanmuller

The way I read this originally was that the offsets are already included, but now that you mention it I'm not so sure. I agree it is somewhat ambiguous in the specification (in any language ;-) ).

Do you have any insight into what a 'correct' value should be? I'm afraid much of this is just numbers to me.

If you're confident that the values are more plausible if the offsets are added, it's a trivial change.

[semuadmin]

I've done a quick provisional fix. Try installing and running the RC-1.0.3 branch and see if it gives you more sensible figures...

python3 -m pip install git+https://github.com/semuconsulting/[email protected]

[semuadmin]

@jonathanmuller any further feedback on this?

[jonathanmuller]

@semuadmin See comment below : looks definitely better

[jonathanmuller]

I don't have any easy way to test (not your code, but the "does it make sense" part).
What I will try to do it to calculate the iono and tropo for a location where 3 GAD overlap, and try both variant of your code to see if any of them gives the same result for all 3 GAD.
Hopefully there should visible difference between no correction and correction.
I should have to do that this week, keeping you updated.

[semuadmin]

Thanks @jonathanmuller

At the end of the day, I guess it's kind of arbitrary whether the offset is included or not, as long as this is clearly understood by end users. But I'd ideally like the parsed data attribute to be as intuitive as possible.

[jonathanmuller]

@semuadmin
I should have expected that : Comparing delta of the tropo correction on overlapping GAD area give the same (really small) difference, regardless if using the offset version (RC-1.0.3) or not (master)

However, when comparing to SAAST model, the offset version makes a lot more sense.
To give you an order of magnitude : SAAST gives me a correction of 5[m]
When using the no offset version it give me a correction of -0.1[m]
When using the offset version it gives me a correction of 4.3[m]

Also, just looking at the numbers, tropo delay can NOT be negative, so the only way to avoid those negative numbers is to include the offset

So, even if I don't have a clear proof the offset needs to be applied, I'm still fairly confident it should be

[semuadmin]

@jonathanmuller Works for me - thanks again for the input - much appreciated

[semuadmin]

Added in v1.0.3

[umbertorob]

I don't have any easy way to test (not your code, but the "does it make sense" part). What I will try to do it to calculate the iono and tropo for a location where 3 GAD overlap, and try both variant of your code to see if any of them gives the same result for all 3 GAD. Hopefully there should visible difference between no correction and correction. I should have to do that this week, keeping you updated.

Can you share your code to calculate IONO e TROPO correction from HPAC message and GAD?