* Cache icon
* Append rather than insert
* Do fewer things on update
* Don't create a fill unless needed
* Don't apply tag and member classes (never used)
* Drop down to raw setAttribute (d3 is slow :trollface:)
At z16 and below, tagged points are rendered with a small
dot in the center. At z17 and above, they are rendered with
a maki icon.
See the test rendering page for examples.
Fixes#381.
From the wiki:
> If you have one closed way making up the outer ring and it does not
> describe something in its own right, you may also put these tags on
> the outer ring and leave the relation untagged.
During line and area rendering, fix up such ways so that they are
rendered as if the tags were on the relation instead.
Fixes#613.
Multipolygon relations report their geometry as 'area' and are rendered
as such. However, they do not render a stroke. The stroke rendering
will come from the individual lines, which are given the tag
classes of their parent relations, allowing them to have a stroke
style matching the style of simple areas with the same tags.
Untagged circular ways are no longer considered areas. This prevents
an untagged inner way of a multipolygon from rendering as an area and
is consistent with how P2 and JOSM treat them.
In the CSS, it's no longer necessary to deal with multipolygons
explicitly in selectors. But keep in mind that area boundaries can
now be rendered either as lines or as area strokes. In most cases
the selector should be `path.stroke.tag-_____`, i.e. an explicit
`.area` or `.line` classes should not be included.
Finally, the parent ways of selected multipolygons are given the 'selected'
class.
This doesn't address stacking multipolygons, or interleaving
areas and multipolygons. More and more, I'm thinking we should
just merge the two into a unified "area" geometry.
An entity that is a member of a relation will have the classes
`member`, `member-role-<member role>`, and `member-type-<relation type>`.
The first use of these classes is to avoid filling multipolygon
member areas.
John Firebaugh