Tag that imply linear object and tag that imply area object should not be used on element without explicit area=yes/no

[mkoniecz]

Currently object like this are not reported by validator. For start barrier=*, landuse=* without area=yes may be reported.

Such objects cause issues for data consumers that use osm2pgsql. It also makes interpretation of additional tags (for example name, height, width, bridge etc) complicated or impossible.

Wider description problem: ​https://github.com/gravitystorm/openstreetmap-carto/issues/971 (ticket closed as caused by a tagging error - that is currently not detected by JOSM)

Example of object that should cause validator warnings: ​https://www.openstreetmap.org/way/255792852

Repository Root: http://josm.openstreetmap.de/svn
Build-Date: 2014-09-23 01:33:40
Last Changed Author: Don-vip
Revision: 7580
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Relative URL: ^/trunk
URL: http://josm.openstreetmap.de/svn/trunk
Last Changed Date: 2014-09-22 23:20:16 +0200 (Mon, 22 Sep 2014)
Last Changed Rev: 7580

Identification: JOSM/1.5 (7580 en) Linux Ubuntu 14.04.1 LTS
Memory Usage: 370 MB / 889 MB (225 MB allocated, but free)
Java version: 1.7.0_65, Oracle Corporation, OpenJDK Server VM
Java package: openjdk-7-jre:i386-7u65-2.5.2-3~14.04
Dataset consistency test: No problems found

[skyper]

Think it would be much better to split the object in two. Use the ways for the barrier and a multipolygon for the area.

This way validator should warn about the mixed use.

area=yes/no would be ambiguous in any way and does not work in your case anyway as the landuse is an area.

[mkoniecz]

Yes, obviously. But there may be some edge case where it would be valid - see garden on "Place du Carrousel, Louvre, Paris, France" described in ​https://github.com/gravitystorm/openstreetmap-carto/issues/971 - and it this case with explicit area=yes/no validator should not complain.

"Place du Carrousel, Louvre, Paris, France" is about leisure=garden that is completely covered by hedge, IMHO in this case [leisure=garden; barrier=hedge; area=yes] is proper tagging.

Also, IMHO direct setting area applies to all tags and overrides all defaults so it is not ambiguous.

In general proper way to fix problem is to separate element into two objects.

[mkoniecz]

​https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.style has list of tags that imply linear object or imply area object.

[bastiK]

I don't see how this is a mapping error: barrier=* is a line feature (unless there is the tag area=yes) and landuse=* is an area feature. Both should be rendered separately. Isn't this more a limitation of the osm2pgsql / carto / mapnik toolchain?

[mkoniecz]

It is limitation of toolchain, but also a tagging problem. For example somebody adds name tag - should it be applied to field, hedge or both? Or height tag. Or species tag.

[stoecker]

There are plans to implement an area style in OSM API, but I doubt it will come in the near future. Currently we don't have one, but heuristics and multipolygons. There are ways to solve such special cases:

• create a multipolygon, it's always an area and tags for it refer to the area
• use area=no on ways and don't close ways (i.e. split them) to say clearly it is no area.
• Otherwise rely on the heuristics developed over the time.

[mkoniecz]

"There are ways to solve such special cases" - so in opinion of JOSM devs "[barrier=hedge; landuse=farmland]" on one object is a good way to tag hedge around a field?

[stoecker]

Replying to mkoniecz:

"There are ways to solve such special cases" - so in opinion of JOSM devs "[barrier=hedge; landuse=farmland]" on one object is a good way to tag hedge around a field?

If you refer to an area farmland and a line hedge: No. You have at least two solutions:
a) make the farmland a multipolygon and the tag hedge on the line
b) make one line for the hedge and one for the farmland

Probably lots of other solutions. But this is no JOSM ticket issue, ask in the tagging related mailinglists and forums.

[mkoniecz]

"If you refer to an area farmland and a line hedge: No."

So is there a good reason to not inlude validator test detecting this issue?

[stoecker]

Replying to mkoniecz:

So is there a good reason to not inlude validator test detecting this issue?

As such area/line issues cannot be reliable detected it would be an INFO message which nobody sees. Adding a special testcase for a specific tag-combination is only useful when that error is very common.

[bastiK]

Replying to stoecker:

Replying to mkoniecz:

So is there a good reason to not inlude validator test detecting this issue?

As such area/line issues cannot be reliable detected it would be an INFO message which nobody sees. Adding a special testcase for a specific tag-combination is only useful when that error is very common.

Should be possible to detect this somewhat reliably: Basically run ElemStyles.generateStyles on the way and see if you get a line-style and a way-style in the list.

[stoecker]

Actually if I think about it: The [barrier=hedge; landuse=farmland] is only a problem with "area=yes". Without this the heuristics are perfectly ok and the area is landuse and the hedge is line style.

So a simple style compare does not help, as in some cases it is valid, in others not. But feel free to implement it and then see how it works .-)

