OTK command line tools usage

This page lists all available commands of the OTK with their options

convert

usage: java -jar otk-<version>.jar convert -if -of (-i -o)

Converts location references between the physical data formats. Please note that conversion from non-binary into the binary format incorporates a compression of the parameters. There will be a loss in accuracy.

-i,--input <arg> Input data (path to data file or data string). The application first checks if a file with the given name exists. If not it uses the given string itself as the input data. If this option is missing the tool blocks listening for data from standard input.
-if,--input-format <arg> identifies the format of the input data
valid format identifiers:
binary -- binary format
binary64 -- binary and Base64 encoded
xml -- XML data
datex2 -- Datex2 data
-o,--output-file <arg> path to the the output file [if missing output is written to standard out]
-of,--output-format <arg> identifies the format of the output data
valid format identifiers:
binary -- binary format
binary64 -- binary and Base64 encoded
xml -- XML data
datex2 -- Datex2 data

xml2kml

usage: java -jar otk-<version>.jar xml2kml -i (-d)

Creates KML representations of OpenLR location references in XML format. The tool has two input modes. If the specified input source matches a directory the tool will process every file ending with ".xml" in it. If the input source links to a file the tool processes only this single file. The resulting KML files are placed into the current working directory or into a dedicated directory if specified. The file names match the input file, but with extension ".kml".

-d,--output-directory <arg> Path to the the output directory, will be created if missing
-i,--input-source <arg> Path to the single input file or the input directory

binview

usage: java -jar otk-<version>.jar binview (-i -o -t -b64 -k)

Prints the data contained in a binary location reference. The location reference can consist of either pure binary or base 64 encoded binary data provided via file, direct specification in the command line or piped in. The content is printed in a readable way and/ or visualized via KML.

-b64,--base64 data file contains Base64 encoded data [mandatory, if input data is Base64-encoded]
-i,--input <arg> Input data (path to data file or data string). The application first checks if a file with the given name exists. If not it uses the given string itself as the input data. If this option is missing the tool blocks listening for data from standard input.
-k,--kml-file <arg> KML output file. Writes KML data that visualizes the location reference information. The file is created if it not exists or overridden otherwise.
-o,--output-file <arg> path to the the output file [if missing output is written to standard out]
-t,--template-file <arg> The path to a velocity template file for formatting the output data

bbox

usage: java -jar otk-<version>.jar bbox -i (-d)

Calculates bounding boxes from location references and draws them via KML. The created bounding box describes the sufficient part of the target map to decode the location reference.
The tool has two input modes. If the input source links to a file the tool processes only this single file. If the specified input source matches a directory the tool will process every file in it matching the following naming schema.
The tool assumes to find location reference in the contained files by the following conditions. Files ending with ".stream" are processed as pure binary OpenLR location references. Files ending with ".b64" are assumed to contain Base 64 encoded OpenLR binary location references. Files with suffix ".xml" are tried to process as OpenLR location references in XML format.
The resulting KML files are placed into the current working directory or into a dedicated directory if specified. The file names match the input file, but with suffix "-boundary.kml".

-d,--output-directory <arg> Path to the the output directory, will be created if missing
-i,--input-source <arg> Path to the single input file or the input directory

loader-info

usage: java -jar otk-version.jar loader-info ([loader-jar])

Provides information about an OpenLR map-loader implementation. This implementation is either provided by specification of a path to a JAR archive or searched in the class-path of the current run of the OTK if the tool argument is omitted.

<loader-jar  The path to the library containing an OpenLR map loader implementation. This has to be a JAR file that
provides an implementation of interface OpenLRMapLoader published via Java ServiceLoader interface.

encode

usage: java -jar otk-<version>.jar encode -of -m (-i -d -k -p)

Encodes locations on an OpenLR map instance. The result can be stored in a file or visualized via KML representation. If option -d is missing all output is written to the console.

