CartoSym 2.0 draft: judgement calls, rendered

Decision matrix#

Proposed resolutions from the PR author, for discussion at the review.

Symbolizer opacity: whole symbol or each part#

With opacity: 0.5, is the symbol made translucent as a whole, or are fill and stroke made translucent separately? Separately, the stroke and fill overlap shows through.

The draft says the opacity applies to the portrayal as a whole, as SVG and CSS group opacity do. Applied to fill and stroke separately, the overlap shows through.

Render it yourself: style.cs.json · Background.geojson · Parcels.geojson · view.json↑ Matrix

Casing beneath or above the stroke#

A road with a 14 px yellow stroke, a red casing extending 4 px on each side at 60 % opacity (so what lies under it shows through) and a thin white centre line. Is the casing drawn beneath the stroke (an outline) or on top of it?

The draft says the casing is drawn beneath the main stroke. libCartoSym models casing and center as StrokeStyling, like the draft.

Render it yourself: style.cs.json · Roads.geojson · view.json↑ Matrix

Casing at crossings#

Two cased roads crossing. Does each road draw its casing together with its own stroke, or are all casings drawn before any stroke, so the crossing merges?

The draft now says that within a visualization pass, the casings of all features with the same zOrder are drawn beneath their main strokes (Jérôme, #147; also the painter's algorithm in clause 7, which loops over casing passes inside each zOrder). A feature with a higher zOrder, such as a bridge, has its casing drawn over the roads below it. Drawing each feature in turn is possible with visualization or feature passes.

Sources: Jérôme, #147: equivalent to drawing all casings first

Render it yourself: style.cs.json · Roads.geojson · view.json↑ Matrix

What casing width means#

The stroke is 12 px wide and casing.width is 3 px. Is 3 px the casing's total width, or how far it extends beyond each side of the stroke?

The draft now says the casing extends its width beyond each side of the main stroke, for a total of stroke width + 2 × casing width (Jérôme, #147). Annex C's road example agrees: its casings of 0.25 to 1 px under strokes of 2.5 to 6 px would be hidden under the total-width reading.

Sources: Jérôme, #147: total width = main width + 2 × casing width

Render it yourself: style.cs.json · Roads.geojson · view.json↑ Matrix

Font outline beneath or above the glyphs#

Text with a 2 px white outline over a dark background. Is the outline drawn beneath the glyphs (a halo) or on top of them?

Outlines beneath the glyphs are the convention: SE draws a Halo on the backgrounds of the glyphs, QGIS a text buffer, MapLibre a text-halo.

Sources: SE 1.1, 11.4.5 Halo: applied to the backgrounds of font glyphs · QGIS label buffer

Render it yourself: style.cs.json · Background.geojson · Places.geojson · view.json↑ Matrix

Which zOrder is drawn on top#

Two overlapping features. Lakes come first in the data but have zOrder: 2; Forest has zOrder: 1. Is the higher zOrder drawn on top?

The draft says portrayals with a higher zOrder are drawn on top. The earlier clause 7 text only said that zOrder modifies the default order, not in which direction.

Render it yourself: style.cs.json · Lakes.geojson · Forest.geojson · view.json↑ Matrix

Hatch angle direction#

A hatch fill with angle: 30. Clockwise or counter-clockwise from horizontal?

The Part 1 Hatch table says "Hatches orientation clockwise degree". libCartoSym still uses the older forward/backward/cross hatch model.

Render it yourself: style.cs.json · Zones.geojson · view.json↑ Matrix

Units of dashPattern#

A 6 px wide line with dashPattern: [4, 2]. Are the values pixels, or multiples of the stroke width?

Jérôme: units are as in Graphical Units of Measure, pixels unless qualified with another unit. The PR now says so for dashPattern, as SE does for stroke-dasharray; MapLibre's line-dasharray is in multiples of the line width.

Sources: SE 1.1, Stroke: stroke-dasharray lengths in the symbolizer's units of measure · GeoServer: stroke-dasharray in pixels · MapLibre line-dasharray: units in line widths

Render it yourself: style.cs.json · Boundaries.geojson · view.json↑ Matrix

Default hot spot of an Image#

A pin icon on a point (black cross = the point's location). Without an explicit hotSpot, which part of the image sits on the point?

Jérôme: the default hot spot is the centre { 0.5, 0.5 }, since centred icons are by far the most common case (after first saying top-left). This is what the draft says and what libCartoSym does (GraphicalElement.ec). Pin-shaped icons need the bottom centre, so styles would set it explicitly.

Render it yourself: style.cs.json · POI.geojson · view.json↑ Matrix

The default marker#

A style that sets only a fill and a stroke, and no marker. Clause 7's defaults say the default Marker is a single default Dot (white, 10 px), and markers are drawn at points, line vertices and polygon centroids. Does every feature get a white dot?

Jérôme: intended, so that every feature type is visible by default, and a single default Symbolizer is intended; a typical base style unsets the marker for lines and polygons, e.g. [dataLayer.featuresGeometryDimensions > 0] { marker: null; }. marker: { elements: [] } is equivalent, while marker: { } still yields the default Dot; the draft renderer does the same, and the PR's NOTE now says so. Open: the JSON schema rejects all three forms, and the Dot defaults (size 10 px, color white) set properties the Dot class does not have: clause 8 and the schema draw a Dot with its stroke's width and color. The other cards leave the default marker off, so they stay readable.

Render it yourself: style.cs.json · Things.geojson · view.json↑ Matrix

What a stipple or dot-pattern dot looks like open in draft#

A stipple fill (ratio: 0.15, left) and a dot pattern (distance: 14 px, right), both with a dark green fill color. Neither the requirements nor the model say how big a dot is or which color it has.