You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Many file formats support non-height information, for example the piezo voltage and others. Right now some readers return those channels (DI, IBW) while some do not (EZD, GWY).
The goal
Moving forward with the code base, I think we want to support non-height data channels and should implement reading those. Issues to resolve are:
Possible solution
We need to report two units - lateral unit and data unit. Suggestion: If information is not-height, then unit should be a tuple with lateral unit first and data unit second. This would not break most of the downstream codes.
Some properties have explicitly height in the names, e.g. the method heights() or the height_scale_factor. We should change the API to reflect this (maybe deprecating heights in the long run).
The channel index is currently used to uniquely refer to the data channel. Those indices would change if we just remove skipping of non-data channels in DI and IBW readers. This will break downstream topobank badly, because the channel index is stored verbatim in the database to refer to a specific channel. There should be a unique channel-indexing scheme that is invariant to the actual order of channels in the data file. Note that the channel name cannot be used as there are data files that have multiple channels of the same name. We could of course normalize that name by appending an index, but then the order matters again.
Some of the code is currently specific to height, e.g. unit name mangling. We should probably move this to a third-party library such as pint.
The text was updated successfully, but these errors were encountered:
The problem
Many file formats support non-height information, for example the piezo voltage and others. Right now some readers return those channels (DI, IBW) while some do not (EZD, GWY).
The goal
Moving forward with the code base, I think we want to support non-height data channels and should implement reading those. Issues to resolve are:
Possible solution
We need to report two units - lateral unit and data unit. Suggestion: If information is not-height, then
unit
should be a tuple with lateral unit first and data unit second. This would not break most of the downstream codes.Some properties have explicitly
height
in the names, e.g. the methodheights()
or theheight_scale_factor
. We should change the API to reflect this (maybe deprecatingheights
in the long run).The channel index is currently used to uniquely refer to the data channel. Those indices would change if we just remove skipping of non-data channels in DI and IBW readers. This will break downstream
topobank
badly, because the channel index is stored verbatim in the database to refer to a specific channel. There should be a unique channel-indexing scheme that is invariant to the actual order of channels in the data file. Note that the channelname
cannot be used as there are data files that have multiple channels of the same name. We could of course normalize that name by appending an index, but then the order matters again.Some of the code is currently specific to height, e.g. unit name mangling. We should probably move this to a third-party library such as
pint
.The text was updated successfully, but these errors were encountered: