Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-09 Thread John Willis via Tagging


> On Feb 7, 2020, at 7:48 PM, Peter Elderson  wrote:
> 
> If area=yes is added to say a leisure area surrounded by a hedge, that is a 
> mapping mistake. If that results in the area displaying as a hedge area, the 
> mapper has to correct that, not the renderer.


exactly!

If I want a hedge around a tennis court, I draw a hedge around a tennis court. 

if a traffic island has a large triangle shaped hedge, then I draw a large 
triangle shaped hedge with area=yes. 

Mappers can’t mix area and way tags on the same object if they depend on 
area=yes to define what they are. 


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-09 Thread Jeroen Hoek
On 09-02-20 12:36, Peter Elderson wrote:
> For the record, I am not opposed to renderers, data users or toolmakers
> reporting a problem or an improvement request and asking the taggers
> list to come up with a solution everyone can live with. Information in
> the database should be renderable and usable, because that is the
> purpose of the whole thing. But please, in co-operation, and when a
> sudden change leads to problems, rethink it and take another path to get
> to a shared solution.

+1.

It would probably suffice to restore just the rendering for
`barrier=hedge` plus `area=yes` for now.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-09 Thread Peter Elderson
OSM Carto stopped rendering barrier=hedge, area=yes as a hedge barrier
area, without proper announcement. Immediately this was reported as a
problem, because it is established and documente tagging and many people
noticed the change.

The right way to handle this is to revert this particular change. Even if
the reason behind it is fundamentally right, it still causes a practical
problem on the map, which requires change management and co-operation. .
Instead, taggers are told they are wrong and the problem does not exist.
That does not help.

In fact, there was no mapping problem with the established and documented
tagging, until the rendering was radically changed. Before that, it
rendered just fine, and where the map did not reflect the actual situation,
there was a tagging error, so that should be corrected by changing the
tagging for that particular feature.

If there is a fundamental problem in the established tagging, then the
right way to handle that is to first explain and discuss that on the
tagging list (and mapper forums). That should provide a solution both
renderers and taggers can live with.

For the record, I am not opposed to renderers, data users or toolmakers
reporting a problem or an improvement request and asking the taggers list
to come up with a solution everyone can live with. Information in the
database should be renderable and usable, because that is the purpose of
the whole thing. But please, in co-operation, and when a sudden change
leads to problems, rethink it and take another path to get to a shared
solution.

Fr gr Peter Elderson


Op zo 9 feb. 2020 om 03:30 schreef Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> I don't understand why mappers in Zeeland are considered less reliable
> than those in South Holland? Isn't all of the Netherlands below sea
> level, consisting entirely of polders and dykes? ;-) (Just joking... I
> know there are hills some tens of meters above sea level...)
>
> http://overpass-turbo.eu/s/QyU - hedge ways in South Holland (1011)
> http://overpass-turbo.eu/s/QyT - hedge closed ways in South Holland
> (137) - <14% of ways
> http://overpass-turbo.eu/s/QyS - hedge closed ways with area=yes in
> South Holland (91)
>
> So in this case there is a 2:1 ratio of those with area=yes vs
> without, unlike in Zeeland - but the total numbers for ways and closed
> ways are both slightly lower than those for Zeeland (where there are
> 1179 ways, 146 closed).
>
> I checked The Haag and Rotterdam, since it has been suggested that we
> should look at mapping in towns and cities.
>
> There are 3 places with area=yes hedges in Rotterdam. One is here,
> where several plantings of bushes(?) spell out "ROTTERDAM" next to a
> highway:
> https://www.openstreetmap.org/way/325978680#map=19/51.91438/4.53259
> - note that the multipolygon hedges like
> https://www.openstreetmap.org/relation/4550190 do not have area=yes. I
> think it is a stretch to use "barrier=hedge" for a purely ornamental,
> low-height planting like this.
>
> The other place with more than one hedge is in this cemetery.
> https://www.openstreetmap.org/way/550331809#map=19/51.87471/4.50668
>
> In The Haag the main place was these hedge areas by the Vredespaleis
> ("Peace Palace"?): eg http://www.openstreetmap.org/way/665101476
>
> But they are tagged area=yes + barrier=hedge, even though they look like
> this:
>
>
> https://www.alamy.com/stock-photo-beautiful-garden-of-the-peace-palace-or-vredespaleis-in-dutch-which-104165268.html
>
> Those are short linear hedges, about 1/2 meter wide, around a garden
> flower bed. It is not a solid area of hedge, so area=yes is
> misleading.
>
> There are also some thin, 1 to 2 meter wide linear hedges along some
> roads to the north of this palace, eg:
> http://www.openstreetmap.org/way/291963185
>
> The current rendering looks the same as before for these at z16 to
> z18, since they are too narrow to see any gap between the lines:
> https://www.openstreetmap.org/way/291963185#map=18/52.10004/4.29410.
>
> At z19 a small gap between the lines is just visible:
> https://www.openstreetmap.org/#map=19/52.10017/4.29383 - So there is
> little advantage from mapping this feature as an area for rendering
> maps at most zoom levels, though it might make a visible difference at
> z20 and higher. Using the `width=` tag would be a reasonable
> alternative.
>
> Overall, even in South Holland it is rare to map hedges as an area
> instead of as a linear feature, and there are a number of hedges
> mapped as areas which lack area=yes, and some hedges with `area=yes`
> that are not actually area features.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-08 Thread Joseph Eisenberg
I don't understand why mappers in Zeeland are considered less reliable
than those in South Holland? Isn't all of the Netherlands below sea
level, consisting entirely of polders and dykes? ;-) (Just joking... I
know there are hills some tens of meters above sea level...)

http://overpass-turbo.eu/s/QyU - hedge ways in South Holland (1011)
http://overpass-turbo.eu/s/QyT - hedge closed ways in South Holland
(137) - <14% of ways
http://overpass-turbo.eu/s/QyS - hedge closed ways with area=yes in
South Holland (91)

So in this case there is a 2:1 ratio of those with area=yes vs
without, unlike in Zeeland - but the total numbers for ways and closed
ways are both slightly lower than those for Zeeland (where there are
1179 ways, 146 closed).

I checked The Haag and Rotterdam, since it has been suggested that we
should look at mapping in towns and cities.

There are 3 places with area=yes hedges in Rotterdam. One is here,
where several plantings of bushes(?) spell out "ROTTERDAM" next to a
highway: https://www.openstreetmap.org/way/325978680#map=19/51.91438/4.53259
- note that the multipolygon hedges like
https://www.openstreetmap.org/relation/4550190 do not have area=yes. I
think it is a stretch to use "barrier=hedge" for a purely ornamental,
low-height planting like this.

The other place with more than one hedge is in this cemetery.
https://www.openstreetmap.org/way/550331809#map=19/51.87471/4.50668

In The Haag the main place was these hedge areas by the Vredespaleis
("Peace Palace"?): eg http://www.openstreetmap.org/way/665101476

But they are tagged area=yes + barrier=hedge, even though they look like this:

https://www.alamy.com/stock-photo-beautiful-garden-of-the-peace-palace-or-vredespaleis-in-dutch-which-104165268.html

Those are short linear hedges, about 1/2 meter wide, around a garden
flower bed. It is not a solid area of hedge, so area=yes is
misleading.

There are also some thin, 1 to 2 meter wide linear hedges along some
roads to the north of this palace, eg:
http://www.openstreetmap.org/way/291963185

The current rendering looks the same as before for these at z16 to
z18, since they are too narrow to see any gap between the lines:
https://www.openstreetmap.org/way/291963185#map=18/52.10004/4.29410.

At z19 a small gap between the lines is just visible:
https://www.openstreetmap.org/#map=19/52.10017/4.29383 - So there is
little advantage from mapping this feature as an area for rendering
maps at most zoom levels, though it might make a visible difference at
z20 and higher. Using the `width=` tag would be a reasonable
alternative.

Overall, even in South Holland it is rare to map hedges as an area
instead of as a linear feature, and there are a number of hedges
mapped as areas which lack area=yes, and some hedges with `area=yes`
that are not actually area features.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-08 Thread Jeroen Hoek


On 06-02-20 13:29, Peter Elderson wrote:
> Joseph Eisenberg  >:
> 
> 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`.
> 
> 
> Zeeland, of all places... Most of Zeeland is water, dykes and polders. 
> 
> Try Noord-Brabant, Zuid-Holland, Utrecht. 
> 

Absolutely! Zeeland is a really unfortunate choice to illustrate this issue.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-08 Thread Jeroen Hoek
On 07-02-20 17:58, Martin Koppenhoefer wrote:> interestingly, for paths
and roads there is also an area=yes variant
> (which is likely more common than the newer "area:highway" tag, which
> has different semantics).

To be precise: `area=yes` on a `highway=*` means that the whole area is
routable, not just the (closed) way surrounding it. I.e., clever routing
software could send someone along a (shorter) path across the area
instead of along its sides.

Its semantics match that of `barrier=hedge` plus `area=yes`.

`area:highway=*` is more akin to `landcover=*` in that it represent the
surface area of the road, where `highway=*` represents the linear route
of the road.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-07 Thread Mateusz Konieczny via Tagging



Feb 7, 2020, 17:08 by pla16...@gmail.com:

> On Fri, 7 Feb 2020 at 15:25, Mateusz Konieczny via Tagging <> 
> tagging@openstreetmap.org> > wrote:
>
>> Feb 7, 2020, 15:53 by >> pla16...@gmail.com>> :
>>
>>> Then we give up on entirely sensible ideas because Carto insists on a "no
>>> synonyms" rule.  Which leads me to say, frequently, that OSM
>>> doesn't do joined-up thinking.
>>>
>> landcover is disliked by big part of this mailing list and iD devs and JOSM 
>> devs.
>>
>
> Landcover=* has 153,499 uses.   Or did you mean landcover=grass specifically?
> That's the second-most popular, with 19,755 uses despite not being rendered.
> For a tag that's not supported by editors or rendered, that's significant use.
>
landuse=grass alone has 3.5 million of uses

> If landcover were approved, iD and JOSM might decide to support it.  But
> probably not, because it doesn't render, and they wouldn't want to deal with
> people raising issues about iD suggesting tags that don't render.
>
iD and JOSM and Vespucci support many many many tags that are not rendered

lack of rendering is not the blocker

> Editors won't support it because it doesn't render.  Around
> and around we go.
>
lack of rendering in OSM Carto is not the blocker for adding presets.
JOSM, iD, Vespucci have many things in presets that are not rendered in
OSM Carto.

Note: please do not report new issues if there is already existing issue
for such request
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-07 Thread Martin Koppenhoefer
Am Fr., 7. Feb. 2020 um 11:26 Uhr schrieb Christoph Hormann :

> I currently tend towards a broader solution of dropping rendering of all
> barrier tags on polygons.



great, this would make it very clear that there is indeed some problem with
the tagging. Although I guess carto would get a lot of flak for a decision
like this.


This would
> open a path for the various solutions already discussed - like
> introducing a new tagging scheme for indicating a polygon to
> be 'enclosed by a barrier'



there is for example fenced=yes, currently used 4841 times (even applicable
to nodes)



> or by strictly adhering to 'one feature, one
> OSM element' without implicit tagging of barriers.



adhering to 'one feature, one OSM element' and supporting fenced=yes on
polygons isn't a contradiction. Implicit tagging is ok, it's explicit
tagging of more than one thing on the same element, which creates the
problem. "fenced=yes" doesn't say this is a fence, it says this has a fence
around it. The problem with this approach is that it slows down the adding
of details, because if you want to add the height of the fence you would
either have to make it its own object at this point, or resort to new tags
like fence:height=x
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-07 Thread Martin Koppenhoefer
Am Fr., 7. Feb. 2020 um 11:03 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> 1) The tag `area=yes` is only supposed to mean "this closed way is an
> area, not a line", and is only used when this is not already obvious
> from other tags.
>
> It is not necessary to add `area=yes` when the closed way already has
> a tag which defines an area, such as `landuse=forest` or
> `natural=scrub` or `leisure=playground`: all of these keys are always
> areas when mapped as closed ways, so they do not require `area=yes`,
> whether or not `barrier=hedge` or `barrier=fence` is added.
>
> This also means that `area=yes` is never needed when the same object
> is turned into a multipolygon relation, so checking for `area=yes`
> alone is not sufficient
>
> A closed way with `hedge=barrier` + `natural=scrub` is an area, and
> the presence or abscense of `area=yes` should not be required. This
> makes this a poor tag to rely on for rendering decisions, at least for
> a style that influences how mappers use tags.
>


in our data model, some area-feature plus barrier=hedge can mean: a hedge
(linear) around the area. Actually, it is what people do, it is not really
something that was conceptionally designed (contrarily, it is against the
one-feature-one-element rule but "we" have decided to support this kind of
mapping rather than for example ignore the whole object as "invalid"). If
we could educate people (through rendering decisions) to choose
representations that get rid of these ambiguities, it could be beneficial
in the long run. Rejecting all hedges mapped as areas by ignoring the area
tag for rendering, doesn't seem a sensible response. It is a 180 degree
turn, from supporting this style for hedges mapped as area to making it
impossible to apple the barrier=hedge tag on areas in a way that it gets
rendered.



>
> 2) Many hedges which were mapped like areas are currently missing
> `area=yes` tags. In this comment
> (
> https://github.com/gravitystorm/openstreetmap-carto/pull/3844#issuecomment-582692389
> )
> you can see that over 90% of the `barrier=hedge` closed ways in a
> Dutch province (random example) are missing `area=yes`



I do not have much knowledge about the Dutch map, but I recall they have
imported their landuse once and at least one time updated it with a
following import. Maybe these missing tags are missing because they were
forgotten in the import?



> , though they
> appear to be mapping the outline/area of the hedge. This means that a
> rendering solution that relies on `area=yes` would miss a large
> percentage of hedges mapped in this way.



these have been broken before and would be broken afterwards as well, no?



>
> Most likely, many mappers do not see why they should need to add a tag
> like `area=yes` when they map a hedge as a closed way.
>


indeed, they do not need, only if they intend to represent the whole
enclosed area rather than a hedge as perimeter they would have to add
area=yes.
Clearly, it isn't nice to have a tag for something basic as the distinction
between the line and polygon geometry type, and maybe this will be solved
more generally in the future by adding an additional geometry type.


>
> A better solution is to use different tags for linear features and
> area features. This is the standard used in Openstreetmap for common
> linear features such as paths, roads, railways and waterways: the area
> and the line are different tags.
>


interestingly, for paths and roads there is also an area=yes variant (which
is likely more common than the newer "area:highway" tag, which has
different semantics). For example there are 158502 (27% of all pedestrian
objects) instances of highway=pedestrian, area=yes alone. It's the
standard. ;-)




>
> (The rare exception to the rule that the same tag isn't used for lines
> and areas is for pedestrian plazas which are mapped with area=yes, but
> in this case the idea is that there is no linear feature: the area
> allows travel in "any" direction by pedestrians, so there is no "line"
> to map, just the area.



exactly, just like the case of barrier=hedge as an area.



> Yet there often is confusion about how
> pedestrian highway areas should be mapped and how they differ from
> area:highway=, so this cannot be considered a good example to emulate
> in the future. )



IMHO these are sign of a lack of awareness of squares as important feature
in the urban structure amongst the early contributors (the idea and focus
was the creation of a routing graph). Later on, really late, place=square
was added.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-07 Thread Peter Elderson
Mateusz Konieczny via Tagging :

> If you think that there is broad support for landcover proposal - feel
> free to
> start vote on the landcover proposal.
>

How about changing established tagging for hedge areas - was there a
proposal? What did it propose? I must have missed it somehow.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-07 Thread Paul Allen
On Fri, 7 Feb 2020 at 15:25, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> Feb 7, 2020, 15:53 by pla16...@gmail.com:
>
> This list regularly suggests things like replacing landuse=grass with
> landcover=grass, and proposes that editors make the appropriate changes.
>
> Vocal part of the list that seems minority to me.
>

Seems like there is little opposition, to me.  But my memory isn't what it
was and
could be selective.  And those suggesting it might be a minority because
most
have realized that however desirable it may be that it's unlikely to go
anywhere, just like it didn't go anywhere the time they did speak in favour
of it.

> Then we give up on entirely sensible ideas because Carto insists on a "no
> synonyms" rule.  Which leads me to say, frequently, that OSM
> doesn't do joined-up thinking.
>
> landcover is disliked by big part of this mailing list and iD devs and
> JOSM devs.
>

Landcover=* has 153,499 uses.   Or did you mean landcover=grass
specifically?
That's the second-most popular, with 19,755 uses despite not being rendered.
For a tag that's not supported by editors or rendered, that's significant
use.

If landcover were approved, iD and JOSM might decide to support it.  But
probably not, because it doesn't render, and they wouldn't want to deal with
people raising issues about iD suggesting tags that don't render.

There's no point calling for it here because it doesn't render and editors
don't support it.  Editors won't support it because it doesn't render.
Around
and around we go.

Did I ever mention that OSM doesn't do joined-up thinking?

>
> There were multiple attempts that tried to use OSM Carto map style as a
> battering
> ram to force this tagging style and I am getting irritated by this.
>

Some of us see the recent change to area barriers as OSM Carto map style
being
a battering ram to force tagging changes.  One that has actually had major
effects.  Maybe we could try joined-up thinking.

If you think that there is broad support for landcover proposal - feel free
> to
> start vote on the landcover proposal.
>
> I am tempted to do this to get it finally rejected, but I feel that it
> would be not nice.
>

If you feel you can do so in a manner that is neutral, then please do it.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-07 Thread Mateusz Konieczny via Tagging



Feb 7, 2020, 15:53 by pla16...@gmail.com:

> This list regularly suggests things like replacing landuse=grass with
> landcover=grass, and proposes that editors make the appropriate changes.
>
Vocal part of the list that seems minority to me.

> Then we give up on entirely sensible ideas because Carto insists on a "no
> synonyms" rule.  Which leads me to say, frequently, that OSM
> doesn't do joined-up thinking.
>
landcover is disliked by big part of this mailing list and iD devs and JOSM 
devs.

Please do not make like everybody supports and wants
it and solely OSM Carto blocks it.

There were multiple attempts that tried to use OSM Carto map style as a 
battering
ram to force this tagging style and I am getting irritated by this.

This kind of thing makes harder to decide whatever other criticism is warranted 
or not.

If you think that there is broad support for landcover proposal - feel free to 
start vote on the landcover proposal.

I am tempted to do this to get it finally rejected, but I feel that it would be 
not nice.

> OSM doesn't do joined-up thinking.
>
Or people dislike this specific idea.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-07 Thread Mateusz Konieczny via Tagging
Feb 7, 2020, 15:48 by marc_marc_...@hotmail.com:

> On Fri, 7 Feb 2020 at 10:26, Christoph Hormann wrote:
>
>> it would make a lot of sense for OSM-Carto to stop indicating this is valid 
>> tagging.
>>
>
> it would make more sense to
> 1) decide what a valid/ideal schema is.
> 2) decide what a invalid/bad schema is.
>
If there is consensus/clear support for tagging
not supported in OSM Carto then it should be changed.

(from what I see there is no such case)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-07 Thread Paul Allen
On Fri, 7 Feb 2020 at 10:50, Christoph Hormann  wrote:

> On Friday 07 February 2020, Peter Elderson wrote:
> > E.g. if a solution would be to tag hedge areas as natural=hedge
> > or landcover=hedge, then the change path would be for the renderer to
> > temporarily render the old AND the new tagging, so mappers can edit
> > the old tagging to the new tagging.
>
> We always try to avoid that because it never works towards a more
> consistent tagging but only perpetualizes the use of both tags as
> synonyms because mappers get feedback that both tags are correct.
>

All it takes is for editors to use the new synonym for its presets and to
alert users when they edit an object with the old synonym with an offer
to upgrade the tags.  Like iD does for many other tags that have been
obsoleted (like old bus stop tagging).  Mappers DO get feedback about
which tag is correct, at least in iD.

This list regularly suggests things like replacing landuse=grass with
landcover=grass, and proposes that editors make the appropriate changes.
Then we give up on entirely sensible ideas because Carto insists on a "no
synonyms" rule.  Which leads me to say, frequently, that OSM
doesn't do joined-up thinking.

We could make this work very easily for landuse=grass.  Existing objects,
when edited for other reasons, would warn about outdated tags and
the mapper would have the option to check iif the area is landcover=grass
(grass is grown there for no purpose other than landcover) or if it's
something like a
meadow.  For new objects, when the user types in grass then the editor
would throw
up a list of suitable presets for grass/meadow/whatever.  It's all
perfectly feasible,
except "no synonyms."

OSM doesn't do joined-up thinking.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-07 Thread marc marc
On Fri, 7 Feb 2020 at 10:26, Christoph Hormann wrote:
> it would make a lot of sense for OSM-Carto to stop indicating this is valid 
> tagging.

it would make more sense to
1) decide what a valid/ideal schema is.
2) decide what a invalid/bad schema is.
3) making sure that the new schema is at least as well rendered in the
default style as the old one. if not, some mapper wouldn't move from
"it's rendered" to "not anymore"
4) propose a collective effort or automated edit to migrate from one to
the other
5) AFTER some time and/or after its use has strongly decreased, remove
the old schema from the default style.

of course, this implies that the tagging discussion takes place here and
the rendering takes place there, instead of the current bad-bad situation.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-07 Thread Paul Allen
On Fri, 7 Feb 2020 at 10:26, Christoph Hormann  wrote:

>
> I currently tend towards a broader solution of dropping rendering of all
> barrier tags on polygons.


Aaaarghh!  No.  Nononononono.  "Oh dear, I've just made a change
that upsets a lot of mappers.  I'll deal with the problem by making an
additional
change that upsets even more mappers."  You may not think of it that way,
but that's how many mappers will see your proposal.  Possibly a good
solution if it affects only a few dozen objects, not a good solution given
how many objects would need to be retagged.

  I originally was under the impression that
> use of barrier tags as a secondary tag for landuse polygons etc. was
> consensus among mappers based on the fairly large use numbers for that
> (>350k) but it quite clearly isn't.


Yes.  A lot of mappers do that.  Purists insist they should use "one way,
one
object" and map a park with a hedge around it as two coincident closed ways
but at least one editor makes this very difficult to maintain.  So people
take the easy way out and a LOT of objects have been tagged that way.


>   So it would make a lot of sense
> for OSM-Carto to stop indicating this is valid tagging.


And require a LOT of edits to fix things.  No!
This is not the sort of change that should be made given how common
it is.

appers, in the long term be possible to interpret barrier tags on
> polygons as 2d barriers again but it might be a better idea - as Joseph
> indicated - to use a different tag than for linear barriers to avoid
> confusion.  Using the same tag for 1d and 2d representations always
> bears the potential for problems (like leisure=track for example).
>

The thing is, if I read Andy Townsend's comments correctly, you've made
this change because a relatively small number of situations give rise to
silly rendering.  Situations that most people here regard as bad tagging
in the first place.  Most people here think it would have been better
to not have made the change and tell anyone who got unexpected
results to fix their broken tagging.

Instead you seem to have fixed things for the few at the expense of the many
and, now the many are complaining you propose to break lots of other things
too.  This seems sub-optimal.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-07 Thread Marc Gemis
for me, this discussion can be closed if you start rendering
natural=hedge in the same colour as barrier=hedge.
I would have been nice that we just had such an alternative the moment
you changed the rendering.

regards

m.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-07 Thread Peter Elderson
Christoph Hormann :

> On Friday 07 February 2020, Peter Elderson wrote:
> > E.g. if a solution would be to tag hedge areas as natural=hedge
> > or landcover=hedge, then the change path would be for the renderer to
> > temporarily render the old AND the new tagging, so mappers can edit
> > the old tagging to the new tagging.
>
> We always try to avoid that because it never works towards a more
> consistent tagging but only perpetualizes the use of both tags as
> synonyms because mappers get feedback that both tags are correct.
>

Not if a clear path is agreed upon and an end date is set, communicated and
documented. Most OSM communities wil handle his in time. Basic change
management, this.



> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-07 Thread Christoph Hormann
On Friday 07 February 2020, Peter Elderson wrote:
> E.g. if a solution would be to tag hedge areas as natural=hedge
> or landcover=hedge, then the change path would be for the renderer to
> temporarily render the old AND the new tagging, so mappers can edit
> the old tagging to the new tagging.

We always try to avoid that because it never works towards a more 
consistent tagging but only perpetualizes the use of both tags as 
synonyms because mappers get feedback that both tags are correct.

-- 
Christoph Hormann
http://www.imagico.de/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-07 Thread Peter Elderson
Christoph Hormann :

> I originally was under the impression that
> use of barrier tags as a secondary tag for landuse polygons etc. was
> consensus among mappers based on the fairly large use numbers for that
> (>350k)


Correct.


> but it quite clearly isn't.


Yes it is, but an explicit area=yes adds the information that the whole
area is the barrier.

If area=yes is added to say a leisure area surrounded by a hedge, that is a
mapping mistake. If that results in the area displaying as a hedge area,
the mapper has to correct that, not the renderer.


___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-07 Thread Peter Elderson
oseph Eisenberg :

> 2) Many hedges which were mapped like areas are currently missing
> `area=yes` tags. In this comment
> (
> https://github.com/gravitystorm/openstreetmap-carto/pull/3844#issuecomment-582692389
> )
> you can see that over 90% of the `barrier=hedge` closed ways in a
> Dutch province (random example) are missing `area=yes`, though they
> appear to be mapping the outline/area of the hedge. This means that a
> rendering solution that relies on `area=yes` would miss a large
> percentage of hedges mapped in this way. The situation is worse for
> barrier=wall.


Zeeland is a bad example, and absolute numbers are low. Not wise to base
decisions on that. Please check Noord-Brabant, Zuid-Holland, Utrecht.
Nederland as a whole did not have any problem with the wiki-conform
rendering, but it does have a huge problem with the current rendering which
does not conform to the wiki. If mappers do not conform to the wiki
documentation, the tagging is the error, and it is a good thing that that
is visible, so mappers will correct the mapping.

I agree that tagging could have been better defined. I am not against
simpler/cleaner/better tagging, if it helps renderers. The first thing to
do is to get the problem clear so that mappers can agree to find a better
solution. Then discuss solutions, including a change path. E.g. if a
solution would be to tag hedge areas as natural=hedge or landcover=hedge,
then the change path would be for the renderer to temporarily render the
old AND the new tagging, so mappers can edit the old tagging to the new
tagging. Then set an end of support date for the old tagging.
Would that be so hard?


>
>
___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-07 Thread Christoph Hormann
On Friday 07 February 2020, Marc Gemis wrote:
>
> I still do not understand why area=yes is a bad tag.

I never said it was.  I said area=yes currently has one *and only one* 
meaning - to indicate a closed way is a polygon.  Since this is such a 
fundamental low level distinction in the OSM data model - comparable in 
a way to the type=* tag on relations - overloading this tag with 
additional meanings would be ill-advised and there is visibly no 
consensus among mappers for such an additional meaning.

> I have little hope that you will revert the change and take a
> different approach.

That is not up to me.  I have given my assessment to what options have a 
chance for achieving consensus among maintainers.  For a simple revert 
of PR 3844 this is unlikely.  Same for any change that interprets 
area=yes beyond the current established meaning for the fundamental 
polygon vs. line string decision for closed ways.

I currently tend towards a broader solution of dropping rendering of all 
barrier tags on polygons.  I originally was under the impression that 
use of barrier tags as a secondary tag for landuse polygons etc. was 
consensus among mappers based on the fairly large use numbers for that 
(>350k) but it quite clearly isn't.  So it would make a lot of sense 
for OSM-Carto to stop indicating this is valid tagging.  This would 
open a path for the various solutions already discussed - like 
introducing a new tagging scheme for indicating a polygon to 
be 'enclosed by a barrier' or by strictly adhering to 'one feature, one 
OSM element' without implicit tagging of barriers.  As indicated 
before - it would in principle, if any such solution finds support by 
mappers, in the long term be possible to interpret barrier tags on 
polygons as 2d barriers again but it might be a better idea - as Joseph 
indicated - to use a different tag than for linear barriers to avoid 
confusion.  Using the same tag for 1d and 2d representations always 
bears the potential for problems (like leisure=track for example).

-- 
Christoph Hormann
http://www.imagico.de/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-07 Thread Joseph Eisenberg
> I still do not understand why area=yes is a bad tag...

> you have problems to implement it in your workflow.

That is not correct. It is simple enough to check for the presence or
abscenss of `area=yes` prior to rendering. See an attempt at
https://github.com/gravitystorm/openstreetmap-carto/pull/3834 (Though
I now realize that this PR did not properly account for multipolygons
relations).

The problem with relying on `area=yes` for deciding how to render a
feature like a hedge or wall is two-fold:

1) The tag `area=yes` is only supposed to mean "this closed way is an
area, not a line", and is only used when this is not already obvious
from other tags.

It is not necessary to add `area=yes` when the closed way already has
a tag which defines an area, such as `landuse=forest` or
`natural=scrub` or `leisure=playground`: all of these keys are always
areas when mapped as closed ways, so they do not require `area=yes`,
whether or not `barrier=hedge` or `barrier=fence` is added.

This also means that `area=yes` is never needed when the same object
is turned into a multipolygon relation, so checking for `area=yes`
alone is not sufficient

A closed way with `hedge=barrier` + `natural=scrub` is an area, and
the presence or abscense of `area=yes` should not be required. This
makes this a poor tag to rely on for rendering decisions, at least for
a style that influences how mappers use tags.

2) Many hedges which were mapped like areas are currently missing
`area=yes` tags. In this comment
(https://github.com/gravitystorm/openstreetmap-carto/pull/3844#issuecomment-582692389)
you can see that over 90% of the `barrier=hedge` closed ways in a
Dutch province (random example) are missing `area=yes`, though they
appear to be mapping the outline/area of the hedge. This means that a
rendering solution that relies on `area=yes` would miss a large
percentage of hedges mapped in this way. The situation is worse for
barrier=wall.

Most likely, many mappers do not see why they should need to add a tag
like `area=yes` when they map a hedge as a closed way.

A better solution is to use different tags for linear features and
area features. This is the standard used in Openstreetmap for common
linear features such as paths, roads, railways and waterways: the area
and the line are different tags.

(The rare exception to the rule that the same tag isn't used for lines
and areas is for pedestrian plazas which are mapped with area=yes, but
in this case the idea is that there is no linear feature: the area
allows travel in "any" direction by pedestrians, so there is no "line"
to map, just the area. Yet there often is confusion about how
pedestrian highway areas should be mapped and how they differ from
area:highway=, so this cannot be considered a good example to emulate
in the future. )

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-06 Thread Marc Gemis
On Thu, Feb 6, 2020 at 5:27 PM Christoph Hormann  wrote:
>
> On Thursday 06 February 2020, Marc Gemis wrote:


>
> > And I want to end with a quote from {1]
> >
> > "My approach to this matter has been – from the beginning of my
> > contributions to OSM-Carto – to regard the role and task of the
> > project as mapper support without active steering."
> >
> > My feeling is that in this case that principle has been broken (I am
> > not going to repeat the arguments given here by the others in this
> > thread)
>
> Your feeling is wrong, possibly due to you misunderstanding the concept
> of mapper support.  Mapper support does not mean doing what the loudest
> mappers want you to do.  There are tons of nonsensical or
> non-verifiable tags loudly promoted by mappers.  Rendering such in
> OSM-Carto would not be mapper support, it would be sabotage.  Mapper
> support in style design primarily means - as i like to phrase it -
> supporting mappers in consistent use of tags.
>
> The irony here is that - as i mentioned in another mail - OSM-Carto is
> to a significant extent responsible for encouraging mappers to use this
> ambiguous tagging and we now get criticized for trying to fix this
> counterproductive incentive.

I still do not understand why area=yes is a bad tag. So far, the only
argument I have seen is that you have problems to implement it in your
workflow. Someone Else had to problem to implement it.

Area=yes is imho usefull for features that can be closed ways and
areas, such as hedges and a few other  barrier tags that were
mentioned in this thread. It makes no sense for
landcover/landuse/natural/leisure/amenity, which, AFAIK, cannot be
closed ways, but are always areas when represented by a closed
polygon.

So when area=yes is used in combination with barrier I expect the
polygon to be filled. The other people tat to the time to respond to
your question on what does the following mean to you, had the same
opinion.

So when barrier=hedge, landuse/amenity/leisure/natural/landcover and
area=yes are placed on the same closed way or multipolygon, the only
interpretation is that the hedge fills the area. This is probably
wrong, but it should still be rendered as such.

Even if there are a few 10k-100k of such instances, they can easily be
fixed with a Maproulette challenge..
This has been done before when the landuse=farm stopped rendering or
during the multi-polygon cleanup. Although the numbers might be of a
different order.

If OS carto-team would have chosen this route, the fix would have been
straightforward, though time-consuming. WIth your solution, people are
forced to come up with new tagging proposals for each of the barrier
types, go through the approval process and then start the retagging.

I have little hope that you will revert the change and take a
different approach. Given earlier discussions on landcover, I feel
that people trying to properly map green areas are left in the cold.
The approach seems to be take: one of the features that colours green,
then you are fine, do not bother about the details.

regards

m

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-06 Thread Daniel Koć
W dniu 06.02.2020 o 17:25, Christoph Hormann pisze:
> Rendering such in OSM-Carto would not be mapper support, it would be
> sabotage. 

As much as I disagree with you on what should be rendered or not (and
why), I understand how sure you are of you about your opinions. But the
thing that bothered me the most is using such word for what some other
people think is right.

There is an easy test one can apply when in doubt - how would you feel
if you heard this about your actions instead? Would it feel like neutral
and respectful to you? I don't feel like that.

There's also another, utilitarian consideration - do you expect it would
make someone with different point of view more willing to talk and find
a common ground or rather discouraged to do so? For me it's surely the
latter.


-- 
"Rzeczy się psują – zęby, spłuczki, kompy, związki, pralki" [Bisz]


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-06 Thread Christoph Hormann
On Thursday 06 February 2020, Marc Gemis wrote:
> > And please keep in mind that - as i mentioned - barrier=hedge is
> > not the dominant tag for mapping hedges with polygons in the first
> > place - as i have shown with various links earlier.
>
> I only clicked on a few of your examples and had to figure out which
> areas you meant. But they were outside of urban areas.

Yes, the vast majority of hedges that are currently mapped in OSM with 
polygons are in rural areas.

> As Paul Allen pointed out earlier none of your alternatives (forest,
> scrub) are a good match for those.

If you say so.  That is not a discussion i currently have an opinion on.  
Wooden plants in an urban environment for decorative purpose or as 
barriers for pedestrians come in a wide range of forms, especially if 
you consider different parts of earth in different climate zones.  I 
would not consider existing tags to be wrong for most of them but as 
already said a more specific verifiable characterization would 
certainly not hurt.

> And I want to end with a quote from {1]
>
> "My approach to this matter has been – from the beginning of my
> contributions to OSM-Carto – to regard the role and task of the
> project as mapper support without active steering."
>
> My feeling is that in this case that principle has been broken (I am
> not going to repeat the arguments given here by the others in this
> thread)

Your feeling is wrong, possibly due to you misunderstanding the concept 
of mapper support.  Mapper support does not mean doing what the loudest 
mappers want you to do.  There are tons of nonsensical or 
non-verifiable tags loudly promoted by mappers.  Rendering such in 
OSM-Carto would not be mapper support, it would be sabotage.  Mapper 
support in style design primarily means - as i like to phrase it - 
supporting mappers in consistent use of tags.

The irony here is that - as i mentioned in another mail - OSM-Carto is 
to a significant extent responsible for encouraging mappers to use this 
ambiguous tagging and we now get criticized for trying to fix this 
counterproductive incentive.

-- 
Christoph Hormann
http://www.imagico.de/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-06 Thread Peter Elderson
Joseph Eisenberg :

> 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`.
>

