Are the time tags on my data similar to those used by an existing format?
In particular, what time frame (UTC, GPS, TDT, etc.) are the time tags in? What is the format (MM/DD/YYYY, number of days into the year, etc.)? Many formats expect their time tags to be specified in a particular manner. If your data is not similar, you can spend a lot of time writing code to manipulate the time tags, often leading to errors and frustration and questions like "Is this a leap year? Was there a leap second?" If you think you may have to do this, it is best to write your own plugin and let ODTK worry about all the conversions. You just have to tell it what the time tag is and it will handle the conversions internally.
You have two choices for implementing your plugin:
- Compiled code: You can develop a Visual C++ or Visual Basic DLL similar to the plugins provided with ODTK. Visual Basic is easier for a novice. You can use any language that supports creating COM components (C# for instance).
PRO: It provides better performance, supports binary and ASCII files, and is easily distributed to other users.
CON: It may be slower to develop and requires a compiler ($$$) to make changes. - Develop a Windows Scripting Component (WSC) similar to those provided in the accompanying Scripts directory. The scripting language used in the component is typically VBscript or PerlScript, although you can certainly use others such as Python.
PRO: It is quicker to develop for most good script writers, and it is the least complicated. Scripting languages are often free.
CON: It is slower and may not support binary files.
Ninety percent of the time we have found that a WSC is the quickest way to get a plugin up and running. It allows for quick debugging since you don't have to restart ODTK each time (as compared to a compiled plug in). However, the debugging is limited to message box dialogs or writing debug information out to a log file that you can examine. A compiled plugin allows you to use a real debugger and step through your code line by line. For the most part, run time speed is not an issue when deciding between compiled components and WSCs. Compiled components are faster than interpreted scripting languages, but ODTK spends very little time actually calling your plugin to get data. Most of the processing time is spent actually running the filter.
Some caveats on choosing a scripting language:
- Most of the time, we implement our plugins in VBScript or Perlscript.
- VBScript is on almost any computer on which you want to run ODTK, but its parsing abilities are limited, and it has no support for reading and writing binary files.
- Perlscript excels at parsing and supports binary files, but it requires that Perl be installed on any computer on which you want to run ODTK. Perlscript also suffers from a startup speed penalty. This is not a big problem if you only work with a few tracking data files at a time (fewer than 20), but if you use more than that you will see a startup lag between the time you start running the filter and the time the filter actually starts processing. Memory usage will ramp up too, observed even with Perl-based WSCs that are completely stubbed out to not actually do anything. There is a connection to the Windows::OLE module.
Click here for information on adding WSCs. Also, check out the Microsoft Docs page on Script Components.