The longitude and latitude coordinates of stations provided by different organizations are inconsistent

The station longitude and latitude data provided by ISC seismic phase travel time is inconsistent with the station longitude and latitude data provided by IRIS, GFZ, IPGP and other servers?

hello everyone. I now have some seismic phase travel time data downloaded from the ISC (The International Seismological Centre), which provides the longitude and latitude coordinates of each station but does not provide the network name.So I want to use clients. fdsn get_ stations () obtains the corresponding STATIONTXT file, and then filters the data in this file to obtain the minimum difference between longitude and latitude coordinates provided by ISC as the network name.

I found that the longitude difference (dlo) of most stations is very small, which can be accurate to 1E-04 °; However, the latitude difference (dla) is relatively large, which can only reach 1E-01 °, and this problem is not an accidental problem.

network station stalo cli_lo dlo stala cli_la dla stael
GE KBS 11.942 11.9417 0.0003 78.853 78.925598 -0.072598 0.074
GE KBS 11.942 11.9417 0.0003 78.853 78.925598 -0.072598 0.074
NO SPB4 16.348 16.34819 -0.00019 78.101 78.178909 -0.077909 0.34
NO JMIC -8.505 -8.5057 0.0007 70.867 70.986603 -0.119603 0.158
SY SCO -21.95 -21.950001 1.00E-06 70.361 70.483299 -0.122299 0.069
GE SUMG -38.454 -38.453899 -0.000101 72.466 72.576302 -0.110302 3.275
IU KEV 27.007 27.0035 0.0035 69.63 69.7565 -0.1265 0.08
IU KEV 27.007 27.0035 0.0035 69.63 69.7565 -0.1265 0.08
NO ARA0 25.506 25.505779 0.000221 69.408 69.534859 -0.126859 0.403
IM ARCES 25.506 25.5058 0.0002 69.408 69.534897 -0.126897 0.403

network: name of the network to be matched
station: station name provided by ISC
stalo: longitude coordinate provided by ISC
cli_ lo: using get_ Station longitude of the best match obtained by stations ()
dlo: difference between ISC longitude and best matched station longitude
stala: latitude coordinates provided by ISC
cli_ la: using get_ Station latitude of the best match obtained by stations ()
dla: difference between ISC latitude and best matched station latitude
stael: elevation information provided by ISC

Shouldn’t the longitude and latitude coordinates of the same station be identical? Which unit of data should I use?

A ~10 kilometer discrepancy for station coordinate is certainly not intended/acceptable. It is not quite clear to me though how your seismic phase info is giving information on the station location. Can you elaborate on that? What kind of data format/source is your phase info that comes together with built in station coordinates apparently?

Thank you for your reply. Now I can basically confirm that there is a problem with the longitude and latitude coordinates in the travel time data file. Use The STATIONTXT file parameters obtained by the get_ stations () method are more accurate. My verification method is very direct, which is to find a third-party organization for the same seismic station( International Registry of Seismograph Stations: station search )And then compare the error between the results. The results are as follows:

network station stalo cli_lo td_lo stala cli_la td_la
GE KBS 11.942 11.9417 11.94169 78.853 78.925598 78.92561
NO SPB4 16.348 16.34819 16.34819 78.101 78.178909 78.17889
NO JMIC -8.0505 -8.5057 -8.51667 70.867 70.986603 70.98833

Where, td_ lo and td_la is data from a third party.
As you can see, the difference between the longitude and latitude coordinates obtained by the get_ stations () method from the server and those obtained by the third-party mechanism is very small, which can be basically accurate to 1E0-5 °.
Finally, as to why the longitude and latitude coordinates of the travel time file will have such a shift, I think the greatest possibility is that this data has been processed in a forced format by the computer in the past. It is suggested to use first-hand data in the future :rofl:.
Thank you again for your answer.

Well yes, the metadata hosted by data centers should always be the go-to.