Offset lines in MapInfo

This graph shows the effect of offset increasing from 1 to 4 pixels. The size of the direction arrows increases with the offset. MI takes into account the complete pattern width (it would be of 9 pixels for the last offset) and adjusts the arrow size to go beyond the pattern in the same proportion as with a single base line.

Impact of line thickness

Another element of pen style is the thickness of the line that can go from de 1 to 7 pixels. There is an interesting interaction between thickness and offset: the actual offset is multiplied by the line thickness. In the graph below, the two colors (here = patterns) are distant of 2 pixels (offset of 2 and 4)

The separation between the lines resulting from non contiguous offsets is maintained whatever be the the line thickness. This separation is useful for maintaining color distinctiveness and enhance readability.

The 1-pixel offset must be avoided if one wants to keep the base line clearly visible. Furthermore, the thickness of the base line should enter into consideration because if it must remain visible, the first offset line, the position of which being independent of the base line thickness, must be sufficiently "off" not to cover it even partially.

Choosing successive offsets leads generally to some blurring of the colors, making difficult the identification of a specific one if the line is not  thick enough. That disadvantage becomes all an asset for building "fading" patterns as we will see below.

All these observations are valid only if the same thickness is used for each offset line. As each line is drawn independently, mixing thicknesses may result in gaps and overall that might destroy the intended effect.

Application to « routes »

This very simple example (a small base network and 2 routes) show what could be obtained and what are some of the problems in such a context.

Two design conditions must me respected: 1 - the routes must be on the proper side of the base line to give an idea of their directions, and 2 - the offset lines must be as close as possible to the base line.

A further technical prerequisite is the network topology: the network must be split at the nodes where routes join and the various segments must be drawn in the appropriate direction.

The problems areas identified by circles are typical of offset line applications.

1 – continuity of routes (center circle)

 

At any junction node, a given route may have to "pass over" another route, which is the case here with the blue route. If the two routes had been switched in the left part, the "pass over" would have been averted, but there will be some displacement in the red line (from a 2 offset to a 1). Minimizing these problems in a real life network may prove to be rather difficult.

 

There is away to deal with that problem by simply hiding it, using symbols over these junctions that will add the idea of transfer between routes.  

 

2 – « internal » corners (left circle)

 

At the nodes where the base line makes an angle < 180 degrees on the side of the offset lines, there are some overlaps; the more closed the angle and important the offset, the more pronounced the overlap.

 

There does not seem to a way to prevent that to happen

Other problems that do not appear on that graph can also be expected had the routes been drawn on the other side. They are visible in the "application to regions" first illustration. there are the possible gaps between route segments if the angle of the overall route is there > 180 degrees on the side of the offset lines (making the imperfections at junction nodes even more complex) and the form of the offset lines at « external » corners (rounding seems imperfect at best)..

Application to regions 

When dealing with regions, we can expect the same problems as those encountered with polylines compounded by the fact that a region is defined essentially by a closed polyline, its border being drawn as such.

The most noticeable problems are the shape of the corners that are "rounded" but in a very approximate way and the situation at the start/end node where the offset line does not close on itself if it is drawn on the outside of the region.. 

Those two problems are exaggerated in this graph (4-pixel offset, 2-pixel line thickness)

Working on a set of regions, the resulting map can give us a new information, such as in the following image.

This map produced with AllClock.mbx (see below "Implementation") show that all the adjacent borders come out as double lines, while the border with outside world are visible as single lines. The "selected" region (a 3- polygon donut-cum-island region) is the proof that its topology has been respected.

The problems noted above are here practically invisible because of the small offset value and the thinness of the line.

Example of under-lining of regions

I explored that avenue when confronted with the following situation: the "state" is formed of "municipalities" that are regrouped into "regions". There is also a set of operational "zones" that does not cover all the state. Initially, region and zone boundaries had to follow municipal boundaries, but it is not the case anymore, due in a large part to the fusion of municipalities or partial annexations and the non readjustment of the other-level boundaries.

The question was how to show clearly the 3 types of borders (municipal, zone, region) in a map of a region.

