Re: [Tagging] How to tag an utilitarian fountain?

[European Water Project]

Hi Martin

Beautiful...

amenity=fountain & drinking_water =yes
fountain =sarcophagus,

But either way 

Please add pictures to Wikimedia commons as possible and link back to each
node.  I would be happy to help.

Best Regards,

Stuart


On Fri, Feb 7, 2020, 09:36 Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> Il giorno 7 feb 2020, alle ore 07:01, European Water Project <
> europeanwaterproj...@gmail.com> ha scritto:
>
> This old drinking fountain is harder to classify:
> https://en.wikipedia.org/wiki/File:Fountain_Snow_Hill_Samuel_Gurney..jpg
> Technically just a drinking fountain but it is rather decorative.  Is it
> amenity=water or amenity=fountain + drinking_water=yes?
>
>
>
> the ones I find hard to classify are antique sarcophagus that are
> repurposed as drinking fountains, e.g.
> http://www.romaincamper.it/foto/data/images1/sarcofago-colosseo.jpg
>
> There are several of them in my area, and I think I’ll tag them with
> amenity =drinking water and fountain =sarcophagus
>
> Although one might also see them as fountains, maybe
>
> Cheers Martin
> ___
> 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

[Marc Gemis]

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

regards

m.

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

Re: [Tagging] amenity=faculty?

[Mateusz Konieczny via Tagging]

Feb 6, 2020, 10:14 by lionel.gi...@gmail.com:

> One problem with multipolygon relation is that by definition you can't put > 
> node > it those and you can't put > contiguous buildings>  either
>
Nodes are a problem. 

Contiguous buildings are solvable, but it requires turning buildings into 
multipolygons.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Joseph Eisenberg]

> I still do not understand why area=yes is a bad tag...

> you have problems to implement it in your workflow.

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

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

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

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

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

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

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

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

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

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

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

Re: [Tagging] amenity=faculty?

[Mateusz Konieczny via Tagging]

Thanks for all comments! For now I created 
https://wiki.openstreetmap.org/wiki/Tag:amenity%3Duniversity#Complex_areas
to document complexity discovered during this discussion.

This way we can avoid remaking entire discussion next time and problem is at 
least documented.

Feb 6, 2020, 11:34 by vosc...@gmail.com:

> Sorry, Martin, but what do you do, if you have a big multi-storey building 
> and all you have is the door bell on the street level? Not map it?
> The Tuebingen example illustrates the problem. The relation has two nodes in 
> a multipolygon as outer? That is not kosher either.
> Volker
>
> On Thu, 6 Feb 2020 at 11:21, Martin Koppenhoefer <> dieterdre...@gmail.com> > 
> wrote:
>
>>
>>
>> Am Do., 6. Feb. 2020 um 11:01 Uhr schrieb Volker Schmidt <>> 
>> vosc...@gmail.com>> >:
>>
>>> Padua, Italy, where I live, has a big university spread all over the place. 
>>> This includes smaller sections being in apartments in buildings that are 
>>> mainly used residentially. 
>>>
>>
>>
>> yes, I am also well familiar with universities spread over many different 
>> buildings (or sometimes just a floor of a building although I have not yet 
>> seen an apartment used (for what? Office? lecture room? Probably not as a 
>> lecture hall, would not be suitable)).
>>
>> Common way to map this (unfortunately) is amenity=university on all parts, 
>> e.g. 
>> https://www.openstreetmap.org/way/25074981
>>
>> Here's an example of a (not yet complete and in some parts overcomplete) 
>> multipolygon for the Universität Tübingen: >> 
>> https://www.openstreetmap.org/relation/8639592
>> (curiously, there are also node members ;-) ).
>>
>>  
>>
>>>
>>> With other words "pieces" of the University come in all sizes and shapes, 
>>> from what would be a typical campus to single apartments, where the 
>>> "location" is the building entrance where the university institution is 
>>> only one of many door bells.
>>> And I know that this is true of other universities and research 
>>> establishments. 
>>> This situation made me think of (mis-)using the site relation for tagging.
>>>
>>>
>>
>>
>> yes, but if we keep the small places like the apartment as nodes, it will 
>> not be possible to see that they are small, because a node can be any kind 
>> of size.
>>
>>
>> Cheers,
>> Martin
>> ___
>>  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]

Christoph Hormann :

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


Correct.


> but it quite clearly isn't.


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

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


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

Re: [Tagging] barrier=hedge

[Joseph Eisenberg]

> Zeeland is a bad example, and absolute numbers are low. ...
> Please check Noord-Brabant, Zuid-Holland, Utrecht.

You can do these searches yourself at overpass, eg Utrecht:
http://overpass-turbo.eu/s/Qv7

There are 107 linear hedges in Utrecht, and only 1 mapped as a polygon
(http://www.openstreetmap.org/way/634369167) where it is combined with
leisure=outdoor_seating

But you should also consider how the tag is used in other countries...

- Joseph Eisenberg

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

Re: [Tagging] amenity=faculty?

[Volker Schmidt]

On Fri, 7 Feb 2020 at 10:19, Lionel Giard  wrote:

> The site relation was originally created for groups of features : power
> plant (wind turbine nodes spread over the land or sea), historical sites
> (often only some element (one tower, one building, ...) are historic and
> not the entire place) and parking (especially underground parking with only
> entrance mapped) spread over multiple locations. It fit exactly what is an
> university spread over a city or multiple places. The word "site" may be
> wrong, but that was the one chosen there and could be changed i suppose (i
> don't care for the word used myself ^_^). But creating a new relation type
> which would be with the same specification than a site relation would be a
> bit weird to me. It is overly complex for the usage no ? As the only
> interest is to have one feature in OSM that group all the university part
> and get all the university attribute. Is that really important that it is
> called "site" instead of "institution" ? :p
>
> In any case, it would be interesting to define it correctly in the wiki so
> other mappers can find a "how to map" (either on site relation or a new
> relation if more people are in favour for that). :-)
>

I support this opinion.

Additional use cases, beyond university and research organisations: city
administrations - we have here a number of decentralised admin offices that
use part of commercial buildings (no way to draw a polygon arund them.
All my examples are based on real local situations.
___
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 Friday 07 February 2020, Marc Gemis wrote:
>
> I still do not understand why area=yes is a bad tag.

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

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

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

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

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

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

Re: [Tagging] amenity=faculty?

[Lionel Giard]

The site relation was originally created for groups of features : power
plant (wind turbine nodes spread over the land or sea), historical sites
(often only some element (one tower, one building, ...) are historic and
not the entire place) and parking (especially underground parking with only
entrance mapped) spread over multiple locations. It fit exactly what is an
university spread over a city or multiple places. The word "site" may be
wrong, but that was the one chosen there and could be changed i suppose (i
don't care for the word used myself ^_^). But creating a new relation type
which would be with the same specification than a site relation would be a
bit weird to me. It is overly complex for the usage no ? As the only
interest is to have one feature in OSM that group all the university part
and get all the university attribute. Is that really important that it is
called "site" instead of "institution" ? :p

In any case, it would be interesting to define it correctly in the wiki so
other mappers can find a "how to map" (either on site relation or a new
relation if more people are in favour for that). :-)

Le jeu. 6 févr. 2020 à 12:13, Martin Koppenhoefer 
a écrit :

>
>
> sent from a phone
>
> > Il giorno 6 feb 2020, alle ore 11:37, Volker Schmidt 
> ha scritto:
> >
> > Sorry, Martin, but what do you do, if you have a big multi-storey
> building and all you have is the door bell on the street level? Not map it?
>
>
> that’s indeed a problem with multipolygons ;)
> But you wouldn’t call something a „site“ either that is, hm, many sites,
> would you?
>
>
>
> > The Tuebingen example illustrates the problem. The relation has two
> nodes in a multipolygon as outer? That is not kosher either.
>
>
> Yes, the Tübingen example is far from perfect, it was just an illustration
> for a university with many locations, but there are many details that are
> not kosher (e.g. the streets are not part of the campus, at least the
> unrestricted, public ones, also the nurse residences could be questioned,
> while the library arguably consists also of the grounds, not just the
> building, etc.)
>
> Do we need another kind of relation? If we want an object for the
> university, maybe yes. Adding just a tag like university= the university> on all the parts would maybe do the trick as well? It
> wouldn’t allow for adding details about the university though (e.g.
> start_date, alt_name, wikipedia/wikidata, website, operator, etc.).
>
> Either we could say, a university in or around the same town, seen on a
> global level, is still a “site”, although on the local level it would be
> seen as several sites.
> Or we’d make a more generic kind of new relation for things that belong
> together under a certain point of view (together they form an institution,
> for example public city offices also belong to the same institution and are
> often distributed over the city, or on a national level ministries and
> agencies, there we’re doing it with admin level. For pt routes, there are
> specific route master and network relations.
> Time for an university relation? Or more generically a “type=institution”
> relation?
>
> Cheers Martin
> ___
> 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?

[Volker Schmidt]

"Removing" amenity=drinking_water is to be excluded as an option. It is
used more than 20 times.
Volker

On Thu, 6 Feb 2020 at 17:02, Paul Allen  wrote:

>
>
> On Thu, 6 Feb 2020 at 15:27, António Madeira 
> wrote:
>
>>
>> If, in Britain, a fountain is normally a ornamental fountain, that
>> shouldn't restrict the possibility of widening its meaning to encompass the
>> reality in other countries,
>>
>
> OSM tag names and values use British English where possible.  There's a
> reason
> for that: mappers from around the world are exposed to tag names and
> values and
> they have to know how to interpret them.  This is difficult enough when
> they are
> in British English, but it becomes impossible if mappers have to guess that
> words that are recognizably English are being used with meanings in
> randomly-chosen languages.  It's bad enough having to look up the British
> English meaning, it's even harder to guess which language should be used
> to interpret the tag.  Are we using the French interpretation of
> "fountain" or
> the Italian interpretation or...?
>
> Call it cultural imperialism if you wish, but OSM uses British English for
> tagging.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Peter Elderson]

oseph Eisenberg :

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


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

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


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

Re: [Tagging] How to tag an utilitarian fountain?

[Martin Koppenhoefer]

sent from a phone

> Il giorno 7 feb 2020, alle ore 07:01, European Water Project 
>  ha scritto:
> 
> This old drinking fountain is harder to classify:
> https://en.wikipedia.org/wiki/File:Fountain_Snow_Hill_Samuel_Gurney..jpg
> Technically just a drinking fountain but it is rather decorative.  Is it
> amenity=water or amenity=fountain + drinking_water=yes?


the ones I find hard to classify are antique sarcophagus that are repurposed as 
drinking fountains, e.g. 
http://www.romaincamper.it/foto/data/images1/sarcofago-colosseo.jpg

There are several of them in my area, and I think I’ll tag them with amenity 
=drinking water and fountain =sarcophagus 

Although one might also see them as fountains, maybe 

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

Re: [Tagging] barrier=hedge

[Peter Elderson]

Well, I'm not so good with overpass turbo, but this query gives an
impression:


[out:json][timeout:25];
(
   way["barrier"="hedge"]["area"="yes"]({{bbox}});
);
// print results
out body;
>;
out skel qt;


When I run it on different parts of Nederland and Belgium, it finds many
hedge areas in most parts. Zeeland, not so much.
Data inspection shows these are almost all intentionally mapped hedge
areas. Not leisure/natural/landuse etc.
___
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 Friday 07 February 2020, Peter Elderson wrote:
> E.g. if a solution would be to tag hedge areas as natural=hedge
> or landcover=hedge, then the change path would be for the renderer to
> temporarily render the old AND the new tagging, so mappers can edit
> the old tagging to the new tagging.

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

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

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

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

[Peter Elderson]

Christoph Hormann :

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

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



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

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

[Mateusz Konieczny via Tagging]

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

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

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

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

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

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

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

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

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

Re: [Tagging] barrier=hedge

[marc marc]

Le 07.02.20 à 13:59, Peter Elderson a écrit :
> intentionally mapped hedge areas. Not leisure/natural/landuse etc.

https://overpass-turbo.eu/s/Qwl exclude it
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] How to tag an utilitarian fountain?

[European Water Project]

Hi Paul,

>From what I understand, the US Federal regulation in 1912 was a blanket ban
on all water fountains with reusable metal cups not the fountain itself.

There are also some regulations regarding the nozzle itself on modern
fountains... some of the older ones accumulated dribble which could
projected into the next drinkers mouth... (gross). Needless to say, this is
no longer an issue.

Best regards,

Stuart


On Fri, Feb 7, 2020, 16:00 Paul Allen  wrote:

> On Fri, 7 Feb 2020 at 06:01, European Water Project <
> europeanwaterproj...@gmail.com> wrote:
>
>>
>> The fountain in the picture you show is an old style fountain with a
>> drinking cup who style was banned by Federal Regulation in the US in 1912
>> due to its unsanitary nature.
>>
>
> This one is in the UK, not the US.  But it's probably not a legal source
> of drinking
> water in the UK either.  However, in other countries drinking fountains
> that look
> like that may be legal.
>
> --
> Paul
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] key damage and HOT

[Tod Fitch]

> On Feb 6, 2020, at 10:35 PM, Warin <61sundow...@gmail.com> wrote:
> 
> On 7/2/20 3:47 pm, Graeme Fitzpatrick wrote:
>> 
>> 
>> 
>> On Fri, 7 Feb 2020 at 14:30, Warin <61sundow...@gmail.com 
>> > wrote:
>> Let say a hospital has collapsed.
>> 
>> The crisis mapping page I linked to would have you add the tag 
>> damaged=collapsed to the amenity=hospital.
>> 
>> So the render would render the hospital the same as a fully functional 
>> hospital. That is certainly not want I'd want.
>> 
>> 
>> 
>> Better if life cycle things were rendered .. but different from fully 
>> functional things.
>> 
>> 
>> How about rendering a nice, big red X overlaying the outline of the building 
>> when it's marked as disused! :-)
> 
> Not only buildings.. paths, roads, train stations/tracks shops,  etc. And not 
> only disused, abandoned, razed, etc...
> 
> Rendering is not easy.
> 

+1

Based on the little rendering that I’ve been doing, it seems to me that each 
and every feature may require different treatment when handling lifecycle 
tagging. I handle lifecycle tagging on buildings as there are a number of them 
along some of the trails I hike and they are distinct landmarks so I’d like 
them to be on my hiking focused maps. But my treatment of lifecycle tagging on 
buildings would not be suitable for rendering a ruined railway or highway 
bridge. I’ve yet to hike (and map) a trail that took me within sight of a 
ruined bridge so I haven’t thought about how it could be rendered in a manner 
appropriate to my general map style.

I think a strong argument can be made that the style used to generate the 
“standard” map at https://www.openstreetmap.org/ should ignore ruins:* and, by 
extension, objects that also have “ruins=yes” tags. Though maybe it ought to 
treat disused:* and maybe abandoned:* as null prefixes (i.e. render the same as 
the equivalent *). But for maps where the state of a building or other feature 
is more important, like rendering for HOT, some effort should be made to 
support lifecycle prefixes on as many types of objects as possible.

Cheers,
Tod




signature.asc
Description: Message signed with OpenPGP
___
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 Fri, 7 Feb 2020 at 15:25, Mateusz Konieczny via Tagging <
tagging@openstreetmap.org> wrote:

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

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

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

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

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

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

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

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

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

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

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

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

Re: [Tagging] How to tag an utilitarian fountain?

[European Water Project]

Hi Martin,

Add an image tag or wikimedia commons tag to OSM node or OSM to an image on
Wikimedia commons.

Best regards,

Stuart




On Fri, Feb 7, 2020, 15:29 Martin Koppenhoefer 
wrote:

> Am Fr., 7. Feb. 2020 um 10:00 Uhr schrieb European Water Project <
> europeanwaterproj...@gmail.com>:
>
>>
>> But either way 
>>
>> Please add pictures to Wikimedia commons as possible and link back to
>> each node.  I would be happy to help.
>>
>
>
> do you intend, add a link from wikimedia to osm, or from OSM via the image
> tag to wikimedia?
>
> Cheers,
> Martin
> ___
> 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

[Paul Allen]

On Fri, 7 Feb 2020 at 10:50, Christoph Hormann  wrote:

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

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

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

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

OSM doesn't do joined-up thinking.

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

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

[Paul Allen]

On Fri, 7 Feb 2020 at 10:26, Christoph Hormann  wrote:

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


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

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


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


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


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

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

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

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

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

Re: [Tagging] amenity=faculty?

[Martin Koppenhoefer]

sent from a phone

> Il giorno 7 feb 2020, alle ore 10:19, Lionel Giard  
> ha scritto:
> 
> But creating a new relation type which would be with the same specification 
> than a site relation would be a bit weird to me.


we’ve done this for boundary relations too, which are essentially multipolygons 
plus admin centre roles.
If a new relationtype has similar or the same workings but different semantics, 
it would be a oneliner for data consumers to add support-if they wish.

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]

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

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

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

Re: [Tagging] How to tag an utilitarian fountain?

[Paul Allen]

On Fri, 7 Feb 2020 at 06:01, European Water Project <
europeanwaterproj...@gmail.com> wrote:

>
> The fountain in the picture you show is an old style fountain with a
> drinking cup who style was banned by Federal Regulation in the US in 1912
> due to its unsanitary nature.
>

This one is in the UK, not the US.  But it's probably not a legal source of
drinking
water in the UK either.  However, in other countries drinking fountains
that look
like that may be legal.

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

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

[Mateusz Konieczny via Tagging]

Feb 7, 2020, 15:48 by marc_marc_...@hotmail.com:

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

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

Re: [Tagging] How to tag an utilitarian fountain?

[Martin Koppenhoefer]

Am Fr., 7. Feb. 2020 um 10:00 Uhr schrieb European Water Project <
europeanwaterproj...@gmail.com>:

>
> But either way 
>
> Please add pictures to Wikimedia commons as possible and link back to each
> node.  I would be happy to help.
>


do you intend, add a link from wikimedia to osm, or from OSM via the image
tag to wikimedia?

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

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

[Mateusz Konieczny via Tagging]

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

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

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

lack of rendering is not the blocker

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

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

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

[Peter Elderson]

Mateusz Konieczny via Tagging :

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

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

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

[Martin Koppenhoefer]

Am Fr., 7. Feb. 2020 um 11:03 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

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


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



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



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



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



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



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


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


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


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




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



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



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



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

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

[Martin Koppenhoefer]

Am Fr., 7. Feb. 2020 um 11:26 Uhr schrieb Christoph Hormann :

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



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


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



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



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



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