different stations (e.g. with differing coordinates) with same station code not handled properly

[megies]

The following example StationXML stub is not handled properly by jane..

<FDSNStationXML xmlns="http://www.fdsn.org/xml/station/1" schemaVersion="1.0">
  <Source>Tobias Megies/LMU Munich</Source>
  <Module>ObsPy 1.0.2.post0+877.g4ead341348</Module>
  <ModuleURI>https://www.obspy.org</ModuleURI>
  <Created>2017-06-23T11:17:49.804704</Created>
  <Network code="XX">
    <Description>temporary/noise measurements</Description>
    <Station code="ABC" endDate="2017-06-10T00:00:00" startDate="2017-06-02T00:00:00">
      <Latitude unit="DEGREES">49</Latitude>
      <Longitude unit="DEGREES">12</Longitude>
      <Channel code="HHZ" endDate="2017-06-10T00:00:00" locationCode="" startDate="2017-06-02T00:00:00">
        <Latitude unit="DEGREES">49</Latitude>
        <Longitude unit="DEGREES">12</Longitude>
      </Channel>
    </Station>
    <Station code="ABC" endDate="2017-06-30T00:00:00" startDate="2017-06-10T00:00:00">
      <Latitude unit="DEGREES">50</Latitude>
      <Longitude unit="DEGREES">13</Longitude>
      <Channel code="HHZ" endDate="2017-06-30T00:00:00" locationCode="" startDate="2017-06-10T00:00:00">
        <Latitude unit="DEGREES">50</Latitude>
        <Longitude unit="DEGREES">13</Longitude>
      </Channel>
    </Station>
  </Network>
</FDSNStationXML>

Indexing is still working fine, but during output via FDSNWS both channels get merged into one single station, garbling the original information.

Also.. the WebGIS is only showing one of the two geographic locations.

I know that the best practice in general is to use a different station code if the location is different, but sometimes it is in practice still much more useful to keep the same station code even with changing coordinates. For example if the local station setup is changed and the station moves slightly but is still in the same vicinity or with temporary measurements when the hardware setup is connected to the station code but the deployments are done in several different spots.

I would propose to not group all channels rigorously by station code like it's done right now, but rather only group channels if all of the fields that get mapped to station level (like lat/lon/elevation/station description/...) do match.

CC @krischer @jwassermann

TODOS:

• [ ] fix WebGIS, only combine channels into one station object if coordinates match, otherwise make two station objects with differing coordinates
• [ ] fix FDSNWS assembly of StationXML result, stations should only be merged if all attributes of station (comments, coordinates, ...) really match. Right now all channels are merged into one station for each station code

[krischer]

Hmm...I don't see any particular difficulty implementing this but it might be a nasty to get it fully correct mainly for the fdsnws - the webgis should be much simpler.

I'm not sure I'll get to this in the next few weeks - but this is mostly an issue about merging StationXML files for the fdsnws implementation which is done here: https://github.com/krischer/jane/blob/master/src/jane/fdsnws/station_query.py

Also should the example file not still have a single station with differing channel coordinates?

[megies]

Also should the example file not still have a single station with differing channel coordinates?

No idea what the standard solution for this might be, but since Station also holds coordinates it seems logical to me to open another station. Seems safer to me since you never now what people will pick.. the coordinates of Station level for a ll channels or always the coordinates of each separate channel. (This duplication/potential ambiguity in StationXML is very unfortunate, I think, btw)

[megies]

I didn't find where the geometric objects for the WebGIS are assembled, btw.. did only see the FDSNWS assembly..

[krischer]

I didn't find where the geometric objects for the WebGIS are assembled, btw.. did only see the FDSNWS assembly..

Its in the javascript - the webgis only utilizes the REST interface and as you already asserted that it works correctly in the document database it only has to be adjusted in the javascript code. The station objects internally used are assembled here:

https://github.com/krischer/jane/blob/master/src/jane/static/web_gis/src/baynetapp.js#L97

[megies]

Ah OK so for the WebGIS this if/else will have to be adapted.. taking into account coordinates.. https://github.com/krischer/jane/blob/master/src/jane/static/web_gis/src/baynetapp.js#L144

[krischer]

The factory returns a stations object with NETWORK.STATION as keys. This somehow has to be expanded to also take coordinates into account.

[megies]

The factory returns a stations object with NETWORK.STATION as keys. This somehow has to be expanded to also take coordinates into account.

.. and ideally also other fields on the station level. I agree that most people will probably not keep a lot of useful information in there but in principle the idea of StationXML still is that comments and additional info on the deployment ("sensor was broken", "people moved in next door", "bear ate my seismometer", "spilled my beer on the digitizer during maintenance") can be kept in there for maximum usability of data in the long range (field notes just get lost.. but station inventory is always needed to be kept close to the data).

[megies]

As discussed on gitter in private conversation, when assembling the StationXML (on a FDSNWS query for example), ideally when pulling out a channel, the parent nodes should be pulled out from the original xml as well. That would mean that initially multiple stations with same code might reside next to each other in the resulting xml (like it's shown in the real example up top, which was fed to jane). Merging the Inventory should be implemented in obspy and e.g. stations or networks should only be merged if all of their fields (coordinates, comments, description, etc etc) match (meaning a ultra conservative merge). Alternatively a lax merge could also be implemented that just merges everything based on the SEED code and throwing away all finer grained information.

We have something similar for waveforms.. Stream.merge(method=-1) only merges perfectly matching traces or overlaps that hold identical sample data, while other more progressive merge operations result in masked arrays or even interpolation..

[megies]

The pure display aspect in the WebGIS is fixed in above commit and should be integrated into master at some point.

But the more important issue regarding FDSNWS stations assembly remains.