Release date: 21st April 2017
Previous release: 4.2, 12th December 2016
Major changes since the previous release
Added a new routing system, turn-expanded A-star, which allows routes to pass through the same junction or road segment twice.
Added functions to set and get the preferred routing system and find out what the actual current routing system is.
Improved the system for allowing routes to pass along private highways at start and end, which was formerly unreliable and could cause slow route calculation.
The CFramework functions GeoCodeSummary and GetAddress no longer take a locale parameter. They use the locale set by CFramework::SetLocale; analogous changes have been made to the Android, .NET, and iOS SDKs.
Changes affecting the C++ API only
Abolished the CartoType-specific array classes CArray, CPointerArray, CNonOwningPointerArray, TFixedSizeArray. Standard library std::vector and std::array classes are now used instead of them.
Added functions CFramework::AbbreviatePlacename and ExpandStreetName.
Added the string class TWritableText, mostly for internal use.
The TTextLiteral macro now causes no code to be executed at run-time.
Changes affecting the .NET API only
The Geometry class now has functions to get the number of contours, number of points in any contour, the coordinates of a point, and whether the object is empty.
Changes affecting the IOS API only
The CartoTypeGeometry class now has functions to get the number of contours, number of points in any contour, and the coordinates of a point.
Changes to makemap
Many more projections are supported by the /project option, allowing you to use (for example) Lambert Equal Area with default parameters by simply using /project=laea instead of having to supply the full set of proj.4 options. The names are the same as those used in proj.4. The following projections are now supported: merc, cea, eqc, tmerc, tcea, cass, sinu, moll, eck1...eck6, goode, hatano, mbtfpp, mbtfpq, mbtfps, putp2, putp5, quau, winkl, boggs, collg, dense, parab, poly, hammer, wag7, aitoff, wintri, loxim, bonne, lcc, eqdc, pconic, aea, leac, rpoly, stere, sterea, gnom, ortho, airy, laea, aeqd.
A better memory allocation system gives about a 13% speed improvement when creating a CTM1 file from OSM data.
Some parallellization gives a further small speed improvement on multi-core computers; e.g., 3% on four physical cores.