[IGS-DCWG-154] Re: Sitelog and Countries

Markus Bradke bradke at gfz-potsdam.de
Mon Nov 21 06:39:18 PST 2016 

Hi Nacho,

To break the issue down to one question the MetOffice had while checking 
the names
of the IGS stations: Why not using country codes for "island countries" 
as standardized in ISO 3166-1?

To what country the IGS stations are allocated to has nothing to do with 
the RINEX v.3 file naming convention.
We only build the station/file names from what is defined in section 2 
of the site log. As Fran said that will
be on the agenda for the next telecon.

@Rolf: At GFZ we have no problems with duplicated station names since we 
only use internal database ID's for the
processing. But the problem comes up if we need to generate an IGS-like 
SINEX for other parties for instance.
A duplicated station name is a killer in this format, e.g. two different 
stations 'TEST':

%=SNX 2.02 GFZ 16:316:22315 GFZ 00:000:00000 00:000:00000 P 00000 0
+SITE/ID
*CODE PT __DOMES__ T _STATION_DESCRIPTION__ APPROX_LON_ APPROX_LAT_ _APP_H_
  TEST  A -----M--- P Potsdam            DEU 13 03 58.1 52 22 44.7  174.0
  TEST  A 12358M003 P Bishkek            KGZ  74 31 59.4 42 51 15.1  749.2
-SITE/ID
+SITE/RECEIVER
*SITE PT SOLN T _DATA_START_ __DATA_END__ ____DESCRIPTION_____ _S/N_ 
_FIRMWARE__
  TEST  A ---- P 13:349:48600 00:000:00000 JAVAD TR_G3TH 70089 3.4.12
  TEST  A ---- P 14:086:21600 15:258:47520 JAVAD TRE_G3TH DELTA 216   3.4.14
-SITE/RECEIVER

It is impossible to state which metadata belongs to a station.
This is clearly not an IGS problem, but one for AC's that analyse more 
than one network.

Best,
Markus

