Obspy: support for ints in nslc values when writing mseed

[d-chambers]

I am using Obspy 1.1.0 with python 3.6 (installed with Anaconda) on Ubuntu 16.04.

When trying to write an Obspy stream to mseed format it appears int values for network, station, location, and channel are not supported. For example:

import io

import obspy

buffer = io.BytesIO()
st = obspy.read()
st[0].stats.station=2

# this next line raises an AttributeError trying to encode the station field 
st.write(buffer, 'mseed')

It should be an easy fix to support ints in these fields, but before I spend time on it, does it make sense to do so? If not would it be worth raising a TypeError when a value of stats is assigned an invalid value/data type?

[barsch]

station/network/location/channel names are within SEED defined as alphanumeric field (see https://github.com/obspy/obspy/blob/master/obspy/io/mseed/docs/SEEDManual_V2.4.pdf, p37) - also most other waveform format I know of do the same

I don't want to "automagically" change the data type of such given parameter, as this will result into confusions why the input type (during write) is different to the output type (after read).

Why not just using st[0].stats.station=str(2) instead?

I'm going to close this for now - please reopen if you insist on it and give me some valid reasons why we would need such "feature" ;)

[d-chambers]

Hey @barsch, thanks for the comments.

I have been working with some exploration data sets where it is common to name stations based on line number, and instrument number in the line. I have been interpreting the line number as the network code and the instrument number as the station code, hence the reason for having ints in these fields.

I can easily cast these values to strings, and I can understand the desire to avoid "automagic", but I think we should at least do one of two things:

1. Have Stats objects raise a TypeError when a non str value is assigned to one of the alphanumeric fields. This way you cannot have a Stats object in memory that can't be written to disk.

2. Check for invalid values in the write mseed function and raise a TypeError with a clear message stating which values in the Stats object are invalid and what type they should be. As it is now it would be rather hard for someone who doesn't know python well to figure out what is going on.

[barsch]

fair enough - reopening for suggested improvements of error messages

IMHO only option 1 makes sense as otherwise we would have to check within each single waveform plugin ..

[d-chambers]

Option 2 could work if we just check the Stats objects when Stream.write or Trace.write gets called before passing off the data to any particular write plug-ins no?

I am happy to work on this but would like to make sure we have a consensus before I put time into it. Any thoughts @krischer or @megies ?

[krischer]

The nslc identifiers are modelled after the SEED/FDSN identifiers in any case so option 1 is IMHO the one that makes the most sense. The identifiers will soon be updated by the FDSN to be a bit more flexible but they will still be string to either raise a TypeError upon assigning a non-string or just convert to a string. I would tend to raise TypeError but this might break some existing codes so maybe just check if its a string/int/float and then convert to a string and otherwise raise a TypeError?

[megies]

Closed by #1997