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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
67 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

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

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:
[hidden email]

- Joseph Eisenberg

On 2/3/20, Marc Gemis <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Paul Allen
On Mon, 3 Feb 2020 at 12:42, Joseph Eisenberg <[hidden email]> 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: 

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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Jeroen Hoek
In reply to this post by Joseph Eisenberg
This update has the unfortunate side-effect of breaking the rendering of
over 10000 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&oldid=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:
> [hidden email]
>
> - Joseph Eisenberg
>
> On 2/3/20, Marc Gemis <[hidden email]> 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
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging
>

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Andy Townsend
On 05/02/2020 13:02, Jeroen Hoek wrote:
> This update has the unfortunate side-effect of breaking the rendering of
> over 10000 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Paul Allen
On Wed, 5 Feb 2020 at 13:21, Andy Townsend <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Christoph Hormann-2
In reply to this post by Andy Townsend
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Paul Allen
On Wed, 5 Feb 2020 at 14:48, Christoph Hormann <[hidden email]> 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:
spaces between the bushes, they have thorns.

--
Paul


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Jeroen Hoek
In reply to this post by Christoph Hormann-2
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Jeroen Hoek
In reply to this post by Paul Allen
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Peter Elderson
In reply to this post by Jeroen Hoek
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 <[hidden email]> 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
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Peter Elderson
In reply to this post by Jeroen Hoek
+1

Mvg Peter Elderson

> Op 5 feb. 2020 om 16:37 heeft Jeroen Hoek <[hidden email]> 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
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Christoph Hormann-2
In reply to this post by Jeroen Hoek
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Paul Allen
On Wed, 5 Feb 2020 at 16:29, Christoph Hormann <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Andy Townsend
In reply to this post by Christoph Hormann-2
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Christoph Hormann-2
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Sarah Hoffmann
In reply to this post by Christoph Hormann-2
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Christoph Hormann-2
In reply to this post by Andy Townsend
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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

Marc M.
In reply to this post by Andy Townsend
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
<cut>
> "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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

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

dieterdreist
In reply to this post by Paul Allen


sent from a phone

> Il giorno 5 feb 2020, alle ore 16:11, Paul Allen <[hidden email]> 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
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
1234