Zeeland, of all places... Most of Zeeland is water, dykes and polders.

Try Noord-Brabant, Zuid-Holland, Utrecht.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-06 Thread ael
On Wed, Feb 05, 2020 at 10:49:23PM -0600, Shawn K. Quinn wrote:
> On 2/5/20 17:15, Lionel Giard wrote:
> > In my usage, i always thought that using a barrier=* + any other main
> > tag was wrong and widely accepted (as i saw that it was separated in
> > most examples when i started mapping). Thus my method has always been to
> > map them separately (one way for the barrier and one way for the other
> > main tag, even if they are exactly sharing the same node). This is in
> > order to keep the one feature to one object and keep things manageable
> > and without ambiguity. Thus to me, all the examples of "barrier=*" (+
> > "area=yes" +) "leisure=playground" are a tagging error, that should be
> > two separate objects.
> 
> JOSM's validator will flag ways that share the same nodes as a warning,
> or at least it used to. I think it's just more rubbish in the database
> to have one way for the fence and another for an area when they share
> the same nodes.

-1

Sorry, but the trouble I have with editing places where nodes are shared
is ridiculous. Often I have updated information, usually accurate gps,
on one element, but not the others with shared nodes. It is painful,
time-consuming and tedious to have to separate the ways. Often I just
don't bother and risk degrading previous information. But if people will
share nodes, then it's too bad.


The overhead in the database of sometimes duplicate nodes is tiny.

ael


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Jeroen Hoek
On 06-02-20 05:22, Marc Gemis wrote:
> My interpretation is the same as Paul's. Including the not thought
> through part, as I never needed that.

Mine too.

There is only a subset of barrier-tags where `area=yes` makes sense,
like hedge and (city-)wall.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread John Willis via Tagging


> On Feb 6, 2020, at 5:14 AM, Jeroen Hoek  wrote:
> 
> Keeping the rendering for `barrier=hedge` plus `area=yes` for the time
> being seems sensible and in keeping with the general use of those two
> tags in combination.


+1

Javbw___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread John Willis via Tagging


> On Feb 3, 2020, at 10:09 PM, Paul Allen  wrote:
> 
> It isn't wrong to use barrier=hedge, since it does provide a visual
> barrier


It also provides a physical barrier. Try riding a bike through one, or sleeping 
on one, or taking a shortcut through one!

Hedges are physical barriers made of plants. people put them for decoration 
*and* to keep people out of many areas.

a hedge is any bushes that have been pruned into an ornamental barrier. they 
may be singular or plural. 

people, such as myself, micromap hedges in some areas. I don’t use them for 
trees or flowerbeds, but you will find plenty of hedges in a rose garden 
keeping people from taking shortcuts through the flowers. 

removing the rendering for area=yes on the hedge is a very poorly thought out 
decision. 

it should be reversed. 

Javbw


___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Shawn K. Quinn
On 2/5/20 17:15, Lionel Giard wrote:
> In my usage, i always thought that using a barrier=* + any other main
> tag was wrong and widely accepted (as i saw that it was separated in
> most examples when i started mapping). Thus my method has always been to
> map them separately (one way for the barrier and one way for the other
> main tag, even if they are exactly sharing the same node). This is in
> order to keep the one feature to one object and keep things manageable
> and without ambiguity. Thus to me, all the examples of "barrier=*" (+
> "area=yes" +) "leisure=playground" are a tagging error, that should be
> two separate objects.

JOSM's validator will flag ways that share the same nodes as a warning,
or at least it used to. I think it's just more rubbish in the database
to have one way for the fence and another for an area when they share
the same nodes.

-- 
Shawn K. Quinn 
http://www.rantroulette.com
http://www.skqrecordquest.com

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Marc Gemis
> And please keep in mind that - as i mentioned - barrier=hedge is not the
> dominant tag for mapping hedges with polygons in the first place - as i
> have shown with various links earlier.

I only clicked on a few of your examples and had to figure out which
areas you meant. But they were outside of urban areas. I used the
combination barrier=hedge; area=yes for micro mapping areas of hedges
in urban areas, e.g. near parking lots.
As Paul Allen pointed out earlier none of your alternatives (forest,
scrub) are a good match for those.

I accept that not a lot of people are mapping such objects yet. But,
as Joseph points out in another mail, there is a need to be able to
map all kinds of green areas inside build-up areas such areas of
hedges, flowerbeds, grass areas, and areas with a combination of them
and trees.

And I want to end with a quote from {1]

"My approach to this matter has been – from the beginning of my
contributions to OSM-Carto – to regard the role and task of the
project as mapper support without active steering."

My feeling is that in this case that principle has been broken (I am
not going to repeat the arguments given here by the others in this
thread)


regards


[1] 
http://blog.imagico.de/some-thoughts-on-the-roles-and-responsibilities-of-developers-and-project-maintainers-in-the-openstreetmap-community/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Marc Gemis
On Thu, Feb 6, 2020 at 12:16 AM Lionel Giard  wrote:
>
> In my usage, i always thought that using a barrier=* + any other main tag was 
> wrong and widely accepted (as i saw that it was separated in most examples 
> when i started mapping). Thus my method has always been to map them 
> separately (one way for the barrier and one way for the other main tag, even 
> if they are exactly sharing the same node). This is in order to keep the one 
> feature to one object and keep things manageable and without ambiguity. Thus 
> to me, all the examples of "barrier=*" (+ "area=yes" +) "leisure=playground" 
> are a tagging error, that should be two separate objects.

That's exactly what I do as well.

m.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Marc Gemis
My interpretation is the same as Paul's. Including the not thought
through part, as I never needed that.

