If you have tracking data in a format that is not natively supported by ODTK, you are faced with one of two choices: reformat the data into a format that is supported, or write a plugin reader to read your format directly. More often than not, it is easier to write a custom plugin. To help with that decision, examine your tracking data and ask yourself the following question:
Are the time tags on my data similar to those used by an existing format?
In particular, what time frame are the time tags (UTC, GPS, TDT, etc)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: 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:
90% 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 ODTK does not have to be restarted each time (as compared to a compiled plug in). However, the debugging is limited to popping up 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: