chad-earthscope
commented
2 years ago
There are some redundant elements in the schema. For example, <Latitude> and <Longitude> is within <Station> as well as under <Channel>. As <Channel> is inside <Station>, the <Latitude> and <Longitude> of the <Channel> could be inherited from <Station>, as it cannot be different (the same of <Elevation>).
Note that those are not redundant, while it is not as common, the station and the channel can have different coordinates for appropriate reasons. Example, a station that has multiple sensors (and then channels) that are physically spread out like a small array or sub-array element. If anything these scenarios will probably becomes more common in the future.
crotwell
This issue is filed to keep the discussion we started during reviewing the schema in January 2022. It partly follows the issue #101 and also slightly issue #20 and others. There are some redundant elements in the schema. For example, <Latitude> and <Longitude> is within <Station> as well as under <Channel>. As <Channel> is inside <Station>, the <Latitude> and <Longitude> of the <Channel> could be inherited from <Station>, as it cannot be different (the same of <Elevation>).
Then, there are elements of <Channel>, which are often repeated for more channels of a seismic stations. These are: <Latitude>, <Longitude>, <Elevation>, <Depth>, <SampleRate>, <SampleRateRatio>, <ClockDrift>, <Sensor>, <DataLogger> and <Response>. Generally, each component of a seismic sensor could have different transfer function, sure. Hence these elements need to be allowed inside each <Channel>. However, In practice, the <Response> is copied-pasted 3 times for all 3 channels. Repeating all PaZ and FIR filter coefficients 3 times for a classical seismic sensors seems impractical to me. Obviously, one cannot set it at the <Station> level, as station can have more instruments. To me, the nicest solution would be to have one more level between <Station> and <Channel>, something like <Instrument>, so that station can have 2 instruments, each having 3 channels. One instrument is very specific BB thing with individual <Response> for each channel, and hence the <Response> needs to be given separately for each <Channel>. The second instrument is only cheap thing with all properties defined just once for all 3 channels and hence the <Response> could be inherited from <Instrument>. This would not only save the space from repeating everything 3 times, but would also allow to clearly see, if the properties are the same or different channel to channel.
I also see some inconsistency of the elements listed at the same level: While <Latitude>, <Longitude>, <Elevation>, <Depth> and <Sensor> must be the same for all channels of the same instrument, and while <SampleRate>, <SampleRateRatio>, <ClockDrift>, <DataLogger> and <Response> can be either the same or different, there are two elements (<Azimuth> and <Dip>), which are in principle different for each component of a sensor. As they are at the same level as those which are in practice always the same, their more important presence here is bit hidden. To solve this would require a schema change.