On Wed, Feb 5, 2020 at 10:24 PM Paul Allen  wrote:
>
> On Wed, 5 Feb 2020 at 21:09, Christoph Hormann  wrote:
>>
>>
>> closed way, barrier=fence
>
>
> Linear fence
>
>> closed way, barrier=fence, area=yes
>
>
> Not sensible.  Fences are linear structures.  Tagging error.
>
>> closed way, barrier=fence, leisure=playground
>
>
> Playground with a fence around it.
>
>> closed way, barrier=fence, leisure=playground, area=yes
>
>
> Tagging error.  Interpretable as a playground with a fence around it if
> you want to special-case it, but probably not worth the effort.
>>
>>
>> multipolygon, barrier=fence
>> multipolygon, barrier=fence, area=yes
>> multipolygon, barrier=fence, leisure=playground
>> multipolygon, barrier=fence, leisure=playground, area=yes
>
>
> Not sure.  Never needed to do that, not really thought through the
> implications.
>
>> closed way, barrier=hedge
>
>
> Linear hedge.
>
>> closed way, barrier=hedge, area=yes
>
>
> Area hedge.
>
>> closed way, barrier=hedge, leisure=playground
>
>
> Playground with a hedge around it.
>
>> closed way, barrier=hedge, leisure=playground, area=yes
>
>
> Tagging error.  Could be handled by ignoring area=yes if you want to
> special-case it, probably not worth the effort.
>>
>>
>> multipolygon, barrier=hedge
>> multipolygon, barrier=hedge, area=yes
>> multipolygon, barrier=hedge, leisure=playground
>
>
> As above, but with holes in the area hedge or the playground, if there are
> interior polygons.
>
>> multipolygon, barrier=hedge, leisure=playground, area=yes
>
>
> Tagging error, as above.
>
>> closed way, barrier=ditch, waterway=ditch
>> closed way, barrier=ditch, waterway=ditch, area=yes
>> closed way, barrier=ditch, waterway=ditch, leisure=playground
>> closed way, barrier=ditch, waterway=ditch, leisure=playground, area=yes
>
>
> As for hedge, not for fence.  Ditches can have a significant width.  There's
> a dry ditch I know of that is part of a castle fortification where the ditch 
> is as
> broad as it is long that could usefully be handled that way (specifying a 
> ditch with a
> width doesn't render as a wide ditch).
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Joseph Eisenberg
> In my usage, i always thought that using a barrier=* + any other main tag was 
> wrong...

I agree that this usage is ambiguous. However, that usage is very
common, 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

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.

I will discuss these particular examples further at github where I can
post images (see. Also please discuss the particular
Openstreetmap-carto rendering issues there
(https://github.com/gravitystorm/openstreetmap-carto/pull/3844), after
reading through the relevant history. We did try just rendering hedges
with area=yes first, but this did not work:
https://github.com/gravitystorm/openstreetmap-carto/pull/3834 - read
this first.

Here on this mailing list we should try to focus on how to tag and map things.

For example, perhaps someone can make a reasonable proposal for how to
map small  areas of pruned and trimmed bushes and shrubs: often these
are currently mapped as natural=scrub or leisure=garden, but perhaps a
new, more specific tag would be better?

The natural vegetation tags like natural=scrub, natural=heath and
natural=wood could also be improved by additional property tags which
described the density of the vegetation (e.g. are there wide gaps
between the tallest plants, or is there a continuous canopy?).

It could also be considered to go back to using `fenced=yes` along
with `walled=yes` and `hedged=yes` as a "property tag" to go with a
feature like a playground or meadow, but this would require a huge
amount of re-tagging.

What doesn't make sense is trying to use the same tag to describe a
linear feature like a road, barrier or waterway, and also for the area
of that same feature. In all other cases we use a different tag for
the area:

* waterway=river + waterway=riverbank
* highway= + area:highway=
* railway= + 

Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Lionel Giard
In my usage, i always thought that using a barrier=* + any other main tag
was wrong and widely accepted (as i saw that it was separated in most
examples when i started mapping). Thus my method has always been to map
them separately (one way for the barrier and one way for the other main
tag, even if they are exactly sharing the same node). This is in order to
keep the one feature to one object and keep things manageable and without
ambiguity. Thus to me, all the examples of "barrier=*" (+ "area=yes" +)
"leisure=playground" are a tagging error, that should be two separate
objects.

If it is a tagging error, then we don't need to remove the rendering, it
just need to be corrected on the data side by mappers. Am i wrong in
thinking that ?

Le mer. 5 févr. 2020 à 22:43, marc marc  a
écrit :

> Le 05.02.20 à 22:08, Christoph Hormann a écrit :
> > (either 'invalid', '1d barrier' or '2d barrier'):
>
> Here is my view AND I known that osm consensus is not that :
>
> > closed way, barrier=fence
>
> 1d barrier
>
> > closed way, barrier=fence, area=yes
>
> 2d barrier
>
> > closed way, barrier=fence, leisure=playground
>
> bad idea
>
> > closed way, barrier=fence, leisure=playground, area=yes
>
> 2d barrier
>
> > multipolygon, barrier=fence
>
> 2d barrier
>
> > multipolygon, barrier=fence, area=yes
>
> 2d barrier
>
> > multipolygon, barrier=fence, leisure=playground
>
> 2d barrier
>
> > multipolygon, barrier=fence, leisure=playground, area=yes
>
> 2d barrier
>
> > closed way, barrier=hedge
>
> 1d barrier
>
> > closed way, barrier=hedge, area=yes
>
> 2d barrier
>
> > closed way, barrier=hedge, leisure=playground
>
> 2d barrier
>
> > closed way, barrier=hedge, leisure=playground, area=yes
>
> 2d barrier
>
> > multipolygon, barrier=hedge
> > multipolygon, barrier=hedge, area=yes
> > multipolygon, barrier=hedge, leisure=playground
> > multipolygon, barrier=hedge, leisure=playground, area=yes
>
> all : 2d barrier
>
> > closed way, barrier=ditch, waterway=ditch
> > closed way, barrier=ditch, waterway=ditch, area=yes
> > closed way, barrier=ditch, waterway=ditch, leisure=playground
> > closed way, barrier=ditch, waterway=ditch, leisure=playground, area=yes
>
> all : same as for barrier=hedge
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread marc marc
Le 05.02.20 à 22:08, Christoph Hormann a écrit :
> (either 'invalid', '1d barrier' or '2d barrier'):

Here is my view AND I known that osm consensus is not that :

> closed way, barrier=fence

1d barrier

> closed way, barrier=fence, area=yes

2d barrier

> closed way, barrier=fence, leisure=playground

bad idea

> closed way, barrier=fence, leisure=playground, area=yes

2d barrier

> multipolygon, barrier=fence

2d barrier

> multipolygon, barrier=fence, area=yes

2d barrier

> multipolygon, barrier=fence, leisure=playground

2d barrier

> multipolygon, barrier=fence, leisure=playground, area=yes

2d barrier

> closed way, barrier=hedge

1d barrier

> closed way, barrier=hedge, area=yes

2d barrier

> closed way, barrier=hedge, leisure=playground

2d barrier

> closed way, barrier=hedge, leisure=playground, area=yes

2d barrier

> multipolygon, barrier=hedge
> multipolygon, barrier=hedge, area=yes
> multipolygon, barrier=hedge, leisure=playground
> multipolygon, barrier=hedge, leisure=playground, area=yes

all : 2d barrier

> closed way, barrier=ditch, waterway=ditch
> closed way, barrier=ditch, waterway=ditch, area=yes
> closed way, barrier=ditch, waterway=ditch, leisure=playground
> closed way, barrier=ditch, waterway=ditch, leisure=playground, area=yes

all : same as for barrier=hedge
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Christoph Hormann
On Wednesday 05 February 2020, Andy Townsend wrote:
>
> What would help make the data clearer (regardless of this
> discussion).  For example, https://overpass-turbo.eu/s/QqU is where
> the same object is used to represent both an amenity and a hedge in
> most of England and Wales.  There are only 12 polygons in that list -
> not beyond the bounds of manual fixing.  A similar query covering
> most of The Netherlands https://overpass-turbo.eu/s/QqV gets only 2
> polygons.  Looking for combinations of "landuse" will get more, but
> not that many more: 44 https://overpass-turbo.eu/s/QqW .

There are currently at least about 10k ways with barrier=hedge and a 
landuse=* or leisure=* tag - most of which are probably closed ways 
(though i have not checked).

And please keep in mind that - as i mentioned - barrier=hedge is not the 
dominant tag for mapping hedges with polygons in the first place - as i 
have shown with various links earlier.

-- 
Christoph Hormann
http://www.imagico.de/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Paul Allen
On Wed, 5 Feb 2020 at 21:09, Christoph Hormann  wrote:

>
> closed way, barrier=fence
>

Linear fence

closed way, barrier=fence, area=yes
>

Not sensible.  Fences are linear structures.  Tagging error.

closed way, barrier=fence, leisure=playground
>

Playground with a fence around it.

closed way, barrier=fence, leisure=playground, area=yes
>

Tagging error.  Interpretable as a playground with a fence around it if
you want to special-case it, but probably not worth the effort.

>
> multipolygon, barrier=fence
> multipolygon, barrier=fence, area=yes
> multipolygon, barrier=fence, leisure=playground
> multipolygon, barrier=fence, leisure=playground, area=yes
>

Not sure.  Never needed to do that, not really thought through the
implications.

closed way, barrier=hedge
>

Linear hedge.

closed way, barrier=hedge, area=yes
>

Area hedge.

closed way, barrier=hedge, leisure=playground
>

Playground with a hedge around it.

closed way, barrier=hedge, leisure=playground, area=yes
>

Tagging error.  Could be handled by ignoring area=yes if you want to
special-case it, probably not worth the effort.

>
> multipolygon, barrier=hedge
> multipolygon, barrier=hedge, area=yes
> multipolygon, barrier=hedge, leisure=playground
>

As above, but with holes in the area hedge or the playground, if there are
interior polygons.

multipolygon, barrier=hedge, leisure=playground, area=yes
>

Tagging error, as above.

closed way, barrier=ditch, waterway=ditch
> closed way, barrier=ditch, waterway=ditch, area=yes
> closed way, barrier=ditch, waterway=ditch, leisure=playground
> closed way, barrier=ditch, waterway=ditch, leisure=playground, area=yes
>

As for hedge, not for fence.  Ditches can have a significant width.  There's
a dry ditch I know of that is part of a castle fortification where the
ditch is as
broad as it is long that could usefully be handled that way (specifying a
ditch with a
width doesn't render as a wide ditch).

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Christoph Hormann
On Wednesday 05 February 2020, Paul Allen wrote:
>
> > disagreement about the meaning of certain tagging to in case of
> > doubt opt for not rendering something compared to rendering
> > something in a potentially misleading way.  That would mean
> > following Paul's
>
> Ummm, wasn't me.  I don't recall seeing another Paul post on this on
> the tagging list, but I don't always pay full attention to the
> identities of posters.

Oh, sorry - i meant Paul Norman on the OSM-Carto issue tracker.

-- 
Christoph Hormann
http://www.imagico.de/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Paul Allen
On Wed, 5 Feb 2020 at 20:55, Christoph Hormann  wrote:

I am generally inclined to follow the principle in case there is
> disagreement about the meaning of certain tagging to in case of doubt
> opt for not rendering something compared to rendering something in a
> potentially misleading way.  That would mean following Paul's
>

Ummm, wasn't me.  I don't recall seeing another Paul post on this on
the tagging list, but I don't always pay full attention to the identities of
posters.

suggestion here and dropping rendering of barrier=* on polygons all
> together.
>
> Do you think this would be an improvement compared to the current
> rendering?
>

Nope.  That would make matters even worse.  We have mappers who lazily
apply barrier=hedge to things like leisure=park and, not unreasonably,
expect it to render.  Given how hard it is in iD to deal with multiple
objects having the same outlines, it's not entirely laziness either.  If
iD allowed a method (such as shift-click) to cycle through mutliple
objects that have overlapped ways, this wouldn't be so much of a
p;roblem.  But we have what we have.  Breaking it in carto would
mean a lot of retagging to fix things, and a lot of maintenance hassle
unless iD extends its functionality.  Don't even think about it until
and unless iD can handle what we'd have to do instead.

We also have mappers who, following instructions in the wiki, used
barrier=hedge + area=yes to deal with specific situations, and carto
has just broken that.  The justification for this breakage appears to
be that some people have done things like leisure=park +
barrier=hedge + area=yes.  This usage is the actual problem.
Somebody else suggested rendering that as a hedge area (or
even in red) to show it is a tagging error.

So far the approach seems to have been "some things are mistagged so
let's break the rendering for both them and lots of other things that aren't
mistagged" followed by "You seem unhappy with that, so how about we
break even more things?"

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Christoph Hormann

Not replying to anyone in particular but it seems there is a lot of 
dysfunctional communication here due to people focusing on something 
very specific without making up their mind (or at least not 
communicating their view) on the overall subject of the semantics of 
barrier mapping.

Therefore i would like to suggest everyone who presents their opinion on 
the matter here to - for clarity of everyone else - state what they 
think the semantics of barrier mapping are supposed to be.  That means 
assigning to each of the mapping scenarios in the following a meaning 
(either 'invalid', '1d barrier' or '2d barrier'):

closed way, barrier=fence
closed way, barrier=fence, area=yes
closed way, barrier=fence, leisure=playground
closed way, barrier=fence, leisure=playground, area=yes

multipolygon, barrier=fence
multipolygon, barrier=fence, area=yes
multipolygon, barrier=fence, leisure=playground
multipolygon, barrier=fence, leisure=playground, area=yes

closed way, barrier=hedge
closed way, barrier=hedge, area=yes
closed way, barrier=hedge, leisure=playground
closed way, barrier=hedge, leisure=playground, area=yes

multipolygon, barrier=hedge
multipolygon, barrier=hedge, area=yes
multipolygon, barrier=hedge, leisure=playground
multipolygon, barrier=hedge, leisure=playground, area=yes

closed way, barrier=ditch, waterway=ditch
closed way, barrier=ditch, waterway=ditch, area=yes
closed way, barrier=ditch, waterway=ditch, leisure=playground
closed way, barrier=ditch, waterway=ditch, leisure=playground, area=yes


-- 
Christoph Hormann
http://www.imagico.de/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Andy Townsend

On 05/02/2020 19:17, Christoph Hormann wrote:

- in other words: Special casing exactly the situation in question to
be treated as an exception.


Hedges historically were treated as areas if appropriate, whereas other 
barriers were not.


https://github.com/gravitystorm/openstreetmap-carto/blob/0fac157a650b25844806f3f49fc65432751da38d/landcover.mss#L710

is from a couple of years ago.  I'm not sure when OSM Carto changed its 
mind on them - I must have missed the memo.


You could perhaps ask "why were hedges special-cased in the first 
place", but the answer's pretty obvious - a hedge more often has a 
significant mappable width than a fence.


What would help make the data clearer (regardless of this discussion).  
For example, https://overpass-turbo.eu/s/QqU is where the same object is 
used to represent both an amenity and a hedge in most of England and 
Wales.  There are only 12 polygons in that list - not beyond the bounds 
of manual fixing.  A similar query covering most of The Netherlands 
https://overpass-turbo.eu/s/QqV gets only 2 polygons.  Looking for 
combinations of "landuse" will get more, but not that many more: 44  
https://overpass-turbo.eu/s/QqW .


Once the small amount of double-tagged data is fixed, OSM Carto will be 
free to represent hedges as mappers had always intended.


Best Regards,

Andy




___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Christoph Hormann
On Wednesday 05 February 2020, Jeroen Hoek wrote:
> > But that is not in any way sustainable and it would be highly
> > confusing for mappers because the conditions resulting in this
> > rendering would be unique and could not be derived from any general
> > principles.
>
> I understand the reasoning, but what mappers see now is:
> > You thought you could map hedges as areas using `area=yes`, the
> > wiki told you that, and you've seen it done like that everywhere,
> > but it was wrong, there is no way to map hedges as areas, and all
> > those hedges you and your fellow mapper mapped are now tens of
> > thousands of errors on the map.
>
> That is, to put it mildly, quite confusing, not to mention
> disheartening.

I understand and agree (not on there being no way to map hedges with 
polygons though - i have commented on that already) and although as you 
mentioned this is not fully the fault of osm-carto (you mentioned the 
wiki, editors are another culprit) osm-carto previously communicating 
to mappers this to be correct tagging has a huge part in creating this 
confusion.  But having made an error in the past does not mean we need 
to carry it indefinitely into the future.

I am generally inclined to follow the principle in case there is 
disagreement about the meaning of certain tagging to in case of doubt 
opt for not rendering something compared to rendering something in a 
potentially misleading way.  That would mean following Paul's 
suggestion here and dropping rendering of barrier=* on polygons all 
together.

Do you think this would be an improvement compared to the current 
rendering?

-- 
Christoph Hormann
http://www.imagico.de/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Jeroen Hoek
On 05-02-20 20:17, Christoph Hormann wrote:
> But that is not in any way sustainable and it would be highly 
> confusing for mappers because the conditions resulting in this 
> rendering would be unique and could not be derived from any general 
> principles.

I understand the reasoning, but what mappers see now is:

> You thought you could map hedges as areas using `area=yes`, the wiki
> told you that, and you've seen it done like that everywhere, but
> it was wrong, there is no way to map hedges as areas, and all those
> hedges you and your fellow mapper mapped are now tens of thousands
> of errors on the map.

That is, to put it mildly, quite confusing, not to mention
disheartening. It will also result in less-involved mappers remapping
the damage by turning hedges into scrub on the map. The only
alternatives are redrawing them as linear features (losing detail in the
process, and feeling like a massive waste of time) or removing them
completely.

Surely we can come up with a more constructive way forward?

Keeping the rendering for `barrier=hedge` plus `area=yes` for the time
being seems sensible and in keeping with the general use of those two
tags in combination.

If a tagging can be agreed on that can work for several applicable
barrier-values mapped as areas, then that can gradually replace the
`area=yes`-way for hedges. At some point the rendering for the old way
can be turned off to help mappers migrate, but there has to be some
overlap in time.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Philip Barnes
On Wednesday, 5 February 2020, Martin Koppenhoefer wrote:
> 
> 
> sent from a phone
> 
> > Il giorno 5 feb 2020, alle ore 16:11, Paul Allen  ha 
> > scritto:
> > 
> > 4) Where the only tags are barrier=hedge + area=yes then render
> > as before,
> 
> 
> +1, any object with area=yes should be considered an area.
> 
> 
> > a hedge that has area.  This would exclude the cases like 
> > leisure=park + barrier=hedge which is a non-preferred way of
> > mapping a park with a hedge around it. 
> 
> 
> IMHO, area objects (like leisure=park) with barrier=hedge should display as 
> area hedges to demonstrate the problematic tagging ambiguity.
> 
> Cheers Martin 
+100

Phil (trigpoint)

 ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

-- 
Sent from my Sailfish device
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Martin Koppenhoefer


sent from a phone

> Il giorno 5 feb 2020, alle ore 16:11, Paul Allen  ha 
> scritto:
> 
> 4) Where the only tags are barrier=hedge + area=yes then render
> as before,


+1, any object with area=yes should be considered an area.


> a hedge that has area.  This would exclude the cases like 
> leisure=park + barrier=hedge which is a non-preferred way of
> mapping a park with a hedge around it. 


IMHO, area objects (like leisure=park) with barrier=hedge should display as 
area hedges to demonstrate the problematic tagging ambiguity.

Cheers Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread marc marc
Le 05.02.20 à 18:41, Andy Townsend a écrit :
> On 05/02/2020 17:24, Christoph Hormann wrote:
> About the "removing tags where they may clash" point

> "if something is mapped as a brewery and also as
> tourist attraction, remove the tourist attraction tags

if osm-carto goal is to trying to give a feedback to mapper,
I'm more fan for a tule "fill it with a flashing red and don't render
any other tag" :)

of course, it need that an alternative exist (mapping 2 objets, one for
the area, another for the barrier is fine, but does a style use it ?
another alternative is to use a subtag, for ex fenced=* oups no,
it's deprecated
https://wiki.openstreetmap.org/wiki/Key:fenced
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Christoph Hormann
On Wednesday 05 February 2020, Andy Townsend wrote:
> [...]
>
> Basically it's saying "if something is mapped as a brewery and also
> as tourist attraction, remove the tourist attraction tags prior to
> rendering so the renderer renders it as a brewery, not a tourist
> attraction".
>
> Obviously a decision has to be made which of the two tags to render
> if either potentially could - either by layer order or by explicitly
> ensuring that one does and one doesn't, which I've done here.

But that is not the problem here - barriers are rendered after the 
landcover layer both in the past and now.

There is no technical difficulty in doing what Jeroen wants to do by 
re-adding a separate area-barriers layer with something like 

(SELECT way,
barrier
  FROM planet_osm_polygon
  WHERE (barrier IN ('hedge')
AND tags->'area' IN ('yes')
AND osm_id > 0
AND building IS NULL
) AS area_barriers

and adding a condition to the polygon subquery of the barriers layer 
along the lines of

NOT (barrier IN ('hedge')
  AND tags->'area' IN ('yes')
  AND osm_id > 0)

- in other words:  Special casing exactly the situation in question to 
be treated as an exception.  But that is not in any way sustainable and 
it would be highly confusing for mappers because the conditions 
resulting in this rendering would be unique and could not be derived 
from any general principles.  Mappers would rightfully ask:

* why does turning a closed way tagged barrier=hedge + area=yes into a 
multipolygon releation (for adding an interior ring) change rendering?
* why does removing the unnecessary area=yes from a closed way tagged 
barrier=hedge + area=yes + leisure=playground change the rendering?

-- 
Christoph Hormann
http://www.imagico.de/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Sarah Hoffmann
On Wed, Feb 05, 2020 at 05:28:03PM +0100, Christoph Hormann wrote:
> On Wednesday 05 February 2020, Jeroen Hoek wrote:
> > > the semantic ambiguity of the > 350k cases where barrier tags are
> > > currently used as a secondary tag on landuse/leisure/etc. polygons
> > > to incidate the polygon is enclosed by a linear barrier.
> >
> > The PR specifically removes the filled rendering from `barrier=hedge`
> > mapped with `area=yes` from 36665 hedges.
> 
> No, it does not, the PR removes the fill rendering of all *polygons* 
> tagged barrier=hedge.  This includes closed ways with barrier=hedge and 
> area=yes, closed ways with barrier=hedge and a different tag implying a 
> polygon and also multipolygons.  I explained the way the renderer 
> interprets the data in the PR discussion.  Understanding this and 
> understanding the current meaning of the area=yes tag is *essential* 
> for understanding the reasoning behind this change.

area=yes is a secondary tag that has the meaning "the way it is
on is an area, no matter what any other tag suggests". So clearly,
if something is tagged barrier=hedge+area=yes, it must be a hedge
mapped as an area. Our current interpretation of the tag leaves
no room for interpretation here.

The more interesting case is barrier+landuse. You argue that the
presence of landuse makes the entire OSM way a polygon. I know
that osm2pgsql implements it this way but I don't think that is
entirely correct. barrier and landuse are two main tags. The
rules what happens, when an OSM object has two main tags are a
bit on the fuzzy side. In general we have interpreted it as a short
cut for: there are essentially two objects that share the
geometry and the secondary tags. That does not mean that one
main tag inherites all the implicit assumptions of the other
main tag. So in this case a barrier does not automatically
inherit the implicit area=yes of the landuse tag.

In this interpretation the landuse inherently is a polygon,
the barrier inherently a line feature.

> What you essentially want is for barrier=hedge on polygons to have a 
> different meaning depending on the presence of area=yes.  Given the 
> very specific and highly significant technical meaning of area=* 
> overloading it with additional more specialized meanings w.r.t. 
> specific tags seems a very bad idea to me.

I don't understand what the special case here is. area=yes makes
a feature a polygon. Always. It doesn't matter what the main tag
is. It just means that the object has been mapped in two dimensions
instead of the usual one.

> I never claimed it to be.  What i did say is that what is mapped with 
> barrier=hedge on polygons with a different meaning than 'this polygon 
> is enclosed by a hedge' is elsewhere predominantly mapped with 
> natural=scrub/wood or landuse=forest.  I demonstrated this with links 
> to various places.

No, the meaning of a barrier=hedge on a closed way without area=yes
is exactly the same as for a barrier on a non-closed way:
there is a hedge that follows the path of the line. The fact
that the line meets at its ends is not relevant for the interpretation.

Sarah

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Andy Townsend


On 05/02/2020 17:24, Christoph Hormann wrote:

With "only feasible alternative" i means the only alternative that has
even a remote chance for consensus among the maintainers.


Ah! OK - that's much more understandable.

About the "removing tags where they may clash" point, here's an example:

https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/master/style.lua#L4767

(that's in lua, which may not be appropriate for OSM Carto, but I'm sure 
that something similar could be done as a regular SQL Select)


Basically it's saying "if something is mapped as a brewery and also as 
tourist attraction, remove the tourist attraction tags prior to 
rendering so the renderer renders it as a brewery, not a tourist 
attraction".


Obviously a decision has to be made which of the two tags to render if 
either potentially could - either by layer order or by explicitly 
ensuring that one does and one doesn't, which I've done here.


Best Regards,

Andy





___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Christoph Hormann
On Wednesday 05 February 2020, Andy Townsend wrote:
> > As explained there the only feasible alternative would be to stop
> > rendering barrier tags on polygon features universally.
>
> No, it's not the only alternative - another would be "where there are
> conflicting tags, decide which one to render". 

I don't quite understand, you will have to elaborate.

> There may be good 
> reasons for not doing that, but to claim this is the "only feasible
> alternative" doesn't seem correct to me.

With "only feasible alternative" i means the only alternative that has 
even a remote chance for consensus among the maintainers.

-- 
Christoph Hormann
http://www.imagico.de/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Andy Townsend

On 05/02/2020 14:46, Christoph Hormann wrote:

On Wednesday 05 February 2020, Andy Townsend wrote:

It doesn't sound like a tagging issue to me; I'd suggest that the
renderer that made this change did so in error.  Is using a different
renderer an option until it is fixed (perhaps the Humanitarian tiles
linked from openstreetmap.org)?

The change in rendering is intentional.  Is has been explained in:

https://github.com/gravitystorm/openstreetmap-carto/pull/3844

As explained there the only feasible alternative would be to stop
rendering barrier tags on polygon features universally.


No, it's not the only alternative - another would be "where there are 
conflicting tags, decide which one to render".  There may be good 
reasons for not doing that, but to claim this is the "only feasible 
alternative" doesn't seem correct to me.


I'm fully aware of the issue having dealt with it myself (and agree that 
area=yes per se is something of a red herring), but it does seem odd 
that of the examples at 
https://github.com/gravitystorm/openstreetmap-carto/pull/3844 3 of the 5 
are clearly rendered incorrectly _after_ the PR but were correct _before_.


Obviously the people developing the style are the ones putting the time 
in and can take it in any direction they choose, but sometimes the 
reason for the direction taken is a bit unclear.


Best Regards,

Andy



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Paul Allen
On Wed, 5 Feb 2020 at 16:29, Christoph Hormann  wrote:

> > A hedge is not the same as bushes or trees.
>
> I never claimed it to be.  What i did say is that what is mapped with
> barrier=hedge on polygons with a different meaning than 'this polygon
> is enclosed by a hedge' is elsewhere predominantly mapped with
> natural=scrub/wood or landuse=forest.  I demonstrated this with links
> to various places.
>
> Introducing a secondary tag to natural=scrub/wood and landuse=forest
> (like barrier=yes) indicating that it is impassible without difficulty
> would be a good idea


Not so good an idea.  A hedge area differs from natural=scrub/wood
or landuse=forest in at least one way, other than just by being impassable.
There is the matter of height.  Although newly-planted trees may be shorter
than a typical hedge, those trees will soon be much taller than the hedge
but the hedge will be maintained at a lower height.  Scrub, too, may
become taller than a hedge, or may be a mix of heights, depending upon
the mix of species.  Area hedges have a maintained height and are
usually of a single species, or mix of two species, not a random
selection of many species.

If you're prepared to go down the route of an additional tag or value,
then landcover=hedge is a cleaner way to go.  I'm not opposed to
having something like passability=* for use on actual forest or
actual scrub, but I'm not happy with using it to mean "This scrub
isn't really scrub, it's a hedge."

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Christoph Hormann
On Wednesday 05 February 2020, Jeroen Hoek wrote:
> > the semantic ambiguity of the > 350k cases where barrier tags are
> > currently used as a secondary tag on landuse/leisure/etc. polygons
> > to incidate the polygon is enclosed by a linear barrier.
>
> The PR specifically removes the filled rendering from `barrier=hedge`
> mapped with `area=yes` from 36665 hedges.

No, it does not, the PR removes the fill rendering of all *polygons* 
tagged barrier=hedge.  This includes closed ways with barrier=hedge and 
area=yes, closed ways with barrier=hedge and a different tag implying a 
polygon and also multipolygons.  I explained the way the renderer 
interprets the data in the PR discussion.  Understanding this and 
understanding the current meaning of the area=yes tag is *essential* 
for understanding the reasoning behind this change.

What you essentially want is for barrier=hedge on polygons to have a 
different meaning depending on the presence of area=yes.  Given the 
very specific and highly significant technical meaning of area=* 
overloading it with additional more specialized meanings w.r.t. 
specific tags seems a very bad idea to me.

> A hedge is not the same as bushes or trees.

I never claimed it to be.  What i did say is that what is mapped with 
barrier=hedge on polygons with a different meaning than 'this polygon 
is enclosed by a hedge' is elsewhere predominantly mapped with 
natural=scrub/wood or landuse=forest.  I demonstrated this with links 
to various places.

Introducing a secondary tag to natural=scrub/wood and landuse=forest 
(like barrier=yes) indicating that it is impassible without difficulty 
would be a good idea and i would support rendering such in OSM-Carto as 
a variation of the rendering we currently have for those if it is being 
used consistently by mappers.

-- 
Christoph Hormann
http://www.imagico.de/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Peter Elderson
+1

Mvg Peter Elderson

> Op 5 feb. 2020 om 16:37 heeft Jeroen Hoek  het volgende 
> geschreven:
> 
> On 05-02-2020 16:10, Paul Allen wrote:
>> 4) Where the only tags are barrier=hedge + area=yes then render
>> as before, a hedge that has area.  
> 
> There are some additional tags that should be allowed for. Including
> (mainly?) `height=*`.
> 
>> 5) Introduce, and render, landcover=hedge so we can tag an object
>> as landcover=hedge + barrier=hedge.
> 
> That is actually a neat solution too.
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Peter Elderson
Are there many correctly tagged features with the combi barrier=hedge & 
area=yes where area=yes could be meant to specify something else than the 
hedge? Most polygon features are implicit areas, I think?

Peter Elderson

> Op 5 feb. 2020 om 16:22 heeft Jeroen Hoek  het volgende 
> geschreven:
> 
> On 05-02-2020 15:46, Christoph Hormann wrote:
>> the semantic ambiguity of the > 350k cases where barrier tags are currently 
>> used as a secondary tag on 
>> landuse/leisure/etc. polygons to incidate the polygon is enclosed by a 
>> linear barrier.
> 
> The PR specifically removes the filled rendering from `barrier=hedge`
> mapped with `area=yes` from 36665 hedges.
> 
> There are 36665 hedges mapped with `area=yes`. These appear to be mostly
> used for hedges drawn as an area, which follows the existing documented
> convention. The PR effectively deprecates the combination of
> `barrier=hedge` plus `area=yes` for hedges drawn as areas, because
> `area=yes` may have been intended for one of the other tags on that
> entity (which breaks the 'one feature, one object' good practice),
> without providing an alternative.
> 
> No one is disputing that `barrier=hedge` on a polygon without `area=yes`
> should not be considered a filled area. That part of the PR is good and
> does not break the existing convention.
> 
>> it should be noted that barrier=hedge is currently 
>> not the dominant method of mapping strips of trees or bushes with 
>> polygons
> A hedge is not the same as bushes or trees. Where bushes or clumps of
> trees may form some sort of barrier (although you can often barge
> through them), hedges predominantly are.
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Jeroen Hoek
On 05-02-2020 16:10, Paul Allen wrote:
> 4) Where the only tags are barrier=hedge + area=yes then render
> as before, a hedge that has area.  

There are some additional tags that should be allowed for. Including
(mainly?) `height=*`.

> 5) Introduce, and render, landcover=hedge so we can tag an object
> as landcover=hedge + barrier=hedge.

That is actually a neat solution too.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Jeroen Hoek
On 05-02-2020 15:46, Christoph Hormann wrote:
> the semantic ambiguity of the > 350k cases where barrier tags are currently 
> used as a secondary tag on 
> landuse/leisure/etc. polygons to incidate the polygon is enclosed by a 
> linear barrier.

The PR specifically removes the filled rendering from `barrier=hedge`
mapped with `area=yes` from 36665 hedges.

There are 36665 hedges mapped with `area=yes`. These appear to be mostly
used for hedges drawn as an area, which follows the existing documented
convention. The PR effectively deprecates the combination of
`barrier=hedge` plus `area=yes` for hedges drawn as areas, because
`area=yes` may have been intended for one of the other tags on that
entity (which breaks the 'one feature, one object' good practice),
without providing an alternative.

No one is disputing that `barrier=hedge` on a polygon without `area=yes`
should not be considered a filled area. That part of the PR is good and
does not break the existing convention.

> it should be noted that barrier=hedge is currently 
> not the dominant method of mapping strips of trees or bushes with 
> polygons
A hedge is not the same as bushes or trees. Where bushes or clumps of
trees may form some sort of barrier (although you can often barge
through them), hedges predominantly are.

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Paul Allen
On Wed, 5 Feb 2020 at 14:48, Christoph Hormann  wrote:

