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 MiniLabels please refer to the Mini Labels 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
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 FBtrans 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 FBtrans, except for modifications of output unit for geographic coordinates. Files which could be read by KMStrans can therefore not always be read by FBtrans, 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 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
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 |