Introduction to MapTextLabeller

As of FME 2024.0, the MapTextLabeller plugin will no longer be available from Safe Software. Contact Maptext directly for ongoing support and updates. For more information see MapTextLabeller Plugin Deprecation

Introduction

The MapTextLabeller is an extra-cost plug-in for automated high-quality cartographic labelling. The underlying technology is developed by MapText, Inc. MapText had already developed plug-ins for GIS and CAD products such as ArcGIS, Geomedia, and Intergraph, and now intelligent map labelling is available to FME users. Placing labels can be a very tricky task, especially when we deal with complicated maps with many layers and overlapping features of different geometry types, sizes, and orientations. The MapTextLabeller takes into consideration all these factors using user-defined styles and rules. It resolves conflicts and produces aesthetically pleasing output. Combined with the power of FME, the MapTextLabeller can create thousands of labels within minutes. Below, we show a few examples of how MapTextLabeller works, and how labels can be placed with more intelligence and speed than ever using FME.

GUI Overview

Styling and Rules

Once the "Configure" button is pressed, FME passes the relay to MapText. The FME help system contains detailed documentation about the MapText Label Manager; here we only give a quick overview of the Label Manager GUI.

All the layers previously set in the transformer are shown in the Label Manager dialog:


One of the first steps we have to take in the Label Manager is to select a correct "Feat(ure) Type" - it can be either a point, a line, an area, or a general 'obstacle', which won't be labelled but will be considered when MapText tries to place labels.



Once the "Feat Type" is selected, it cannot be changed. If the wrong type was chosen, we will have to re-create the entry.

The second step we should take before defining placement rules is styling (the "Style..." button), which opens the following dialog:



Here we specify an attribute or an expression for labelling, the font name and style, font size, and color. If we multiply the font size by the value used in the "Ground Units per Font Point" parameter, we will get the size of the label in ground units.

In the image above, we use font size 9, which, multiplied by 5 as set in the MapTextLabeller main dialog (the image even higher above), makes the label height equal to 45 ground units (meters in this case).

The next step is setting up rules (the "Rule..." button). MapText offers a rich set of rules that allow fine-tuned label placement. Below, you can see the different "Rule Properties" dialogs:

• For points

• For lines

• For areas

After the rules are set, we can check the boxes in the "Label" column. The transformer is now ready for labelling. Each layer can get a unique set of rules, or a rule can be shared between several layers.

Examples

Now let's go through several examples, try some of the MapTextLabeller capabilities, and see how FME can make the labelling process even more powerful. Most examples use data downloaded from the Open Data website provided by the City of Vancouver (http://vancouver.ca/your-government/open-data-catalogue.aspx).

Simple Labelling

The first example takes a Shapefile containing the areas representing Vancouver neighborhoods, and places labels with 25 ground units per font point, using Times New Roman font, size 10 (that makes 250 meter high characters):



The MapTextLabeller creates only 16 labels for 23 neighborhoods.

Note that MapTextLabeller reports how successful the labelling process was by logging the following message:
MapTextLabeller(LabelEZFactory):
**************************************
* Input: Neighborhoods
* Feature Count: 24
* Number of Label Requests: 24
* Number of Placed Labels: 16
* Success rate (%): 66.6667
**************************************
The Strathcona neighborhood is an aggregate feature consisting of two pieces. It requested two labels, and this is why we see "Feature Count" and "Number of Label Requests" equal to 24 instead of 23.

Now we change a single rule in the "Rule Properties" dialog, which allows placing labels on two or more lines:



The MapTextLabeller will create 23 labels for all areas (Strathcona was labelled with a single label):



Download Vancouver Neighborhoods Example.

The Power of FME

Now let's see how FME can help with some situations that cannot be handled directly in the MapTextLabeller. This time we will try labelling the countries of the world.

Amalgamation

If we send an aggregate feature, for example, an archipelago such as the Philippines, to the MapTextLabeller, the transformer will deaggregate it first and label all parts that satisfy transformer settings. In many cases, this cannot be called a desirable result. With the Amalgamator transformer, FME can combine such archipelagos into single features, which will be labelled much better:

With No Amalgamation


With Amalgamation

Character manipulations

With FME, we can pre-calculate how long a label can be and add spaces between characters for better visibility (check the SpaceAdder custom transformer in the world labelling example):

No Spaces Added


Spaces Added:


Similarly, FME can be used for inserting multiple line breaks between words (not included in this example):


Many more manipulations are possible by enriching features with their metric and non-metric properties and changing text strings accordingly.

Second Round of Labeling

The MapTextLabeller does not guarantee that all incoming features will be labelled - it might be simply impossible with some styling/rule settings:
MapTextLabeller(LabelEZFactory):
**************************************
* Input: AVERAGE_COUNTRIES
* Feature Count: 89
* Number of Label Requests: 89
* Number of Placed Labels: 65
* Success rate (%): 73.0337
**************************************

With FME, we can easily find features that weren't labelled and try to run the labelling process again - this time with different settings or with a different attribute. For example, if country names do not fit into some small countries, we can find them using the FeatureMerger transformer (joining countries and the labels and taking the output from the INCOMPLETE port), then we can number them using the Counter transformer and use the attribute with unique numbers for the second round of labelling.