[bastiK]

Replying to stoecker:

Actually if I think about it: The [barrier=hedge; landuse=farmland] is only a problem with "area=yes". Without this the heuristics are perfectly ok and the area is landuse and the hedge is line style.

So a simple style compare does not help, as in some cases it is valid, in others not. But feel free to implement it and then see how it works .-)

mkoniecz suggests to report barrier=*, landuse=* without area=yes as validation error and to show no warning when area=yes/no is present.
As stoecker says, I think it should be rather the opposite:

• barrier=*, landuse=* && area=yes is a tagging error because it implies that the barrier is an area, i.e. it covers all the landuse.
• barrier=*, landuse=* && area=no is wrong, because it means that the landuse feature is not an area.
• barrier=*, landuse=* and no other tags: It is much simpler to put 2 tags on a single way than to have to identical ways on top of each other. There is also no ambiguity at this point. For me this is just the same as highway=residential && railway=tram. At the moment, I'm not convinced that there is community consensus to ban this tagging style. It makes it easier for mappers and harder for data consumers, but it's not wrong per se.

[mkoniecz]

Wiki since 2013 encourages to not tag linear and area things as one element. Before this it encouraged data consumers to deal with such tagging.

Note that mappers frequently use multiple tags on the same closed way can result in the way being used to define both a closed area and also a polyline; for example a closed way tagged landuse=grass and barrier=fence can be interpreted as a fence enclosing an area of grass. A clean solution would be to create one way for each feature.

Relevant edit + ​https://wiki.openstreetmap.org/w/index.php?title=Key:area&diff=922093&oldid=872234

[cmuelle8]

Just to mention I've also seen this problem. Standard mapnik style must have changed for osm.org, e.g.

barrier=hedge landuse=allotments

once had a different semantic meaning wrt to the mapnik style. I've not tagged this myself, but am pretty sure that the map rendering was checked back at the time this kind of data was commited. I.e. (probably before) 2013 the outline was correctly rendered green, and the space within brown. Now the whole feature, outline and area, are rendered green on a closed way tagged like this.

IMHO this tagging practice should clearly be discouraged and the validator should warn about it. Why?:

• barrier=hedge in osm wiki is defined as both, a linear and an area feature -- this means mapnik style is correctly rendering this as an area, if it's used on a closed way, i.e. in this case area=yes will be implied (but obviously was not before the relevant change in the style rules, i.e. at the time data was entered)

• landuse=* also implies area=yes -- with the exception of possibly natural=scrub all of the area-implying tags contradict an barrier=hedge on the same area.

Essentially, what the mapper is trying to do, is defining a 2nd area style when a 1st one already had been given. There might be corner cases but in the majority of cases this is undesirable.

The validation should check wheter the closed way is tagged with two or more contradicting area styles and warn or error out in those cases, since, according to the wiki, it would be wrong to interpret barrier=hedge on a closed way as a linear feature. This is also why the above combination should indeed be treated as an error. Also, I think we can safely assume, that 'serious' allotments do not solely consist of hedges.

If area=* is explicitely given, then in the yes-value case the same statements apply. In case of area=no on a closed way however,

barrier=hedge  area=no  is valid  (mapnik should only render outline)

landuse=*  area=no  is INvalid  (as bastik already mentioned)

barrier=hedge  landuse=*  area=no  is INvalid  (as it's ambigue which tag is to be linearized)

barrier=hedge  landuse=*  is INvalid  (as stated above:  two (contradicting) area styles for one and the same area)

I have not thought about which general validator rule might include this case, but it's a common error (for sure, since the mapnik style rule adheres to the wiki specification, and, strictly speaking, as long as it's been in the wiki like this..). For the specific common error case laid out above validation should be possible and useful.

To resolve this, a good solution is to split the ways representing the hedges, tag the now non-closed ways with barrier=* accordingly and create an MP for the area within (using the split ways as outer segments).

Thanks

[cmuelle8]

It might make sense to unify validation with the way overpass turbo treats closed ways (or more specific: detects whether a closed way is an area or not):

​https://wiki.openstreetmap.org/wiki/Overpass_turbo/Polygon_Features

In the long run closed-way-areas should be phased out in favor of and suggestion to use MP-relations. This is the only way to clearly decide if a mapper intended an object to be an area or not.

The "mix" of "linear-only" and "possibly-area" tags on the same closed-way is error-prone and more than often lead and leads to confusion. Also, it makes it _very_ hard to maintain software that works with areas, i.e. it always needs the latest set of area-implying tags to somewhat reliably decide how to treat a closed way.

Greetings

[SomeoneElse2]

I hesitate to wake this up again after 9 years, but it'd still be great to advise mappers not to combine area tags and linear tags on the same object. It's still a problem - see ​https://www.openstreetmap.org/user/SomeoneElse/diary/401631 and the links from there for more information and some numbers for the UK and Ireland for hedges.