|
POSC Specifications Version 2.2 |
Usage Examples Recommendations for Seismic |
In Epicentre, the number of points in a grid does not contain any semantic meaning. However, for a binset, there are no attributes that specify the "number of lines" or the "number of traces." Consequently, the binset_grid counts are used to carry this information.
In particular, the grid axes should be formed so that the 'count' attribute accurately reflects the number of points (or lines) in the binset. Clearly, the binset_grid axes should not be shared with other binsets.
Since the grid axes are of type grid_1d_equal, they contain a relationship to a coordinate_system_axis. In general, these axes can be reused. I.e., a coordinate_system_axis has a many relationship from the grid_1d_equal. But it must be anticipated that a binset formation will lead to a coordinate_system formation. Since axes cannot be reused in a coordinate system, it is recommended that each time a binset is formed, the related coordinate_system_axes be grouped into a coordinate_system. The coordinate_system thus formed will be of type that has 'bin point index' and/or a 'bin line index' as the properties of the axes.
The use of these axes as a binset coordinate system does not allow their use later in a seismic_data_set. I.e., when forming a coordinate_system for storage of a seismic cube (or a section), you must have a coordinate_system that has "binpoint/ line" axes as the spatial axes, and a time axis as the vertical axis. When forming this, an all-new set of axes must be instantiated.
1. Form the general_coordinate_system_axis with ref_quantity_property.name = 'bin point index.' If needed, also form the
general_coordinate_system_axis with ref_quantity_property.name = 'bin line index.'
2. Form the local_spatial_coordinate_system using this (these) axi(e)s.
3. Form the grid_1d_equal axis with reference to the 'bin point index' (and 'bin line index') axis. If needed, group the two axes into a single grid. Insure that the count attribute accurately reflects the size of the binset. The count attribute has the semantics of being the size of the binset.
4. If seismic_data_sets are formed, each coordinate_system used must instantiate its own set of "binning" axes for use in forming the coordinate system.
I want to capture the geometry of "shot point" lines. I have three cases to consider:
1. I am given a small number of ends and bends.
1A. I am given ends and bends, and may later get all the location data.
2. I am given a patterned list of stations and locations.
2A I am given a patterned list and may later get all the location data.
3. I am given the full set of locations.
3A. I am given a full set, but wish to identify a subset for plotting.
The "A's" attached to the numbers indicate that, although they may be different scenarios, they must be treated the same, i.e., I cannot treat 1 and 1a differently, because 1 may turn into 1a at any time, and I cannot "change" what I have already done.
Consider the following two lines, for discussion purposes:
Line B fits scenario 1 above. The ends and bends are recorded. Line P fits the patterned case, in which every 40th station (slight exception at the end) is stored.
Case 1: Line B
a) Instantiate a grid_1d_equal of count 7. Note that the semantics of count indicates that there is only information about 7 stations. The grid_1d_equal should use property 'seismic station uid', with start, increment = 1,1.
b) Instantiate seismic_geometry_set.seismic_station_uid --> the grid from a).
c) Instantiate seismic_geometry_set.station_name. This will be a property frame using
ref_descriptive_property.kind = 'name', and referencing the grid from a). There should be seven values which are the ends and bends stations. ('101', '183', , '586') located at grid indexes 1-7.
c1) Instantiate seismic_geometry_set.acquisition_index at these seven grid points to indicate the ordering of these stations. Use the ordering array (1,83,144,216,304,399,486) . Note that the actual value in this array has no meaning. The only meaning is that the relative value determines which station goes where in a relative ordering (how to "connect the dots").
d) Instantiate pty_location_array: .seismic_geometry_set --> referencing the above instance, and .data_value being storage of the seven locations (referencing the grid from a), and the appropriate coordinate_system). (Note: the restriction to 2d locations makes it difficult to handle VSP's, and to set up a 1d coordinate system of "length along the line.")
The case of extending this to 1A) is straightforward. It is done with steps e) and f)
e) The original .station_name must be deleted and replaced by the full set of 486 station names. Note that the original seven station names will (must) show up at the first seven grid locations as before, unless everything is updated at the same time.
f) Instantiate another pty_location_array: .seismic_geometry_set --> referencing the above instance, and .data_value being the full storage of 486 locations. Again, remember that the first seven are the original seven locations, and the rest are put in as appropriate.
Note that the "plotting" array (the seven stations) is stored in the first pty_location_array. So it will be possible to look at all the seismic_geometry_set.station_location values and pick out some short ones that give locations for plotting.
There was some discussion about interpolation of the intermediate points, i.e., in step d) above, why not do a linear interpolation of the missing locations so that a location exists for all stations? This would involve an interpretation of the data and the manufacture of new data. It would be better to store the data as it exists, and not manufacture additional data. An application can interpolate if it needs to.
When moving to Line P, the assumption of linear interpolation is even more spurious. Therefore, it would be wrong to perform a linear interpolation. For Line B, it is probable that the stations were chosen as "ends of approximately linear segments." So linear interpolation might be a good approximation. But the method of choosing stations in Line P is to choose the first, every 40th, and the last. And since the last is near the next-to-last, eliminate the next-to-last. Linear segments do not enter in at all.
In order to maintain consistency among cases 1), 1A), 2), and 2A), steps a) - f) should be followed.
Case 3 follows steps a) - c1) and f). This sets up the names, ordering, and locations of all the stations.
The problem now comes in identifying the locations we wish to plot. At present, there is no way to do this explicitly. Given the interpretations from cases 1) and 2), though, it would be consistent to implement step d) by instantiating a limited set of location values. The semantics behind such a limited set would be that this is the "plotting" set of locations.
Note, however, that these will not be the first "n" locations. Instead, these will be part of a sparse frame that selects only those locations that should be plotted.
A possible extension to the model would be to allow set[0,?] pty_plotting_array, which would allow an array of flags that could be set to control plotting. (Probably integers that would indicate plotting for different scales, or size of "circle", or some such information).
Here is a summary of the recommendations:
1) Don't reuse grids between seismic_geometry_sets, unless they are semantically related.
2) Set up the grid for the known geometry, and extend it as more data becomes available.
3) Always assume the full geometry will eventually be stored, so set up the acquisition_index for that.
4) Update (add to) but don't change values. For example, if station name 152 is given between 101 and 183, add 152 as the eighth position on the grid, with uid value of 8. The new arrays will be:
acquisition_index = (1,83,144,216,304,399,486,52)
station_name = ('101','183','244','316','404','499','586','152')
The initial bin geometry is specified in the grid_1d_equal axes. In particular, the attributes 'origin', 'step', and 'count' specify the bin geometry. The relationship to an axis specifies the property. The grid numbering has no semantic meaning at all. It is the bin point index (and bin line index) as defined by the 'origin', 'step', 'count' that has the semantic meaning. If origin and step are 1 and 1, the bin geometry for that axis is equivalent to the grid numbering.
Consider for the rest of this note that a 2d binset consisting of bin point axis and bin line axis have been formed.
The two grid axes are formed into a grid_structured that is the mandatory attribute of a binset_grid. The two coordinate_system_axes are formed into a local_spatial_coordinate_system. The interpretation is that the bin point and bin line indexes form a coordinate system. The interpretation is strengthened by actually instantiating the coordinate system. However, it should also be pointed out that Epicentre presently does not capture the semantics that this coordinate system so formed has any relationship to the binset.
Alternate geometries can be formed in two ways at present. A third way is being considered.
The first way is to instantiate pty_geometry_2d_face to create as many alternate geometries as desired. Note, however, that since the original geometry is part of the Grid_1d axis instantiation, there is no way to say that an alternate geometry is a different representation than the bin point, bin line "representation." This semantics, however, is implied in the binset_grid definition itself. I.e., there is the semantics that the "primary" geometry is the bin point, bin line geometry as specified by grid_structured, and the pty_geometries are alternate geometries.
At present, The data_value attribute for the pty_geometry_2d_face leaves no alternative than to give the calculated values. In particular, giving three (or four) "corner" values using the sparse storage mechanism will allow the implementer to give a minimal amount of values for the generally very regularly spaced set of data. Having these values, plus the 'origin,' 'step,' 'count' attributes from the primary geometry (the grid), the application can determine the "coordinate transformation" between the bin point, bin line coordinate system and the alternate coordinate system.
Of course, the application can also instantiate a full set of locations. However, many users do not wish to fill out the full set of coordinate values because of space limitations, and because the regularity of a binset makes the calculation "on the fly" a much more desirable choice.
A second way to give a minimal geometry is to instantiate a binset_grid_variant with a 2 x 2 binset grid. The axes for the binset_grid_variant would have the same origin, a count = 2, and a step = count - 1, as related to the original binset grid. This would have the effect of creating a four point binset that contains only the corner points. The attribute ref_grid_variant would be 'corners only', which would indicate that this binset has only the corner points. Thus, the semantic meaning of this binset would be explicit. In the first method from above, the meaning is implicit in the fact that only the four corner locations were given.
Having formed the binset_grid_variant, it is now straightforward to instantiate the pty_geometry_2d_face for this variant. This gives the application the information necessary (as above) to calculate the implied coordinate transformation.
The third way is to make the coordinate transformation explicit. In this method, the information given in the above two methods is used to explicitly calculate and store the coordinate transformation. The applied_coordinate_transformation is instantiated that indicates the from coordinate system (recall that the bin point index and bin line index axes were put together into a local_spatial_coordinate_system) and the to coordinate system, which may be a local_spatial, a projected, or a geographic coordinate system. At present, however, in Epicentre, there are not semantics that tie either the to or the from coordinate system to the binset. These ties must be made, along with the interpretation that this coordinate transformation is a way to give alternate spatial representations. It is felt by some that these semantics should somehow be recorded in a pty_geometry_... so that an application has only one place to search to find the alternate geometries (remember that we must also keep open the option of storing all the values in a pty_geometry_...).