SEGY的替代品会是什么样子?

Question

这周我读得很痛苦SEGY文件。这是世界上最大的地震采集公司的数据，该公司的客户是世界第七大石油公司。所以如果有人能做对的话，你会认为是这两个。

用于存储地震数据的SEGY标准在整个石油行业都在使用，但它的使用年限很长。问题包括:

• 非标准报头信息
• 文本头可以是ASCII或EBCDIC
• 为了节省几个字节而费尽心机
• 存储在IEEE或IBM浮点数中的二进制数据
• 等。

一些最明显的缺陷正在通过v2版本进行修补。详情如下:http://www.seg.org/documents/51956/6062543/SEGY+2.0+draft+February+2014．

这不是一个仅仅通过阅读规范就可以实现的标准，这个新版本也不会帮助解决这个问题。对标准的持续滥用意味着需要花费历年的时间来“调试”一个能够承受真实世界数据文件的库。这对于软件开发人员和与之打交道的地球科学家来说都是非常令人沮丧的。

有一个关于这个很棒的博客最近提到了HDF5

• http://www.agilegeoscience.com/journal/2014/3/27/how-to-load-seg-y-data.html
• http://www.agilegeoscience.com/journal/2014/3/26/what-is-seg-y.html

我更希望看到一个比SEGY更简单、不依赖第三方库的新标准。所以我认为技术就像HDF5(和JavaSeis等)可能在公司中有一个角色，但他们不是SEGY的替代品。即使是像XML江南登录网址app下载这样的技术在未来也会被我们必须读取的数据文件所超越。所以我认为格式需要非常简单和保守。

可以取代SEGY格式的一些特性可能包括:

• 单字符编码(ASCII或UTF-8)
• 所有标题都是人类可读的表单-键-值对?
• 必须的头信息，例如射击点，x/y位置等。
• 标准单位定义，地图投影等。
• 跟踪可以是二进制的，但只能是IEEE的
• 数据应该在一个文件中(SEGY是对的)
• 无数据压缩

那么现在的问题是——我们必须做些什么才能超越令人沮丧的SEGY标准?有没有什么东西是我们应该开始传福音的?如果不是，你认为替换的格式应该是什么样的?

感谢阅读。在这次咆哮之后，我感觉好多了，并且将返回调试为什么字节编号3603是错误的。

---

编辑:在周末放松之后，这里有一些更多的想法。SEGY之所以复杂，有以下几个原因:

• 固有的复杂性
• 偶发复杂性
• 用户对格式的期望不同

因此，SEGY很难使用，因为地震问题域本身就很难建模。我们很幸运能够受益于那些想出这种模式的人的智慧。

即便如此，多年来，这种形式也积累了很多麻烦。这就造成了一个不小的认知负担，我可以不这样做，但实际上必须要处理。

最后一点很有趣。我们已经有了用于存储原始字段数据的SEGD。这种格式比SEGY更具挑战性，但也是一个埋葬许多真实世界地震数据固有复杂性的好地方。

当人们建议HDF作为替代品时，我猜(可能)他们将SEGY视为一种“处理”格式?

上周，我在考虑将SEGY作为与解释人员共享最终地震量的工具。我在周末读到，80%的SEGY头没有在真实世界的数据中填充。这只是我的推测，但也许我们需要的是

• SEGD用于原始现场数据
• 还有一些实际处理的东西
• 另外还有处理器和解释器之间的数据共享

为了准确、可重复地将地震数据加载到解释系统中，我们不需要太多元数据，但它绝对需要存在。通过SEGY从处理器到解释器的转换是我认为我们可以使用一种新方法的地方。

Answer 1

我用SEGY文件做过工作，固定长度的头和被忽略的字段是一个问题。还有，端部问题。你必须记住SEGY是目前的交换和归档标准。这是一件好事。

