February 2025 update
Latest news and plans
Improvements to 8.12 since release
The current CartoType release is 8.12, which came out on 7th November last year, 2024. We’ve made a number of fixes and improvements since then, and they are briefly mentioned on the evaluation SDK web page. Here I will look into them more deeply.
Much less RAM is used when loading maps side by side
What is ‘side by side’ and why should I care? CartoType has the ability to load multiple maps in the same display and blend them or join them seamlessly. They may actually be side by side, acting as tiles, or they can be used as overlays and underlays. It’s convenient to use this method on low-RAM devices so that only the maps needed for the current display are loaded into memory. The latest version of CartoType vastly reduces run-time RAM use for side-by-side maps. For example, in an experiment using files representing OSM-type tiles and loading all four zoom-1 tiles and two zoom-4 tiles, RAM use declined from almost 2Gb to 450Mb. Further tiles consumed only a few Mb each when they were loaded.
Better address searching
Address searching is a problem that can never be solved perfectly. Addresses are imprecise and user expectations can’t always be fulfilled. For example, it is often unclear which locality a street belongs to if it is part of a large city or relatively close to several towns, villages and suburbs. Official address data often contradicts local usage. Most CartoType clients use OpenStreetMap data, which is incomplete and sometimes incorrect.
The latest iteration of CartoType’s address finding system includes fixes to both the run-time system and to makemap, the tool for creating map files. To take advantage of the latest version you need to obtain the latest CartoType library, and re-create your CTM1 map files using the latest makemap.
Fuzzy matching was too broad
In the map of Wisconsin an address search for a street containing the string 'Forrest' with locality = 'Laona', using fuzzy matching, produced Moore Street, Wabeno, because the string 'orest' in 'Moore Street' was fuzzy-matched with 'forrest'. Fuzzy matching is now less enthusiastic but still works well for missing, extra or transposed letters.
Streets were not matched with localities in US searches
In the USA, streets and roads that are relatively distant from their nearest town are still regarded as being ‘in’ that town for the purposes of an address. A number of tweaks have fixed that problem. They are complex, but include changing the weights used by makemap to choose relevant localities when creating the street index, and using the actual (great-circle) distance between places rather than the on-map distance, which may be much greater in a Mercator projection.
New relevance weightings
Address and free-text searches use a relevance weighting to assess the usefulness of each result. The results are returned in order of relevance. Ideally, the first result should be the one the user wants, however incomplete or misspelt the query.
The weighting systems have been rewritten to give better results, and to be more easily modifiable.
Free-text searches give 50% weight to quality of match (full match > phrase match > fuzzy match), 30% weight to place rank (cities and countries outrank villages, etc.) and 20% weight to the distance from search centre, if there is a search centre.
Address search weights are more complicated, and balance quality of match of the POI if any (30%), street match quality (20%), city match quality (10%), city rank (10%), postcode match quality (10%), distance of building from street (10%) and distance of street from city centre (10%).
These weighting systems are of course first attempts, but give far better results than the previous less systematic method.
Asynchronous map loading
Maps can now be loaded asynchronously by a background thread, meaning that the user experiences no delay or freeze to the responsiveness of an application while a map is loaded. This new feature is helpful on devices with relatively slow file systems, or when loading very large maps.
Current work
Universal tiling system
Popular map tiling systems use the Web Mercator projection, cutting it off at ~85 degrees North and South to give a square projected map, and dividing it successively into four smaller squares at each zoom level.
Another system uses the Plate Carrée projection with a rectangular map twice as broad as its height, with two square level-0 tiles and subsequent division of each tile into four.
Internally, in its graphics-accelerated map drawing code and when rendering on-line CTM1 files, CartoType uses its own universal tiling system that works for any map projection as long as that projection does not create coordinates greater than about 31,000 km or less than -31,000km; or can be conveniently clipped, as is necessary with any Mercator projection (because the poles are at infinity).
This range of 62,000km was chosen because it is much greater than the circumference of the Earth at the equator (just over 40,000km), and works well with CartoType’s internal integer coordinate system, in which the units are 32nds of a projected metre, because coordinates for any tile, and its width and height, fit into signed 32-bit integers. (The bounds, in CartoType’s units, of the single level-0 tile (x=0, y=0, zoom=0) are -1006632960, -1006632960, 1006632960, 1006632960, and its width and height are 2,013,265,920. The maximum signed 32-bit integer, 2^31 - 1, is 2,147,483,647.)
In the next CartoType release, makemap will make it easy to create maps using this universal tile system when a non-Mercator projection is used, allowing easy side-by-side map loading for such maps. The current version of makemap supports the command-line option -extent=<zoom>,<x>,<y> for Web Mercator maps; that option will be enhanced to use universal tiles for maps in other projections.
Automatic map loading and unloading
The automatic map loader, which will also be available in the next release, combines asynchronous map loading with the universal tile system and side-by-side maps to provide a flexible way to draw very large maps, including maps of the whole world, while loading only the data required for the currently displayed region.
A new CartoType Framework API function will allow you to specify parameters including:
template for a tile file, like
/map_tiles/zoom{z}/{x}/{y}.ctm1, where {z}, {x} and {y} represent the zoom level and tile coordinatesdisplay zoom levels at which tiles are loaded, for a given tile zoom level: for example, it might be desirable to draw the zoom-level-0 tile at all display zoom levels if it was a background tile containing the world’s coastlines and country borders.
Once you have supplied CartoType with these parameters and turned on auto-loading, there is nothing more to do. Panning, zooming and other changes to the map view trigger loading the correct map files asynchronously, and unloading those that are no longer needed, using an LRU cache.
Future plans
Here are some future plans for CartoType. None of them are guaranteed to happen. If you are a CartoType user or intended user, please let us know what you think, whether you would find these new features useful, and tell us about any other feature requests that are important to you.
Loadable driving instructions in any language
Turn by turn driving instructions while navigating, including speech synthesis (using platform text-to-speech APIs) are already supported, but only for English, French, German, Portuguese, Spanish and Swedish. A new API would allow a standard set of translations for any language to be loaded from a file.
One difficulty is of handling grammatical diversity. For example, Polish numbers take different forms of the noun: 1 behaves as an adjective; for 2, 3 and 4 and compound numbers ending in them the noun is in the same case as the number; for 5, 6, 20, 21, 25, 26, etc., the noun sometimes, but not always, must be in the genitive plural. The result is that ‘4 kilometres’ is ‘4 kilometry’, while ‘5 kilometres’ is ‘5 kilometrów’. This makes the task non-trivial. Even though we might be able to solve that particular problem using the abbreviations 4km and 5km, that’s not always possible.
Multiple icons for a single map object
It’s easy to add your own map objects to a CartoType map, and most if not all clients make use of that feature, often displaying point objects with custom icons.
In a hypothetical example, imagine point objects representing monitoring devices such as fire alarms or sensors. Any object can have several states: type of alarm, on/off, signal strength, alarm triggered, and so on. Similarly, a hotel or tourist attraction might have various attributes such as star rating, seasonal or year-round, open to non-residents, and availability of on-site parking. Supporting multiple icons would mean that a point might be shown by the presence of several icons side by side or arranged in pre-set places, and that those icons could be shown or hidden as needed.
Support for Overture map data
Overture is a self-described ‘collaborative open-data initiative’ aiming to provide open map data that is more consistent than that of OpenStreetMap, although OpenStreetMap data forms most of the basis for Overture’s offering.
It would probably be useful for CartoType’s customers to be able to use the Overture data in an easy way that was compatible with CartoType’s API and style sheets, just as Mapbox vector data can be used seamlessly and cleanly already.
Support for HERE traffic data
HERE Technologies provides mapping and routing services. One service that can be used independently of the others is traffic data, consisting of current traffic flow speeds, diversions, temporary speed restrictions, and road closures. CartoType can make use of OpenLR location referencing data, and HERE can provide its traffic data in that format, so it looks like a good fit. Nevertheless, there is a cogent argument against adding this feature, which is that it requires data connectivity, while CartoType works well offline; clients writing applications for which data connectivity is available might prefer to use an online solution for the whole mapping package.
AI address searching
Address searching could be greatly improved by using AI (specifically ML, or machine learning, which is the application of AI to a specific learning task) to parse free-form addresses. The best candidates for implementation look to be TensorFlow to create the model, and LiteRT on devices.