Rendering hedge as area is not always correct

[SK53]

A closed way tagged as barrier=hedge is interpreted as an area for zoom 16 and greater (landcover.mss line 425 & seq). Fields mapped as an area of farmland with a surrounding hedge are now shown exactly the same as woodland.

Example area is Cherry Hinton (z16 and z15):

In this cases the hedges surrounding the fields are uninterrupted.

[matkoniecz]

Can you provide also link to this location on the map?

EDIT: http://www.openstreetmap.org/?mlat=52.1797&mlon=0.1775#map=16/52.1797/0.1775 https://www.openstreetmap.org/way/255792852#map=16/52.1797/0.1775

[matkoniecz]

Link to mentioned line (corrected, it is line 433)

openstreetmap-carto/landcover.mss

Line 433 in 8af299b

[zoom >= 16] {

[matthijsmelissen]

I'm not sure what is the desired behaviour.

Adding the tag area=no should be a temporary workaround.

[matkoniecz]

It may be blamed in part on not the best tagging - this fields are not fully enclosed by hedges. But it is probably possible to find situation where it would be really a proper tagging.

@math1985 - it would break rendering of landuse=farmland on this object.

Apparently osm2pgsql encountered landuse=* and treated object it as instructed - as an area ( https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.style ). Unfortunately border on the same element also is treated as area.

[matthijsmelissen]

@mkoniecz, ah I see the problem now.

[matkoniecz]

@math1985 As I understand:

barrier=hedge with area=yes - render as area
barrier=hedge without area=yes - render as line

Problem: landuse=* is treated as area=yes (indicates that this object is an area).

[matkoniecz]

I wonder whatever this hedge is in database both as line and area - or is it only as an area? In the first case some hacks may be possible, in the second it requires at least change of .style.

objects the tag with are areas

from https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.style#L23

Seems to indicate the second case.

[matthijsmelissen]

@mkoniecz I'm not sure, but I believe both as area and line.

However, even with a style change, you can't drop the barrier from the polygons table without dropping the landuse from it too. That means that Mapnik has no way to know whether the barrier is a real polygon or not. We therefore can't fix this here, and I will close the issue.

I would suggest retagging the field with a double line, one for the field and one for the area. I think that's also conceptually better, because it feels strange that a single object represents both an area and a field.

[matkoniecz]

I would rephrase it to "suggest retagging the place with a double line, one for the field and one for the hedge".

[matthijsmelissen]

Thanks, that's what I meant!

[SK53]

Link to area.

I suspect that this is not an isolated example, and as rightly mentioned above when two distinct tags are applied to a single OSM element there is potential for a clash in how they are treated.

My reaction is that rendering hedge as an area should be removed from the style sheet: I suspect its a minor use-case, only relevant at high zooms, and hedges, by definition, are linear features and mapping them as areas (as some have done for individual trees) is probably something which the renderer should discourage. On the other hand mapping a bit of farmland surrounded by hedges without adding gates or breaks in the hedge line is surely a reasonable start which can then be refined incrementally.

[Rovastar]

Obviously we have a problem with the carto.
But also is this not a tagging issue. A hedge in a closed way, how do you get in or out? Maybe it is how you map but I would always leave a gap where the "entrance" is.

[SomeoneElseOSM]

Mapping something as both landuse and a hedge goes against "one OSM feature one element" too, surely?

Also I can think of some quite thick hedges (~5m or so) that might benefit from being mapped as areas. Here's an example of a small patch of woodland that degenerates into a hedge - some bits of the "wood" might be better described as "hedge area":

https://www.openstreetmap.org/#map=18/52.93516/-0.73845

[SK53]

As I stated a closed hedge is a reasonable first approximation, and iterative refinement of features is crucial to OSM. Incidentally I please be clear that I did not map this, and would not have mapped it this way myself, but as a result of the Carto rendering spent quite some time trying to find why it appeared that way.

[SK53]

Quick check on taginfo shows 101,000+ elements with both a landuse and barrier tag, and 91k elements sharing a leisure and a barrier tag. This suggests rendering barriers as areas may cause other issues.

[imagico]

It should be noted that double use of a feature for both representing linear elements and areas is not uncommon - another case are coastlines where small islands get some area tags like landuse/leisure in addition to natural=coastline. The difference here is of course that there is no risk in interpreting natural=coastline as an area tag. A related issue by the way was #268 - circular cliffs could also get some additional tags referring to the enclosed area.

If this is considered bad practice the question is of course how such mapping practice differs from applying several independent line tags to the same way - like highway/waterway and administrative boundary tags. From the data interpretation side the difference is clear, line tags are conflict free. But for the mapper this distinction is not that obvious.

The clearest interpretation probably is that tags like barrier=* or natural=cliff are always considered line tags unless there is an explicit area=yes. The heuristic approach interpreting a closed way as indicating an area only makes sense for tags that normally refer to areas or that can't be on a closed line by definition (like waterway=river).

[matkoniecz]

The heuristic approach interpreting a closed way as indicating an area

Is there somewhere example of barrier=hedge on a closed way without tags indicating that it is an area (like landuse=*) rendered as an area? Because that would be a separate issue, similar to #268

[dieterdreist]

2014-09-22 19:02 GMT+02:00 Mateusz Konieczny [email protected]:

It may be blamed in part on not the best tagging - this fields are not
fully enclosed by hedges. But it is probably possible to find situation
where it would be really a proper tagging.

@math1985 https://github.com/math1985 - it would break rendering of
landuse=farmland on this object.

Apparently osm2pgsql encountered landuse=* and treated object it as
instructed - as an area

IMHO this is also a mapping error, as different objects (linear hedge and
polygon landuse inside) are tagged to the same OSM object. This could be
solved by creating a multipolygon for the area. The current state also
creates other ambiguities, e.g. a potential name added to this object could
refer to either the hedge or to the farmland.

[dieterdreist]

2014-09-23 13:50 GMT+02:00 imagico [email protected]:

If this is considered bad practice the question is of course how such
mapping practice differs from applying several independent line tags to the
same way - like highway/waterway and administrative boundary tags.

these cases are bad practice as well. I am aware that this is not unusual
in OSM mapping, but it should be discouraged nonetheless, because it
creates ambiguities

[matkoniecz]

highway/waterway and administrative boundary tags on the same way is bad tagging - and it is really fragile. I fixed many mistakes that were caused by this type of tagging (highway changed, boundary remained the same and variations on this theme).

[imagico]

I did not want to initiate a discussion of the mapping practice here (wrong place for such) - i just wanted to point out that dismissing this case as bad tagging is making it too easy since - like it or not - this is broadly used tagging practice. Accepting this in cases where it is easy to deal with from the rendering side (lines with multiple independent tags) and dismissing it in cases where it creates difficulties (ways with tags referring to it as both area and line) would be a bit opportunistic.

[dieterdreist]

2014-09-23 15:33 GMT+02:00 imagico [email protected]:

I did not want to initiate a discussion of the mapping practice here
(wrong place for such) - i just wanted to point out that dismissing this
case as bad tagging is making it too easy since - like it or not - this is
broadly used tagging practice.

It is a used tagging method, but this is not the first time it gets
disputed as bad style leading to data corruption (ambiguities). This has
nothing to do with personal preference (like it or not), it has to do with
tags being associable to a distinct object. Somehow it is a similar case
like building=, shop= on the same object, but it is even worse here,
because you cannot tell whether an area or a linear feature is tagged (a
human can interpret the situation with very high probability, especially
with the help of aerial imagery, but this doesn't make this mapping style
acceptable --- IMHO).

[mboeringa]

Of course, there are always the "horrible" real world exceptions... ;(

See this, and think of how you or the average OSMer would likely tag this...:

Place du Carrousel, Louvre, Paris, France:
On OSM:
http://www.openstreetmap.org/way/53819213
On Google StreetView
https://www.google.nl/maps/@48.8611929,2.3343561,3a,75y,328.07h,91.87t/data=!3m4!1e1!3m2!1sxgjcJ1uEKDVN3d19bjrglg!2e0!6m1!1e1

Wuppertal Suspension Railway, Wuppertal, Germany (yes, this thing runs for kilometers over both water and roads, the history of this "railway" is actually quite interesting...):
http://en.wikipedia.org/wiki/Wuppertal_Suspension_Railway

Well, in the second case, it is actually included as a separate way over a waterbody, but it might just as well have had a double waterway/railway tagging scheme...
On OSM:
http://www.openstreetmap.org/way/37195413#map=18/51.26457/7.17797&layers=D

[pnorman]

I agree with closing it - if there is an issue, it's an osm2pgsql one, but mixing tags to indicate a linear feature and tags to indicate an area feature will never work with our current data model, and I don't believe osm2pgsql is the only converter to have issues on combinations like that.

[matkoniecz]

Place du Carrousel, Louvre, Paris, France:

From aerial view and Google StreetView it seems to be tall hedge with not so tall hedge/bushes inside, so rendering as an area would be OK.

double waterway/railway tagging scheme

And this is a great example why this approach is a bad idea - how bridge and name tags would be interpreted?

[matkoniecz]

I opened a ticket to request reporting this type of tagging as a problem in JOSM - https://josm.openstreetmap.de/ticket/10551#ticket

[mboeringa]

From aerial view and Google StreetView it seems to be tall hedge with not so tall hedge/bushes inside, so rendering as an area would be OK.

I wonder how the municipal gardeners even manage to trim this? I guess the French have long arms ;-)

And this is a great example why this approach is a bad idea - how bridge and name tags would be interpreted?

I wasn't supporting this (but you probably understood that), I agree with most written here, although I do see a case for area=yes to distinguish between area and line based rendering.
And luckily, in the Wuppertal case, the editors did not combine all tagging on a single way, but created separate ways for the different objects.

[jeisenbe]

This can be corrected now that area=yes is available as a tag in hstore, so I recommend reopening this issue.

I downloaded most of the features mapped as way["barrier"="hedge"]["area"!="yes"]["tourism"]. I found 31 closed ways tagged with hedge and tourism without area=yes. These should not be rendered with the hedge fill color.

Current screenshot:

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

After checking for "area=yes". (I've also changed the outline color to match the fill color).

• This can be done in the SQL query to exclude all types of barrier=* without area=yes, or it could just be done in the CSS for hedges only.
  

Alternately, we could get rid of the polygon fill and just render the 3 pixel wide green line on the outline of the area, similar to the current rendering for barrier=wall when mapped as an area.

[matkoniecz]

I would suggest retagging the field with a double line, one for the field and one for the area. I think that's also conceptually better, because it feels strange that a single object represents both an area and a field.

I agree, in my opinion tagging hedge around area and area with the same closed way is a tagging mistake.

But this appears to not be shared by wider OSM community (for example I proposed validator warning in JOSM for that and it got rejected), so workaround in rendering adding support for this tagging would be OK.

[pnorman]

We've always had access to the area tag, it's nothing that's changed in 4.0. I stand by the object being an area or not - not some combination of both.

[matkoniecz]

I also agree with that and I would be OK with closing this issue again.

But I am also not happy about divergent ideas how such object should be tagged. I am not sure is it preferable is it better to continue with approach different than most(?) of OSM community or to change it to one that is introducing some mixed status of a single element.

[jeisenbe]

I checked out this issue again after learned that the ID editor always requires area=yes with tags that are allowed to be tagged on a linear way or an area, for example, barrier=wall, barrier=fence. [See comment].(#3453 (comment))

It sounds like JOSM also follows the principle most of the time? And the wiki pages for barrier=hedge and barrier=wall are also clear that area=yes is required when mapping a closed way that is meant to be considered an area.

Since we can distinguish between closed ways tagged with area=yes or not, I believe it is reasonable to use this to adjust rendering, so that our rendering is consistent with the wiki documentation and with the editors function.

However, I'm also happy to submit a PR to remove the area fill for hedges, instead, if that's the best option.

[jeisenbe]

We've always had access to the area tag, it's nothing that's changed in 4.0

I used AND tags->'area' = 'yes' as a filter
When I tried using AND "area" = 'yes' or AND area = 'yes' I got errors, so I thought it must be in hstore.

Is there a way to find out which keys are imported into separate columns by osm2pgsql and which ones are only in the hstore column?

[sommerluk]

The file openstreetmap-carto.style lists the columns that are imported namely.

[pnorman]

Is there a way to find out which keys are imported into separate columns by osm2pgsql and which ones are only in the hstore column?

Prior to 4.0 we used the default osm2pgsql .style file

[jeisenbe]

OK, there are 2 options for fixing this:

1. Use the presence of "area=yes" to determine if the area fill is rendered. We would also use the standard-width green line for polygons with barrier=hedge but without area=yes, so that they rendered the same as hedges on lines.

2. Remove the area fill rendering from hedges. There are few examples where this improves the cartography, and this would make it consistent with barrier=wall with area=yes where there is no fill.

3. ADDED: As @matkoniecz suggests, close this issue as "wontfix" and expect that mappers should not tag features with barrier=hedge along with another feature key like tourism / natural / amenity etc.

[matkoniecz]

Or consider the current behavior as correct.

[Adamant36]

this would make it consistent with barrier=wall with area=yes where there is no fill.

Wouldn't make it consistent with reality though. In what examples would it improve the cartography?

[imagico]

In contrast to what i said in 2014 i would now be in favour of completely dropping filled polygon rendering of hedges. I have the impression there is no significant volume of intentional and correct uses of this.

[jeisenbe]

In what examples would it improve the cartography?

The map will definitely improve for closed ways that are tagged barrier=hedge and another feature tag like tourism= or landuse= or amenity= which causes the closed way to be imported as a polygon, and rendered with the solid hedge-color fill.

For barrier=hedge that are intentionally mapped as areas (mainly those tagged area=yes as recommended), the rendering will usually be the same at z16 and z17. Hedges over a meter in width will look different at 18 and z19 in high latitudes.