This release was made on 5th July 2022 and is based on mainline revision 10787.

The previous release, 7.8, was made on 28th March 2022 and was based on mainline revision 10409.

This is a major release which introduces many source code incompatibilities. They fall into two categories: renaming of public identifiers, and the introduction of simpler and consistent feature types for map objects. The aim is to make CartoType applications easier to write, read and debug.

The previous release will continue to be supported until 31st July 2024 and will receive bug fixes but no new features.

Renaming

Classes, functions and other identifiers have been systematically renamed, with the aim of improving consistency and removing outdated and unnecessary conventions.

Renaming in the C++ API

The general principle for the C++ API is to use Pascal case (the first letter of each compound word in an identifier is capitalised).

For reasons of supporting .NET APIs, the main namespace is now named CartoTypeCore. However, the name CartoType is defined as an alias if the header cartotype.h is used. Therefore user applications can continue to use the CartoType namespace qualifier.

Classes no longer have C (class) and T (type) prefixes. The M (mixin or interface) prefix, as in MString, has been retained. In most cases the removal of the prefix is quite simple, but in a very few cases such as TContour and CContour, which have become ContourView and Contour, and TBitmap and CBitmap, which have become BitmapView and Bitmap, other changes were necessary to avoid ambiguity.

Public data members no longer have the i (instance) prefix. For example, the Point class has data members X and Y. The former TPoint class had data members iX and iY.

The Rect and RectFP classes now have Min and Max data members, not TopLeft and BottomRight.

The Get prefix has been removed where possible: that is, from functions which return a single value that is implied by their names.

The K prefix has been retained for public numeric constants.

Renaming in the .NET API

The general principle for the .NET API is to use Pascal case.

Public data members now use Pascal case instead of the former convention of prefixing with m_. Where possible, these public data members have become properties. For example, the public data member RouteProfile.m_vehicle_type has become the property RouteProfile.VehicleType.

As with the C++ API the Get prefix has been removed where possible. For example, the function Geometry.GetCoordType has become the property Geometry.CoordType.

The K prefix has been retained for public numeric constants.

Renaming in the Android API

The general principle for the Android API is to use Pascal case for classes, and camel case (the first letter is lower case and other words in a compound identifier are capitalised) for public methods and public data members.

The i prefix has been removed from public data members. For example, LocationMatchParam.iLocationAccuracyInMeters has become locationAccuracyInMeters.

The get prefix has been removed where possible. For example, Framework.getLastMapHandle has become Framework.lastMapHandle.

Renaming in the iOS API

The general principle for the iOS API is to use Pascal case for classes, prefixed by CartoType to avoid ambiguity, and camel case (the first letter is lower case and other words in a compound identifier are capitalised) for public methods and public data members.

This has resulted in relatively little renaming. One example is the change of the CartoTypeRect public data members from x_min, y_min, x_max, and y_max to minX, minY, maxX and MaxY.

The get prefix has been removed where possible, and in many cases getters and setters have been replaced by properties.For example, the methods CartoTypeFramework.setNightModeColor and CartoTypeFramework.getNightModeColor have been replaced by the property CartoTypeFramework.nightModeColor.

The FeatureInfo class: consistent map object properties

The former integer attribute of a map object has been replaced by a FeatureInfo object. There is no size or efficiency overhead because FeatureInfo wraps a 32-bit integer.

Formerly the meaning of a map object's integer attribute was determined by convention, and without knowing those conventions it was impossible to discover the road type (e.g., Primary Road) or non-road feature type (e.g., Fuel Station) of a map object, or the access restrictions, level, one-way status, etc., of an object.

A FeatureInfo object has as one of its attributes a FeatureType. The FeatureType enumerated class combines the former TRoadType, OsmAttrib, and TPointOfInterestType types (to use the C++ names).

The main effect on the CartoType API of the FeatureInfo class is that a FeatureInfo object now needs to be supplied where formerly an integer attribute value was used, as in the functions to insert map objects.

The feature info for a route object contains:

• discriminator: ordinary route, bridge or tunnel
• a level in the range -8...+7
• a feature type in the range 0...31; these are the route types, which also act as indexes into speed and bonus arrays in route profiles
• flags for one-way, drive-on-left, roundabout and toll road
• speed limit in kph
• gradient code (only avalable in internal route calculation layers)
• access flags (wrong-way, pedestrian, cycle, motor, emergency, other)

The feature info for a non-route object contains:

• discriminator: always 0
• a level in the range -8...+7
• a feature type in the range 32...32767
• a sub-type in the range 0...2047; sub-types are used to distinguish island sizes, settlement ranks, etc.

Simpler style sheets

CartoType 8.0 can read older style sheets correctly, with some very minor exceptions, but some attributes and other usages in style sheets have been simplified or abolished.

• The roadflags attribute, used in the <CartoTypeStyleSheet> and <layer> elements, is no longer needed.
• OsmType and RoadType in expressions have been replaced by @feature_type.
• Type in expressions has been replaced by @sub_type, and it is no longer necessary to use a mask: for example, exp='(Type bitand #FFFF)=4' becomes exp='@sub_type=4'.
• Attributes of a map object can be tested consistently in style sheet expressions using the variables @ or @type (map object type), @layer, @id, @feature_type, @feature_type_name, @sub_type, @level, @bridge, @tunnel, @one_way, @one_way_forward, @one_way_backward, @drive_on_left, @drive_on_right, @roundabout, @toll, @gradient, @private, @pedestrian_access, @cycle_access, @motor_vehicle_access, @other_access, and @wrong_way.

A new CTM1 format: CTM1 8.0

In the new CTM1 format, 8.0, FeatureInfo values are used consistently where either TRoadType, OsmType or KArc... values were used. The new version of makemap always creates CTM1 8.0 files. If you need to create CTM1 files in older versions (4.2 to 7.1) you can use the older version of makemap, now renamed makemap7.

Versions of CartoType before 8.0 cannot read CTM1 8.0 files.

CartoType 8.0 can read all CTM1 file formats from 4.2 to 8.0 inclusive.

New import rules

Many of the import rule commands have changed to support the new feature info system.

• set_osm_type and set_road_type have been merged into set_feature_type; for example, <set_osm_type name='bou'/> becomes <set_feature_type name='bou'/>, and <set_road_type name='Motorway'/> becomes <set_feature_type name='motorway'/>.
• set_road has been replaced by specific attribute setters such as set_cycle_access, set_pedestrian_access, etc.; set_feature_info_raw_value is available where low-level access is needed.
• set_int_low has become set_sub_type.

The new version of makemap cannot read old-style import rule files (.makemap files) correctly. If you need to create CTM1 files using old-style .makemap files you can use the older version of makemap, now renamed makemap7.