>
> 1) remove all rendering of barrier tags on polygons
> 2) mappers in a concerted effort resolving the semantic ambiguity of the
> >350k cases where barrier tags are currently used as a secondary tag on
> landuse/leisure/etc. polygons to incidate the polygon is enclosed by a
> linear barrier.
> 3) (re-)introducing the rendering of barrier polygons with a fill where
> this is consistently used tagging.
>

4) Where the only tags are barrier=hedge + area=yes then render
as before, a hedge that has area.  This would exclude the cases like
leisure=park + barrier=hedge which is a non-preferred way of
mapping a park with a hedge around it.  Maybe that's what you
meant in your point 3, but it didn't read that way to me.

5) Introduce, and render, landcover=hedge so we can tag an object
as landcover=hedge + barrier=hedge.  It would be sub-optimal
to use landcover=scrub or landcover=heath because the bushes
in those are not so close together as to form a barrier.  You might
be able to squeeze through a gap in a hedge and then walk through
scrubland or heathland, but you're not going to be able to do that here:
https://goo.gl/maps/52wy5CAAVgXeMfXZ6  Not only are there no
spaces between the bushes, they have thorns.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Christoph Hormann
On Wednesday 05 February 2020, Andy Townsend wrote:
>
> It doesn't sound like a tagging issue to me; I'd suggest that the
> renderer that made this change did so in error.  Is using a different
> renderer an option until it is fixed (perhaps the Humanitarian tiles
> linked from openstreetmap.org)?

