You will need the program generate_map_data_type1.exe, which you can download here. The program is supplied as-is and is not warranted to be fit for purpose or bug-free. It is a 32-bit Windows console application.
It can read and convert various data formats. Data formats are inferred from file extensions:
.osm - OpenStreetMap data
.xml - an XML control file specifying SHP and DBF files (ESRI shapefiles)
.hgt - USGS height data
.csv - Ordnance Survey Code-Point Open postcodes
.osm_to_ctm1_rules - rules for converting OSM to CTM1 - affects following files
Data from several data sets can be combined into a single map by using multiple /input parameters in addition to the main input file.
The map data files (CTM1 files) are usable by any version of CartoType.
This method uses data from OpenStreetMap, a organisation that is creating a world-wide street map from data collected by volunteers using GPS devices.
1. Download OSM files from one of the links here.
or you can make OSM files for any area:
Use the Export tab in the main
OpenStreetMap map page (small areas only) or, for larger areas, use the Overpass API
(see http://wiki.openstreetmap.org/wiki/Overpass_API)
Put something like this into the query form at http://www.overpass-api.de/query_form.html:
<osm-script timeout="10000" element-limit="1073741824">
<union into="_">
<bbox-query into="_" s="52" n="53" w="4" e="5"/>
<recurse from="_" into="_" type="up"/>
<recurse from="_" into="_" type="down"/>
</union>
<print from="_" limit="" order="id"/>
</osm-script>
with your own values in the s, n, w and e attributes.
Save the downloaded data (which at present is always called 'interpreter') to your hard disk as a file and change its name to something suitable ending in .osm.
2. If your file is called 'my_file.osm', use the following command line
generate_map_data_type1 /project=utme my_file.osm
This will create a .ctm1 file that can be loaded by any of the CartoType demonstration programs.
Large files like the OSM data for Italy, which is over 6Gb, or Germany, which is bigger, can cause the 32-bit Windows version of generate_map_data_type1 to run out of memory (error code = 2). Please contact us if you need to create map files from large data sets. We can supply a version of generate_map_data_type1 for Unix and Unix-like OSs, or create the maps for you.
You can optionally control the way data is converted from OSM to CTM1 format, and which data is used, and which data is omitted, using an XML file containing rules. By convention such a file has the extension osm_to_ctm1_rules. You supply its name on the command line, before the names of any osm files it needs to affect, using /input=<rules file name>.
The rules file consists of a single <OsmRules> element containing as many <Rule> elements as necessary. Rules may be nested. All the rules at the top level are tested, and for any rule that is fulfilled, (i) it is executed, and (ii) all its nested rules are tested.
A Rule element tests OSM tags. It can test the key, the value, and whether the tag is in a way. It does this using attributes:
<Rule Key="name" StringAttribName="name"/> tests whether the key is 'name', and if so sets the object's string attribute name to 'name'.
<Rule KeyStartsWith="name:" StringAttribName="%Key%"/> tests whether the key starts with 'name:' and if so sets the object's string attribute name to the key value.
<Rule Value="motorway" Layer="major-road" RoadType="Motorway"/> tests whether the value is 'motorway', and if so sets the layer to 'major-road', the road type to 'motorway, and implicitly sets the one-way flag to true.
<Rule InWay="true" Type="polygon"/> tests whether the tag is in a way, and if so sets the object type to polygon.
The actions of a rule element, like the tests, are attributes of <Rule>. If a rule's tests all succeed, all its actions are performed, and its nested rules are tested. (Only one of the actions marked with * can be used in a single rule. Use multiple rules to perform more than one of these actions.) The available actions are:
Layer: set the object's layer to the supplied layer name.
StringAttribName: set this string attribute to the supplied value
Type: set the object's type; legal values are 'point', 'line'. 'polygon' and 'array' (but 'array' is not yet supported in any useful way).
*OsmType: set the object's OSM type - a three-letter abbreviation usable by the style sheet, e.g., 'woo' for a wood. This is encoded using 5 bits per letter and placed in the top 15 bits of the object's integer attribute.
*IntAttrib: set the object's integer attribute to the supplied value. If the value is '%Value% use the tag's value.
*IntAttribLowWord: set the low word of the object's integer attribute to the supplied value. If the value is '%Value% use the tag's value.
*RoadType: set the object's road type; legal values are Motorway, MotorwayLink, TrunkRoad, TrunkRoadLink, PrimaryRoad, PrimaryRoadLink, SecondaryRoad, TertiaryRoad, UnclassifiedRoad, ServiceRoad, Track, PedestrianRoad. The values Motorway and MotorwayLink implicitly set the one-way flag.
*Level: set the object's level (for tunnels, bridges, overpasses, etc.) to the supplied value. If the value is '%Value% use the tag's value.
*Bridge: set the object's bridge flag to the supplied value. If the value is '%Value% use the tag's value.
*Tunnel: set the object's tunnel flag to the supplied value. If the value is '%Value% use the tag's value.
*OneWay: set the object's one-way value to the supplied value. If the value is '%Value% use the tag's value.
*Roundabout: set the object's roundabout flag to the supplied value (0 or 1). If the value is 1, set the one-way-forward flag true.
The standard rules are stored by generate_map_data_type1. You can write them out, so that you can edit them and create a customised version, by using the following command:
generate_map_data_type1 /writerules=osm >standard.osm_to_ctm1_rulesThe best way is to use the coastline data which Mapnik uses to create tiles for the OpenStreetMap slippy map.
1. Get the coastlines as an SHP file and associated files from http://tile.openstreetmap.org/processed_p.tar.bz2. Unpack them and put them in a folder called \coastlines.
2. Create a file called coastlines.xml as follows:
<?xml version="1.0" encoding="UTF-8"?>
<DataSet Version="1.0" Name="World Coastlines" Copyright="unknown">
<ShpFileGroup PointFormat="mercator" XAxisDirection="right" YAxisDirection="up">
<File Name='..\coastlines\processed_p' Layer='outline'/>
</ShpFileGroup>
</DataSet>
3. Run generate_map_data_type1 with these extra options:
/extent=<min-long>,<min-lat>,<max-long>,<max-lat> /input=coastlines.xml
The longitudes and latitudes for the /extent option should be big enough to enclose all the rest of your map data. The /extent option tells generate_map_data_type1 to select only coastlines in that region from the coastline data.
4. Modify your style sheet so that it has a blue background, and fills the <outline> layer, which now consists of filled shapes, in white or whatever color you prefer for land. For example:
<CartoTypeStyleSheet name='my style' background='lightblue'>
...
<layer name='outline'>
<shape fill='white' border='white' borderWidth='1'/>
</layer>
The border is the same color as the fill. This is intentional, because sometimes the outline (land) areas don't meet precisely, and a border is needed to hide the joins.
Digital height data can be obtained from more than one source. A convenient one is the United States Geological Survey, which publishes data as tiles for one-degree-square sections of the world in a simple format called HGT. Here is the site containing the data and documentation. Other sources are described, reviewed and referenced at ViewFinder Panoramas.
Disclaimer: as with all map data, neither Cartography Ltd nor CartoType Ltd nor any of its officers, directors, employees or sub-contractors take responsibility for or guarantee the copyright status or intellectual property status of this data. It is the user's responsibility to obtain permission for using data.
First download SRTM3 data covering the area you are interested in. For example, the USGS data for Eurasia is here. The files will usually be zipped and have names like N00E072.hgt.zip. Unzip them and don't change the names: generate_map_data_type1 uses the filenames to identify the correct data. The names refer to the south-west corner of the one-degree tile. Put all the files in a single directory. In the example below, the directory name is \usgs-height-data.
Then add it to your map using the /usgs command-line parameter in generate-map-data-type1. The format is
/usgs={<extent>}{,<directory>} - load USGS height data (.hgt) files for the extent from the directory given
and you can specify the extent as either three numbers, giving the OpenStreetMap map tile number in the form zoom, x, y; or four numbers, min-long, min-lat, max-long, max-lat. If you omit the extent you need to specify it earlier on the command line using /extent.
Other parameters affecting height data are:
/terrain=height|height-feet|shadow - generate height or shadow arrays from height data; affects following files; default is shadow
/interval=<number> - interval between terrain sample points in metres; default is 250; the SRTM3 data is sampled at 90m so for this data there is no advantage in using an interval less than 90. The smaller the interval, the larger the data.
Here is an example showing how to generate a map of Greece with both height in feet and shadows. (Don't use both layers unless you are happy to incur the cost of slightly slower display and larger data.)
generate_map_data_type1 /lowreslayers=yes /compress=a /project=m /extent=18.74,34.39,29.64,42.19 /interval=100 /usgs=\usgs-height-data /terrain=height-feet /usgs=\usgs-height-data /input=coastlines.xml greece.osm
/lowreslayers=yes - create sets of layers for different zoom levels - speeds up map display but increases data size by about 30%.
/compress=a - compress arrays: that is, compress the array objects used to store terrain using ZLIB
/project=m - use spherical Mercator projection
/extent=18.74,34.39,29.64,42.19 - set the extent, both for getting coastlines and for terrain. These bounds in lat/long cover the whole of Greece.
/interval=100 - resample the data at an interval of 100 metres
/usgs=\usgs-height-data - specify the location of the height data (.HGT) files; this parameter creates a terrain-shadow layer, which is the default
/terrain=height-feet /usgs=\usgs-height-data - these two parameters change the terrain mode to create a terrain-height-feet layer, and reload the height data
/input=coastlines.xml - load the SHP data for the coastlines (see above)
greece.osm - load the OSM data for Greece
If you supply an XML file (which must have the extension .xml) to generate_map_data_type1.exe, it is assumed to be a control file for reading SHP data. Its format is as follows.
The entire file consists of a <Dataset> element. It has the following attributes, all of which are optional:
Version: a string describing the version of this data.
Name: a string that is the name of the data; usually a geographical name.
Copyright: the copyright information for the data.
Inside the <Dataset> element are one or more <ShpFileGroup> elements.
A <ShpFileGroup> encloses a group of files sharing the same coordinate format and axes. Its attributes, all of which are optional, are:
PointFormat: the meaning of point coordinates; possible values are 'degree' (degrees of latitude and longitude, stored as double-precision floating point numbers), 'plane' (Cartesian coordinates in metres. The projection is unknown. This format is suitable for local, large-scale data or informal mapping projects.), 'osgb' (Ordnance Survey of Great Britain: British National Grid format; eastings and northings stored as double-precision floating point numbers), and 'mercator' (spherical Mercator projection). Other values, or no value, are taken to mean an arbitrary or unknown format.
Proj4: parameters for the projection, in the format accepted by the proj-4 library. These parameters override PointFormat if present and define the meaning of point coordinates in the SHP file. For example, if the SHP file contains data in Universal Transverse Mercator (UTM) form, for zone 11, north, using the NAD83 datum, you should use Proj4='+proj=utm +zone=11 +datum=NAD83'.
XAxisDirection: possible values are 'true' if the x axis increases to the right, and 'false' if it increases to the left. If this attribute is missing the x axis direction is assumed to be to the right.
YAxisDirection: possible values are 'true' if the y axis increases upwards, and 'false' if it increases downwards. If this attribute is missing the y axis direction is assumed to be upwards.
The <ShpFileGroup> element contains one or more <File> elements.
Each <File> actually specifies a pair of files: a DBF file and an SHP file. Both must have the same name, given by the Name attribute, and the extensions dbf and shp respectively.
It is legal for there to be several <File> elements referring to the same pair of files. In this case, different data is extracted each time, to produce several layers from the same file.
Legal attributes are:
Name (compulsory): the base file name, without extension, used for the
dbf and shp files containing the data for this layer.
Layer (compulsory): the name of the layer; this name is used in the style
sheet to select the layer.
MappedObjectsOnly (optional): if the value of this attribute is 'true', and there are mappings in at least one of the field specifications (<Field> elements: see below), objects that are not selected by a mapping are ignored. This allows mappings to select a subset of the objects and make a layer from them.
CodePage (optional): if this is present and the numeric value of the attribute is non-zero, it is the Windows code page number for the 8-bit text in the dbf file. For example, code page 1251 is Windows Cyrillic. If the CodePage attribute is not present the text is assumed to be UTF-8. Only two code pages are supported: 1251 (Windows Cyrillic) and 1252 (Windows Latin 1).
The <File> element contains one or more <Field> elements.
The <Field> element names a DBF field and specifies the name of the object attribute it is to be converted into. It can also contain <Mapping> elements to specify a mapping between values.
Legal attributes are:
Name (compulsory): the name of the field in the dbf file.
NumericAttrib: the name of a numeric map object attribute into which this field's value is converted.
StringAttrib: the name of a string map attribute into which this field's value is converted.
RoadTypeAttrib: the name of a numeric road type attribute into which this field's value is converted. Road type attributes are ORed together into a single value which becomes the first numeric attribute of a map object.
Attrib (obsolete): the name of an attribute, taken to be a numeric attribute unless the name is 'Label', in which case it is a string attribute.
The <Field> element must contain either a NumericAttrib or a StringAttrib element.
The StringAttrib value 'Label' is special. Multiple <Field> objects with StringAttrib='Label' can exist, in which case all the fields are selected in order, and the values are concatenated, separated by spaces, to produce the label. This special feature allows databases containing street names with prefixes ('North', 'East', etc.) and suffixes ('Street', 'Gardens', etc.) to be handled in a simple way, concatenating prefix, main name and suffix to produce a single label.
Default (optional): the default value for this field, to be used if it is not present for an object.
A field can optionally contain <Mapping> elements.
DecimalPlaces: the number of decimal places to which numeric values are rounded. If it is in the range -9 ... 9 any field containing a number (and nothing else) is rounded. To round to integers use 0 decimal places; to round to two decimal places use the value 2; to round to the nearest thousand use the value -3, etc. Rounding applies to both string and integer attributes. A useful application is in rounding contour heights set by gdal_contour to integers.
Special treatment for a field called CFCC, to support US Census TIGER data: If the field is CFCC and no explicit mappings are specified, convert the US Census TIGER data CFCC code to a number. For roads, convert to the road types specified by TRoadType in cartotype_map_data.h. For other types replace the leading letter with a number. This is a mapping of CFCC codes A00...Z99 to the numbers 100...2699.
Mappings convert specified field values to attribute values. Field values can be mapped to integer or string attributes, or to special OSM types, which are three-letter codes compressed into the top bits 15 bits of a 32-bit integer. The attributes are:
From: the field value to convert; a string. If <From> is absent the empty string is assumed.
ToInt: causes the field value to be converted to this integer value as an integer object attribute.
ToOsm: causes the field value to be converted to this three-letter CartoType OSM type as an integer object attribute.
ToText: causes the field value to be converted to this text as a string object attribute.