问题是SEGY是为磁带设计的，所以它是单个文件。在今天这个时代，这可能不是一件好事。允许扩展的“元数据”作为一个单独的文件保存可能会更好。基本上，就是在购买数据之前可以查看的目录记录。您应该能够将此元数据添加回文件中。

如果这是交易所配置文件。基本上是信息组，而不是一个大的信息块，那么不同的格式可能会得到更多的购买，并随着时间的推移而遵守。

至于HDF和其他格式，则是关于如何布局数据结构。在NetCDF文件中组织时间序列数据访问(~traces)的方式可能存在一些性能问题。

可以取代SEGY格式的一些特性可能包括:

• 单字符编码(ASCII或UTF-8)
  • 是的
• 所有头部在人类可读的形式-键值对?
  • 是的
• 必须的头信息，如射击点，xy位置等。
  • 我想说是的，但我认为这不会发生。
• 标准单位定义，地图投影等。
  • 是的,
• 跟踪可以是二进制的，但只能是IEEE的
• 数据应该在一个文件中(SEGY是对的)
  • 所有的数据，是的。所有的信息，没有。
  • 单个包，比如tar文件，是的
• 无数据压缩

比特很便宜。在文件中包含使用的字典项的详细信息。在这个时代，我们不需要在文件之外有一本翻译书。但我们应该使用在线的标准参考术语，如链接开放数据。

Answer 2

SEGY的优势也是它的主要问题;它已经存在很长时间了。我一直在努力正确地打开一个十年前的word文档，而人们实际上仍然可以访问70年代或80年代的SEGY。所有程序包都可以导入和导出文件，这也是一个优点。

我同意David的观点，头文件不需要和数据在同一个文件中。我更喜欢将跟踪标头作为ASCII文件可读，而数据可以是二进制的，但最好是在标头中标准化或至少定义。ASCII跟踪标头也很容易为GIS应用程序、SQL或电子表格导入。

的rsf格式(从SEPlib开发)，可能正是我所寻找的，但是跟踪头文件没有写入头文件，而是放在单独的文件中。这对于处理工作流来说并不坏，但是它使得导出文件变得困难。

根据我有限的经验，完美的解决方案是类似rsf文件的东西，文件头和跟踪头在同一个.rsf中。我一直在向一些马达加斯加的用户推荐它，反对它的观点是，在大型项目中，头文件会非常(太)大。然而，我不认为这是一个问题，而是另一个参数，让跟踪头易于搜索，据我所知，没有ascii文件大小的限制。

Answer 3

一个已经存在的东西是ph5PASSCAL组:https://www.passcal.nmt.edu/content/ph5-what-it

它本质上是SEG Y格式的一个端口，删除了一些限制并添加了一堆新的元信息。它基于HDF5，目前主要用作存档格式，尽管我不明白为什么它不能也用作处理格式。

以下段落免责声明:我是背后的人之一。我们最近正在开发一种新的数据格式，包括同样基于HDF5的地震学数据来源。目前，它主要适用于被动源数据，例如地震和记录环境波场的台站-我们的社区对我们刚刚纳入的元信息有非常广泛和完善的标准。这将是一些工作，但地震震源和接收器的概念转化为主动震源情况，因此这可能是一个有价值的研究方向。更多信息:http://seismic-data.org

Answer 4

SEG有一个SEG- y修订2的会议委员会，该委员会讨论了自上次修订以来对SEG- y进行更改的必要性(例如取消连续数据的跟踪长度限制，被动数据的格式，等等)。如果你想为SEG- y的未来做点什么，你应该加入SEG并成为委员会的志愿者。

人们需要记住SEG-Y是一种交换/交换格式，而不是一种处理格式。采集格式(如SEG-D)适合野外采集。SEG-Y用于数据交换。事实上，它是旧的SEG Exchange格式(SEG- x，明白吗?)的替代品。没有人会卷入关于处理格式的标准的争论，因为它比SEG-Y有更多的兼容性和遗留问题。