The solution that is presented here uses offset lines. A region is drawn in blue offset to the outside of the region (see below a discussion on inside/outside and direction of drawing), a zone is in red offset inside the zone, a municipality a thin black base line.

In the first example, there are no "extensions" of the region beyond its limits. The region contains 3 zones; the borders common to 2 zones are seen as triple lines (2 red, one black) except where they do not follow a municipal boundary (slightly above the map center); municipality 29073 is split between zones 202910 and 202915. Parts common to zones and region are also triple lines (blue, black, red).  

In the second example, there are several "extensions" to the region. Municipality 43023 is not included in its entirety, and a very small part only of 42005 is in the region (the small triangle between 43023 and 43020). Zone 102043 overspills to the west adding to the region municipality 42025 that is in part in that zone.

Maps produced that way are richer visually. They can also contribute to the updating of the basic data because situations such those detected in the second example may come from data input error, or may justify the redefinition of some entity borders.

The « direction » of regions

We have seen that the direction of a line is from first to last node, left and right being relative to that direction. With regions, we are more interested in specifying offset as being to the inside or the outside of the region to imagine the effect of using a given offset pattern. To be able to do so, we must know the "direction" of regions.  

A region is defined as been clockwise when the drawing direction of its border is such that the inside of the region is to the right relative to that direction. Thus, with a clockwise region, a line offset to the left will be outside the region, and one to the right in the inside.  

This applies well to one-polygon region but when a region is made of several polygons several of them  overlapping (more or less complex donuts), this definition must be further elaborated. The notion of pile will help us here. 

When several polygons of the same region overlaps, they must must nest into each other (they cannot overlap because that would go against the topology of the region). If they are sorted in order of size, an order can be assigned to each; in this situation, the order is the number of polygons that are containing a given one . The largest polygon is of order 1 (it is contained within itself only)

The rule to follow is that polygons of odd orders must be in the clockwise direction while the even order polygons must be counter-clockwise. 

The reason comes from the fact that MI uses only one line style for all the polygons of a region. If we choose a line offset to the left, the line will be drawn to the outside; that is correct for the order-1 polygon, but for the order-2, the outside of the polygon is really inside the region (it represents the hole of the donut). The direction of the border line must thus be reversed to get the offset line to display outside the region.

Fading patterns

Using a set of lines with increasingly larger offsets and fading colors allows the creation of potentially useful fading patterns as in this example.

I prepared this image in a layout window because the order with which the lines are displayed is crucial to get the desired effect (this control on single objects in not possible within the same layer). This most simple experience yielded some concrete information:

- the offset should be to the inside (a line offset to the right)

- the faintest color should be drawn first (at the bottom of the pile)

- the order of the objects must be strictly enforced.

In this example with neat equal size corners, none of the problems identified above can be found, the hiding of the single line overlaps are well hidden behind successive decreasing offset lines. But this is a rather unrealistic situation as the more complex example will show.   

Example of fading patterns

Let us begin by looking at the results of a 4-line 2-width pattern created with Fader (see Implementation support, below).

The base line is not included in that image of the 4 generated layers only. We can identify 3 problem areas:

A - patterns extend beyond the original regions in "pointed" corners

B - patterns do not close on themselves along the internal borders of donut polygons

C - there can be some overlapping of fading patterns in tight areas

Some of these manifestations can be alleviated in part  at least by two "recipes"

1 - using a cache for the entire country in order to erase the outside blurs.

2 - using the original borders to clean up the gap (normally filled by the borders)

The overall quality has really increased and the patterns look noticeably neater. The only unsolved "original" problem is the gaps in the internal polygon patterns. This could be solved by some additional code that would generate for even-order polygons an extra 3-node polyline defined with the first, second and one-before-last nodes of these polygons. 

.

Implementation support

MapInfoW_OFF9.pen (offered originally by Pierre Blanc with 4 styles) contains now 9 patters (the maximum allowed on the standard MI v6.5 pen file without wiping out existing patterns) and is available here. (download PEN_OFF9.zip)

To make sure that all the regions in a map are clockwise in the way defined above, AllClockReg.MBX is presently available as a version BETA on this site. It work also on selections.

Fader.MBX used to create the above example is available in its present state as an MLC compatible freeware.