ScopeOfDeliveredServices - softwareunderground/xsdf GitHub Wiki
Scope of delivered services
Looking at the draft SEG-Y Rev. 2 specs, watch the authors of the document trying to make it possible to create entire subsurface data stores in one SEG-Y file. There are two issues with this broadening of the scope:
- By adding possibilities, you force readers of the format to prepare for more and more possibilities, like variable trace lengths, storage types, coordinate system specifics, and so forth
- When writing, you need to put more and more work in delivering a 'valid' SEG-Y file.
Both effects have proven to be harmful, as you can see in the current situation of reading and writing SEG-Y files. SEG-Y revision 1 was a huge improvement because finally, we knew where to find crucial position information. If people would have actually used the 'extended stanza' mechanism, we would have had a disaster too: everything would become crazily difficult, also in simple situations.
A very important rule for good interfaces is: 'keep things very easy for simple work, try to make complicated work just slightly more difficult to do'. To achieve this, we should limit the scope of the work to explicitly only cover seismic data access and exchange. To explicitly not encapsulate the connected fields but store only keys to those and keep those optional. In that way, we can keep our products usable for a wide range of users.