我一直有一个悲惨的时间本周阅读SEGY文件。这是世界上最大的地震数据采集公司的客户是世界第七大石油公司。如果任何人都可以得到它你会觉得这两个。

SEGY标准存储使用地震数据在整个石油行业但正显示出它的年龄相当严重。问题包括:

• 非标准头信息
• 文本标题可以在ASCII、EBCDIC
• 疯狂的阴谋诡计来拯救几个字节
• 二进制数据存储在IEEE或IBM浮点
• 等。

一些最明显的缺陷被修补的v2发布作品。细节是:http://www.seg.org/documents/51956/6062543/SEGY + 2.0 + + 2 + 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口译员的传球给队友,我认为我们可以用一种新方法。