Remove polygon fill rendering for barrier=hedge

[jeisenbe]

Follow-up to closed PR #3834
Fixes #971
Also see discussion in about walls mapped as areas (not rendered) #3453

Changes proposed in this pull request:

1. Stop rendering the green fill for hedges on polygons
2. Render standard green line for hedges on polygons instead

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 imported as areas currently have a narrow black outline, unlike those mapped as linear ways.

This PR will remove the fill color for hedges on areas, and instead render them with the standard green line rendering used for other hedges. This is consistent with how other barrier features are rendered, including walls.

There are currently 30,177 ways with barrier=hedge and area=yes which may currently be rendered with the fill color, which will have the rendering changed by this PR. 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.

As review in #3834 showed, most of the features with area=yes are not clearly hedges, but many appears to be areas of shrubs or garden areas or scrub, etc. The current rendering does not make it clear that these areas are barrier features, rather than just a general "green" area, which may contribute to such mis-tagging.

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 loose the area fill rendering but have a clearer "hedge" barrier style outline.

Test renderings with links to the example places:

1) Long Acres Caravan & Camping

https://www.openstreetmap.org/way/225683577/#map=17/51.1651/-0.04265
way 225683577
barrier=hedge +
tourism=caravan_site

Before:

After:

2) Wide "hedgebank" next to a road (like an area of shrubs used to stabilise the slope?) with current rendering and rendering after:

https://www.openstreetmap.org/way/379793281#map=17/47.6418/10.1072

z16 before

z16 after

z17 before

z17 after (1 pixel wide outline in green)

3) Hedge along orchard border

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 Rue de la gare, Luxembourg - compare linear hedge in parking lot (upper left) to those mapped as areas (lower left)

z18 before

z17 before

z18 after

z17 after

Place de les Martyrs, Luxembourg

• Currently grass area in center is incorrectly rendered as solid hedge.

z18 before

z18 after

[imagico]

Just to make sure i understand this change - you remove the rule specifically for the area-barriers layer completely because you stop filling the areas and the outline is to be drawn according to the class based rules that apply both to the area and the lines layers.

It might be worth considering then combining polygons and lines into a single layer (using a compound UNION ALL query as we do for points and polygons in many cases).

In any case i think the area-barriers and line-barriers queries should follow each other and have the same starting zoom level - otherwise this can easily be confusing.

[jeisenbe]

remove the rule specifically for the area-barriers layer completely because you stop filling the areas and the outline is to be drawn according to the class based rules that apply both to the area and the lines layers.

That's right.