To avoid collisions between the existing labels and the labels being created with the second MapTextLabeller, we should replace the former with bounding boxes and send these bounding boxes into the transformer as obstacles:

MapTextStyler

Now let's have a look at the following example. We have a Rapid Transit dataset consisting of three layers: Skytrain lines, Skytrain stations, and the Vancouver boundary. Stations are point features, which we replace with circles for better visibility. However, in order to apply point placement rules, we have to send points - not circles - into the MapTextLabeller. As a result, the transformer may create labels that overlap the circles, simply because the MapTextLabeller is not aware of their existence. The MapTextStyler transformer "educates" the MapTextLabeller about the sizes of the features that are passed through it. In the MapTextStyler parameters, we can specify how much space should be left around a point, along a line, or from a polygon boundary, to ensure labels do not touch or overlap other geometries.

Compare these two fragments of the map:

With no MapTextStyler


With MapTextStyle


The example includes two workspaces - one that does not use MapTextStyler, and another that does use it.

FME Generic and Raster

This example makes labels according to FME Data Inspector requirements. The workspace sets up colors, replaces points representing Skytrain stations with circles, and replaces polylines representing Skytrain lines with buffered polygons. It includes a TextStroker transformer, which creates polygons from true type fonts because FME cannot rasterize fonts directly. The workspace also creates an _order attribute, which defines the order that features will be rasterized - that is, which feature will be on top of the others.

Data Inspector:



PNG Image:



Here is an interesting detail - the Data Inspector recognizes the font name assigned by the MapTextStyler. If the Inspector receives a text feature with an _ez_font_name attribute containing a font name, it will display the text with the correct font. There is no other way in FME 2013 to use fonts other than the default one, so this trick can be used for any text visualization. Simply create an _ez_font_name attribute and set its value to a correct font name.
Download Vancouver Street Labelling example for Data Inspector and Rasterization (the template includes the output raster in PNG format).

DWG

DWG as a target format works similarly to FME Generic. AutoCAD displays features in the same order as they were written to the file, so it makes sense to sort features before writing (use an AttributeCreator for each layer with the order number and a Sorter). The DWGStyler transformer is used to set colors and fonts.



Download Vancouver Street Labelling example for Autodesk DWG.

DGN

DGN is probably the trickiest target format of all. MicroStation supports different kinds of fonts; however, with the MapTextLabeller it has to use true type fonts. There is also a difference in font handling in V7 and V8.

MicroStation V7

For MicroStation V7, we have to add true type fonts through a special utility within MicroStation called the Font Installer (Menu->Utilities->Install Fonts...). This utility allows a user to control which fonts will be imported into the font resource file (font.rsc, which can be located, for example, here - C:\Program Files (x86)\Bentley\Workspace\system\symb). Through this utility, we can also control the number that will identify the font for FME. With the AttributeCreator transformer we should create a format attribute igds_font and set the font number for each font name used in the MapTextStyler. For example, if in MicroStation V7 we added "Arial Narrow Bold" and set its number to 251, and in the MapTextLabeller we defined a style using "Arial Narrow Bold", then igds_font should also be set to this number. Note that in V7, the font numbers cannot exceed 255.

The DGNStyler transformer can be used for setting colors. In this case, "Color Index" is a better option than "RGB" as it allows using colors pre-set in a seed file.

MicroStation V8

V8 works with fonts quite differently than V7. V8 uses a seed file to store fonts with their numbers. When we set up a project, we should add fonts that we need to the seed file by placing their samples. This will also create a font number. Arial seems to always get the number 1025, and other fonts receive numbers starting from 1024. Then we can inspect the seed file with the FME Data Inspector to get all the numbers, and use them in the workspace by setting igds_font with an AttributeCreator transformer. Of course, before writing a DGN V8 file, we should not forget to select the seed file containing fonts in the Workbench Navigator.

Again, using a DGNStyler transformer with the "Color Index" option is recommended for choosing colors set within a seed file.



Download Vancouver Street Labelling Example for Bently MicroStation V8 (the template includes the output DGN).

MapInfo

The workspace targeting MapInfo does not require ordering control - this should be done directly in MapInfo by arranging layers in "Layer Control" and saving the result within a MapInfo workspace (*.WOR file).

The MapInfoStyler allows setting colors, symbols, and polygon patterns, so this transformer is actively used in our example.



Download Vancouver Street Labelling example for MapInfo (the template includes the output TAB files and the MapInfo Workspace file VancouverStreets.WOR).

ArcGIS

ArcGIS requires minimal setup in FME. Labels should be output as geodb_annotation geometries. All the styling and layer ordering should be performed within ArcGIS and can be saved as a *.MXD file.



Download Vancouver Street Labelling example for ArcGIS (the template includes the output -ArcGISLabels.gdb and ArcGISVancouverLabels.mxd file).

PDF

Geospatial PDF can be written using ArcGIS as a target format.

In order to correctly write fonts, the PDF writer should know where it should search for them. This is controlled by "TrueType Font Directories" in the PDF writer parameters in the Navigator. Usually, the path points to C:\Windows\Fonts.

We also should expose the pdf_text_font format attribute on the destination feature type, to which we are going to write the labels, and connect it to the _ez_font_name attribute present on the features entering the writer.

The PDFStyler transformer also can be used for coloring, line styles, and fonts.