[IGS-DCWG-155] Re: Sitelog and Countries
Nacho Romero
nacho at canaryspaceconsulting.co.uk
Mon Nov 21 07:14:45 PST 2016
Hi Markus,
Thanks for the clarification.
below was Zukeir's proposal for the station long names in SINEX ... no
official resolution as of yet. not sure if Daniela has consulted in the
IERS about this to see how we move forward. Thanks! One camp wanted a
correspondence table as part of the SINEX (below), and others wanted to
"bite the bullet" and use an a9 field everywhere, it could contain the
traditional 4 char name or the new 9 char name ... in the first approach
(below) each AC would pick a variation of the conflicting 4 char code
creating AC flexibility ...
regards,
Nacho
-------- Forwarded Message --------
Subject: [IGS-ACS-1043] SINEX changes for 9 char IDs
Date: Fri, 13 May 2016 18:54:32 +0100
From: Nacho Romero <nacho at canaryadvancedsolutions.com>
To: AC IGS List <igs-acs at igscb.jpl.nasa.gov>, acc at igs.org <acc at igs.org>
CC: Paul Rebischung <Paul.Rebischung at ign.fr>
Dear all,
After consultation with Paul Rebischung and through him with Zuheir A. I
think we have agreed on a reasonable way forward to accommodate the new
9 character GNSS station IDs. We simply have to use the feature of the
format that IVS already uses for their 8 character station names, by
re-purposing the "STATION DESCRIPTION" field in the SITE/ID block to
include the 9 character ID, if available, and still using in the file a
unique 4 character code as the solution identifier.
Thus we would suggest that we include the 9 character names into the
SINEX as follows, and that each AC selects a unique 4 character ID in
case there could be a duplication inside your solution, for example;
+SITE/ID
*CODE PT __DOMES__ T_STATION DESCRIPTION__ APPROX_LON_ APPROX_LAT__APP_H_
MAS1 A 31303M002 MAS100ESP Maspalomas 344 22 00.2 27 45 49.4 197.1
MAS2 A 99999M999 MAS100USA Somewhere,CA 236 30 45.1 48 23 23.2 31.8
YHUT A 88888M888 Yuhty, Tamor 123 45 56.7 12 34 56.7 0.0
...
-SITE/ID
a station without a 9 character ID (unknown by the AC, or not found)
should be left blank. The IGS 4 char and 9 char ID list is kept updated
daily directly from the IGS SLM in this file on the igs.org ftp server;
ftp://ftp.igs.org/pub/station/network_list_longnames
Please all ACs and the ACC let me know if you see any kind of issue with
this proposed solution for the SINEX files, and the timeline for
software implementation for those responsible for their own software.
This is an important step in the RINEX3 transition plan as presented and
discussed in the last IGS workshop, and while there is no immediate
urgency we cannot delay progress since new RINEX3 stations are appearing
all the time and we need to be ready to avoid possible confusions.
Thanks and a good weekend to all.
On 21/11/2016 14:39, Markus Bradke wrote:
> 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
>>>>
>>
>
>
--
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.igs.org/pipermail/igs-dcwg/attachments/20161121/73d8865d/attachment.html>
More information about the IGS-DCWG
mailing list