combining polygons and lines into a single layer (using a compound UNION ALL query

Good idea, I had not considered that. I hope this would lead to slightly faster rendering performance, by reducing the number of layers by 1?

[imagico]

The point of having just one layer would be not so much performance but simplifying code since you only need to have the value lists once in an outer query wrapping the two. Best example probably is:

openstreetmap-carto/project.mml

Lines 1539 to 1594 in 5fd5107

	(SELECT
	ST_PointOnSurface(way) AS way,
	name,
	access,
	aeroway,
	amenity,
	barrier,
	boundary,
	building,
	highway,
	historic,
	landuse,
	leisure,
	man_made,
	military,
	"natural",
	place,
	power,
	ref,
	religion,
	shop,
	tourism,
	waterway,
	tags,
	way_area
	FROM planet_osm_polygon
	WHERE way && !bbox!
	UNION ALL
	SELECT
	way,
	name,
	access,
	aeroway,
	amenity,
	barrier,
	boundary,
	building,
	highway,
	historic,
	landuse,
	leisure,
	man_made,
	military,
	"natural",
	place,
	power,
	ref,
	religion,
	shop,
	tourism,
	waterway,
	tags,
	NULL AS way_area
	FROM planet_osm_point
	WHERE way && !bbox!
	) _

The main question would be if there would be any issues with the query returning mixed POLYGON and LINESTRING feature types (in which case you would need to do do an ST_Boundary(way) AS way on the polygons). In my experience Mapnik has no issues with that but i can't say for sure. Maybe @pnorman has more info.

[jeisenbe]

I've added new commits which combine the two layers, line-barriers and area-barries, into one, and removes the class: barriers. I could also try to change the indenting, but I wanted to minimize the number of changed lines if possible, and I'm still unclear on the proper indenting style for the SQL queries. (Honestly I was surprised that my first attempt worked properly and rendered without errors)

[jeisenbe]

I didn't use WHERE way && !bbox! since that wasn't in either of the current layers, line-barrier or area-barrier - should this be added for better performance?

[imagico]

You need the way && !bbox! in cases where Mapnik is not able to do this itself - which tends to be the case when you have a UNION ALL in a subquery involving several different tables.

Would look like (untested code):

        (SELECT
            way, COALESCE(historic, barrier) AS feature
          FROM (SELECT way,
            ('barrier_' || (CASE WHEN barrier IN ('chain', 'city_wall', 'embankment', 'ditch', 'fence', 'guard_rail',
                  'handrail', 'hedge', 'kerb', 'retaining_wall', 'wall') THEN barrier ELSE NULL END)) AS barrier,
            ('historic_' || (CASE WHEN historic = 'citywalls' THEN historic ELSE NULL END)) AS historic
            FROM 
              (SELECT
                  way,
                  historic,
                  barrier,
                  waterway
                FROM planet_osm_polygon
                WHERE way && !bbox!
              UNION ALL
              SELECT
                  way,
                  historic,
                  barrier,
                  waterway
                FROM planet_osm_line
                WHERE way && !bbox!
              ) _
            WHERE barrier IN ('chain', 'city_wall', 'embankment', 'ditch', 'fence', 'guard_rail',
                  'handrail', 'hedge', 'kerb', 'retaining_wall', 'wall')
              OR historic = 'citywalls'
              AND (waterway IS NULL OR waterway NOT IN ('river', 'canal', 'stream', 'drain', 'ditch', 'wadi'))
          ) AS features
        ) AS line_barriers

[jeisenbe]

Thank you, that code works. Hedges and city walls still render fine on linestrings and polygons. I've tested the changes and pushed a new commit.

[pnorman]

2. Render standard green line for hedges on polygons instead

I'd rather not render them at all. To do this implies that an object can be both an area and not an area at the same time.

[jeisenbe]

There used to be a tag “fenced=yes” which could be added as a property of another feature, but now the wiki page says this has been discouraged for many years and barrier=fence should be used instead. Similarly, there isn’t any documented tag like hedge=yes for adding to other features; I believe many mappers think that barrier=fence and barrier=hedge etc can be added to an area feature as a property, “this area is surrounded by a hedge / fence”. So we would need a proposal for new tags for the property, to help clarify the situation. I wouldn’t mind doing a proposal for hedge=yes, wall=yes, fence=yes - because I agree that one database element should only represent one Maine feature. But under the current documentation it appears that barrier=hedge can also be a property, not only a feature. Also, it’s clear that area=yes can be used with barrier=hedge mapped as a polygon, according to documentation and current usage. So for now I would continuing rendering hedges on objects which become polygons, until the tagging changes.

[imagico]

I'd rather not render them at all. To do this implies that an object can be both an area and not an area at the same time.

That's a good point - however this would be a high impact change and i am not sure if it is sufficiently broadly accepted among mappers that this is wrong.

At least in one case this is quite universally accepted mapping - with natural=coastline + place=island/islet (150k combinations). For barrier=fence there are nearly 300k combinations with landuse/leisure/amenity - which is not exactly rare either. I don't think either of these is indicated by editor validation rules as wrong.

[matkoniecz]

I don't think either of these is indicated by editor validation rules as wrong.

I opened https://josm.openstreetmap.de/ticket/10551 long time ago and it remains open, but response was at best mixed

[imagico]

Note the core of the problem is the ambiguity when one OSM feature is used to represent several different real world concepts at the same time. This can be cases where one of them is linear and one is polygon-like. But it does not have to be. Example: Something tagged building=yes, shop=bakery, name=foo. It is not clear if the name is the name of the building or the name of the bakery. In cases like this we simply assume the name applies to both the shop and the building (and render them with whatever priority they have for us). The analog interpretation for the linear vs. polygon-like case would be to interpret it as both polygon and linestring.

[HolgerJeromin]

I could also try to change the indenting, but I wanted to minimize the number of changed lines if possible

You could change the sql, make a commit, adjust indenting, make another commit. So the code would be clean, but both diffs would be readable.

[jeisenbe]

Good idea. I've pushed a new commit with the indenting changes.

[jeisenbe]

@imagico has approved this PR. Are there other comments or reviews? I'll wait a few more days.

[pnorman]

I'm still 👎 on the idea of rendering a polygon in a way that makes it look like it's a linear feature.

[imagico]

Have you considered the arguments above - that barrier tags in combination with landuse/leisure/amenity are very common and that we render multiple uses of the same geometry for different things already in other cases (like building + shop)?

Note right now we already interpret barrier tags on polygons as line tags and render them with a line for all barriers:

openstreetmap-carto/landcover.mss

Lines 849 to 850 in eae0909

	line-color: #444;
	line-width: 0.4;

The only change this PR makes is making this consistent also for barrier=hedge which has so far been rendered with a fill color.

[jeisenbe]

@pnorman - hedges which are tagged on polygons are currently rendered both with a green fill and a dark gray 0.4 pixel width line. The line rendering is identical to that for barrier-wall tagged on a polygon feature, but barrier=wall has no color fill rendering.

The wiki page Tag:barrier=hedge says "For a thick hedge draw a closed way around the perimeter of the hedge and tag it with area=yes." and "onArea" is also set to "yes" in the valueDescription box, and mapping as an area has been mentioned since the page was first created in November 2008.

However, Tag:barrier=hedge also mentions mapping as areas (with area=yes), and Key:barrier also shows both can be mapped as areas. Similarly, barrier=city_wall has "area" as a possible mapping method.

Area rendering of barrier=wall has been requested in #3453 and I tried rendering wall polygons with a gray fill in #3453 (comment) and #3453 (comment) - where I discovered that the majority of features tagged with barrier=wall + area=yes are questionable, because area=yes has been used even though there is another polygon key.

See the similar discussion about hedges imported as areas in #971 especially #971 (comment) and below.

I tried rendering just barrier=hedge with area=yes with the polygon fill in PR #3834 but closed it due to the bad results.

So there are 4 options now:

0. No change: hedges continue to render as a green polygon fill and black outline when imported as a polygon (often due to the presence of another key like leisure=, but also if tagged appropriately with area=yes), but as a thick green line otherwise. However, barrier=wall and city_wall do not have the fill rendering, so this is inconsistent and confusing to mappers.

• This means that mappers must be expected not to add area feature tags like leisure or tourism to the same closed way as a hedge. However, this does not appear to be clearly stated anywhere in the documentation about barriers. I've tried adding something general to [One Feature, One OSM Element] but this has met resistance.

1. Walls same as hedges - same as current for hedges, but also render a fill for all barrier=wall and barrier=city_wall features when they are imported as polygons. As shown in area of barrier=wall not filled #3453 (comment) this will mainly render mistaken with barrier=wall/city_wall. Again, this assumes that mappers should not add barrier tags to objects that are also tagged with a polygon feature like amenity, landuse.

2. Render walls and hedges with area=yes, like Render line for hedges without area=yes and only show fill with explicit area=yes #3834 and area of barrier=wall not filled #3453 (comment) - render polygon fill for hedge, wall (and city_wall) when area=yes only. This reminds mappers that area=yes must be used for feature that can be either a line or area when they are mapped on a closed way. Unfortunately this still mainly renders mistakes, as shown in area of barrier=wall not filled #3453 (comment)

3. Remove the fill for hedges: this PR All barriers, including hedge, wall, and city_wall, would only render as a linear feature, whether imported as polygons or linestrings. This makes it clear that barrier=* is mainly a linear key. Mappers may consider adding an area key like natural=scrub, natural=wood or similar when there is a wide hedge-like area which needs to be rendered

What are your thoughts on the way forward?

[jeisenbe]

Oh, I forgot another option (probably not a good one):

4. Do not render anything for barrier=hedge or barrier=wall on polygons.

• This would imply that mapping a barrier=hedge or barrier=wall on a closed way with another feature tag or area=yes, or as a multipolygon, is a mistake in mapping which should not be rendered. I don't believe this would be consistent with the current documentation and usage of these tags.

[jeisenbe]

@pnorman - have you had a chance to think about this issue again, and the 4 possible solutions above?

[pnorman]

1. Do not render anything for barrier=hedge or barrier=wall on polygons.

• This would imply that mapping a barrier=hedge or barrier=wall on a closed way with another feature tag or area=yes, or as a multipolygon, is a mistake in mapping which should not be rendered. I don't believe this would be consistent with the current documentation and usage of these tags.

I'd be okay with this.

[jeisenbe]

OK, you would prefer that we not render anything for polygons tagged as barrier=hedge. This means that an area of landuse=meadow + barrier=hedge would not have the linear barrier rendering, so mappers would need to use a separate geometry to map the hedge.

Would this need to be discussed on the mailing lists first? Perhaps there should be a tag like hedge=yes or hedged=yes that can be added to other features?

[jeisenbe]

Re: "broke the rendering" - this is not exactly true. This PR renders all lines and areas with the barrier=hedge tag in the same way: they all have the same green line now.

Previously, barrier=hedge on a line was represented by this line, but when barrier=hedge was used on an area feature the was changed to a black thin outline (same as a wall or fence) with dark green fill.

This style is now interpreting barrier=hedge and barrier=wall in the same way: both are sometimes mapped as closed ways (or multipolygons) which could be interpreted as areas, but now both are shown as a line. Prior to this PR, only barrier=hedge had a fill color, while barrier=wall areas only had the line, which was inconsistent.

I previously considered rendering barrier=wall features with the fill color to solve the inconsistency in the other direction, but this did not work: see discussion and test renderings in #3453 which showed that most features which would be rendered are mistakes, due to use of barrier=wall along with another tag which represents an area feature (#3453 (comment) and earlier #3453 (comment)).

Another option was to only render barrier=hedge features with area=yes to solve #971 (previously all features like landuse=meadow + barrier=hedge looked like huge hedge areas), which I tried in PR #3834 but this does not work, as shown in that PR. It's also a problem that area=yes is not always used consistently in this case (it is added by iD but not all mappers realize that this is recommended, since it is not needed for other vegetated areas)

Thus, this PR is the best option. An alternative supported above by @pnorman was to not render anything for barrier=hedge tags on areas (#3844 (comment)) - this reallly would have removed the rendering for these features.

As noted above, the fill color will be rendered if there is also appropriate tag to describe the vegetation such as natural=scrub for areas covered by bushes and shrubs, natural=wood for areas covered by trees. While hedges are often made of shrubs or bushes, this tag is often used on areas of full-grown trees (See for example https://www.openstreetmap.org/edit?way=454450673#map=20/47.08463/-1.36882), and sometimes on areas of mixed greenery which might merit a different tag (leisure=garden? something new?)

[AllroadsNL]

For me area=yes on a polygon means, the whole plane need a render color, not only the outline.
I tagged hedges all the time this way if I did not want to use the line structure.
The wiki says, so it is kind of common thing to do.

For a thick hedge draw a closed way around the perimeter of the hedge and tag it with area=yes.

A hedge should be decribed as a hedge, and not as something like natural=scrub.
The qualitiy of tagging.

The above example:

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

There where the highway enters the caravan_site on the highway, there is not a hedge, so the site does not have a hedge on that part and can not be mapped entire circumference.
This is mapped wrong. This is wrong mapping. And wrong visualisation, do not visualise, when it is not there.

The area:* methodology.
Never used: I could consider using it for area:barrier, not only hedge but also, width, lowered kerb.
As it is used with area:highway.
The area:* method, has the advantage that in 1 key, the key barrier=* and area=yes are connected to each other.
When multiple keys used , there is less conflicts when area=yes is used (to whom belongs this tag), it gives more options to use the "ways".
But this is the future!
Be prepared.

area=yes and area:* are always next to each other and should be render the same.

[jdhoek]

@jeisenbe The problem lies not in rendering normal closed ways (i.e., tagged without area=yes) the same as as an open way, that is fine and desrable. However, hedges tagged with area=yes explicitly declare that they are mapped as areas. This PR treats them as linear features, despite widespread use in areas where accurate mapping sources are available.

The reason hedges use area=yes and scrub etc. don't, is because hedges can be mapped both as linear features and areas, whereas scrub/grass/forest are areas by definition.

[jdhoek]

Prior to this PR, only barrier=hedge had a fill color, while barrier=wall areas only had the line, which was inconsistent.

I completely agree that this is inconsistent, but given that there is a valid use case for walls mapped as areas too, I would opt for adding rendering to barrier=wall plus area=yes instead.

Barriers can be mapped as areas if sufficient detail can be surmised, and in case of massive, thick walls or huge blocks acting as barriers this certainly makes sense.

[jdhoek]

Never used: I could consider using it for area:barrier, not only hedge but also, width, lowered kerb.
As it is used with area:highway.

[…] you need to invent a new tag.

An alternative is fine too of course, but please add that to this PR instead of first removing the existing documented and accepted solution. I could live with area:barrier=yes, but if I change hedges to that now it will be treated as a completely new key that won't be rendered until it has tens of thousands of uses.

Please provide a migration path (with rendering) and time to re-tag.

[imagico]

For me area=yes on a polygon means, the whole plane need a render color, not only the outline.

No, area=yes has one and exactly one meaning: It indicates that a closed way is a polygon. And as @jeisenbe has explained it is common practice right now that barrier tags are applied to polygons in a way indicating this polygon is enclosed by a barrier of this type. There are >350k combinations of a barrier and a landuse/leisure tag the vast majority of which represent exactly that use case. If you want to change/overload the meaning of the area=yes you need to discuss this with the mapper community.

As @jeisenbe also explained there are only two possible approaches that are in line with the goals of this style and that could achieve consensus here:

• the current rendering you are complaining about
• removing any rendering of barrier tags on polygon features.

[Recoil016]

area=yes has one and exactly one meaning: It indicates that a closed way is a polygon

EXACTLY. So why is barrier=hedge + area=yes not rendered as one? That is the point.
When you have a barrier=fence and a landuse=meadow you don't need an area=yes tag. It is clear that the fence is the outline and the meadow is a polygon. Putting an area=yes tag on a landuse=meadow would be malpractice.

[imagico]

For better understanding of how OSM data interpretation works: Every feature is imported into the rendering database either as a point, a linestring or a polygon. Features imported as a polygon with a barrier tag could either be rendered with an outline or with a fill. If you render them with a fill (like it has been done so far inconsistently for barrier=hedge but not for other barriers like barrier=fence/wall/etc.) that means misinterpreting >350k features were the barrier tag is used as a secondary tag characterizing the outline of the polygon. Interpreting the area=yes tag beyond its established meaning regarding the import decision linestring or polygon is not an option. We will not use our influence for pushing for an even more complex rule set for interpreting OSM data beyond the already existing complexity. If you want to lobby the mapper community for such added complexity you are free to do so of course.

[jdhoek]

misinterpreting >350k features were the barrier tag is used as a secondary tag

There are exactly 36665 hedges that carry the area=yes tag. A quick glance at the hedges tagged in Western Europe shows that these are predominantly hedges mapped as areas, not other kinds of polygons with a hedge around it. Usually, the tags are only barrier=hedge and area=yes, sometimes height=* is included. Are there areas where the predominant use of barrier=hedge plus area=yes is in addition to something like landuse=meadow?

Not rendering barrier=hedge without area=yes is a good change, but completely removing rendering for valid hedges mapped as areas does not seem like a positive change.

I'm fine with exploring alternatives for area=yes that can work for any kind of barrier that can be reasonably mapped as an area (walls in particular), but can we keep the filled rendering for (specifically) barrier=hedge plus area=yes until we have a migration path to something to replace it?

[AllroadsNL]

350k combinations of a barrier and a landuse/leisure tag

We are talking about the situations, where there is area=yes added to it.

And how many have also the area=yes tag?
key area in barrier#combinations 68005, minus (this include the barrier=hedge area=yes) Where we talking about.

In Nederland is this 7829. from what with landuse 8 with leisure 0 .

[kennykb]

I've run into several situations (boundary=protected_area is another) where there is a conflict between rendering the border of an area feature as a linestring and rendering the interior as an area - or otherwise considering the boundary and interior as separate topologies.

One workaround that consistently works - and it's hard to imagine future changes breaking it - is to describe the interior as a multipolygon relation, while continuing to describe the boundary as one or more linestrings. Tagging relevant to the boundary can go on the boundary, and cause the linestrings to be imported as linear features. Tagging relevant to the interior goes on the multipolygon relation, and causes the area to be imported as a (multi)polygon feature.

I concede that the approach seems awkward, but in my experience, it is less awkward than mapping the boundary twice - once for treatment as a boundary (or barrier, or whatever) and again for treatment as an area. It's also less error-prone than dual-mapping in that editing the member ways cannot introduce an inconsistency.

[ghost]

In my opinion this change discriminate against those who care about a correct and precise mapping and supports bad tagging.

Please revert it and render all barrier=* + area=yes or barrier=* multipolygons as area. For closed ways tagged with barrier=* and another main element, i suggest to either stop rendering of barrier=* or to completely stop rendering of these closed ways.

[jeisenbe]

For closed ways tagged with barrier=* and another main element, i suggest to either stop rendering of barrier=* or to completely stop rendering of these closed ways.

I agree that this usage is ambiguous. However, that usage is very common, more common than the use of area=yes, and is suggested on Key:fenced:

https://wiki.openstreetmap.org/wiki/Key:fenced - "Whether the outer perimeter of something is fenced."

"This feature has been labeled as deprecated. The recommended replacement is: barrier=fence."

"Once upon a time there were no barrier tags, because nobody had invented them yet. In that time the only way to map a fence in Openstreetmap was with fenced=yes. Almost all fences mapped since the invention of barrier=fence are (re)mapped using that new tag."

Since the original mapping was to add "fenced=yes" to "landuse=meadow" or "leisure=playground", it is still very common to add 'barrier=fence' to one of these features, and by analogy this is also done with walls, hedges and other barriers.

According to http://overpass-turbo.eu/s/Qr1 there are 36k closed ways with barrier=hedge + area=yes without another area feature, but there are 16k uses of barrier=hedge + another tag which describes an area: http://overpass-turbo.eu/s/Qr3

The situation is worse for barrier=wall and barrier=city_walls: there are over 98k ways with barrier=wall and another tag which defines an area (like leisure, landuse, amenity etc: http://overpass-turbo.eu/s/Qr4), compared to under 12k ways with barrier=wall but without one of those other tags.

While the average wall is thinner than the average hedge, the difference is less than an order of magnitude, and there is another feature that is about as wide as a hedge: barrier=city_wall - which is also sometime mapped as a area. But there are only 787 of these ways with area=yes (http://overpass-turbo.eu/s/Qr6) versus 1800 barrier=city_wall ways which are combined with a polygon feature tag like landuse=* (not including historic=citywalls) - http://overpass-turbo.eu/s/Qr8

This means that if mappers want to use barrier=hedge and barrier=wall and barrier=city_wall for both linear features and areas, database users are going to have to look for tags like area=yes and type=multipolygon to try to figure out if it is a linear or area features, and often there will be mistakes.

For this reason, we should not rely on the presence of area=yes (or type=multipolygon) to determine the rendering: this is confusing for mappers and does not fit the common way that these tags are understood.

A real solution to this would require changing common tagging practices, but since overall the tagging of linear barriers on other features is very common (~360k uses, mainly with fence and wall) it would be a huge effort to change the database, and such ideas would need to be discussed elsewhere.

[jeisenbe]

The Netherlands has been claimed as a place where barrier=hedge areas are used properly and are necessary. I have already downloaded one whole provicne, Zeeland, which has quite complete landcover and landuse mapping due to an import.

In Zeeland there are 149 uses of barrier=hedge on a closed way without area=yes or landuse=, natural= or leisure=, and only 12 closed ways with barrier=hedge + area=yes. I checked some of the former and all of the later, and it appears that the local mappers have treated both the same ways:

1. as an alternative to mapping thin hedges as a single line
2. as an alternative to mapping tree rows as a natural=wood or landuse=forest area
3. to map areas of bushes around farms or residential areas, which are perhaps more of a "shrubbery" than a proper "hedge" - often these are patches of bushes rather than a linear, barrier-like feature

But in most areas, you will find similar features tagged with landuse=forest right next to the barrier=hedge closed ways. The tag natural=scrub for areas of bushes seems less common in the Netherlands than in some other countries, so perhaps the barrier=hedge areas are being used as an alternative.

There are only 3 places in Zeeland where barrier=hedge + area=yes has been used. This farm has 5 of them:

but https://www.openstreetmap.org/way/733907216 is tagged natural=wood + barrier=hedge + area=yes - it is not clear to me why this combination is used here, but not on the landuse=forest located 10m to the west, or the barrier=hedge + area=yes features to the north and east. Also see https://www.openstreetmap.org/way/733907213 - a round patch of bushes.

https://www.openstreetmap.org/way/624268968 - this is also barrier=hedge + area=yes
This was the 2nd example I found, and here it is not at all clear why barrier=hedge was used on the west side and landuse=forest on the east: perhaps the vegetation is shorter on the west, yet the mapper did not want to use natural=scrub? I cannot see how this sort of feature can be considered a "hedge" in the English sense of the term, rather it is an area of bushes or small trees:

Afterward, I randomly looked for barrier=hedge closed ways which lacked area=yes (recall there are 151 of these, compared to only 12 with area=yes, in Zeeland)
https://www.openstreetmap.org/way/628a1748
The first I found was a parking lot with a number of areas of bushes, mapped as barrier=hedge. I would not have considered this a hedge in US English: most of these patches are 8m x 2m, or 25m x 5m, and in other parking lots the same areas might have small trees or patches of grass. So here barrier=hedge is being used for what British English might call a "shrubbery", and what we call "landscaping" in California.

https://www.openstreetmap.org/way/433123082
This tourism=camp_site is surrounded by 10 meter wide buffers of trees or shrubs, but these are mapped as landuse=forest (imported), unlike some of the hedges above. But there is a much narrower feature, hard to see on the aerial imagery, mapped as a hedge area it appears. In this case I don't see much benefit mapping these 1 to 1.5 meter wide hedges as areas instead of lines + width=, nor of rendering them with a fill color.

https://www.openstreetmap.org/way/444439556
Here is another randomly selected barrier=hedge without area=, but clearly intended to map an area of bushes or small trees. This one is at least linear. I would have considered the features around the house to the north-west to be traditional hedges. To the south there is a more widely spaced line of small trees or large shrubs mapped as natural=tree_line, to the northeast there is a slightly wider area of shrubs or trees which is mapped as landuse=forest (imported).

(Note also that JOSM always renders hedges as linear features, no matter whether they are tagged with area=yes or not, so all the screenshots from JOSM show the hedge as a yellow line)

[jeisenbe]

To summarize the previous posts:

• If we only render a color fill for area=yes + barrier=hedge, most of the hedges mapped as closed ways in the Netherlands (and everywhere else) will need to be retagged to add area=yes to get the polygon fill rendering. Since the area=yes tag is not necessary for other types of vegetation area mapping, it is not fair for us to expect mappers to add these tags.

• If we render all barrier=hedge areas, this causes problems in over 10k features where the barrier tags is added to another area feature, and since the prior rendering was a black outline + green fill similar to woodland, it was not very obvious what had gone wrong. Rendering like natural=scrub or natural=wood would still be counter-intuitive, if this tag is not also used on the same feature.

• If we render barrier=hedge areas, this causes confusion when barrier=wall and barrier=city_wall areas do not also render. See area of barrier=wall not filled #3453 for my attempt to render barrier=wall areas and the serious problems that were found.

So our possible solutions are:

1. This PR, which renders all linear barriers in a similar way: as a line whether they are mapped on a linear way feature or an area feature.

• This is the best option based on current mapping practices, though I am aware it is not perfect.

2. Completely remove the rendering of all hedges (and presumably other barriers like fences and walls) when mapped on a polygon.

• This option enforces the "one feature, one element" rule, but it would cause more confusion, since double-tagging an area feature with barrier=fence/wall/hedge is common and documented as an option, and mapping 2 seperate overlapping features is difficult in most editors.

[bdxd111]

So our possible solutions are:

Maybe also consider providing support for an alternative tagging system like the one proposed by jdhoek as a valid solution. I believe this would be better than just the 2 solutions you proposed.

The advantage is that it solves both the issue of ambiguity of barriers on polygons, and still allows the mapper to specify the hedge or other barrier as an area. In the end would keep most mappers happy.

[jeisenbe]

Maybe also consider providing support for an alternative tagging system like the one proposed by jdhoek as a valid solution. I believe this would be better than just the 2 solutions you proposed.

That is an option, if a new method of tagging becomes widely used. Currently natural=scrub and landuse=forest or natural=wood are most widely used for mapping such areas, with some use of leisure=garden and some (mis-)use of village_green. If something like leisure/landuse/natural=shrubbery/greenery or another tag becomes established and common over the next year or two, we could certainly consider rendering it in the future. But our policy is to avoid rendering brand-new tags before they are accepted by mappers, as shown by widespread use.

[imagico]

If anyone wants to develop a followup to this change - i prepared two branches that could be helpful:

https://github.com/imagico/osm-carto-alternative-colors/tree/no-barrier-polygons

This implements the complete removal of rendering barrier=* on polygons - as discussed this would remove support for an in general inherently ambiguous mapping practice - which is however unfortunately widely used. It would provide a clean slate in terms of barrier mapping (leaving only the undisputed and consistently used mapping on linear ways) and would allow mappers to decide on an approach without being influenced in a counterproductive direction by this style. It would however also mean removing the rendering of several hundred thousand features currently rendered.

https://github.com/imagico/osm-carto-alternative-colors/tree/hedge_polygons_as_landcover

This adds barrier=hedge to the landcover layer and does not render it with the other barrier tags as a secondary tag on polygons any more. Functionally this is somewhat similar to a revert of this change - but it would do so cleanly and consistently with the other tags in the landcover layer. Note this means among other things having features with barrier=hedge default to being polygons, that any other landcover tag has precedence over barrier=hedge and that they are rendered within the normal way_area based sorting of the landcover layer.

I will not submit a PR for either of these changes at this time but i don't want to choke a potential consensus in either direction. If anyone wants to prepare and argue for a change based on either of these approaches that would be welcome and i would be willing to listen to their arguments.

What i would as said strongly oppose however is any change that tries to interpret the area=yes tag in any way on the style level beyond the decision of linestring or polygon on the data import level.

[nickvet419]

I also agree that area=yes should indicate a filled area for hedge or wall as the Area tag notes "An area (or filled polygon)" The proper way of adding a hedge as a single line barrier would be to leave off area=yes from the tags. It would be improper to add a scrub tag, which is meant to be for a point, not an area, to the feature for only rendering proposes.

[jaffroy62]

In terms of displayed position accuracy i can not agree with the current rendering.

Assuming that a hedge is accurately mapped according to the wiki with an closed polygon for me as a mapper this polygon should represent the edge of the object.

Actually the current rendering makes such hedges thicker as they really are. Not mentioning the uncolorized center of the hedge.

Here you can see an example of an overlap with benches. Both the bench an the edge of the hedge are positioned correctly.

https://www.openstreetmap.org/#map=19/48.51844/9.05444

We don't map for the renderer, but whats about rendering for the mapper? Or only rendering for the renderer?