International Federation of Digital Seismograph Networks
Thread: station xml extension for obs
Sleeman, Reinoud (KNMI)
Dear all,
our colleagues from RESIF proposes an extension of Station.XML with the
new elements below, in particular to serve the needs for OBS deployments.
This proposal was presented already last year in an initial form but never
formally send around in this WG. Please consider this proposal and give
feedback within 4 weeks if needed. An image is attached to illustrate the
need and possibilities for having the 3 elements Depth. WaterDepth and
Elevation.
Best regards
Reinoud
Station level
+ Depth : element : distanceType: 0..1
indicates the wished depth of the station (relative to sea level). This information is required in the case of OBS station description
+ Levelling : LevellingType : 0..1
indicates the method used to level the equipment. This information is mandatory in the case of OBS station description
+ LevellingType : Type : attribute : string [MOTORIZED, GRAVITY]
Precision : attribute : double : 0..1
indicates the error factor of the levelling system
Unit : attribut : string [DEGREES]
_________________________________________________________________________
Channel level
+ WaterDepth : element : distanceType: 0..1
Water depth, mandatory for OBS position description
Motivation: both "depth" and "water depth" should be in the channel description as instruments
may be placed in bodies of water above sea level. It is important to know how far the instrument
is below the water surface, so that, among other things, surface reflections can be removed.
In the ocean, the "elev" and "depth" parameters are adequate for this: the "elev" is a negative number
giving the elevation of the sea floor relative to sea level, the depth specifies how far below or above
the seafloor the instrument is placed, and the water depth will simply be the inverse of the "elev".
In lakes, however, the water level is not necessarily sea level and so the water depth must be specified.
+ Clock : element : string : 0..*
Clock type
+ Vault: element : string : 0..*
Motivation: The element <Vault> is presently defined at the 'Station level'. But the <Vault> element
should also be present at the Channel Level, because the vault can differ from sensor to sensor in the
case of a complex antenna.
+ Geology: element : string : 0..*
Motivation: The element <geology> is presently defined at the 'Station level'. But the <geology> element
should also be present at the Channel Level (in the case of a complex antenna).
_________________________________________________________________________
END
Attachments
-
Dear Reinoud and all,
I couldn't resist reading - and now I can't resist commenting. Please see comments embedded
Station level
- why 'wished' - and not measured? (and if whished, by whom and when? :-)
+ Depth : element : distanceType: 0..1
indicates the wished depth of the station (relative to sea level). This information is required in the case of OBS station description
- according to the drawing 'depth' is relative to sea floor level (not sea level)
(following the argumentation that 'elevation' is the height of 'solid ground' relative to sea level - question on that - how well can in this sense the sea floor elevation be determined?)
- why at Station level? following logic for land-based sensors Depth should be at the Channel level? (text after WaterDepth also requests Depth at Channel level)
(see also below question re. Elevation (elev))
+ Levelling : LevellingType : 0..1
- given the argumentation below about 'complex antennas' I would assume that Levelling and LevellingType may be instrument specific and thus should rather be on the Channel (Location?) level than the Station level?
indicates the method used to level the equipment. This information is mandatory in the case of OBS station description
+ LevellingType : Type : attribute : string [MOTORIZED, GRAVITY]
question to 'elevation': in the current description of stationXML1.0 at http://www.fdsn.org/xml/station/fdsn-station-1.0.xsd the channel.elevation is described as 'elevation of the sensor' (rather than topographic elevation of the earth surface at the sensor location). If this description is correct then 'elevation' at the channel level for OBS channels (in oceans) should be the distance of the sensor from sea level. (is 'elevation' at the station level different than 'elevation' at the channel level?)
Precision : attribute : double : 0..1
indicates the error factor of the levelling system
Unit : attribut : string [DEGREES]
_________________________________________________________________________
Channel level
+ WaterDepth : element : distanceType: 0..1
Water depth, mandatory for OBS position description
Motivation: both "depth" and "water depth" should be in the channel description as instruments
may be placed in bodies of water above sea level. It is important to know how far the instrument
is below the water surface, so that, among other things, surface reflections can be removed.
In the ocean, the "elev" and "depth" parameters are adequate for this: the "elev" is a negative number
giving the elevation of the sea floor relative to sea level, the depth specifies how far below or above
the seafloor the instrument is placed, and the water depth will simply be the inverse of the "elev".
In lakes, however, the water level is not necessarily sea level and so the water depth must be specified.
+ Clock : element : string : 0..*
is it realistic that for oone station (i.e. one station code) the geology changes that drastically over the location of sensors? (shouldn't that almost require separate station codes then?)
Clock type
+ Vault: element : string : 0..*
Motivation: The element <Vault> is presently defined at the 'Station level'. But the <Vault> element
should also be present at the Channel Level, because the vault can differ from sensor to sensor in the
case of a complex antenna.
+ Geology: element : string : 0..*
Motivation: The element <geology> is presently defined at the 'Station level'. But the <geology> element
should also be present at the Channel Level (in the case of a complex antenna).
if vault & Geology are to be defined at channel level then I would not also define them at station level
(I would in general try to avoid having parameters with the same name (and potentially different meanings) at various levels.)
Kind regards
florian
_________________________________________________________________________
END
<StationXML_WDepth.pdf>_______________________________________________
fdsn-wg2-data mailing list
fdsn-wg2-data<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data
-
Hi
I agree with everything Florian said, but wanted to add that there is
no need to add a "clock" element as that can be accommodated within
the existing <Equipment> element of channel.
My understanding is station elevation is at free surface, so the
elevation of the lake surface, channel elevation is the sensor,
channel depth is emplacement depth into solid earth. Thus water depth
would be "station elevation" - "channel elevation" - "channel depth".
So a OBS drilled 10 m into the bottom of a 30m deep lake with water
surface at 100m elevation would have:
station elevation = 100m
channel elevation = 60m
channel depth = 10m
That said I am not opposed to having an explicit spot to put water
depth as that is something that is directly measured and so is useful
to keep in original form.
Also, this does bring up the point that both <vault> and <geology>
probably should have been declared on the channel in the first place
since even on land it is legitamate to have multiple "vaults" that
contain different instruments all contained within the same "station".
For example a borehole seismometer that also has a surface strong
motion instrument. A channel <geology> field would be useful to
describe the rock type that the borehole is emplaced in, while the
surface geology might be very different.
It is a bit late in the game, but I wish there had been a containing
element in between station and channel, perhaps a "site" or "location"
or "substation" that would collect all channels that were together to
avoid repeating much of the channel information that is shared by all
three components of a seismometer for example. The horse has left the
barn, so I will just file that under "what could have been".
thanks
Philip
On Fri, Jul 11, 2014 at 5:37 AM, Haslinger Florian
<florian.haslinger<at>sed.ethz.ch> wrote:
Dear Reinoud and all,
I couldn't resist reading - and now I can't resist commenting. Please see comments embedded
Station level
- why 'wished' - and not measured? (and if whished, by whom and when? :-)
+ Depth : element : distanceType: 0..1
indicates the wished depth of the station (relative to sea level). This information is required in the case of OBS station description
- according to the drawing 'depth' is relative to sea floor level (not sea level)
(following the argumentation that 'elevation' is the height of 'solid ground' relative to sea level - question on that - how well can in this sense the sea floor elevation be determined?)
- why at Station level? following logic for land-based sensors Depth should be at the Channel level? (text after WaterDepth also requests Depth at Channel level)
(see also below question re. Elevation (elev))
+ Levelling : LevellingType : 0..1
- given the argumentation below about 'complex antennas' I would assume that Levelling and LevellingType may be instrument specific and thus should rather be on the Channel (Location?) level than the Station level?
indicates the method used to level the equipment. This information is mandatory in the case of OBS station description
+ LevellingType : Type : attribute : string [MOTORIZED, GRAVITY]
question to 'elevation': in the current description of stationXML1.0 at http://www.fdsn.org/xml/station/fdsn-station-1.0.xsd the channel.elevation is described as 'elevation of the sensor' (rather than topographic elevation of the earth surface at the sensor location). If this description is correct then 'elevation' at the channel level for OBS channels (in oceans) should be the distance of the sensor from sea level. (is 'elevation' at the station level different than 'elevation' at the channel level?)
Precision : attribute : double : 0..1
indicates the error factor of the levelling system
Unit : attribut : string [DEGREES]
_________________________________________________________________________
Channel level
+ WaterDepth : element : distanceType: 0..1
Water depth, mandatory for OBS position description
Motivation: both "depth" and "water depth" should be in the channel description as instruments
may be placed in bodies of water above sea level. It is important to know how far the instrument
is below the water surface, so that, among other things, surface reflections can be removed.
In the ocean, the "elev" and "depth" parameters are adequate for this: the "elev" is a negative number
giving the elevation of the sea floor relative to sea level, the depth specifies how far below or above
the seafloor the instrument is placed, and the water depth will simply be the inverse of the "elev".
In lakes, however, the water level is not necessarily sea level and so the water depth must be specified.
+ Clock : element : string : 0..*
is it realistic that for oone station (i.e. one station code) the geology changes that drastically over the location of sensors? (shouldn't that almost require separate station codes then?)
Clock type
+ Vault: element : string : 0..*
Motivation: The element <Vault> is presently defined at the 'Station level'. But the <Vault> element
should also be present at the Channel Level, because the vault can differ from sensor to sensor in the
case of a complex antenna.
+ Geology: element : string : 0..*
Motivation: The element <geology> is presently defined at the 'Station level'. But the <geology> element
should also be present at the Channel Level (in the case of a complex antenna).
if vault & Geology are to be defined at channel level then I would not also define them at station level
(I would in general try to avoid having parameters with the same name (and potentially different meanings) at various levels.)
Kind regards
florian
_________________________________________________________________________
_______________________________________________
END
<StationXML_WDepth.pdf>_______________________________________________
fdsn-wg2-data mailing list
fdsn-wg2-data<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data
fdsn-wg2-data mailing list
fdsn-wg2-data<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/fdsn-wg2-data
-
Florian Haslinger
Philip Crotwell