-i,--input <arg> Input data (path to data file or data string). The application first checks if a file with the given name exists. If not it uses the given string itself as the input data. If this option is missing the tool blocks listening for data from standard input.
-k,--kml-dir <arg> KML output directory. Writes KML files that visualizes the location information. The directory is created if it not exists.
-m,--map-access <arg> Map access string. This parameter expects a formatted string that consists of the map loader identifier and a list of the loader's parameter values. All the parts are separated by commas:
<loader ID> [,<loader param ID>,<value>]*
The loader identifier either contains the path to an OpenLR map loader JAR file or the name of a map loader instance in the class path. In the example below the map loader is expected to reside in file "tt-sqlite-with-dependencies.jar" in the current working directory. Accessing the loader by specification of the JAR depends on the class loading behavior in the loader library. If there are any problems like ClassNotFoundExceptions the class path alternative should be chosen if possible. This alternative, using the loader name, is useful for cases where there are several loader implementations in the class path of otk at runtime. In both cases the loader library has to provide access to an implementation of OpenLRMapLoader via Java ServiceLoader interface. The map loader identifier is followed by a list of key value pairs.
"(<path to map jar> | <loader name in the class path>) (,<loader param id>,<value>)*"
If there is a need to have a comma itself in a parameter key or value it has to be escaped by backslash "\". All backslashes in keys and values therefore have to be escaped too, e.g. - "1,5.10007\,52.10320" -> key "1", value: "5.10007,52.10320"
The key of each parameter is expected to match the identifier delivered by the parameter implementation. To figure out the relevant parameter IDs the user can use the tool itself. If he just specifies the loader identifier but the loader requires mandatory parameters it will explain which parameter IDs are available.
Examples:
"tt-sqlite-with-dependencies.jar,1,tomtom_utr echt_2008_04.db3" (points to a JAR)
"SQLite Map Loader (TomTom),1,tomtom_utrecht_2008_04.db3" (refers to a loader in the classpath)
Please note that if there are any blanks in the access string, the entire string must be quoted!
-d,--output-directory <arg> Path to the the output directory, will be created if missing.
-of,--output-format <arg> identifies the format of the output data
valid format identifiers:
binary -- binary format
binary64 -- binary and Base64 encoded
xml -- XML data
datex2 -- Datex2 data
-p,--properties <arg> Path to the properties. If no properties are declared then the default properties are used.

decode

usage: java -jar otk-<version>.jar decode -of -m (-i -o -k -p)

Decodes location references on an OpenLR map instance. The result can be stored in a file or visualized via KML representation.

-i,--input <arg> Input data (path to data file or data string). The application first checks if a file with the given name exists. If not it uses the given string itself as the input data. If this option is missing the tool blocks listening for data from standard input.
-id,--location-id <arg> specifies an identifier that is set to the created output location if the location reference not provides an identifier itself as it is the case for binary encoded location references
-if,--input-format <arg> identifies the format of the input data
valid format identifiers:
binary -- binary format
binary64 -- binary and Base64 encoded
xml -- XML data
datex2 -- Datex2 data
-k,--kml-file <arg> KML output file. Writes KML data that visualizes the location information. The file is created if it not exists or overridden otherwise.
-m,--map-access <arg> Map access string. This parameter expects a formatted string that consists of the map loader identifier and a list of the loader's parameter values. All the parts are separated by commas:
<loader ID> [,<loader param ID>,<value>]*
The loader identifier either contains the path to an OpenLR map loader JAR file or the name of a map loader instance in the class path. In the example below the map loader is expected to reside in file "tt-sqlite-with-dependencies.jar" in the current working directory. Accessing the loader by specification of the JAR depends on the class loading behavior in the loader library. If there are any problems like ClassNotFoundExceptions the class path alternative should be chosen if possible. This alternative, using the loader name, is useful for cases where there are several loader implementations in the class path of otk at runtime. In both cases the loader library has to provide access to an implementation of OpenLRMapLoader via Java ServiceLoader interface. The map loader identifier is followed by a list of key value pairs.
"(<path to map jar> | <loader name in the class path>) (,<loader param id>,<value>)*"
If there is a need to have a comma itself in a parameter key or value it has to be escaped by backslash "\". All backslashes in keys and values therefore have to be escaped too, e.g. - "1,5.10007\,52.10320" -> key "1", value: "5.10007,52.10320"
The key of each parameter is expected to match the identifier delivered by the parameter implementation. To figure out the relevant parameter IDs the user can use the tool itself. If he just specifies the loader identifier but the loader requires mandatory parameters it will explain which parameter IDs are available.
Examples:
"tt-sqlite-with-dependencies.jar,1,tomtom_utr echt_2008_04.db3" (points to a JAR)
"SQLite Map Loader (TomTom),1,tomtom_utrecht_2008_04.db3" (refers to a loader in the classpath)
Please note that if there are any blanks in the access string, the entire string must be quoted!
-o,--output-file <arg> path to the the output file [if missing output is written to standard out]
-p,--properties <arg> Path to the properties. If no properties are declared then the default properties are used.