The change in rendering is intentional.  Is has been explained in:

https://github.com/gravitystorm/openstreetmap-carto/pull/3844

As explained there the only feasible alternative would be to stop 
rendering barrier tags on polygon features universally.

I know that for a mapper who has used this kind of tagging in the past 
unaware of its inherent ambiguity it seems weird that this is ambiguous 
tagging because in isolation it seems clear what it means.  But within 
the overall data model and overall consistency in tagging 
interpretation it is.

If there is a consensus in the community about it the following approach 
would in theory allow ultimately re-introducing the rendering some are 
missing now:

1) remove all rendering of barrier tags on polygons
2) mappers in a concerted effort resolving the semantic ambiguity of the 
>350k cases where barrier tags are currently used as a secondary tag on 
landuse/leisure/etc. polygons to incidate the polygon is enclosed by a 
linear barrier.
3) (re-)introducing the rendering of barrier polygons with a fill where 
this is consistently used tagging.

Note (2) would be a massive endeavour without precedent in OSM history 
and regarding (3) it should be noted that barrier=hedge is currently 
not the dominant method of mapping strips of trees or bushes with 
polygons, see for example:

https://www.openstreetmap.org/#map=15/50.4774/5.2980
https://www.openstreetmap.org/#map=15/51.5144/5.7404
https://www.openstreetmap.org/#map=15/48.8437/6.2252
https://www.openstreetmap.org/#map=14/52.8414/8.4571
https://www.openstreetmap.org/#map=15/53.9644/11.0538
https://www.openstreetmap.org/#map=14/51.9532/-0.1199
https://www.openstreetmap.org/#map=13/44.8335/40.0695

-- 
Christoph Hormann
http://www.imagico.de/

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Paul Allen
On Wed, 5 Feb 2020 at 13:21, Andy Townsend  wrote:

>
> It doesn't sound like a tagging issue to me; I'd suggest that the
> renderer that made this change did so in error.  Is using a different
> renderer an option until it is fixed (perhaps the Humanitarian tiles
> linked from openstreetmap.org)?
>

None of the tile layers on osm.org render area hedges as they used to.
The only renderers I've found so far that shows area hedges are
the French OSM tiles and a really useful map from somebody called
Andy.

The change isn't the end of the world, but it's not what anybody who
deliberately mapped area hedges was expecting and may result in
tagging for the renderer.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Andy Townsend

On 05/02/2020 13:02, Jeroen Hoek wrote:

This update has the unfortunate side-effect of breaking the rendering of
over 1 hedges in the Netherlands.



This means that hedges are often mapped as areas, using the documented
tag pair of `barrier=hedge` plus `area=yes`:


In this case sounds like the renderer has broken the "principle of least 
surprise".


It doesn't sound like a tagging issue to me; I'd suggest that the 
renderer that made this change did so in error.  Is using a different 
renderer an option until it is fixed (perhaps the Humanitarian tiles 
linked from openstreetmap.org)?


(for the avoidance of doubt - I appreciate that this this conversation 
started on one mailing list, then replies moved it elsewhere, so this 
isn't intended to be a criticism of which list you posted to!)


Best Regards,

Andy



___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-05 Thread Jeroen Hoek
This update has the unfortunate side-effect of breaking the rendering of
over 1 hedges in the Netherlands. We have been very fortunate to
have access to highly detailed mapping sources via our government,
including both satellite images and tile-services for street-level
features, including hedges in public spaces.

This means that hedges are often mapped as areas, using the documented
tag pair of `barrier=hedge` plus `area=yes`:

https://wiki.openstreetmap.org/w/index.php?title=Tag:barrier%3Dhedge=1934515

(§ 'How to Map')

This update renders those hedges as linear features instead, creating
holes in the map where none exist.

Because there is no alternative to tag hedge areas, we now have a bunch
of broken hedges on OpenStreetMap.org's standard layer.

I wouldn't mind migrating away from `area=yes` to some alternative
though. `area:barrier=yes` might be suitable, and would allow for the
much desired walls-as-area to be rendered as well without ambiguity as
to the meaning of `area=yes`.

My proposal would be to allow barriers to be explicitly defined as areas
by adding `area:barrier=yes` to the tags, in addition to `barrier=*`.

The reason for the presence of `barrier=*` is that for routing software,
the edges of an area *are* the effective barrier, and nothing needs to
be changed in routing software to work with this proposal (in this
sense, this proposal is slightly different from `area:higway=*`, where
the `highway=*` is not usually present on the same entity, but drawn
separately instead).

The current lack of a migration path does make for a rather jarring change.

On 03-02-2020 13:41, Joseph Eisenberg wrote:
> That appears to be a "shrubbery" in British English, around a tree. It
> isn't wrong to use barrier=hedge, since it does provide a visual
> barrier and you will probably want to walk around it.
> 
> But there is not a very well established way to micro-map very small
> areas of shrubs and bushes like this.
> 
> Some mappers seem to use natural=scrub, others use leisure=garden, and
> some have tried various rarer tags with values like "greenery". There
> does not seem to be a consensus.
> 
> You might ask on the Tagging list to get some more ideas:
> tagging@openstreetmap.org
> 
> - Joseph Eisenberg
> 
> On 2/3/20, Marc Gemis  wrote:
>> Hello Joseph,
>>
>> I noticed Remove polygon fill rendering for barrier=hedge areas (#3844)
>>
>> So I wonder how I should map something like
>> https://www.mapillary.com/map/im/-tERxnfwcP3qlBh-0j7pnw now. For me,
>> that was barrier=hedge; area=yes. But from what I understand from the
>> discussion on Github, this is considered wrong tagging.
>> Should this be mapped as natural=scrub in your opinion?
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-03 Thread Paul Allen
On Mon, 3 Feb 2020 at 12:42, Joseph Eisenberg 
wrote:

> That appears to be a "shrubbery" in British English, around a tree.


For some values of "shrubbery."  In some circles, a shrubbery lines a
winding path
through a garden, it's not just an area of shrubs.


> It isn't wrong to use barrier=hedge, since it does provide a visual
> barrier and you will probably want to walk around it.
>

That's what I ended up using, for lack of anything better, around here:
https://www.openstreetmap.org/?mlat=52.08948=-4.64723#map=19/52.08948/-4.64723

See https://goo.gl/maps/qEiBkiMH7uCHCWNo8  You wouldn't attempt to walk
through that even if you didn't know about the thorns that some of the
bushes have.
It's definitely a barrier.

-- 
Paul
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] [OSM-talk] OpenStreetMap Carto release v4.25.0

2020-02-03 Thread Joseph Eisenberg
That appears to be a "shrubbery" in British English, around a tree. It
isn't wrong to use barrier=hedge, since it does provide a visual
barrier and you will probably want to walk around it.

But there is not a very well established way to micro-map very small
areas of shrubs and bushes like this.

Some mappers seem to use natural=scrub, others use leisure=garden, and
some have tried various rarer tags with values like "greenery". There
does not seem to be a consensus.

You might ask on the Tagging list to get some more ideas:
tagging@openstreetmap.org

- Joseph Eisenberg

On 2/3/20, Marc Gemis  wrote:
> Hello Joseph,
>
> I noticed Remove polygon fill rendering for barrier=hedge areas (#3844)
>
> So I wonder how I should map something like
> https://www.mapillary.com/map/im/-tERxnfwcP3qlBh-0j7pnw now. For me,
> that was barrier=hedge; area=yes. But from what I understand from the
> discussion on Github, this is considered wrong tagging.
> Should this be mapped as natural=scrub in your opinion?

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging