-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
different stations (e.g. with differing coordinates) with same station code not handled properly #33
Comments
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? |
No idea what the standard solution for this might be, but since |
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 |
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 |
The factory returns a stations object with |
.. 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). |
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. We have something similar for waveforms.. |
it sometimes can happen that a station is moved slightly but still using the same station code. this is taken into account now, so that stations/channels only get grouped into a single marker/channel list if having the same longitude/latitude combination. see krischer#33
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. |
The following example StationXML stub is not handled properly by jane..
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:
The text was updated successfully, but these errors were encountered: