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

[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] Feature Proposal - Voting - give box

[Warin]

On 6/2/20 5:13 pm, European Water Project wrote:

I see good arguments on both sides 

but I tend to agree with Joseph and Marc about the need to put 
substance over form.


Maybe the proposal just passes based on objective measurements (vote 
ratio), but that if enough people post facto see enough flaws that it 
can be temporarily suspended.






To help motivate authors, maybe the burden for getting an alternative 
tag implemented can be shifted to the naysayers. ie if they don't 
develop a new tag, the previous proposal goes through ...



The above idea I like!



Best regards,

Stuart



On Thu, 6 Feb 2020 at 01:23, marc marc > wrote:


the proposals (I'm talking generally, not just about this one) have
often 2 flaws:
- often too big (not this one)
- often rfc too short, even active people still have remarks to make
that the vote is already open, so they are stuck to sink the proposal
(with the risk that its author gets demotivated) or to accept it
hoping
that the defects will be corrected later (which is always much more
difficult in the osm world).
with your opinion, I would have voted against it without hesitation.
because it's the best way to improve what you think should be
improved.
i have in mind the proposal diaper<>changing table: totally ok for the
idea, i voted against the first version because of the negative
elements
it contained.

Le 06.02.20 à 01:10, Joseph Eisenberg a écrit :
> Ok, so we should consider it approved in this case.
>
> (For context, both Mateusz Konieczny and myself have abstained,
along
> with 3 others, but had comments expressing concern about using
> "give_box" instead of "free_box" or something easier to understand.)
>
> But hypothetically, what if there were even more comments expressing
> reservations. This time it was over 25%, but what if it was 40% or
> even 50%?
>
> Since the idea of this process is to reach consensus about a tag,
> shouldn't critical comments be addressed by those voting "yes"?
>
> One thing that might help would be to recommend a comment along with
> positive votes. Right now you can vote to approve without saying
> anything about the objections voiced, and the template suggest
this is
> the usual way to do it.
>
> This seems to put too much weight on the percentage of approved vs
> disapproved rather than the actual reasons for the votes.
>
> - Joseph Eisenberg
>
> On 2/6/20, Andrew Davidson mailto:thesw...@gmail.com>> wrote:
>> On 6/2/20 4:02 am, Mateusz Konieczny via Tagging wrote:
>>> I see no good reason to count explicit "abstain but have comments"
>>> exactly like "vote against".
>>>
>>
>> +1
>>
>> To abstain from voting is to not cast a vote. So there were 14
votes
>> with just under 93% approving.
>>
>>



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

Re: [Tagging] Feature Proposal - Voting - give box

[European Water Project]

I see good arguments on both sides 

but I tend to agree with Joseph and Marc about the need to put substance
over form.

Maybe the proposal just passes based on objective measurements (vote
ratio), but that if enough people post facto see enough flaws that it can
be temporarily suspended.

To help motivate authors, maybe the burden for getting an alternative tag
implemented can be shifted to the naysayers. ie if they don't develop a new
tag, the previous proposal goes through ...

Best regards,

Stuart



On Thu, 6 Feb 2020 at 01:23, marc marc  wrote:

> the proposals (I'm talking generally, not just about this one) have
> often 2 flaws:
> - often too big (not this one)
> - often rfc too short, even active people still have remarks to make
> that the vote is already open, so they are stuck to sink the proposal
> (with the risk that its author gets demotivated) or to accept it hoping
> that the defects will be corrected later (which is always much more
> difficult in the osm world).
> with your opinion, I would have voted against it without hesitation.
> because it's the best way to improve what you think should be improved.
> i have in mind the proposal diaper<>changing table: totally ok for the
> idea, i voted against the first version because of the negative elements
> it contained.
>
> Le 06.02.20 à 01:10, Joseph Eisenberg a écrit :
> > Ok, so we should consider it approved in this case.
> >
> > (For context, both Mateusz Konieczny and myself have abstained, along
> > with 3 others, but had comments expressing concern about using
> > "give_box" instead of "free_box" or something easier to understand.)
> >
> > But hypothetically, what if there were even more comments expressing
> > reservations. This time it was over 25%, but what if it was 40% or
> > even 50%?
> >
> > Since the idea of this process is to reach consensus about a tag,
> > shouldn't critical comments be addressed by those voting "yes"?
> >
> > One thing that might help would be to recommend a comment along with
> > positive votes. Right now you can vote to approve without saying
> > anything about the objections voiced, and the template suggest this is
> > the usual way to do it.
> >
> > This seems to put too much weight on the percentage of approved vs
> > disapproved rather than the actual reasons for the votes.
> >
> > - Joseph Eisenberg
> >
> > On 2/6/20, Andrew Davidson  wrote:
> >> On 6/2/20 4:02 am, Mateusz Konieczny via Tagging wrote:
> >>> I see no good reason to count explicit "abstain but have comments"
> >>> exactly like "vote against".
> >>>
> >>
> >> +1
> >>
> >> To abstain from voting is to not cast a vote. So there were 14 votes
> >> with just under 93% approving.
> >>
> >>
> >> ___
> >> Tagging mailing list
> >> Tagging@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/tagging
> >>
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> >
>
> ___
> 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

[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

[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

[Tagging] key damage and HOT

[Warin]

Hi,

Some may remember I raised the issue of using damage:*=* as part of the 
life cycle tagging system.


I have been informed that HOT uses the key damage=* ... most of them on 
buildings.. and with values such as;


yes

no

minor

major

destroyed

complete

significant

minimal

..

It seems to me that the present use of the key damage=*, which has no 
documentation, would better fit into the life cycle system.

Further tag use can be found https://taginfo.openstreetmap.org/search?q=damage

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

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

[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

[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

[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

[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

[Tagging] Abstaining in a proposal vote (Re: Feature Proposal - Voting - give box)

[Andrew Davidson]

There are many things about the proposal process that seem a little odd and
we could spend a lot of time debating them. I'd rather just concentrate on
the question of parliamentary procedure.

On Thu, Feb 6, 2020 at 11:11 AM Joseph Eisenberg 
wrote:

>
> But hypothetically, what if there were even more comments expressing
> reservations. This time it was over 25%, but what if it was 40% or
> even 50%?
>

Doesn't matter, even if there were thousands of comments they still aren't
votes.


> Since the idea of this process is to reach consensus about a tag,
> shouldn't critical comments be addressed by those voting "yes"?
>
>
Well this is one of those odd things. There is a RFC period, where people
are invited to...well..make comments. Once this is done it goes to a vote
where we invite people to vote or make comments...hang on didn't we just
have a RFC period? Isn't it too late to be asking for comments? What is the
proponent (before we even start worrying about the yes voters) supposed to
do with these now? You can't change a proposal part way through the voting
period. How "critical" is a comment from a user that wasn't concerned
enough to vote no?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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] amenity=faculty?

[Joseph Eisenberg]

> ... put the tag "amenity=university" and all the information only 1 time for 
> the whole university

> I would generally just use a multipolygon relation for this

+1 for the common multipolygon relation, not type=site.

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

Re: [Tagging] Feature Proposal - Voting - give box

[marc marc]

the proposals (I'm talking generally, not just about this one) have
often 2 flaws:
- often too big (not this one)
- often rfc too short, even active people still have remarks to make
that the vote is already open, so they are stuck to sink the proposal
(with the risk that its author gets demotivated) or to accept it hoping
that the defects will be corrected later (which is always much more
difficult in the osm world).
with your opinion, I would have voted against it without hesitation.
because it's the best way to improve what you think should be improved.
i have in mind the proposal diaper<>changing table: totally ok for the
idea, i voted against the first version because of the negative elements
it contained.

Le 06.02.20 à 01:10, Joseph Eisenberg a écrit :
> Ok, so we should consider it approved in this case.
> 
> (For context, both Mateusz Konieczny and myself have abstained, along
> with 3 others, but had comments expressing concern about using
> "give_box" instead of "free_box" or something easier to understand.)
> 
> But hypothetically, what if there were even more comments expressing
> reservations. This time it was over 25%, but what if it was 40% or
> even 50%?
> 
> Since the idea of this process is to reach consensus about a tag,
> shouldn't critical comments be addressed by those voting "yes"?
> 
> One thing that might help would be to recommend a comment along with
> positive votes. Right now you can vote to approve without saying
> anything about the objections voiced, and the template suggest this is
> the usual way to do it.
> 
> This seems to put too much weight on the percentage of approved vs
> disapproved rather than the actual reasons for the votes.
> 
> - Joseph Eisenberg
> 
> On 2/6/20, Andrew Davidson  wrote:
>> On 6/2/20 4:02 am, Mateusz Konieczny via Tagging wrote:
>>> I see no good reason to count explicit "abstain but have comments"
>>> exactly like "vote against".
>>>
>>
>> +1
>>
>> To abstain from voting is to not cast a vote. So there were 14 votes
>> with just under 93% approving.
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> 
> ___
> 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] amenity=faculty?

[Jmapb]

On 2/5/2020 6:21 PM, Lionel Giard wrote:

Site relation are more used to put the tag "amenity=university" and
all the information only 1 time for the whole university when it is
spread across a city or multiple sites. This site relation equal to
the amenity=university area under a campus that's all grouped into one
place. Otherwise, if you query the data, you'll see many
amenity=university (which means multiple universities) that are
exactly the same which is wrong.


I would generally just use a multipolygon relation for this. Any
contiguous portions of university campus are mapped as closed ways with
role "outer." Any isolated university buildings are also added to the
relation with role "outer". All the top-level university tags, including
amenity=university, go on the relation. (But it can get tricky if some
university office or department occupies an undefined portion of a
particular building that is otherwise not controlled by the university
-- I tend to just use nodes tagged with name/operator/website and leave
these out of the relation, which is not ideal.)

J


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

Re: [Tagging] Feature Proposal - Voting - give box

[Joseph Eisenberg]

Ok, so we should consider it approved in this case.

(For context, both Mateusz Konieczny and myself have abstained, along
with 3 others, but had comments expressing concern about using
"give_box" instead of "free_box" or something easier to understand.)

But hypothetically, what if there were even more comments expressing
reservations. This time it was over 25%, but what if it was 40% or
even 50%?

Since the idea of this process is to reach consensus about a tag,
shouldn't critical comments be addressed by those voting "yes"?

One thing that might help would be to recommend a comment along with
positive votes. Right now you can vote to approve without saying
anything about the objections voiced, and the template suggest this is
the usual way to do it.

This seems to put too much weight on the percentage of approved vs
disapproved rather than the actual reasons for the votes.

- Joseph Eisenberg

On 2/6/20, Andrew Davidson  wrote:
> On 6/2/20 4:02 am, Mateusz Konieczny via Tagging wrote:
>> I see no good reason to count explicit "abstain but have comments"
>> exactly like "vote against".
>>
>
> +1
>
> To abstain from voting is to not cast a vote. So there were 14 votes
> with just under 93% approving.
>
>
> ___
> 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] amenity=faculty?

[Jmapb]

On 2/5/2020 4:36 AM, Lionel Giard wrote:


Thus, it seems difficult to find "one" subdivision that will always
work worldwide ?! :-) Maybe that we should keep a generic word and
allow everything in it (like subdivision=* with the name of "School",
"Institute", "College",... if relevant) ?


I agree the various terms I've seen (faculty, department, school,
college, institute, program(me), division, educational unit) don't seem
to line up worldwide or even within some small regions.

A generic term, with the site-specific term listed as part of the name=*
tag, seems like a good solution. I'd probably be happier with department
or division as the generic term, but subdivision might work.

(In discussions like these I can't help thinking about the various
proposals for a unifying education=* tag, and how that might affect the
tagging of sort of hierarchy. The most recent one, currently "under
way", is
https://wiki.openstreetmap.org/wiki/Proposed_Features/Education_Reform_Alternative
.)

Jason


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

Re: [Tagging] amenity=faculty?

[Lionel Giard]

Site relation are more used to put the tag "amenity=university" and all the
information only 1 time for the whole university when it is spread across a
city or multiple sites. This site relation equal to the amenity=university
area under a campus that's all grouped into one place. Otherwise, if you
query the data, you'll see many amenity=university (which means multiple
universities) that are exactly the same which is wrong. But i don't see how
it solve the subdivision either.

I also map the building name or ref as what the university use in general,
and put node "POI" for school or institute if they are officially located
there in one place (or if you could argue that their main office is there).


Le mer. 5 févr. 2020 à 22:55, Graeme Fitzpatrick  a
écrit :

> You also have the problem of different Schools sharing the same building.
>
> With the Uni I'm familiar with, in one case you have the Clinical Sciences
> building 1, which holds 3 lecture theatres, plus the School of Nursing &
> the School of Pharmacy.
>
> It's currently mapped as "G16 - Clinical Science 1", which is how the Uni
> refers to it.
>
> & that Uni, incidentally, is spread over 5 separate campuses across 2
> cities!
>
> Thanks
>
> Graeme
> ___
> 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] highway=path for *all* mixed foot/bicycle highways?=<88cad950-d9cc-3c2e-9015-a54d7206a...@gmx.com>

[Volker Schmidt]

Your first point is correct and it applies here in Italy as well.

The default surface argument is weak. We do have unpaved official cycle and
foot-cycle paths.
The surface tag is mandatory in my view.
The same applies to sidewalks and minor roads.

And the "path" approach for foot-cycle-way is very frequent in some
countries. So it's there. I would not deprecate other tagging practices
though.



Il mer 5 feb 2020, 16:29 Dörögdi András  ha scritto:

> Some thoughts from cyclist perspective.
> I personally not using the (highway=path + bicycle=designated +
> foot=designated) combination for shared foot- and cycleways.
>
>  1) If I change a cycleway to path, I will unintentionally enable access
> for equestrians on the highway (according to this table:
>
> https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access_restrictions#Hungary
> )
>  So I need to add an additional 'horse=no' tag to highway=path
>
>  2) The iD Editor doesn't know the shared foot and cycleways, it only
> displays the highway as a classic 'path' category, just like a forest path.
>  Result: some iD users begins to change highway=path back to
> highway=cycleway or highway=footway in urban environment.
>
>  3) As already mentioned by many, without the surface tag the highway=path
> could become meaningless. Some routing engine interprets
>  highway=path + bicycle=designated + foot=designated as an unpaved path,
> while interpreting highway=cycleway as a paved road (correctly)
>  Result: some bicycle routers begins to avoid shared foot- and cycleways
> tagged with highway=path w/o surface.
>  I know we are not mapping for the outputs, but the cycleways works nearly
> perfect while the path does not. Why do we change?
>
> So I need to add two additional tags for the same result without any
> advantages.
>
> highway=cycleway
> foot=designated
> segregated=yes
>
> highway=path
> foot=designated
> bicycle=designated
> horse=no
> surface=asphalt
>
> Best regards,
> András
> ___
> 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

[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] How to tag an utilitarian fountain?

[António Madeira]

That is exactly my opinion on this matter.


Às 19:06 de 05/02/2020, Mateusz Konieczny via Tagging escreveu:




5 Feb 2020, 21:06 by selfishseaho...@gmail.com:

On Mon, 3 Feb 2020 at 00:35, Warin <61sundow...@gmail.com> wrote:


amenity=drinking_water is used for;

streams that people drink from

wells that people drink from

taps that people drink from

blubbers that people drink from

fountains that people drink from


As such it is very non descriptive! More of a property key like
drinking_water=yes.


In my opinion, amenity=drinking_water should be abandoned. There are
more descriptive tags for the features amenity=drinking_water is used
for:

* man_made=drinking_fountain
* amenity=fountain
* man_made=water_well
* man_made=water_tap
* natural=spring

And amenity=drinking_water may be
combined with them (except of unfortunate
case of fountain).

___
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] How to tag an utilitarian fountain?

[Mateusz Konieczny via Tagging]

5 Feb 2020, 21:06 by selfishseaho...@gmail.com:

> On Mon, 3 Feb 2020 at 00:35, Warin <61sundow...@gmail.com> wrote:
>
>>
>> amenity=drinking_water is used for;
>>
>> streams that people drink from
>>
>> wells  that people drink from
>>
>> taps that people drink from
>>
>> blubbers that people drink from
>>
>> fountains that people drink from
>>
>>
>> As such it is very non descriptive! More of a property key like
>> drinking_water=yes.
>>
>
> In my opinion, amenity=drinking_water should be abandoned. There are
> more descriptive tags for the features amenity=drinking_water is used
> for:
>
>  * man_made=drinking_fountain
>  * amenity=fountain
>  * man_made=water_well
>  * man_made=water_tap
>  * natural=spring
>
And amenity=drinking_water may be
combined with them (except of unfortunate
case of fountain).___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] amenity=faculty?

[Graeme Fitzpatrick]

You also have the problem of different Schools sharing the same building.

With the Uni I'm familiar with, in one case you have the Clinical Sciences
building 1, which holds 3 lecture theatres, plus the School of Nursing &
the School of Pharmacy.

It's currently mapped as "G16 - Clinical Science 1", which is how the Uni
refers to it.

& that Uni, incidentally, is spread over 5 separate campuses across 2
cities!

Thanks

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

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

[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] Feature Proposal - Voting - give box

[Andrew Davidson]

On 6/2/20 4:02 am, Mateusz Konieczny via Tagging wrote:

I see no good reason to count explicit "abstain but have comments"
exactly like "vote against".



+1

To abstain from voting is to not cast a vote. So there were 14 votes 
with just under 93% approving.



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

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

[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

[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

[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

[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

[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

[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

[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

[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] How to tag an utilitarian fountain?

[Markus]

On Mon, 3 Feb 2020 at 00:35, Warin <61sundow...@gmail.com> wrote:
>
> amenity=drinking_water is used for;
>
> streams that people drink from
>
> wells  that people drink from
>
> taps that people drink from
>
> blubbers that people drink from
>
> fountains that people drink from
>
>
> As such it is very non descriptive! More of a property key like
> drinking_water=yes.

In my opinion, amenity=drinking_water should be abandoned. There are
more descriptive tags for the features amenity=drinking_water is used
for:

  * man_made=drinking_fountain
  * amenity=fountain
  * man_made=water_well
  * man_made=water_tap
  * natural=spring

Regards

Markus

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

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

[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] bicycle:lanes and foot:lanes on foot-cycle-paths

[Hubert87]

Hi,

I did some thing similar, too.

highway:lanes=cycleway|footway
surface:lanes=
width:lanes=

in addition to all the normal (fallback) tags.

https://www.openstreetmap.org/way/27131742

Didn't use bicycle:lanes=designated|no or foot:lanes=no|designated though.
But I like it. I'm going to also do that in the future.


Yours

Am 04.02.2020 um 10:40 schrieb Volker Schmidt:

Thanks, Marc, for spotting the spelling error.

you seem to have a typo in the "foot:lanes=no|dsgnated"
But when I look at the Mapillary photo's I think there are 2 bicycle
lanes (one for each direction) and a sidewalk (there is a kerb) for
pedestrians.

Yes, there is a (mini-) kerb) and hence I could tag this as as two
separate ways.

Let's move to a nearby foot-cycle-way: Mapillary foto

I mapped it as a separate foot-cycle-path
 with segregation, because
it is separated from the main carriageway by metal arcs. So let me
repeat my question for this one:
how can I tag the relative position of the foot lane and the cycling
lane on this segregated foot-cycle-path?
Would
highway=path
bicycle=designated
foot=designated
segregated=yes
bicycle:lanes=designated|no
foot:lanes=no|designated
width:lanes=2.5|1.5
width=4
a correct tagging?

Volker


___
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

[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

[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

[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

[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

[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

[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

[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] Feature Proposal - Voting - give box

[Mateusz Konieczny via Tagging]

I see no good reason to count explicit "abstain but have comments"
 exactly like "vote against".


Feb 5, 2020, 14:58 by joseph.eisenb...@gmail.com:

> Well, if we count all of those, it is 68% (13/19) which is less than
> the 74% cut-off.
>
> I don't think this should be considered "approved". There were several
> comments that "free box" or something else that is more common in
> British English should be considered instead.
>
> More important than the number of votes is whether signficant problems
> and objections have been addressed. In this case, the concern is that
> "give box" is quite rare in Britain and other native English-speaking
> countries, and is not unambiguous.
>
> - Joseph Eisenberg
>
> On 2/5/20, Markus Peloso  wrote:
>
>> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dgive_box
>>
>> A small facility where people drop off and pick up various types of items in
>> the sense of free sharing and reuse.
>>
>> Hi
>>
>> Thanks for voting and for the inputs. Based on the result «13 votes for, 1
>> vote against and 5 abstentions» I set the status to approved :D.
>>
>> Best regards,
>> Markus
>>
>> Von: Markus Peloso
>> Gesendet: Dienstag, 21. Januar 2020 09:42
>> An: Tag discussion, strategy and related
>> tools
>> Betreff: Feature Proposal - Voting - give box
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/give_box
>>
>> A small facility where people drop off and pick up various types of items in
>> the sense of free sharing.
>>
>> Hi
>>
>> Thanks for the discussion, inputs and improvement to this tag.
>>
>> I request for voting now.
>>
>> Feel free to give also a negative answer if you only don’t like the name.
>> Then please write in the comments what name you prefer. Based on the result
>> I will made a second vote with a new name. Other suggested names are:
>>  • amenity=free_box
>>  • amenity=free_goods
>>  • amenity=give_take_box
>>  • shop=freeshop
>>
>> Best regards,
>> Markus
>>
>> Von: Markus Peloso
>> Gesendet: Donnerstag, 9. Januar 2020 21:26
>> An: tagging@openstreetmap.org
>> Betreff: Re: [Tagging] Feature Proposal - RFC - give box
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/give_box
>>
>> A small facility where people drop off and pick up various types of items in
>> the sense of free sharing.
>>
>> Hi
>>
>> Thank you for your inputs to improve this documentation and make it easy to
>> understand what this tag is all about. I have removed all references and
>> notes to give away shops, because those are not helpful for a clear
>> specification of this tag.
>>
>> Thanks for the hint with the hiker boxes and the other type of boxes. Good
>> to see that there are similar projects all over the world. I have included a
>> section with suggestions on how this boxtypes could be handled with existing
>> tags (the goods tag is already taken). I want this tag to be more specific
>> then the reuse tag. I do not want to cover all existing variations with it.
>> IMO someone like food boxes for example deserve their own tag.
>>
>> Von: Markus Peloso
>> Gesendet: Dienstag, 7. Januar 2020 13:04
>> An: tagging@openstreetmap.org
>> Betreff: AW: Feature Proposal - RFC - give box
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/give_box
>>
>> A facility where people drop off and pick up various types of goods in the
>> sense of free sharing.
>>
>> Many thanks for your helpful Feedback and your support. :D
>>
>> I have updated the proposed.
>>
>> I like the idea of using the shop=charity icon. Maybe the icon could be a
>> combination of the shop=charity icon and the shop=gift icon.
>>
>> I change the tag name to give_box.
>> https://wiki.openstreetmap.org/wiki/Proposed_features/give_box
>> Because the name Givebox is used by a website that provides fundraising
>> tools.
>>
>> The naming was the difficult part. Why am I for give_box:
>>
>> + Give box is already a known concept in Europa with a big community.
>> + I think "gift box" would be a very good name to describes the idea of this
>> facility. As a self organized solidarity space of free giving/donating and
>> free taking/reusing. The name "Give box" is similar.
>> + Give box is not overused for other things found in the internet, eg.
>> internet modems.
>>
>> "reuse" is to generic, eg. someone can tag a fridge with amenity=reuse and
>> reuse=fridge, to document a place to share food. But I think this kind of
>> facility deserves its own tag.
>> I think the tag "reuse" is currently only used because there is no other tag
>> for this kind of facility.
>>
>> Give boxes are some kind of public storage room/space in the sense of giving
>> and reuse. I think the "free store" (German "Umsonstladen") in Germany is
>> more a give box as a store. As I read, even the shelf's in the "free store"
>> ("Umsonstladen") are brought by 

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

[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

[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

[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

[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

[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] Feature Proposal - Voting - give box

[Jmapb]

On 2/5/2020 8:58 AM, Joseph Eisenberg wrote:

Well, if we count all of those, it is 68% (13/19) which is less than
the 74% cut-off.


Is it normal to count abstentions as part of the vote total? The
proposal template text (
https://wiki.openstreetmap.org/wiki/Template:Proposed_feature_voting )
says "I have comments but abstain from voting" followed by the
description "If you don't want to vote but have comments." Unless
there's a clear precedent otherwise, it sounds like "abstain" should not
be part of the vote count.

If abstentions did count in the vote total, then mathematically there'd
be no difference between "oppose" and "abstain," and it would be
impossible to leave comments without affecting the voting.

Jason


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

Re: [Tagging] highway=path for *all* mixed foot/bicycle highways?=<88cad950-d9cc-3c2e-9015-a54d7206a...@gmx.com>

[Dörögdi András]

Some thoughts from cyclist perspective.
I personally not using the (highway=path + bicycle=designated +
foot=designated) combination for shared foot- and cycleways.

 1) If I change a cycleway to path, I will unintentionally enable access
for equestrians on the highway (according to this table:

https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access_restrictions#Hungary
)
 So I need to add an additional 'horse=no' tag to highway=path

 2) The iD Editor doesn't know the shared foot and cycleways, it only
displays the highway as a classic 'path' category, just like a forest path.
 Result: some iD users begins to change highway=path back to
highway=cycleway or highway=footway in urban environment.

 3) As already mentioned by many, without the surface tag the highway=path
could become meaningless. Some routing engine interprets
 highway=path + bicycle=designated + foot=designated as an unpaved path,
while interpreting highway=cycleway as a paved road (correctly)
 Result: some bicycle routers begins to avoid shared foot- and cycleways
tagged with highway=path w/o surface.
 I know we are not mapping for the outputs, but the cycleways works nearly
perfect while the path does not. Why do we change?

So I need to add two additional tags for the same result without any
advantages.

highway=cycleway
foot=designated
segregated=yes

highway=path
foot=designated
bicycle=designated
horse=no
surface=asphalt

Best regards,
András
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[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

[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

[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

[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] Feature Proposal - Voting - give box

[Joseph Eisenberg]

Well, if we count all of those, it is 68% (13/19) which is less than
the 74% cut-off.

I don't think this should be considered "approved". There were several
comments that "free box" or something else that is more common in
British English should be considered instead.

More important than the number of votes is whether signficant problems
and objections have been addressed. In this case, the concern is that
"give box" is quite rare in Britain and other native English-speaking
countries, and is not unambiguous.

- Joseph Eisenberg

On 2/5/20, Markus Peloso  wrote:
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dgive_box
>
> A small facility where people drop off and pick up various types of items in
> the sense of free sharing and reuse.
>
> Hi
>
> Thanks for voting and for the inputs. Based on the result «13 votes for, 1
> vote against and 5 abstentions» I set the status to approved :D.
>
> Best regards,
> Markus
>
> Von: Markus Peloso
> Gesendet: Dienstag, 21. Januar 2020 09:42
> An: Tag discussion, strategy and related
> tools
> Betreff: Feature Proposal - Voting - give box
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/give_box
>
> A small facility where people drop off and pick up various types of items in
> the sense of free sharing.
>
> Hi
>
> Thanks for the discussion, inputs and improvement to this tag.
>
> I request for voting now.
>
> Feel free to give also a negative answer if you only don’t like the name.
> Then please write in the comments what name you prefer. Based on the result
> I will made a second vote with a new name. Other suggested names are:
> • amenity=free_box
> • amenity=free_goods
> • amenity=give_take_box
> • shop=freeshop
>
> Best regards,
> Markus
>
> Von: Markus Peloso
> Gesendet: Donnerstag, 9. Januar 2020 21:26
> An: tagging@openstreetmap.org
> Betreff: Re: [Tagging] Feature Proposal - RFC - give box
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/give_box
>
> A small facility where people drop off and pick up various types of items in
> the sense of free sharing.
>
> Hi
>
> Thank you for your inputs to improve this documentation and make it easy to
> understand what this tag is all about. I have removed all references and
> notes to give away shops, because those are not helpful for a clear
> specification of this tag.
>
> Thanks for the hint with the hiker boxes and the other type of boxes. Good
> to see that there are similar projects all over the world. I have included a
> section with suggestions on how this boxtypes could be handled with existing
> tags (the goods tag is already taken). I want this tag to be more specific
> then the reuse tag. I do not want to cover all existing variations with it.
> IMO someone like food boxes for example deserve their own tag.
>
> Von: Markus Peloso
> Gesendet: Dienstag, 7. Januar 2020 13:04
> An: tagging@openstreetmap.org
> Betreff: AW: Feature Proposal - RFC - give box
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/give_box
>
> A facility where people drop off and pick up various types of goods in the
> sense of free sharing.
>
> Many thanks for your helpful Feedback and your support. :D
>
> I have updated the proposed.
>
> I like the idea of using the shop=charity icon. Maybe the icon could be a
> combination of the shop=charity icon and the shop=gift icon.
>
> I change the tag name to give_box.
> https://wiki.openstreetmap.org/wiki/Proposed_features/give_box
> Because the name Givebox is used by a website that provides fundraising
> tools.
>
> The naming was the difficult part. Why am I for give_box:
>
> + Give box is already a known concept in Europa with a big community.
> + I think "gift box" would be a very good name to describes the idea of this
> facility. As a self organized solidarity space of free giving/donating and
> free taking/reusing. The name "Give box" is similar.
> + Give box is not overused for other things found in the internet, eg.
> internet modems.
>
> "reuse" is to generic, eg. someone can tag a fridge with amenity=reuse and
> reuse=fridge, to document a place to share food. But I think this kind of
> facility deserves its own tag.
> I think the tag "reuse" is currently only used because there is no other tag
> for this kind of facility.
>
> Give boxes are some kind of public storage room/space in the sense of giving
> and reuse. I think the "free store" (German "Umsonstladen") in Germany is
> more a give box as a store. As I read, even the shelf's in the "free store"
> ("Umsonstladen") are brought by the community, that's more something like a
> public storage room. In a store I would except employees who eg. place the
> items on the shelves. That's way a give box is not a shop=charity or
> shop=second_hand. The idea and organization behind a "free store" (German
> 

Re: [Tagging] Feature Proposal - Voting - give box

[Markus Peloso]

https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dgive_box

A small facility where people drop off and pick up various types of items in 
the sense of free sharing and reuse.

Hi

Thanks for voting and for the inputs. Based on the result «13 votes for, 1 vote 
against and 5 abstentions» I set the status to approved :D.

Best regards,
Markus

Von: Markus Peloso
Gesendet: Dienstag, 21. Januar 2020 09:42
An: Tag discussion, strategy and related tools
Betreff: Feature Proposal - Voting - give box

https://wiki.openstreetmap.org/wiki/Proposed_features/give_box

A small facility where people drop off and pick up various types of items in 
the sense of free sharing.

Hi

Thanks for the discussion, inputs and improvement to this tag.

I request for voting now.

Feel free to give also a negative answer if you only don’t like the name. Then 
please write in the comments what name you prefer. Based on the result I will 
made a second vote with a new name. Other suggested names are:
• amenity=free_box
• amenity=free_goods
• amenity=give_take_box
• shop=freeshop

Best regards,
Markus

Von: Markus Peloso
Gesendet: Donnerstag, 9. Januar 2020 21:26
An: tagging@openstreetmap.org
Betreff: Re: [Tagging] Feature Proposal - RFC - give box

https://wiki.openstreetmap.org/wiki/Proposed_features/give_box

A small facility where people drop off and pick up various types of items in 
the sense of free sharing.

Hi

Thank you for your inputs to improve this documentation and make it easy to 
understand what this tag is all about. I have removed all references and notes 
to give away shops, because those are not helpful for a clear specification of 
this tag.

Thanks for the hint with the hiker boxes and the other type of boxes. Good to 
see that there are similar projects all over the world. I have included a 
section with suggestions on how this boxtypes could be handled with existing 
tags (the goods tag is already taken). I want this tag to be more specific then 
the reuse tag. I do not want to cover all existing variations with it. IMO 
someone like food boxes for example deserve their own tag.

Von: Markus Peloso
Gesendet: Dienstag, 7. Januar 2020 13:04
An: tagging@openstreetmap.org
Betreff: AW: Feature Proposal - RFC - give box

https://wiki.openstreetmap.org/wiki/Proposed_features/give_box

A facility where people drop off and pick up various types of goods in the 
sense of free sharing.

Many thanks for your helpful Feedback and your support. :D

I have updated the proposed.

I like the idea of using the shop=charity icon. Maybe the icon could be a 
combination of the shop=charity icon and the shop=gift icon.

I change the tag name to give_box. 
https://wiki.openstreetmap.org/wiki/Proposed_features/give_box
Because the name Givebox is used by a website that provides fundraising tools.

The naming was the difficult part. Why am I for give_box:

+ Give box is already a known concept in Europa with a big community.
+ I think "gift box" would be a very good name to describes the idea of this 
facility. As a self organized solidarity space of free giving/donating and free 
taking/reusing. The name "Give box" is similar.
+ Give box is not overused for other things found in the internet, eg. internet 
modems.

"reuse" is to generic, eg. someone can tag a fridge with amenity=reuse and 
reuse=fridge, to document a place to share food. But I think this kind of 
facility deserves its own tag.
I think the tag "reuse" is currently only used because there is no other tag 
for this kind of facility.

Give boxes are some kind of public storage room/space in the sense of giving 
and reuse. I think the "free store" (German "Umsonstladen") in Germany is more 
a give box as a store. As I read, even the shelf's in the "free store" 
("Umsonstladen") are brought by the community, that's more something like a 
public storage room. In a store I would except employees who eg. place the 
items on the shelves. That's way a give box is not a shop=charity or 
shop=second_hand. The idea and organization behind a "free store" (German 
"Umsonstladen") and "Give box" are the same, they differ only in the storage 
space size. A shack can also be named as a store. This makes a clear 
distinction difficult. As abstraction for OSM, I think we can use the same tag.

free_box would be my second choice. I would like to solve it democratically. In 
two weeks I would like to vote on give_box. If you prefer free_box then vote 
against it and write it in the comment of the vote. Then I change it and do a 
second vote for free_box.

Von: Markus Peloso
Gesendet: Montag, 6. Januar 2020 23:41
An: tagging@openstreetmap.org
Betreff: Feature Proposal - RFC - Givebox

Re: [Tagging] amenity=faculty?

[Martin Koppenhoefer]

sent from a phone

> Il giorno 5 feb 2020, alle ore 11:53, Volker Schmidt  ha 
> scritto:
> 
> I have not looked into this in detail, but this seems to me a strong case for 
> site relations.


I don’t see how site relations would solve the different levels of structure in 
different countries/universities.

Site relations could solve the problem of connecting things added as nodes 
only, on the other hand this would slow down more detailed mapping as areas 
(which are generally preferable for everything with some size IMHO, even if 
approximate).

When a faculty is distributed over several locations, it could be represented 
as multipolygons, or even just with a faculty tag in combination with other 
tags (like name of the university it is part of).

I’m not dismissing the idea of site relations for this in general, but there 
isn’t a strong case in favor of them either (semantically, I would see a 
faculty at 2 locations as 2 “sites”).

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

Re: [Tagging] [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 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

[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] Recycling diapers

[Francesco Ansanelli]

Il mer 5 feb 2020, 13:30 Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> ha scritto:

> Are diapers actually recycled?
>

Well... I've read it's theoretically possible to do it.


> It sounds like waste collection point accepting this specific type of
> trash.
>

Sure. If you read recycling as namespace of tag it makes a lot of sense...

>
>
> Feb 5, 2020, 13:22 by franci...@gmail.com:
>
> Dear List
>
>
> Can be the tag:
>
> recycling:diapers=yes/no
>
> Be accepted as allowed value and documented on wiki?
> It's already on use according to taginfo.
>
> Many thanks
> Best regards
> Francesco
>
> ___
> 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] Recycling diapers

[Mateusz Konieczny via Tagging]

Are diapers actually recycled?

It sounds like waste collection point accepting this specific type of trash.


Feb 5, 2020, 13:22 by franci...@gmail.com:

> Dear List
>
>
> Can be the tag:
>
> recycling:diapers=yes/no
>
> Be accepted as allowed value and documented on wiki?
> It's already on use according to taginfo.
>
> Many thanks
> Best regards
> Francesco
>
>___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] Recycling diapers

[Francesco Ansanelli]

Dear List


Can be the tag:

recycling:diapers=yes/no

Be accepted as allowed value and documented on wiki?
It's already on use according to taginfo.

Many thanks
Best regards
Francesco
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] amenity=faculty?

[Volker Schmidt]

Apart from technicalities, there is another problem. Universities in
different countries are subdivide in dìfferent ways: faculties,
departments, institutes, colleges. Except for campus-type universities they
are often distributed over an entire city.
I have not looked into this in detail, but this seems to me a strong case
for site relations.

On Tue, 4 Feb 2020 at 17:05, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

> Universities may have faculties, that often deserved to be mapped
> separately.
>
> For example university may take a large area, possibly disjointed area
> across the city
> but Faculty of dentistry, Faculty of forestry, Faculty of mathematics etc
> may be
> possible to be mapped as an area/node.
>
> Currently typical way to do that is to either
> - map name on building
> - create fake amenity=university with amenity=university
>
> It seems to me that amenity=faculty would be useful.
> ___
> 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] amenity=faculty?

[Lionel Giard]

Each country (and maybe university) have different subdivision, and
sometimes even inside one university there are multiple different
subdivision co-existing : for example in Belgium i know at least a few
universities that use two separate division at the same time :

   - for the education part : Université > Faculty > School ;
   - for the research part : University > Sector > Institute.

All of these can overlap. One professor can be part of one (or multiple)
school and institute at the same time. And for buildings, an institute can
be spread across multiple building, sharing space with a school ... It is
not simple and purely administrative as there isn't always an unique
spatial localisation for each institute or school. At the moment, i
sometimes see the institute or school name on the building if it is
generally located in one place. I have also seen many research institute
tagged on a node with "office=research" as they are well known publicly,
but again that's not always the case.

Thus, it seems difficult to find "one" subdivision that will always work
worldwide ?! :-) Maybe that we should keep a generic word and allow
everything in it (like subdivision=* with the name of "School",
"Institute", "College",... if relevant) ?

Le mer. 5 févr. 2020 à 03:24, Jarek Piórkowski  a
écrit :

> On Tue, 4 Feb 2020 at 11:44, Greg Troxel  wrote:
> > Mateusz Konieczny via Tagging  writes:
> > > Universities may have faculties, that often deserved to be mapped
> separately.
> > > ...
> > > It seems to me that amenity=faculty would be useful.
> >
> > Perhaps, but beware that in US English, this is bizarre usage.  Faculty
> > refers to the set of people that are professors, not a place, and not a
> > subdivision of a university.
> > ...
> >
> > I'm sure other universities contain within them colleges, and I suspect
> > "school" is fairly common.
> >
> > Really my point is that "Faculty of mathematics" is going to be
> > confusing to en_US speakers.  I have no idea if it's used in en_GB, but
> > I've never heard of it.
>
> As a counterpoint, at my en_CA university established in 1957 we did
> have faculties in the sense used by Mateusz. Schools were generally
> ordered lower than faculties: School of Architecture was part of
> Faculty of Engineering. Most sub-parts of faculties were named
> Departments.
>
> --Jarek
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging