Tracking Data Providers - Implementation Options

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:

  1. 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. Any language that supports creating COM components can be used (C# for instance).

    PRO: Best Performance, supports binary and ASCII files. Easily distributed to other users.

    CON: May be slower to develop and requires a compiler ($$$) to make changes.
  2. 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 others can certainly be used; such as Python).

    PRO: Quickest to develop for most good script writers and the least complicated. Scripting languages are often free.

    CON: Slower, may not support binary files.

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:

Click here for information on adding WSCs. Also, check out the MSDN page on Script Components.

ODTK 6.5