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

Mon Nov 21 05:56:17 PST 2016

Sorry Rolf,

your message below is not easy to follow and its not at all clear how it 
relates to the use of political country codes or "country regions", 
please let us know what exactly you mean.

I think the text in page A3 precisely allows the freedom to other GNSS 
data users to use the "A9" as they see fit, should we remove that line 
since its obvious that they are going to do whatever they want anyways? 
Industry users in any case name the files whatever they want (session_1, 
session_2, etc) thus maybe the clarification line is not needed.

As with any 4 char code whoever "claims" BERN00USA will have it and the 
rest will have to adjust, so what? we never intended to solve every 
possible problem in naming files, just to address part of the underlying 
issues. We always knew, and mentioned it in Olsztyn, that in countries 
with large networks such conflicts could occur, but at least an Azores 
station will not be confused with a NZ station as can happen now with 
GRAC depending how far back you look in the Rinex 2 repositories!

regards,

Nacho

On 21/11/2016 06:54, Rolf Dach wrote:
> Dear colleagues,
>
> the RINEX filenaming convention is ambiguous in the format description
> (page A3):
>
> <STATION/PROJECT NAME>: IGS users should follow XXXXMRCCC (9 char) site
> and station naming convention described above.
>
> GNSS industry users could use the 9 characters to indicate the project
> name and/or number.
>
> This resulted from the fact that the a "XXXXMRCCC" was regarded as a
> reasonable convention for data files exchanged in databases collecting
> from different sources. On the other hand, it is obvious that commercial
> companies that own and maintain their own network will not change their
> naming convention.
>
> To be compliant with the format description everybody (except for IGS
> stations) can do what ever they want. What Markus is reporting here is a
> consequence of this situation. A clarification (where ever it takes
> place) is urgently needed...
>
> Because "BERN" is a nice example, there is a city of Bern in Switzerland
> which would get "BERN00CHE", but which of the about 10 cities of Bern in
> the US? Which one will get "BERN00USA"? What happen if two agencies
> independently start to use the same naming at different locations and
> later want to join the same database (a situation that could be happen
> even today with the 4-ID)?
>
> Looking at the situation of today (which applies also to the new naming
> convention to a certain extent, see the example from above) the 4-ID is
> only changed if different stations meet in one database. When it is only
> a question of processing stations from different networks together it is
> to the analysis people to handle the multiple appearance of the same
> station ID (where only SINEX provides an opportunity to report the
> results, only ambiguous solutions for troposphere, clocks and so on).
>
> So, the situation from Markus could also be declared to a local issue
> when GFZ wants to process stations from different networks. But I'm in
> favor to clarify it in general (even if filenames might need to be
> changed after that decision). It cannot be more confusing that the
> different labeling of BeiDou observations in different versions of RINEX3.
>
> Best regards
>
> Rolf
>
> PS: Ken might correct me if I have not correctly reported the situation
> regarding RINEX3.
>
>
>
> Am 18.11.2016 um 20:04 schrieb Giovanni Sella:
>> 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
>>>

-- 
Best 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
_______________________________________________________________
This message including any attachments may contain confidential
information, according to our Information Security Management System,
  and intended solely for a specific individual to whom they are addressed.
  Any unauthorised copy, disclosure or distribution of this message
  is strictly forbidden. If you have received this transmission in error,
  please notify the sender immediately and delete it.