Custom Data Editing
Besides keeping bad or unwanted data out of the LS and filter processes, you can use the editors to clean unwanted data out of files or simply save off specific time spans of a file, since a method to save measurements is available.
This set of attributes makes it possible to edit tracking data based on any combination of primary object (satellite, surface vehicle, emitter, or GNSS Satellite), tracking strand, and measurement type. For GNSS measurements, the primary object is always the GNSS Constellation; use SelectedTrackingStrand to select a specific receiver attached to a satellite, surface vehicle, or facility.
When defined at the scenario level under the Measurements.ViewAndSave scope, ODTK will use the custom data editing schedule when reporting raw measurements, in reports accessing the TrackingData database, or when saving measurements to a file. It will not use the schedule to modify data available to filter, least squares, or any other process.
This same set of attributes is also defined for the Filter and Least Squares objects, so that each object can have its own set of data editing rules. These attributes are listed in the Custom Data Editing table.
| Custom Data Editing | |
|---|---|
| Parameter | Description |
| Enabled | Turn on or off the entire data editing schedule. |
| OverrideValidity | Set this to true to ignore most validity checks that take place when processing measurements. This is a convenient way to bypass constraints like visibility, elevation, low altitude, low SNR, and exclusion angles. Overriding is only available when Enabled is true. |
| Schedule | Specify a list of edit entries, described below. |
Click the Schedule property to display a List dialog box in which you can add, edit, copy, and remove custom data editing entries. To copy an entry, select it using and and then click .
When you click or , a new line appears in the list, and you can edit selected objects and trackers and selected measurement types. To edit this line, click in each field and select or enter the appropriate information:
| Editing Schedule Definition | |
|---|---|
| Field | Description |
| Enabled | Set this to true to apply the selected editing criteria to the measurements to be processed. |
| Action |
You can set this to one of the following bolded items: A Process record enables you to specify data you want to process, and the Intervals are considered to be Inclusion Intervals. ODTK will not process data outside those intervals. Ignore enables you to skip, or ignore, measurements.IgnoreButReportwill result in measurements being available for reporting purposes, but ODTK will not compute residuals nor included them in the solution. ForceReject means any measurements meeting the requirements will have residuals modeled and reported, but the process marks them for rejection, so ODTK does not include them in the solution. With the Ignore, IgnoreButReport,and ForceReject records, the intervals specify times over which to exclude data. If you do not specify intervals, then the process excludes or rejects all data. Do not use ForceReject at the scenario level because ODTK will not model residuals when viewing or saving measurements. If you want to thin data, create a Thin record and specify the Thinning Time. The process will apply thinning to any measurements surviving the culling by the Process, Ignore, IgnoreButReport, and ForceReject records. Thus, if you want to force thinning to begin at a certain time, you can first Ignore those measurements up to that time. |
| PrimaryObjects |
Select from the following options:
|
| SelectedObject | If you set PrimaryObjects to Specific Satellite, Specific SurfaceVehicle, or Specific Emitter, then select the object to which ODTK applies the intervals. |
| Trackers | Select between All Trackers and Specific Tracker. Because each tracking strand contains specific tracking elements, Specific Tracker is an activator for the SelectedTrackingStrand option. After opting for Specific Tracker, you can make the tracking strand listing visible by clicking below the SelectedTrackingStrand header. Then, from the list of relevant tracking strands, you can select the strand containing the specific tracking elements to which the editing would apply. |
| SelectedTrackingStrand | Select the tracking strand to which the editing is to be applied. |
| MeasType | Select between All and Specific. Selecting All means the process may apply edit criteria to all measurements. Selecting Specific will activate the MeasTypes list, and you may click MeasTypes to enter the measurement types for which the editing would apply. |
| MeasTypes | Select each measurement type to which the editing would apply. |
| ThinningTime |
This is only active when you set Action to Thin. Thinning time is an exclusion period, a time following a measurement during which ODTK will not consider other measurements. For instance, if you have measurements in a tracking file at 5 second intervals, and you set the ThinningTime to 30 seconds, you will end up having measurements processed every 30 seconds. Thinning is performed for each unique primary object - tracking strand - measurement type combination, except for GNSS measurements, where it is GNSS receiver specific. |
| Intervals |
This is only active when Action is Process, Ignore, IgnoreButReport, or ForceReject. The List dialog box that appears will contain a line for the definition of the interval. Click to insert additional subintervals. On each line, set the Enabled value to true if the subinterval is to apply; otherwise set it to false. You can edit the Start and Stop times. The first interval added has a default span based on the scenario's DefaultTimes.Intervals.TimeSpan attribute. To delete a line, select it and click . To clear the list, click . To reorder intervals, select one in the list and click or . If you do not set any specific intervals, then ODTK considers all measurement times. The default start and stop times for the first new interval added are set based on these rules. |
It is possible to set ambiguous directives with this Schedule. When designing a complex custom data editing schedule, you should follow the guideline of starting with the most general rules and ending with the most specific rules. Keep in mind that a rule must include a measurement before another rule can [partially] exclude, reject, or thin it*. When evaluating the schedule entries, the process will use the last entry that applies to a specific measurement. AGI recommends starting with a default Process entry (though not necessary*) and then following with Ignore, IgnoreButReport, or ForceReject entries. ODTK only applies thinning records after applying Process/Ignore/ IgnoreButReport/FR rules, so they can go anywhere in the list. However, if there is more than one Thinning record, the later ones take precedence.
For instance, given a set of tracking data at 10-second steps, one schedule entry could set thinning of all Range measurements to 2 minutes, and the next entry could set thinning for all Facility1 measurements to 30 seconds. So what happens to the Facility 1 Range measurements? Will ODTK thin them to 30 seconds or 2 minutes? Since ODTK uses the last applicable schedule entry, in this case the second rule would take precedence and ODTK would thin them to 30 seconds. If the rules were reversed, ODTK would thin them to 2 minutes.
Also, if you add a specific Process entry, such as Emitter2-All Trackers-TDOA, and you add a second entry to Ignore Emitter3-All Trackers-FDOA over a certain time period, you will find that ODTK ignores Emitter3 measurements over all times. That is because there must first be a record to cause ODTK to process them. One solution would be change the Action attribute from Ignore to Process and change the Intervals attribute from exclusion times to inclusion times. Another solution would be to create a separate Process flag for Emitter3-FDOA and move its list position to just before the Ignore record.
* If there are only Ignore, IgnoreButReport, FR, or Thin entries in the Schedule, you should attempt to add a default Process entry when considering the Schedule. However, when using the Ignore, IgnoreButReport, or ForceReject records, you should add your own Process record for sanity checking.
Additional notes about Thinning Time
Starting in ODTK 6.0, measurements that are thinned may have their own independent thinning grid based on the measurement type and the full tracking strand. For instance, if range measurements are thinned to 10 seconds, and range measurements overlap for two facilities, the resulting measurement times may be something like:
- 00:00:32 Facility1 / Satellite1
- 00:00:35 Facility2 / Satellite1
- 00:00:42 Facility1 / Satellite1
- 00:00:45 Facility2 / Satellite1
The first and third times are 10 seconds apart, as are the second and fourth times, but the two time grids are three seconds apart.
There is an exception to this rule when processing GNSS measurements. In that case, ODTK thins measurements considering only the GNSS receiver ID and not the associated PRN (or PRNs for singly- or doubly-differenced measurements). ODTK thins doubly-differenced GNSS measurements solely based on time and measurement type. There is no need to specify a primary object or tracking strand.
Also, it is possible to move the thinning start time reference by using either an Ignore or Process record. For instance, if you have range data at 1 second starting at 11:57:47, and you want to thin it to 30 seconds in a filter run starting at 12:00:00, but don't want a measurement grid of 17, 47, 17, 47, etc., you can do on of the following
- create an Ignore record to skip the data up through 11:59:59, which will put the resulting range measurements at 12:00:00, 30, 00, 30, etc.
- create a Process record and specify the interval start at 12:00:00 to whenever.
Additional notes about Interval Times
The Intervals property enables you to define one or more subsets of measurements for ODTK to use. For instance, if a measurement file contains 12 days of data, and you want to perform an IOD and run LS over the fifth and sixth days, you can (besides setting your LS start and stop times) set up a Process record with an Intervals entry that starts on the fifth day and ends at the start of the seventh day. Then ODTK will only consider measurements during this time span.
For Ignore, IgnoreButReport, and ForceReject records, the Intervals property excludes measurements over the specified intervals. In the above example involving 12 days of data, you could achieve the same results by creating an Ignore record with two intervals, one excluding all data up to the fifth day, and one excluding all data from the seventh day onward.
If there are no Interval times defined, then ODTK considers all times either to be included or excluded. For instance, if you have a Process record which specifies Satellite1, Facility2, and Range measurements, and there are no Intervals, then ODTK will process, view, and save all available Satellite1-Facility2-Range measurements. If there is an Interval defined, then ODTK will only use the Satellite1-Facility2-Range measurements over those times; it will ignore Satellite1-Facility2-Range measurements not within those intervals. And if you want to exclude all Satellite1-Facility2-Doppler measurements, you can create an Ignore record for Satellite1-Facility2-Doppler and leave the Intervals empty.