<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><tt>Hi Markus,</tt></p>
<p><tt>Thanks for the clarification. <br>
</tt></p>
<p><tt>below was Zukeir's proposal for the station long names </tt>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 ... <br>
</p>
<p>regards,</p>
<p>Nacho</p>
<br>
-------- Forwarded Message --------
<table class="moz-email-headers-table" border="0" cellpadding="0"
cellspacing="0">
<tbody>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Subject: </th>
<td>[IGS-ACS-1043] SINEX changes for 9 char IDs</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">Date: </th>
<td>Fri, 13 May 2016 18:54:32 +0100</td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">From: </th>
<td>Nacho Romero <a class="moz-txt-link-rfc2396E" href="mailto:nacho@canaryadvancedsolutions.com"><nacho@canaryadvancedsolutions.com></a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">To: </th>
<td>AC IGS List <a class="moz-txt-link-rfc2396E" href="mailto:igs-acs@igscb.jpl.nasa.gov"><igs-acs@igscb.jpl.nasa.gov></a>,
<a class="moz-txt-link-abbreviated" href="mailto:acc@igs.org">acc@igs.org</a> <a class="moz-txt-link-rfc2396E" href="mailto:acc@igs.org"><acc@igs.org></a></td>
</tr>
<tr>
<th align="RIGHT" nowrap="nowrap" valign="BASELINE">CC: </th>
<td>Paul Rebischung <a class="moz-txt-link-rfc2396E" href="mailto:Paul.Rebischung@ign.fr"><Paul.Rebischung@ign.fr></a></td>
</tr>
</tbody>
</table>
<br>
<br>
<p><tt>Dear all,</tt></p>
<p><tt>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.</tt></p>
<p><tt>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;</tt></p>
<pre wrap="">+SITE/ID
*CODE PT __DOMES__ T <span class="moz-txt-underscore"><span class="moz-txt-tag">_</span>STATION DESCRIPTION__ APPROX_LON<span class="moz-txt-tag">_</span></span> APPROX_LAT_ <span class="moz-txt-underscore"><span class="moz-txt-tag">_</span>APP_H<span class="moz-txt-tag">_</span></span>
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</pre>
<p><tt><br>
</tt></p>
<p><tt>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;</tt></p>
<p><tt><a moz-do-not-send="true" class="moz-txt-link-freetext"
href="ftp://ftp.igs.org/pub/station/network_list_longnames">ftp://ftp.igs.org/pub/station/network_list_longnames</a></tt></p>
<p><tt><br>
</tt></p>
<p><tt>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. <br>
</tt></p>
<p><tt>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.</tt></p>
<tt>Thanks and a good weekend to all.</tt>
<div class="moz-cite-prefix">On 21/11/2016 14:39, Markus Bradke
wrote:<br>
</div>
<blockquote
cite="mid:ee4adf39-325d-fa72-5a6b-b875e69f23a4@gfz-potsdam.de"
type="cite">Hi Nacho,
<br>
<br>
To break the issue down to one question the MetOffice had while
checking the names
<br>
of the IGS stations: Why not using country codes for "island
countries" as standardized in ISO 3166-1?
<br>
<br>
To what country the IGS stations are allocated to has nothing to
do with the RINEX v.3 file naming convention.
<br>
We only build the station/file names from what is defined in
section 2 of the site log. As Fran said that will
<br>
be on the agenda for the next telecon.
<br>
<br>
@Rolf: At GFZ we have no problems with duplicated station names
since we only use internal database ID's for the
<br>
processing. But the problem comes up if we need to generate an
IGS-like SINEX for other parties for instance.
<br>
A duplicated station name is a killer in this format, e.g. two
different stations 'TEST':
<br>
<br>
%=SNX 2.02 GFZ 16:316:22315 GFZ 00:000:00000 00:000:00000 P 00000
0
<br>
+SITE/ID
<br>
*CODE PT __DOMES__ T _STATION_DESCRIPTION__ APPROX_LON_
APPROX_LAT_ _APP_H_
<br>
TEST A -----M--- P Potsdam DEU 13 03 58.1 52 22 44.7
174.0
<br>
TEST A 12358M003 P Bishkek KGZ 74 31 59.4 42 51
15.1 749.2
<br>
-SITE/ID
<br>
+SITE/RECEIVER
<br>
*SITE PT SOLN T _DATA_START_ __DATA_END__ ____DESCRIPTION_____
_S/N_ _FIRMWARE__
<br>
TEST A ---- P 13:349:48600 00:000:00000 JAVAD TR_G3TH 70089
3.4.12
<br>
TEST A ---- P 14:086:21600 15:258:47520 JAVAD TRE_G3TH DELTA
216 3.4.14
<br>
-SITE/RECEIVER
<br>
<br>
It is impossible to state which metadata belongs to a station.
<br>
This is clearly not an IGS problem, but one for AC's that analyse
more than one network.
<br>
<br>
Best,
<br>
Markus
<br>
<br>
Am 21/11/2016 um 12:06 schrieb Nacho Romero:
<br>
<blockquote type="cite">OK,
<br>
<br>
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'.
<br>
<br>
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.
<br>
<br>
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.
<br>
<br>
regards,
<br>
<br>
Nacho
<br>
<br>
_______________________________________________________________
<br>
<br>
Ignacio (Nacho) Romero
<br>
Aerospace Engineer, PhD
<br>
CSC Ltd @ ESA/ESOC/OPS-GN
<br>
Satellite Navigation Engineer @ ESOC Navigation Support Office
<br>
IGS Infrastructure Committee Chair
<br>
<a class="moz-txt-link-abbreviated" href="http://www.navigation-office.esa.int">www.navigation-office.esa.int</a>
<br>
<a class="moz-txt-link-abbreviated" href="http://www.canaryspaceconsulting.co.uk">www.canaryspaceconsulting.co.uk</a>
<br>
<br>
<br>
On 18/11/2016 19:04, Giovanni Sella wrote:
<br>
<blockquote type="cite">The double ISO code would do the trick
for me and address my agency's
<br>
concerns
<br>
Giovanni
<br>
<br>
On 11/18/2016 11:28 AM, Markus Bradke wrote:
<br>
<blockquote type="cite">Dear all,
<br>
<br>
Thanks for your quick response. The fact with the "Country"
in section 2
<br>
is what I explained to the guys from the UK Met Office.
<br>
They have a different opinion though since they are not
interested in
<br>
the political "ownership" of a station.
<br>
From a geodetic point of view also a reasonable argument.
I don't want
<br>
to select all stations within France and get La Reunion back
=)
<br>
<br>
The question is, what standard do we use within the site
log? There is
<br>
only one standard for that - ISO 3166.
<br>
<br>
I guess having the ISO country code in the file names could
leadto
<br>
problems in future anyway.
<br>
What happens if the country of a station changes?
<br>
<br>
We should find a solutionfor that in the new XML site log.
<br>
<br>
Maybe having two identifiers (Country Territorial and
Country Division),
<br>
e.g. for ASPA: US and AS.And in case they are equal only
keep one.
<br>
They should get flagged with "valid from" and "valid to"
timestamps.
<br>
Then it would be much clearer also to allocatethe
corresponding file
<br>
names over time.
<br>
Or add "valid times" even for the 9 character station code.
<br>
<br>
Just an idea and a starting point for a discussion.
<br>
<br>
Have a nice weekend,
<br>
Markus
<br>
<br>
Am 18/11/2016 um 16:23 schrieb Giovanni Sella:
<br>
<blockquote type="cite">Dear Markus,
<br>
For ASPA, CNMR, GUUG, since the IGS site log says
country we can't
<br>
change this to anything other than US, it would be wrong.
If the IGS
<br>
site log states ISO code then we should be able to. Its a
minor point,
<br>
but it would break a number of DB's that are outside of
IGS and are
<br>
the responsibility of the site operator's (my) agency!
<br>
<br>
Giovanni
<br>
<br>
On 11/18/2016 10:16 AM, David Maggert wrote:
<br>
<blockquote type="cite">Markus,
<br>
<br>
I don’t have an answer to this problem, but I can tell
you how the
<br>
long station names were built. They were built with the
country
<br>
listed in section 2 of the site log. So in the ASPA
site log, the
<br>
country is listed as the United States therefore it was
assigned the
<br>
country code of US. If the country listed in the site
log were
<br>
American Samoa, then it would have been identified as
AS. This is
<br>
the way all of the countries were setup. Now since
those were setup,
<br>
I have been asked to change the country codes for some
<br>
China/Taiwan/Hong Kong stations so those country codes
now don’t all
<br>
match the country listed in the site log section 2.
This kind of
<br>
exception heads down a slippery slope of allowing
station operators
<br>
to have two differing values leading to confusion. This
“big”
<br>
country vs island territory seems no different
China/Taiwan/Hong Kong
<br>
situation. Another problem that could arise, what if
the station
<br>
operator decides five years down the road that they want
to change
<br>
the country ID to something else (think “big” country vs
island) and
<br>
now we have data files out there with two different
country codes.
<br>
That sounds like a big mess to me. It will be
interesting to see how
<br>
this one plays out.
<br>
<br>
Best Regards,
<br>
David
<br>
<br>
<blockquote type="cite">On Nov 18, 2016, at 4:01 AM,
Markus Bradke <a class="moz-txt-link-rfc2396E" href="mailto:bradke@gfz-potsdam.de"><bradke@gfz-potsdam.de></a>
<br>
wrote:
<br>
<br>
Hi guys,
<br>
<br>
I got confronted with a "problem" raised by the UK Met
Office.
<br>
I generate a new format for meteorological products
and sent it to them
<br>
for a check.
<br>
<br>
Now I got the following answer back:
<br>
<br>
<br>
"
<br>
I also noticed that some of the ISO codes are
incorrect.
<br>
DGAR and DGAV in Diego Garcia have ISO [GB] but it
should be [IO].
<br>
ASPA has [US] instead of [AS]
<br>
CNMR has [US] instead of [MP]
<br>
GUUG has [US] instead of [GU]
<br>
REUN has [FR] instead of [RE]
<br>
STHL has [GB] instead of [SH]
<br>
<br>
These are all appear to be islands which are
associated to the country
<br>
code that has been given but they should have the ISO
code for the
<br>
territory that it is in.
<br>
"
<br>
<br>
These are all IGS stations that politically belong to
one of the "big"
<br>
countries but have an own ISO code.
<br>
<br>
Since nothing is really standardized or described in
the current site
<br>
log format, how do we proceed with that? I would like
to give them a
<br>
clear answer but at the moment I can't since "Country"
in the site log
<br>
can mean anything.
<br>
<br>
If we adopt the ISO codes to the actual territory,
that would mean a
<br>
lot
<br>
of changes in the DC archives.
<br>
<br>
Looking forward to some feedback.
<br>
<br>
Best,
<br>
<br>
Markus
<br>
<br>
-- <br>
M.Eng. Markus Bradke
<br>
<br>
Helmholtz Centre Potsdam
<br>
GFZ German Research Centre for Geosciences
<br>
Department 1: Geodesy
<br>
Section 1.1 : Space Geodetic Techniques
<br>
<br>
Telegrafenberg
<br>
Building A17, Room 10.09
<br>
D-14473 Potsdam
<br>
<br>
Phone: +49 331 288-1182
<br>
Fax : +49 331 288-1759
<br>
Mail : <a class="moz-txt-link-abbreviated" href="mailto:markus.bradke@gfz-potsdam.de">markus.bradke@gfz-potsdam.de</a>
<br>
_______________________________________________
<br>
IGS-DCWG mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:IGS-DCWG@igscb.jpl.nasa.gov">IGS-DCWG@igscb.jpl.nasa.gov</a>
<br>
<a class="moz-txt-link-freetext" href="https://igscb.jpl.nasa.gov/mailman/listinfo/igs-dcwg">https://igscb.jpl.nasa.gov/mailman/listinfo/igs-dcwg</a>
<br>
</blockquote>
_______________________________________________
<br>
IGS-DCWG mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:IGS-DCWG@igscb.jpl.nasa.gov">IGS-DCWG@igscb.jpl.nasa.gov</a>
<br>
<a class="moz-txt-link-freetext" href="https://igscb.jpl.nasa.gov/mailman/listinfo/igs-dcwg">https://igscb.jpl.nasa.gov/mailman/listinfo/igs-dcwg</a>
<br>
<br>
</blockquote>
</blockquote>
_______________________________________________
<br>
IGS-DCWG mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:IGS-DCWG@igscb.jpl.nasa.gov">IGS-DCWG@igscb.jpl.nasa.gov</a>
<br>
<a class="moz-txt-link-freetext" href="https://igscb.jpl.nasa.gov/mailman/listinfo/igs-dcwg">https://igscb.jpl.nasa.gov/mailman/listinfo/igs-dcwg</a>
<br>
<br>
</blockquote>
</blockquote>
<br>
</blockquote>
<br>
<br>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
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
<a class="moz-txt-link-abbreviated" href="http://www.navigation-office.esa.int">www.navigation-office.esa.int</a>
<a class="moz-txt-link-abbreviated" href="http://www.canaryspaceconsulting.co.uk">www.canaryspaceconsulting.co.uk</a>
_______________________________________________________________
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.</pre>
</body>
</html>