Am 21/11/2016 um 12:06 schrieb Nacho Romero:
> OK,
>
> Thanks for the positive exchange and for bringing this issue up to the 
> IGS, but in future if the Met Office have a problem with IGS stations 
> or the Rinex 3 format definition please direct them to bring it up 
> themselves to the IGS NC or IC for discussion. If, on the other hand, 
> this came about due to an internal issue with their own files or a 
> completely different format then they can do as they please as long as 
> their metadata and names are consistent I guess, and even more for 
> their GNSS data since its not 'public'.
>
> The Rinex 3 naming is clearly defined in the Rinex 3 format definition 
> document which is managed by the IGS/RTCM Rinex Working Group and not 
> by the DC WG or anyone else. Thus if the Country Code is to be taken 
> then whatever the station owners indicate in their 
> IGS/EUREF/SIRGAS/APREF/(etc) metadata as their "Country" is what we 
> take for the station long name.  In certain cases we have double 
> checked with station owners and some station long names have been 
> adjusted before Rinex 3 data started flowing.
>
> I think Fran that inside the metadata we can have any granularity that 
> we deem necessary or useful, so I welcome including the secondary ISO 
> code for the region as optional, but that does not in any way affect 
> the station long name , since that is defined by the Rinex 3 format 
> standard.
>
> regards,
>
> Nacho
>
> _______________________________________________________________
>
> Ignacio (Nacho) Romero
> Aerospace Engineer, PhD
> CSC Ltd @ ESA/ESOC/OPS-GN
> Satellite Navigation Engineer @ ESOC Navigation Support Office
> IGS Infrastructure Committee Chair
> www.navigation-office.esa.int
> www.canaryspaceconsulting.co.uk
>
>
> On 18/11/2016 19:04, Giovanni Sella wrote:
>> The double ISO code would do the trick for me and address my agency's
>> concerns
>>    Giovanni
>>
>> On 11/18/2016 11:28 AM, Markus Bradke wrote:
>>> Dear all,
>>>
>>> Thanks for your quick response. The fact with the "Country" in 
>>> section 2
>>> is what I explained to the guys from the UK Met Office.
>>> They have a different opinion though since they are not interested in
>>> the political "ownership" of a station.
>>>   From a geodetic point of view also a reasonable argument. I don't 
>>> want
>>> to select all stations within France and get La Reunion back =)
>>>
>>> The question is, what standard do we use within the site log? There is
>>> only one standard for that - ISO 3166.
>>>
>>> I guess having the ISO country code in the file names could leadto
>>> problems in future anyway.
>>> What happens if the country of a station changes?
>>>
>>> We should find a solutionfor that in the new XML site log.
>>>
>>> Maybe having two identifiers (Country Territorial and Country 
>>> Division),
>>> e.g. for ASPA: US and AS.And in case they are equal only keep one.
>>> They should get flagged with "valid from" and "valid to" timestamps.
>>> Then it would be much clearer also to allocatethe corresponding file
>>> names over time.
>>> Or add "valid times" even for the 9 character station code.
>>>
>>> Just an idea and a starting point for a discussion.
>>>
>>> Have a nice weekend,
>>> Markus
>>>
>>> Am 18/11/2016 um 16:23 schrieb Giovanni Sella:
>>>> Dear Markus,
>>>>   For ASPA, CNMR, GUUG, since the IGS site log says country we can't
>>>> change this to anything other than US, it would be wrong. If the IGS
>>>> site log states ISO code then we should be able to. Its a minor point,
>>>> but it would break a number of DB's that are outside of IGS and are
>>>> the responsibility of the site operator's (my) agency!
>>>>
>>>>   Giovanni
>>>>
>>>> On 11/18/2016 10:16 AM, David Maggert wrote:
>>>>> Markus,
>>>>>
>>>>> I don’t have an answer to this problem, but I can tell you how the
>>>>> long station names were built.  They were built with the country
>>>>> listed in section 2 of the site log.  So in the ASPA site log, the
>>>>> country is listed as the United States therefore it was assigned the
>>>>> country code of US.  If the country listed in the site log were
>>>>> American Samoa, then it would have been identified as AS. This is
>>>>> the way all of the countries were setup.  Now since those were setup,
>>>>> I have been asked to change the country codes for some
>>>>> China/Taiwan/Hong Kong stations so those country codes now don’t all
>>>>> match the country listed in the site log section 2.  This kind of
>>>>> exception heads down a slippery slope of allowing station operators
>>>>> to have two differing values leading to confusion.  This “big”
>>>>> country vs island territory seems no different China/Taiwan/Hong Kong
>>>>> situation.  Another problem that could arise, what if the station
>>>>> operator decides five years down the road that they want to change
>>>>> the country ID to something else (think “big” country vs island) and
>>>>> now we have data files out there with two different country codes.
>>>>> That sounds like a big mess to me.  It will be interesting to see how
>>>>> this one plays out.
>>>>>
>>>>> Best Regards,
>>>>> David
>>>>>
>>>>>> On Nov 18, 2016, at 4:01 AM, Markus Bradke <bradke at gfz-potsdam.de>
>>>>>> wrote:
>>>>>>
>>>>>> Hi guys,
>>>>>>
>>>>>> I got confronted with a "problem" raised by the UK Met Office.
>>>>>> I generate a new format for meteorological products and sent it 
>>>>>> to them
>>>>>> for a check.
>>>>>>
>>>>>> Now I got the following answer back:
>>>>>>
>>>>>>
>>>>>> "
>>>>>> I also noticed that some of the ISO codes are incorrect.
>>>>>> DGAR and DGAV in Diego Garcia have ISO [GB] but it should be [IO].
>>>>>> ASPA has [US] instead of [AS]
>>>>>> CNMR has [US] instead of [MP]
>>>>>> GUUG has [US] instead of [GU]
>>>>>> REUN has [FR] instead of [RE]
>>>>>> STHL has [GB] instead of [SH]
>>>>>>
>>>>>> These are all appear to be islands which are associated to the 
>>>>>> country
>>>>>> code that has been given but they should have the ISO code for the
>>>>>> territory that it is in.
>>>>>> "
>>>>>>
>>>>>> These are all IGS stations that politically belong to one of the 
>>>>>> "big"
>>>>>> countries but have an own ISO code.
>>>>>>
>>>>>> Since nothing is really standardized or described in the current 
>>>>>> site
>>>>>> log format, how do we proceed with that? I would like to give them a
>>>>>> clear answer but at the moment I can't since "Country" in the 
>>>>>> site log
>>>>>> can mean anything.
>>>>>>
>>>>>> If we adopt the ISO codes to the actual territory, that would mean a
>>>>>> lot
>>>>>> of changes in the DC archives.
>>>>>>
>>>>>> Looking forward to some feedback.
>>>>>>
>>>>>> Best,
>>>>>>
>>>>>> Markus
>>>>>>
>>>>>> -- 
>>>>>> M.Eng. Markus Bradke
>>>>>>
>>>>>> Helmholtz Centre Potsdam
>>>>>> GFZ German Research Centre for Geosciences
>>>>>> Department 1: Geodesy
>>>>>> Section 1.1 : Space Geodetic Techniques
>>>>>>
>>>>>> Telegrafenberg
>>>>>> Building A17, Room 10.09
>>>>>> D-14473 Potsdam
>>>>>>
>>>>>> Phone: +49 331 288-1182
>>>>>> Fax  : +49 331 288-1759
>>>>>> Mail : markus.bradke at gfz-potsdam.de
>>>>>> _______________________________________________
>>>>>> IGS-DCWG mailing list
>>>>>> IGS-DCWG at igscb.jpl.nasa.gov
>>>>>> https://igscb.jpl.nasa.gov/mailman/listinfo/igs-dcwg
>>>>> _______________________________________________
>>>>> IGS-DCWG mailing list
>>>>> IGS-DCWG at igscb.jpl.nasa.gov
>>>>> https://igscb.jpl.nasa.gov/mailman/listinfo/igs-dcwg
>>>>>
>>> _______________________________________________
>>> IGS-DCWG mailing list
>>> IGS-DCWG at igscb.jpl.nasa.gov
>>> https://igscb.jpl.nasa.gov/mailman/listinfo/igs-dcwg
>>>
>

More information about the IGS-DCWG mailing list