Render line for hedges without area=yes and only show fill with explicit area=yes

[jeisenbe]

Fixes #971
Also related to #3453

Changes proposed in this pull request:

1. Stop rendering the green fill for hedges on polygons unless they are also tagged with area=yes
2. Render standard green line for hedges on polygons when they are not tagged with area=yes
3. Adjust line width based on zoom level for hedges on polygons with area=yes

Explanation:

Currently all closed ways tagged barrier=hedge will render with the dark green hedge fill color when they are imported as a polygon feature. This happens for closed ways tagged area=yes, relations with type=multipolygon or type=boundary, and for closed ways that are tagged with another polygon key like landuse=* or amenity=*. Unfortunately, many mappers add barrier=yes to other features like landuse=meadow to describe that there is a hedge around most of the meadow. In this case the meadow will often render like a solid hedge area, which is incorrect.

Also, hedges mapped correctly as areas currently have a wide green outline, just like those mapped as linear ways. This means that the hedge appears significantly wider than in reality, even at high zoom levels where we could show the exact width (and this is the main reason to map hedges as areas).

This PR will only render the area fill for hedge features imported as polygons which also have area=yes. The wiki documentation and editors like iD recommend adding area=yes to hedge areas, since otherwise the tagging is ambiguous for this feature, like any other feature where a closed way can be either a linear feature or area.

There may be a few properly mapped hedge multipolygons that may no longer be rendered after this change, but such tagging is uncommon. Currently 322 relations are tagged with barrier=hedge and area=yes, compared to 257 relations without area=yes, and

There are currently # ways with barrier=hedge, and of these 30,177 have area=yes
Some also have another key such as "landuse", "amenity" etc which we import as polygons: there are 11,677 of these features, which are often currently being rendered incorrectly as hedge areas, since hedge areas are rendered above other landcover fill colors.

106 features have "area=yes" and another polygon tag like "landuse", so these will still render as a hedge fill color, but this tagging should be discouraged.

So to summarize, as a result of this change:
Over 11,000 features currently incorrectly rendered as hedge fill because of another polygon key on the same way will now be correctly rendered
30,000 ways with area=yes will continue to render as now, but with an improved outline color and width in addition to the current fill color.
250 multipolgyons lacking area=yes will be dropped from rendering
100 features with area=yes and another polygon key will continue to render with the fill.

The width of the polygon outline is also adjusted to be green like the fill and the width will now varry with different zoom levels, as I will show below.

Test rendering with links to the example places:

https://www.openstreetmap.org/way/225683577/#map=17/51.1651/-0.04265
way 225683577
barrier=hedge
name=Long Acres Caravan & Camping
tourism=caravan_site

Before:

After checking for "area=yes".

[jeisenbe]

Well, after doing more research about the features currently tagged barrier=hedge and area=yes, I am losing my enthusiasm for rendering them. Many area features like this, which might be better tagged with natural=wood or =scrub for the area:

Wide hedgebank next to a road, with current rendering and rendering after:
https://www.openstreetmap.org/way/379793281#map=17/47.6418/10.1072

z16 before (0.4 pixel black outline)

z16 after (3 pixel wide outline in green) - outline with matches that of current hedges, which I would actually like to adjust to be narrower, e.g. 1.5 pixel width.

z17 before

z17 after (1 pixel wide outline in green)

z18 before

z18 after (0.6 pixel outline, green)

z19 before

z19 after (0.4 pixel outline, green)

[jeisenbe]

This was the sort of feature I was hoping to find: an fairly narrow area with consistent width, mapped between fields. But even here the fill rendering isn't intuitive now or after, and this sort of example is rare. I actually think it's more intuitive when changed to a line rendering without the fill; at least then you know there's a hedge.

https://www.openstreetmap.org/way/417705052#map=18/48.58993/-1.46011 - France

z16 hedge before ecosite France

z16 after

z17 before

z17 after

z18 before

z18 after

[jeisenbe]

There are 7 barrier=hedge with area=yes in Luxembourg. None of them are definitely wrong tagging (unlike many of the other features I found, which were oval blobs or wide rectangles which probably should be natural=scrub), but the current rendering isn't very helpful:

z18 Rue de la gare before - compare linear hedge in parking lot (upper left) to those mapped as areas (lower left

z17 before

z18 wide hedge between field and meadow, current

z19 Rue Foullert current

• not very helpful
  

z19 Rue Pafebruch current

• not helpful; this is a line of bushes / shrubs in front of a building? Not really a barrier.
  

In other places, you're more like to see something like this:
https://www.openstreetmap.org/way/428813153#map=17/-8.15725/-34.94313
Big square tagged as a hedge area - but it looks like there is parking mapped inside, so the area=yes was a mistake.

https://www.openstreetmap.org/way/428111846#map=19/-8.12032/-34.94444

• Round shape tagged with barrier=hedge and area=yes - not sure what is meant by this.

So it looks like even those features tagged with area=yes are not very helpful with the current rendering. Therefore, I'm going to open a different PR which will remove the area fill entirely.

(I'm also going to try narrowing the width of the hedge line at z16 and z17 to make it clearer that this is a type of barrier - no reason to be wider than city walls at these zoom levels. It may also be reasonable to use the scrub color for hedges rather than the current wood/forest color, since these features are usually made of shrubs rather than full-size trees; this would also help increase the contrast with tree rows and make it easer for that rendering to be adjusted)

[Adamant36]

@jeisenbe, you made a good call closing this. Since it doesn't look like it would have worked out well. I like your ideas at the end of the last message for rendering hedge lines though. The current width and color are both things that I've thought could use improving for a while now.