LandSerf can import and export spatial data in a large range of commonly used data formats. The table below summarises the formats available,
whether the format can be imported or exported, and the ID used to identify the format when handling the file type with LandScript.
Click on a link below to see details of the format.
Default file extensions: .grd or .asc
| Example | Description |
|
ncols 321 nrows 468 xllcorner 387570.0 yllcorner 5289240.0 cellsize 30 nodata_value -32766 -32766 393 393 393 393 ..etc -32766 395 396 396 394 ..etc : etc. |
ASCII file for storing raster data. Header information consists of at least the number of rows/columns,
the geographical origin and the grid cell resolution. Any other header items are permitted but ignored.
Note that this format only allows square pixels to be written (single cellsize value). On output from
LandSerf, if the raster cells are not square, their dimension is given as the average of the two sides.
Raster data are stored in nrows rows from north to south, each row consisting of ncols values from west to east. Raster values can be floating point or integer numbers and are separated by any number of whitespace characters. When output from LandSerf, null values are given the numeric value -32766. If you wish to use another number to represent null on output, the raster should be transformed in LandSerf ('Transform raster values'). |
Default file extension: .bil (with .hdr and .blw files containing metadata)
| Example | Description |
|
.hdr file: BYTEORDER M NROWS 468 NCOLS 321 NBITS 16 NBANDS 1 .blw file: 30.0 0.0000000 0.0000000 -30.0 387570.0 5289240.0 .bil file - binary equivalent of: 386 393 393 393 393 ..etc 387 395 396 396 394 ..etc : etc. |
Binary integer file with two separate header files containing image metadata and georeferencing. fileName.bil
contains the 16 bit or 32 bit integers in row prime order from north to south.
fileName.hdr contains image metadata including the number of rows, columns and bits per cell.
Byte order is 'big-endian' if BYTEORDER is set to M (Motorola), or 'little-endian' if set to I (Intel).
LandSerf assumes only 1 interleaved layer.
fileName.blw contains the georeferencing information including grid resolution, and coordinates of the
centre of the upper-left pixel of the image. The six values represent the affine transformation from image to georeferenced
coordinates. If the order of the 6 values are represented by A-F, the transformation is
x' = Ax + By + E y' = Cx + Dy + F Therefore, values (A,D) give (xRes,-yRes), (E,F) give (xOrigin,yOrigin) and (B,C) define the rotation (usually 0). Note that D is negative since the image origin is at the top, but georeferenced origin will be at the bottom. |
Default file extension: .flt (with .hdr file containing metadata)
| Example | Description |
|
.hdr file: ncols 321 nrows 468 xllcorner 387570.0 yllcorner 5289240.0 cellsize 30.0 nodata_value -32767 byteorder LSBFIRST .flt file - binary equivalent of: 386.1 393.0 393.4 392.8 392.6 ..etc 387.0 394.5 396.4 396.3 393.9 ..etc : etc. |
Binary floating point file with separate header file containing raster metadata and georeferencing. fileName.flt
contains the 32 floating point values in row prime order from north to south.
fileName.hdr contains image metadata including the number of rows and columns, cell
size and location of lower-left corner. Note that only one cellsize value is permitted, so this format
can only store square pixel values. On output from LandSerf, if the raster cells are not square, their
dimension is given as the average of the two sides.Byte order is 'big-endian' if byteorder
is set to MSBFIRST, or 'little-endian' if set to LSBFIRST. Note also that
this '.hdr file' is not in the same format as the .hdr files used by the BIL
format.
|
Default file extensions: .poi, .lin, .pol or .gen (geometry) and .atr (attributes)
| Example | Description |
|
1 320550.0 425320.0 320633.0 425320.0 320720.0 425300.0 320701.0 425295.0 END 2 360297.0 425310.0 361050.0 425305.0 361078.0 425300.0 END 3 361455.0 424987.0 4 361632.0 425001.0 5 361760.0 424977.0 : etc. END |
ASCII file for storing vector data. Points are stored in ID, x, y order on a single line.
Separators can be spaces, tabs or commas. Vector objects consisting of lines or areas comprise an ID
on its own line followed by space, comma or tab separated x and y coordinates, one pair per line. The
end of each object's geometry is marked by the 'END' keyword. A final 'END' terminates the file. The
file extension is usually used to distinguish lines from areas (.lin or .pol). If extension is not one
of these then only repeated first and last coordinates can be used to infer polygon-line distinction.
Attributes are stored in a separate file, each line comprising the object ID, a comma, and the object's
attributes.
IDs should be integers, geometry should be floating point numbers. Attributes can be numbers or text. |
Default file extensions: .shp (with .shx, and .dbf files containing metadata and attributes)
| Example | Description |
| 3 binary files containing geometry, attributes and indexing information. |
Shapefiles contain geometric vector object information without topological structure (for example, the common boundary of shared
polygons will be recorded twice, once for each polygon). A given shapefile can store only one type of object, either points, lines
or areas. It is therefore common to import/export 3 sets of shapefiles representing a vector map containing points, lines and areas.
The geometry is stored in a fileName.shp file with each item referenced by a unique ID. IDs can be related to
multiple attributes in a dBase III format fileName.dbf file. The fileName.shx file contains
indexing information and is not used by LandSerf when importing data, but is created on output.
For detailed information about shapefile formats, see www.esri.com/library/whitepapers/pdfs/shapefile.pdf |
Default file extension: .atr
| Example | Description |
|
1 35.4 "Sheffield" 2 17.6 "Nottingham" 3 11.5 "Birmingham" 4 5.0 "Liverpool" : etc. |
ASCII file representing an attribute table. Columns are space, tab or comma separated. The first column is the primary ID, the remaining columns are the attributes associated with that ID. The primary ID must be integer or a floating point number, the remaining attributes can be numbers or text. Text attributes containing spaces, tabs or commas must be enclosed in double quotes. There must be an equal number of columns in every row. |
Default file extension: .bt
| Byte Offset | Length | Contents | Description |
| 0 | 10 | "binterr1.3" | A marker which indicates that this is a BT 1.3 file |
| 10 | 4 (int) | Columns | Width (east-west) dimension of the height grid. |
| 14 | 4 (int) | Rows | Height (north-south) dimension of the height grid. |
| 18 | 2 (short) | Data size | Bytes per elevation grid point, either 2 or 4. |
| 20 | 2 (short) | Floating-point flag | If 1, the data consists of floating point values (float), otherwise they are integers. |
| 22 | 2 (short) | Projection | 0: Geographic 1: metres or Universal Transverse Mercator (UTM) 2: feet (international foot = .3048 meters) 3: feet (U.S. survey foot = 1200/3937 meters) |
| 24 | 2 (short) | UTM zone | Indicates the UTM zone (1-60) if the file is in UTM. The usual convention is negative zone numbers for the southern hemisphere. |
| 26 | 2 (short) | Datum | Indicates the Datum (ignored). |
| 28 | 8 (double) | Left extent | The extents are specified in the coordinate space specified by the UTM flag/zone fields. If UTM is false, they are ordinary geographic (latitude-longitude) values. |
| 36 | 8 (double) | Right extent | |
| 44 | 8 (double) | Bottom extent | |
| 52 | 8 (double) | Top extent | |
| 60 | 2 (short) | External projection | 0: Projection is fully described by this header 1: Projection is specified in a external .prj file |
| 62 | 4 (float) | Vertical scale | Scaling factor for vertical units. If set to 0 (for backward compatibility), assumed to represent a scaling of 1 |
| 66-255 | 190 | unused | Bytes of value 0 are used to pad the rest of the header. |
|
Followed by binary equivalent of the following... 390.0 392.0 393.0 393.0 393.0 ..etc 391.0 391.0 392.0 392.0 393.0 ..etc : etc. |
Raster data are stored in nrows rows from south to north, each
row consisting of ncols values from west to east.
Raster values should be 'little-endian' values either 32-bit float or 16-bit integer according to the header value. |
||
Default file extension: .ctb
| Example | Description |
|
<?xml version="1.0" ?> <!--Colour table rules--> <!--Generated by LandSerf 2.3--> <colourTable> <rule value="0" type="discrete">255,255,255,255</rule> <rule value="1">98,123,92,255</rule> <rule value="25">130,152,117,255</rule> <rule value="50">196,197,160,255</rule> <rule value="75">244,232,195,255</rule> <rule value="100">249,242,230,255</rule> </colourTable> |
XML file representing a set of colour table rules. Each rule should be associated with a numerica value
and should define a colour using R,G,B,opacity values each scaled between
0 and 255. Colours for raster or vector maps are then interpolated between these rules. If a colour rule
is not to be interpolated, but only associated with a particular numberic value, it should have its type
set to discrete.
If a spatial object's numeric value defines its colour directly (as a 32 bit ARGB integer), its associated colour table should be set to 'raw' as follows: <?xml version="1.0" ?> <colourTable raw="true" /> |
Default file extensions: .dt0, .dt1, or .dt2
| Example | Description |
| Binary integer elevations with origin defined as lat/long coordinates. | Binary format file storing elevation values and associated metadata, originally created by the US Defance Mapping Agency (DMA) but now used by several national mapping agencies as well as the format for processed SRTM data supplied on DVD. Available at a number of resolutions - level 0 at 30 arc seconds, level 1 at 3 arc seconds and level 2 at 1 arc second. For details on the file format, see www.nga.mil/ast/fm/acq/89020B.pdf. |
Default file extension: .asc
| Example | Description |
|
Copyright 1994. EDX Engineering, Inc. All Rights Reserved. 5 280000.0 80000.0 280000.0 100000.0 300000.0 100000.0 300000.0 80000.0 50.0 50.0 401 401 .0 -2.00000 49.00000 6377563.4 .00334091 .99960000 -100000.0 400000.0 .0 323.0 392 393 393 393 393 ..etc 393 394 393 395 394 ..etc : etc. |
ASCII file for storing elevation data. Header information consists of a single
first line with whitespace characters separating the following information
copyright, ktype, xc(1), yc(1), xc(2), yc(2), xc(3), yc(3), xc(4), yc(4),
xinc_ns, xinc_ew, ny, nx, cell_offset, xlno, xlto, rad, f, xko, false_north,
false_east, min_elev, max_elev. LandSerf uses the copyright field, the
south-west [xc(1), yc(1)] and north-east [xc(3), yc(3)] corners and the
resolution fields [xinc_ns, xinc_ew] only, but all other values should be
included in the same order.
Raster data are stored in ncols rows from west to east, each row consisting of nrows values from south to north. Raster values should be integer values only and are separated by any number of whitespace characters. |
Default file extension: .bin
| Example | Description |
|
Binary equivalent of the following... 390 392 393 393 393 ..etc 391 391 392 392 393 ..etc : etc. |
Binary file for storing raster data. No header information is used, by default, when
importing generic binary rasters, the grid resolution is assumed to be 50x the vertical units.
Raster data are stored in nrows rows from north to south, each row consisting of ncols values from west to east. On saving, raster values are stored as integers and are stored as Intel ordered words (low byte first). To store non-integer values, rasters should first be transformed (e.g. by multiplying by 100) into suitable positive integers. Any values outside the range of the word (ie, 0-255 for 8 bits, 0-65535 for 16 bits etc.), will be truncated around the minimum and maximum values. On import, files can be 8, 16 or 32 bit words and use either Intel or Motorola byte ordering. |
Default file extension: .txt
| Example | Description |
|
340530.0 448650.0 390.0 "Church" 340580.0 448650.0 392.0 "Car park" 350550.0 441250.0 493.0 "Unclassified" : etc. |
Text file for storing point data. No header information is required although comment
lines starting with # are ignored and permitted at any point in the file.
Point data are stored in x y [att1] [att2] order, one point per line and can be space, tab or comma separated. All values can be in either integer or floating point formats. Attributes are optional. If only one attribute per point is provided and it is numeric (e.g. height value), it is stored as the primary attribute. If more than 1 attribute is provided, or the first attribute is non-numeric, they are stored in a separate attribute table with an automatically computed point ID. Non-numeric attributes that consist of more than one word should be enclosed in double quotation marks. |
Default file extension: .txt
| Example | Description |
|
390 392 393 393 393 ..etc 391 391 392 392 393 ..etc : etc. |
ASCII file for storing raster data. No header information is used, by default the grid resolution
is assumed to be 50x the vertical units.
Raster data are stored in nrows rows from north to south, each row consisting of ncols values from west to east. Raster values can be floating point or integer numbers and are separated by any number of whitespace characters (including new lines) or a comma. Lines starting with # are assumed to be comments and
are ignored.
When output from LandSerf, null values are given the numeric value -32766. If you wish to use another number to represent null on output, the raster should be transformed in LandSerf ('Transform raster values'). |
Default file extension: .txt
| Example | Description |
|
P 340000.0 483520.0 14.16 5 P 345000.0 479050 13.01 5 L 2 7 366000.0 489530.0 14.5 375210.0 488100.0 10 A 3 9 366000.0 489550.0 14.5 368100.0 488780.0 10.0 368200.0 488180.0 12.0 : etc. |
Text file for storing point, line, flow and area vector data. No header information is necessary
although lines starting with # are assumed to be comments and are ignored.
x,y and z values all assumed to be in the same units.
Feature type is identified by a P, L or A prefix representing point, line and area features respectively. Point data are stored in x y [z] Attrib order, one point per line. z values are optional. Line and Area data have an initial line containing the number of coordinates and an optional feature attribute. Coordinates follow in x y [z] order where the z value is optional. All coordinates and attributes can be in either integer or floating point formats. If multiple attributes are required, they should be stored in a separate attribute table. |
Default file extension: .ghs
| Example | Description |
| Binary floating point lat/long coordinates. | Binary format file holding global shorelines, rivers and lakes as closed areas. Available at a number of generalisation levels from www.ngdc.noaa.gov/mgg/shorelines/gshhs.html. This site includes more detailed information on the file format. |
Default file extension: .gpx
| Example | Description |
|
XML file for storing GPS waypoints, tracks and routes. A de facto standard for sharing GPS
data between applications. Can include a range of metadata in addition to geometric data. For full
details of the format see www.topografix.com/gpx.asp.
Note that all georeferencing uses lat/long coordinates and WGS84.
Note: To have full control over GPX attributes when saving from LandSerf, the vector map should have an attribute table with at least the headings ID, GPSObject and optionally Name, Description,
Comment and Elevation. Valid attributes for the GPSObject column are Waypoint,
Routepoint for point objects and Track for line objects. If an appropriate attribute table is not
found when saving as a GPS file, LandSerf defaults to saving all point objects as waypoints and all line objects as tracks.
|
|
|
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?> <gpx xmlns="http://www.topografix.com/GPX/1/1" creator="MapSource 6.5" version="1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.topografix.com/GPX/1/1 http://www.topografix.com/GPX/1/1/gpx.xsd"> <metadata> <link href="http://www.garmin.com"> <text>Garmin International</text> </link> <time>2005-07-24T22:20:35Z</time> <bounds maxlat="52.292004" maxlon="1.632300" minlat="51.541886" minlon="-0.058193"/> </metadata> <wpt lat="51.542000" lon="-0.058100"> <ele>15.000000</ele> <name>01Strt</name> <cmt>Pub on the Park, London Fields</cmt> <desc>Pub on the Park, London Fields</desc> <sym>Waypoint</sym> </wpt> </gpx> | |
Default file extension: .dem (with .hdr, .dmw, .prj files containing metadata)
| Example | Description |
|
.hdr file: BYTEORDER M LAYOUT BIL NROWS 6000 NCOLS 4800 NBANDS 1 NBITS 16 BANDROWBYTES 9600 TOTALROWBYTES 9600 BANDGAPBYTES 0 NODATA -9999 ULXMAP -99.99583333333334 ULYMAP 39.99583333333333 XDIM 0.00833333333333 YDIM 0.00833333333333 .dmw file: 30.0 0.00833333333333 0.00000000000000 0.00000000000000 -0.00833333333333 -99.99583333333334 39.99583333333333 .prj file: Projection GEOGRAPHIC Datum WGS84 Zunits METERS Units DD Spheroid WGS84 Xshift 0.0000000000 Yshift 0.0000000000 .dem file - binary equivalent of: 386 393 393 393 393 ..etc 387 395 396 396 394 ..etc : etc. |
Global DEM files distributed as a min binary integer .DEM file with a collection of metadata files. Those used by LandSerf
include the .hdr file that contains file format metadata, a .dmw that contains spatial transformation metadata and a .prj
file that contains global map projection information. All spatial metadata are recorded as decimal degrees. Note that
this collection is a specific case of the more general Binary Image file distribution.
fileName.dem contains the raster values in row-wise order in the format indicated by the
associated .hdr file.
fileName.hdr contains image metadata including the number of rows, columns and bits per cell.
Byte order is 'big-endian' if BYTEORDER is set to M (Motorola), or 'little-endian' if set to I (Intel).
LandSerf assumes only 1 interleaved layer.
fileName.dmw contains the georeferencing information including grid resolution, and coordinates of the
centre of the upper-left pixel of the image. The six values represent the affine transformation from image to georeferenced
coordinates. If the order of the 6 values are represented by A-F, the transformation is
x' = Ax + By + E y' = Cx + Dy + F Therefore, values (A,D) give (xRes,-yRes), (E,F) give (xOrigin,yOrigin) and (B,C) define the rotation (always 0 for GTOPO30). Note that D is negative since the image origin is at the top, but georeferenced origin will be at the bottom. fileName.prj contains global map projection information such as the spheroid used and projection type.
It can also contain projection parameters. All GTOPO30 data use WGS84 geographic (lat/long) coordinates with the addition
that an antarctic DEM is provided using a polar stereographic projection.
For more details on the format and distribution of GTOPO30 files, see http://edcdaac.usgs.gov/gtopo30/README.asp. |
Default file extensions: .jpg, .gif, .png, .tif, or .bmp
| Example | Description |
| GIF, TIF, JPEG or PNG file. |
Binary image file. Export is in either GIF, JPEG or PNG format (plus .bmp format from 3d viewer).
Import can read GIF, JPEG, PNG or TIF (including GeoTIFF) format. Currently LZW compressed TIF
files and CMYK colour scales cannot be read. Since most graphics images formats do not generally store
geographical limits, they require some geographical information to be defined.
Import allows image files to be stretched over primary raster. If an ArcGIS 'world' transformation file is present with same name and '.w' extension (ie. .GFW, .JGW, .PGW or .TFW), the image will be georeferenced on import. Exported images are given the dimensions of LandSerf's graphical display at the point at which the image is saved. |
Default file extension: .txt
| Example | Description |
|
north: 517000 south: 506000 east: 350000 west: 333000 rows: 220 cols: 340 null: -32766 type: float multiplier: 10 647 662 680 695 709 ..etc 644 660 680 694 707 ..etc : etc. |
ASCII file for storing raster data. Header information consists of at the outer bounds of the raster
and the number of rows/columns (in any order). It can optionally include the value representing null
cells, the type of cell (float or int), and the value by which cells are multiplied.
Raster data are stored in nrows rows from north to south, each row consisting of ncols values from west to east. Raster values can be floating point or integer numbers and are separated by any number of whitespace characters. |
Default file extension: .txt
| Example | Description |
|
Geometry file... ORGANIZATION: Jo Wood DIGIT DATE: 2.5.03 DIGIT NAME: MAP NAME: contours from lakes.dem MAP DATE: MAP SCALE: 25000 OTHER INFO: ZONE: 0 WEST EDGE: 333000 EAST EDGE: 350000 SOUTH EDGE: 506000 NORTH EDGE: 517000 MAP THRESH: 0 VERTI: L 3 506025 336625 506025 336625 506025 336625 : etc. Attribute file... L 336625.0000 506025.0000 50 L 333165.2545 507005.2545 100 L 334774.6173 506041.1564 100 : etc. Category file... # 2 categories 0.00 0.00 0.00 0.00 50: low risk 100: high risk |
Text files for storing point, line, and area vector data. Geometry, primary and
an optional secondary attribute set are stored in separate files in subdirectories
dig_ascii, dig_att and dig_cats respectively.
The geometry file contains header information in the first 14 lines. The bounds of the vector map are used to set the edge values in the header, the remaining items are either ignored by LandSerf or stored as 'notes' when importing. Feature type is identified by a P, L or A prefix representing point, line and area features respectively. Each new feature contains the type and number of coordinates to follow. Note that coordinate data are stored in y x order, one pair per line in the geometry file, but x y order in the attribute file. The primary attributes are stored in a separate file with the same name in the subdirectory dig_att. Attributes are linked to geometry by identifying a coordinate pair in
common (the first pair) followed by the attribute (one per line).
If secondary attributes (i.e. the attribute selected in an attribute table that is not a primary ID) are present, they are stored in a separate file with the same name in the subdirectory dig_cats
All coordinates and primary attributes can be in either integer or floating point formats. Secondary attributes (category labels in GRASS) can be numeric or textual. |
Default file extension: .kmz
| Example | Description |
|
Compressed binary format containing 'ground overlay' raster(s). |
KMZ files can be imported directly into Google Earth. See http://code.google.com/apis/kml/documentation for more details. LandSerf outputs the current display as a georeferenced raster. If called via LandScript, output is the selected raster. |
Default file extension: .kml
| Example | Description |
|
<?xml version="1.0" encoding="UTF-8" ?> <!--KML file created by LandSerf 2.3--> <kml xmlns="http://earth.google.com/kml/2.1"> <Document xmlns:xlink="http://www.w3/org/1999/xlink"> <Folder> <name>Vector map title</name> <Placemark> <name>1.0</name> <Point> <coordinates>-1.681592,53.186565,0</coordinates> </Point> </Placemark> <Style id="ls3.0"> <LineStyle> <width>3</width> <color>ff000000</color> </LineStyle> </Style> </Document> </kml> |
KML files can be imported directly into Google Earth. See http://code.google.com/apis/kml/documentation for more details. LandSerf outputs the primary vector map when saving in this format. |
Default file extension: .lsc
| Example | Description |
|
# Script to contour a surface baseDir = "c:\data\"; surf = open(baseDir & "fractal1.srf"); contours = contour(surf,0,5,1); save(contours,baseDir & "contours.vec"); |
Text file storing LandScript commands. See the LandScript user's guide for details. |
Default file extension: .srf
| Example | Description |
| Compressed binary format. | This is the default format in which LandSerf raster maps are stored. In addition to raster values, full metadata, colour tables and attributes are stored in the single zip compressed file. |
Default file extension: .vec
| Example | Description |
| Compressed binary format. | This is the default format in which LandSerf vector maps are stored. In addition to vector geometry, full metadata, colour tables and attributes are stored in the single zip compressed file. |
Default file extensions: .gz or .xml
| Example | Description |
|
<?xml version='1.0' encoding='UTF-8'?> <osgb:FeatureCollection xmlns:gml='http://www.opengis.net/gml' xmlns:xlink='http://www.w3.org/1999/xlink' xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance' fid='GDS-2183-1'> : etc. |
GML format vector of GB Ordnance Survey's 'MasterMap' large scale spatial database. See www.ordnancesurvey.co.uk/oswebsite/products/osmastermap/ for more details. |
Default file extension: .ntf
| Example | Description |
|
07 Section header record (raster bounds) 50 Grid header record (DEM range) 51 Grid record (DEM values) : etc. |
ASCII file for storing geographical data. This is a complex transfer format used largely by the GB Ordnance Survey for distributing their pre-MasterMap digital data. It is also referred to as British Standard BS 7567 'Electronic Transfer of Geographic Information'. For details see e.g. http://www.bsi-global.com/ (select a catalogue search for BS 7567). Header information is stored in section and grid header records, the elevation values in a grid record. |
Default file extension: .ntf
| Example | Description |
|
02 Database header record (product type) 07 Section header record (vector bounds) 05 Feature class record (attribute labels) 15 Point record 23 Line record 21 Geometry record (coordinates) : etc. |
ASCII file for storing geographical data. This is a complex transfer format used largely by the GB Ordnance Survey for distributing their pre-MasterMap digital data. It is also referred to as British Standard BS 7567 'Electronic Transfer of Geographic Information'. For details see e.g. http://www.bsi-global.com/ (select a catalogue search for BS 7567) or gdal.velocet.ca/~warmerda/projects/ntf. LandSerf can read Profile and Panorama contour and form-line files, LandLine (large scale), Meridian (medium scale) and Strategi (small scale) vector data in this format. |
Default file extensions: .svg or .svgz
| Example | Description |
| Scalable vector graphics viewable over the web with any SVG plugin. If file has extension .svgz, then it will be compressed using GZIP deflation. Most SVG plugins should be able to decompress .svgz files on the fly. The geometry is mirrored in the X axis since the default SVG origin is the top-left corner. Styles are defined separately allowing easy user customisation of vector appearance. Polygons should have repeated first and last coordinates to ensure closing boundary. | |
|
<?xml version="1.0" encoding="iso-8859-1"?> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 1020.0 1020.0"> <!-- Format definitions --> <defs> <style type="text/css"><![CDATA[ polyline { stroke:black; stroke-linejoin:round; stroke-linecap:round; stroke-width:17.435898; stroke-opacity:1; fill:none; } path { stroke:#ffffff; stroke-linejoin:round; stroke-width:17.435898; stroke-opacity:0.19607843; fill-opacity:0.75; } circle { stroke:none; fill-opacity:1; } text { stroke:none; fill-opacity:1.0; fill:#000000; font-family:sans-serif} ]]></style> </defs> <!-- Object metadata --> <title>Combined vector</title> <desc>Union of Simple shapes and Simple shapes</desc> <!-- Geometry --> <g id="spatialObject" transform="translate(10.0,1010.0) scale(1,-1)"> <path style="fill:#cb6b66; " d="M300.0,300.00006 L100.0,0 500.0,0 300.0,300.00006 Z "/> <path style="fill:#e488ed; " d="M150.0,1000.0 L0.0,700.0 300.0,700.0 150.0,1000.0 Z "/> <circle style="fill:#cb6b66;stroke-opacity:1.0; " cx="300.0" cy="100.0" r="0.2"/> <circle style="fill:#e488ed;stroke-opacity:1.0; " cx="150.0" cy="800.0" r="0.2"/> </g> <!-- Point labels --> <text x="313.05127" y="919.1539" font-size="30" text-anchor="middle" >Thing one</text> <text x="163.05128" y="219.15387" font-size="30" text-anchor="middle" >Thing two</text> </svg> |
|
Default file extensions: .hgt or .srtm
| Example | Description |
|
Binary equivalent of the following... 218 218 219 219 219 ..etc 217 217 218 218 219 ..etc : etc. |
Binary file for storing global elevation data, sampled at 1 arc-second, 3 arc-second or 30 arc-second resolution. No header
information is included, but the file name indicates the geographic origin of the DEM. See
www2.jpl.nasa.gov/srtm/ for details. LandSerf can also read 'srtm30Plus'
files that comprises combined SRTM, GTOPO30 and bathymetric data at 30 arc-second resolution. For more details see
http://topex.ucsd.edu/WWW_html/srtm30_plus.html.
Raster data are stored in nrows rows from north to south, each row consisting of ncols values from west to east. Raster will consist of 1201x1201 cells (3 arc-second DEM), 3601x3601 cells(1 arc-second DEM), 48000x6000 cells (30 arc-second srtm30plus), or 7200x3600 cells (30 arc-second antarctic srtm30plus). |
Default file extension: .raw
| Example | Description |
|
Binary equivalent of the following... 218 218 219 219 219 ..etc 217 217 218 218 219 ..etc : etc. |
Binary file for storing raster data. No header information is included in the file.
Raster data are stored in nrows rows from south to north, each row consisting of ncols values from west to east. On export from LandSerf raster values will be a square of side 2^n+1, for example, 257x257, 513x513, 1025x1025 depending on the original raster size. Attribute values will be 8 bit integers. LandSerf will automatically scale any raster to these dimensions with a range of 0-255. On import a choice of 8, 16 or 32 bit Intel (low byte first) ordered integers can made. |
Default file extension: .ter
| Example | Description |
|
Binary equivalent of the following... 218 218 219 219 219 ..etc 217 217 218 218 219 ..etc : etc. |
Binary file for storing terrain data. Unlike Terragen's 'raw' binary file format, this contains
header information and can be used to export non-square terrain data without resampling of elevation
values.
For details of the format, see www.planetside.co.uk/terragen/dev/tgterrain.html. |
Default file extensions: .r3d .xml
| Example | Description |
| XML file for storing 3d viewing parameters. The optional <environment> tag stores parameters describing the surrounding space. The optional <surface> tag contains parameters describing the surface appearance. The <waypoint> tags describe a sequence of camera positions and views. These are used to construct 'flythroughs' in the 3d viewer, but can also be imported as 2d vectors in LandSerf. | |
|
<?xml version="1.0" ?> <!--3d route and viewing parameters generated by LandSerf 2.3--> <fieldtrip> <title>3d route generated by LandSerf 2.3</title> <environment fogdensity="0.1" sky="true" skycolour="#ff1a801f" seacolour="#ffad69aa" fogcolour="#ffccb4b3" wallcolour="#ffdcdef5"></environment> <surface resolution="4" vscale="1.9" smooth="true" grid="false"></surface> <route> <waypoint name="waypoint1"> <view heading="320.0" pitch="-33.0" fov="70.0"> <spatial type="point" x="50.0" y="-25.0" z="51.5"></spatial> </view> </waypoint> <waypoint name="waypoint2"> <view heading="328.0" pitch="-23.0" fov="30.8"> <spatial type="point" x="89.2" y="6.8" z="17.4"></spatial> </view> </waypoint> </route> </fieldtrip> |
|
Default file extension: .dem
| Example | Description |
|
MOUNT RAINIER WEST, WA-24000 LAT:: 46 45 0.0000 N LONG:: -121 45 0.0000 W SCALE:: 24000 ...etc
... 392 393 393 393 393 ...etc |
ASCII file for storing elevation data. Header information contains spatial extent, resolution,
geometry, projection and error information in 1024 byte blocks. Structure is relatively complex
and is documented at rockyweb.cr.usgs.gov/nmpstds/demstds.html.
See also www.cs.arizona.edu/topovista/sdts2dem/
for an error-corrected and updated version of the sdts2dem converter.
Raster data are stored in columns rows from west to east, each row consisting of values from south to north. Because of the projection or potentially large areas into planar coordinates, each S-N profile can be of a different length. Raster values are integers but can be scaled by a multiplier stored in the header file. They are stored in fixed-width 1024 byte records, although LandSerf will use whitespace delimiters to read in the raster body. |
Default file extension: .vst
| Example | Description |
|
<?xml version="1.0" ?> <!--Vector drawing styles--> <vectorstyles> <point fixed="true" size="2" surround="false"></point> <line fixed="true" size="1" surround="false"></line> <polygon boundary="true" boundarycolour="#000000ff" opacity="0.25"></polygon> <label align="northeast" background="#ffffff80" foreground="#000000ff" size="10" visible="false"> </label> <rendering style="quality"></rendering> </vectorstyles> |
XML file that defines the drawing styles for vector maps. Point, line, polygon and label styles can be
defined along with rendering style (speed or quality). Each attribute corresponds to
a setting shown in LandSerf's 'Vector appearance' window. Colours are defined using 8 digit hex numbers
in the form #RRGGBBAA (red, green, blue and opacity).
|
Default file extension: .bin
| Example | Description |
|
Binary equivalent of the following... 390 392 393 393 393 ..etc 391 391 392 392 393 ..etc : etc. |
Binary file for storing raster data. No header information is used, by
default the grid resolution is assumed to be 50x the vertical units.
Raster data are stored in nrows rows from south to north, each row consisting of ncols values from west to east. Raster values should be 16 bit Intel (low byte first) integers. If floating point values are required, scale up to largest possible integer value (65535) and rescale after file has been transferred. |
Default file extension: .txt
| Example | Description |
|
390 392 393 393 393 ..etc 391 391 392 392 393 ..etc : etc. |
ASCII file for storing raster data. No header information is used, by
default the grid resolution is assumed to be 50x the vertical units.
Raster data are stored in nrows rows from south to north, each row consisting of ncols values from west to east. Raster values should be integers and are separated by any number of whitespace characters (including new lines). |
Default file extensions: .wrl, .wrz or .vrml
| Example | Description |
|
#VRML V2.0 utf8# # Converted from LandSerf file: Soil # SW corner was originally: 320000.0,435020.0 # Scaled so centre is at 0,0,0 with largest side 10 units long Background { skyColor [0.0 0.2 0.7, 0.0 0.5 1.0, 1.0 1.0 1.0 ] skyAngle [ 1.309, 1.571 ] groundColor [0.1 0.10 0.0,0.4 0.25 0.2, 0.6 0.60 0.6, ] groundAngle [ 1.309, 1.571 ] } Transform { translation -5, -4, -10 scale 0.1,0.1,0.1 children [ Shape { appearance Appearance { material Material { } } geometry ElevationGrid { xDimension 100 zDimension 100 xSpacing 1.0 zSpacing 1.0 solid FALSE creaseAngle 3 height [ 2.5961194, 2.5735216, etc. 2.5961135, 2.5735227, etc. etc. ] colorPerVertex TRUE color Color { color [ 0.553 0.163 0.463, etc. 0.553 0.121 0.495, etc. etc. ] } } } ] } |
ASCII file for defining Virtual Reality worlds. If the extension is .wrz, file is GZIP compressed.
Raster maps saved in this format consist of raster elevations values in a VRML97 heightfield and vertex
colouring as RGB triplets for each elevation. Vector TINs can be saved as VRML Indexed Face Sets which
generally produce smaller and more quickly rendered VRML worlds.
All geometry is scaled to form a 20x20 unit grid centred at local coordinates 0,0,0. Null values are represented by the minimum elevation value. You may wish to consider resampling DEM to a reasonably coarse resolution (100x100 or so) or creating a TIN before output to keep the VRML world a manageable size. Includes a simple ground plane and sky to provide background context. Elevation values are floating point and are separated by any number of whitespace characters. Output has been tested with the excellent Cortona VRML client compatible with most web browsers (IE, Opera, Firefox, Mozilla). |