Batch Tab

In the Batch Tab you can perform transformation of multiple points given in data files. KMSTrans2 reads and writes a number of different data file formats as described below.
KMSTrans2  uses a command line program in the ./bin subfolder called trogr to perform transformations of data sources like files and databases.
Before performing transformation of files, it is important to note that trogr is linked against the Geospatial Data Abstraction Library (GDAL) which must be installed on your system in order for the program to run. Prepackaged versions of KMSTrans2 will come with a default GDAL installation.

Formats

KMSTrans2 uses the following data formats:
Generally, input and output data source formats will be the same, except for input formats readable by OGR, where a specific OGR output format can be chosen.

OGR

OGR 'drivers' comprises a range of common vector formats, including various databases.
Available input and output vector data formats will depend on your GDAL installation. OGR will try to open an input data source by iteration over available drivers. This behaviour can be overridden by specifying a specific input driver, for instance (if the WFS driver is available):

WFS:http://kortforsyningen.kms.dk/service?servicename=dagi_gml2&service=WFS&version=1.0.0&login=usr_name&password=pass_wd
 
Refer to the list of OGR formats for more details.  Note that many ogr formats will not be available in the default distribution that comes with prepackaged versions of KMSTrans2 for windows. See the GDAL installation page for information on how to enable a "full" installation of GDAL.

TEXT


A simple column based text format with one point on each line. The column separator and sequence of coordinates in the columns can be specified in the File2file settings dialog.
The File2File settings dialog is opened from the 'Settings' menu in the top menu bar. Here the column separators must be set and the sequence of coordinates in the input file must be provided. If the input file contains height information, the “Has z” box is checked.

Examples of valid formats for coordinate lines are:

K-47-200 ,  11.75 , 55.10 , 100 , windy
CITY,    9.31, 56.20 , 127, sunny

where X column=2, Y column =3, Z column=4 and the column separator is ","  (comma).
Point ID and other attributes can be text or numbers or a combination.
The column separator defaults to all whitespace.

An input system can be specified by using a hash in front of a MiniLabel, for instance:   
#geoEetrs89    (geographical coordinates in ETRS89 datum, ellipsoidal heights).
For a description of the MiniLabel syntax please refer to the MiniLabels page.

NOTE: Coordinates can have units like m or km and for geographic coordinates dg, sx, nt or rad. You can control the interpretation of geographic coordinates if no units are found in the settings dialog. For all other types of input systems, coordinates will be interpreted as meters if no units are found. If you use space ' ' as a column separator, remember NOT to include spaces between coordinates and units or spaces in coordinates, e.g.:
Use 6143200.1m rather than 6 143 200.1 m

A valid format using ',' separator and geographic input coordinates could also be

CITY ,  55 10 20.00 sx , 11 35 40.21 sx

or using white space as separator:

CITY   551020.00sx   113540.21sx

Note that leading white space or repeated white space in between fields will have no significance. When using white space as separator the 'TEXT' format will decide that a new column has started after finding the first space or tab character, and will the skip all subsequent white space until the first regular character is found (or the line is terminated).

Likewise, repeated separation chars like e.g ';;;;' will have the same significance as a single separation character ';'. Thus, a field is only "empty" if it consists of white space enclosed between non-white space separation chars, e.g.: ';  ;'.

So the interpretation of e.g.

CITY   551020.00sx   113540.21sx

will be the same as:

     CITY           551020.00sx           113540.21sx

KMS format


The 'KMS format' is a text based format used internally at GST (formerly known as KMS). It's a readable and friendly format for the human eye (originally designed to be readable in printed format on a real piece of paper), but slightly complicated to read / write in a computer program.

Column separator is *always* at least two spaces or a tabulator character and coordinates must have units. The implementation in KMSTrans2 is (still) a 'thin' version of the KMS format - the region prefix of  a coordinate MiniLabel does not infer special parsing / writing of station names.

A line with coordinates could look like:

BUDD   6 143 200.5 m  512 200.12 m  ...other attributes for instance height...

The format is:
One point on each line, and each line composed as:

<Station_name> <two_spaces> <X or Y>  <two_spaces> <X or Y> <two_spaces> <An optional Z-value - depending on the system> <two_spaces> <extra_attributes>

The order of the coordinates, e.g. X,Y (,Z) or Y,X (,Z) depends on the input system, but generally the KMS format expects planar coordinates in the order N,E (Northing, Easting).
See the MiniLabels page for more details!
The input system is specified like for the TEXT-format using mini labels as for instance:  #utm32_etrs89

NOTE:  with the earlier KMStrans software, modifications to the KMS format was possible. This is not possible with KMSTrans2, except for modifications of output unit for geographic coordinates. Files which could be read by KMStrans can therefore not always be read by KMSTrans2, if for instance point ID or other information is not included. In such cases, the user is encouraged to use the TEXT format instead.

When using KMS format the program will skip, but copy, all lines starting with either * or ;  - so a valid format could also be:

 K -01-02397 f    6 178 913.1051 m      722 090.5882 m            63.79041 m  *
                 ;     1997 01 17, 11.49     1997 01 17, 11.49

in which case trogr will not attempt to read coordinates from the second line.

DSFL

DSFL is a specific Danish exchange format for vector data.

More information on the DSFL format can be found on the web site of GeoForum: http://www.geoforum.dk/DSFL-formatet-10299.aspx


Updating / overwriting


For output OGR datasources the behaviour of the program (trogr) is to try to update a datasource if it is an existing directory in the file system and create new layers corresponding to layers in the input datasource. If the output datasource is an existing file, which is not a directory, trogr will try to delete the existing datasource and create a new one (i.e. overwrite).
For the other, textual, formats TEXT, KMS format and DSFL, the behaviour is always to overwrite an existing file by the same name as the output file.


Coordinate sequence


When working with the TEXT format in  KMSTrans2, it is important to know how the program reads x, y and z coordinates. The following table contains examples of coordinate designation for the most common systems used in Denmark.

System  X coordinate/column
Y coordinate/column Z coordinate/column
DKTM Easting     
Northing 
Height
UTM
Easting 
Northing Height
Geographic coordinates Longitude Latitude
Height
Cartesian coordinates X
 Y
 Z
System 34
 X ( i.e. the usual s34 'Westing')
 Y Height
  
Generally Easting should correspond to X, Northing to Y and Height to Z.