Re: [Tagging] Query regarding seasonal tag combined for outdoor water fountains.

2020-01-15 Thread European Water Project
>
>3. Re: Query regarding seasonal tag combined for outdoor water
>   fountains. (Joseph Eisenberg)
>  Joseph, of all the suggestions I have seen. Open hours seems the
> cleanest and least ambiguous




>5. Re: Query regarding seasonal tag combined for outdoor water
>   fountains. (Jarek Piórkowski)
>     Jarek, I think preferable to avoid seasons on open hours and put
> month range to avoid Northern/Southern hemisphere confusion. What do you
> think?
>
 --

>
> Message: 3
> Date: Thu, 16 Jan 2020 10:52:29 +0900
> From: Joseph Eisenberg 
> To: "Tag discussion, strategy and related tools"
> 
> Subject: Re: [Tagging] Query regarding seasonal tag combined for
> outdoor water fountains.
> Message-ID:
>  x5bzo6rqxhmild...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> > seasonal=summer
>
> Well, this is the problem with the tag "seasonal" - it's not 100%
> clear if "seasonal=summer" means "this feature is only available in
> the summer" or "this feature is NOT available in the summer".
>
> As mentioned on the wiki page "Note these values can be ambiguous for
> features that that vary between different states since it can be
> unclear which state occurs at which time of the year."
>
> For a drinking fountain I would assume that "seasonal=summer" meant
> "available only in summer), but for a natural spring in a hot,
> dry-summer climate, I would have to assume that "seasonal=summer" is a
> mistake which meant "not present in summer", though it should have
> been tagged "seasonal=autumn;winter;spring" perhaps.
>
> And here in the tropics it is every more confusing to interpret
> "seasonal=wet_season" and "seasonal=dry_season" - one expects
> "seasonal=dry_season" for roads and "seasonal=wet_season" for rivers,
> but this is not always used properly.
>
> The simple "seasonal=yes/no" is at least clear, though with natural
> features "intermittent=yes/no" is more common and has a similar
> meaning.
>
> On 1/16/20, Jarek Piórkowski  wrote:
> > On Wed, 15 Jan 2020 at 01:19, Joseph Eisenberg
> >  wrote:
> >> On 1/15/20, European Water Project 
> wrote:
> >> > Would it be appropriate to use the tag "seasonal" for a water fountain
> >> > (whether tagged as "amenity=drinking_water" or "amenity = fountain and
> >> > drinking_water = yes" )?
> >>
> >> Since drinking fountains are man-made rather than natural features,
> >> they usually have a date when they are turned on or off.
> >> ...
> >> For a drinking fountain which is turned on sometime in April and is
> >> turned off sometime in November, you can use "opening_hours=Apr-Nov".
> >>
> >> If the fountain or drinking fountain will be turned on April 10th and
> >> turned off November 25th, you would use "opening_hours=Apr 10-Nov 25"
> >
> > What is the recommendation in cases where the months when they are
> > turned on and off are not easily determined? I have been thinking of
> > seasonal=summer but happy to take a better tag instead.
> >
> > Thanks,
> > --Jarek
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> >
>
>
>
>
> Message: 5
> Date: Wed, 15 Jan 2020 21:14:45 -0500
> From: Jarek Piórkowski 
> To: "Tag discussion, strategy and related tools"
> 
> Subject: Re: [Tagging] Query regarding seasonal tag combined for
> outdoor water fountains.
> Message-ID:
>  9eksxog9bgy18xg6nsxu_aerzg56...@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Wed, 15 Jan 2020 at 20:52, Joseph Eisenberg
>  wrote:
> > > seasonal=summer
> >
> > Well, this is the problem with the tag "seasonal" - it's not 100%
> > clear if "seasonal=summer" means "this feature is only available in
> > the summer" or "this feature is NOT available in the summer".
>
> Ah, good point! So I guess for a drinking fountain seasonal=yes is the
> most reasonable when I don't know the months when it's active (I'm in
> a climate that freezes, so they get shut down sometime before that).
> That's decently human-readable and I'd guess most people will guess
> right when informed that the fountain is "seasonal".
>
> Unfortunately I've just now started noticing that these are shut off
> and while I guess they were actually shut down closer to November...
>
> I was also thinking about public toilets that get closed off in the
> winter (I think because they're not heated, so no water in winter?) -
> I guess opening_hours=off @ (winter) is the best we can do if we don't
> know when they are closed off.
>
> (I'm keeping in mind that "winter" isn't unambiguous, but I hope
> software can apply a rough preset based on hemisphere in which the
> feature is located?)
>
> --Jarek
>
>
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Cooker or Stove in the kitchen?

2020-01-15 Thread Graeme Fitzpatrick
On Thu, 16 Jan 2020 at 10:26, Joseph Eisenberg 
wrote:

> British English speakers:
>

I hope Australian English counts? :-)


> If you are mapping a device which burns fuel or uses electricity to
> cook food in a pot or pan, is this a "cooker" or a "stove" or
> something else?
>

They're stoves out here - electric stove, gas stove etc


> What if it has an oven included, or doesn't?
>

One piece unit is still a stove, or if it's separate there's a stove & an
oven

  Thanks

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


Re: [Tagging] Query regarding seasonal tag combined for outdoor water fountains.

2020-01-15 Thread Jarek Piórkowski
On Wed, 15 Jan 2020 at 20:52, Joseph Eisenberg
 wrote:
> > seasonal=summer
>
> Well, this is the problem with the tag "seasonal" - it's not 100%
> clear if "seasonal=summer" means "this feature is only available in
> the summer" or "this feature is NOT available in the summer".

Ah, good point! So I guess for a drinking fountain seasonal=yes is the
most reasonable when I don't know the months when it's active (I'm in
a climate that freezes, so they get shut down sometime before that).
That's decently human-readable and I'd guess most people will guess
right when informed that the fountain is "seasonal".

Unfortunately I've just now started noticing that these are shut off
and while I guess they were actually shut down closer to November...

I was also thinking about public toilets that get closed off in the
winter (I think because they're not heated, so no water in winter?) -
I guess opening_hours=off @ (winter) is the best we can do if we don't
know when they are closed off.

(I'm keeping in mind that "winter" isn't unambiguous, but I hope
software can apply a rough preset based on hemisphere in which the
feature is located?)

--Jarek

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


Re: [Tagging] Cooker or Stove in the kitchen?

2020-01-15 Thread Paul Allen
On Thu, 16 Jan 2020 at 01:49, Joseph Eisenberg 
wrote:

> Ok, so a propane or butane "camping stove" is a "hob", not a "cooker",
> since it lacks an oven?
>

Didn't think about those.  Probably a camping stove, even in British
English.
There's a lot of cross-cultural contamination. :)

Cooker generally means an oven with hob.  Without an oven, it's not a
cooker.
Without a hob, it's probably just an oven to most people.

>
> I suppose "stove" is used for wood and coal-fueled heating devices too?
>

For heating devices, yes, although "wood burner" or "log burner" are also
common (but not "coal burner" AFAIK).  For coal burners with glass windows,
most people would call them fires.

And just to show how illogical we Brits are, an electrical heater with
elements
that glow red is usually called an electric fire.  Some even have tacky
flame
effects, but even without the flame effects it's still an electric fire.

We also have electric heaters that have no visible elements and which heat
internal
bricks using cheap-rate electricity, known as storage heaters.  Needs a
special
meter with a time clock, and an electricity supplier that offers cheaper
rates
off peak.

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


Re: [Tagging] Query regarding seasonal tag combined for outdoor water fountains.

2020-01-15 Thread Joseph Eisenberg
> seasonal=summer

Well, this is the problem with the tag "seasonal" - it's not 100%
clear if "seasonal=summer" means "this feature is only available in
the summer" or "this feature is NOT available in the summer".

As mentioned on the wiki page "Note these values can be ambiguous for
features that that vary between different states since it can be
unclear which state occurs at which time of the year."

For a drinking fountain I would assume that "seasonal=summer" meant
"available only in summer), but for a natural spring in a hot,
dry-summer climate, I would have to assume that "seasonal=summer" is a
mistake which meant "not present in summer", though it should have
been tagged "seasonal=autumn;winter;spring" perhaps.

And here in the tropics it is every more confusing to interpret
"seasonal=wet_season" and "seasonal=dry_season" - one expects
"seasonal=dry_season" for roads and "seasonal=wet_season" for rivers,
but this is not always used properly.

The simple "seasonal=yes/no" is at least clear, though with natural
features "intermittent=yes/no" is more common and has a similar
meaning.

On 1/16/20, Jarek Piórkowski  wrote:
> On Wed, 15 Jan 2020 at 01:19, Joseph Eisenberg
>  wrote:
>> On 1/15/20, European Water Project  wrote:
>> > Would it be appropriate to use the tag "seasonal" for a water fountain
>> > (whether tagged as "amenity=drinking_water" or "amenity = fountain and
>> > drinking_water = yes" )?
>>
>> Since drinking fountains are man-made rather than natural features,
>> they usually have a date when they are turned on or off.
>> ...
>> For a drinking fountain which is turned on sometime in April and is
>> turned off sometime in November, you can use "opening_hours=Apr-Nov".
>>
>> If the fountain or drinking fountain will be turned on April 10th and
>> turned off November 25th, you would use "opening_hours=Apr 10-Nov 25"
>
> What is the recommendation in cases where the months when they are
> turned on and off are not easily determined? I have been thinking of
> seasonal=summer but happy to take a better tag instead.
>
> Thanks,
> --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


Re: [Tagging] Cooker or Stove in the kitchen?

2020-01-15 Thread Joseph Eisenberg
Ok, so a propane or butane "camping stove" is a "hob", not a "cooker",
since it lacks an oven?

I suppose "stove" is used for wood and coal-fueled heating devices too?

-Joseph

On 1/16/20, Paul Allen  wrote:
> On Thu, 16 Jan 2020 at 00:26, Joseph Eisenberg 
> wrote:
>
>> British English speakers:
>>
>> If you are mapping a device which burns fuel or uses electricity to
>> cook food in a pot or pan, is this a "cooker" or a "stove" or
>> something else?
>>
>> What if it has an oven included, or doesn't?
>>
>
> With oven, and using electricity or gas, a cooker.  Without an oven, using
> electricity or gas, a hot plate or hob (US English means something
> completely
> different by "hob").
>
> Wood or coal-burning, a stove.  Which used to be use for the electric and
> gas variants too, but it seems to have dropped out of British English
> (well,
> my idiolect) except for wood/coal burners.  And even then, the wood/coal
> burner might be called a cooker anyway.  Or an Aga or other brand name.
>
> Oh, and then there are microwaves, slow cookers, etc.
>
> --
> Paul
>

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


Re: [Tagging] How to tag Landscaping tarpaper / weedblocking paper

2020-01-15 Thread Joseph Eisenberg
This sound like a surface=* feature, since it isn't a landuse or
natural vegetation type.

Plastic sheeting is also used on some types of farmland, for example
strawberry fields, for weed prevention.

So map the area's function with landuse=railway/industrial/farmland or
natural=scree/sand/etc. or area:highway=, or whatever is relevant, and
then add surface=plastic_sheeting, surface=tar_paper, etc.

If you don't know the landuse or function, and there is no natural
vegetation, I would use surface=* alone.

On 1/16/20, Warin <61sundow...@gmail.com> wrote:
> On 16/1/20 11:59 am, John Willis via Tagging wrote:
>> here in Japan and other places where unwanted vegetation grows very
>> quickly and/or has heavy rain, heavy tar paper / plastic or metal mesh /
>> or plastic “weedblocking” sheeting is commonly used on embankments,
>> traffic islands, and other places where people want to stop weeds from
>> growing and to prevent erosion from heavy rain. Stakes or landscaping
>> staples hold it in place, and sometimes seams are sealed with additional
>> material (if the barrier is for weedblocking).  It is commonly seen in
>> industrial settings (areas around factories), and in public areas around
>> roads and other transportation infrastructure where people don’t walk.
>> this is a permanent landcover, not temporary covering for construction,
>> etc.
>>
>> While I admit it is rare to tag a lot of this, when mapping public areas
>> around some roads, I have found more and more of it.
>>
>> looking in surface= and landcover= , I cant find anything that matches.
>> “tar paper” as a roofing material is on the wiki, but noting else about
>> “landscaping” or “weedblocking” is found.
>>
>> What do people suggest is a good name to add to “surface” or “landcover”
>> for such a surface?
>>
>> Looking around the internet, there is a large variety of “erosion control”
>> sheeting and materials (this tar paper, plastic & metal mesh, and other
>> landcovers meant to control erosion on slopes), so perhaps a tag for all
>> of them is appropriate.
>>
>> Perhaps landcover=erosion_control is a good tag for all of these types of
>> sheeting applied to the ground. if a further refinement is needed (and
>> someone knows the proper names for these things, then a subtag can be
>> added later  (erosion_control=foo_bar).
>
>
> Different things ;
>
> erosion control,
>
> weed block.
>
> The weed block plastic here is called 'weed mat', it is designed so as not
> to allow sunlight through, well not enough for a plant to grow.
>
> On a steep slope it will do nothing for erosion control as it sits above the
> soil. I have a few square meters of it at home.
>
> Erosion control may well allow enough sunlight through to enable plants to
> grow .. including weeds.
>
>
>
>

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


Re: [Tagging] building=disused

2020-01-15 Thread Paul Allen
On Thu, 16 Jan 2020 at 01:24, Warin <61sundow...@gmail.com> wrote:

My thinking is that both 'disused=yes' and 'disused:*=* tag the same
> condition. As such they should be treated equally by renders.
>

And my thinking is that there is a difference between a disused building
(it's
still a building) and a disused place of worship (it's no longer a place of
worship).  It is misleading to render a disused building as though the
building
did not exist.  It is misleading to render a disused place of worship as
though
it is still a place of worship.  Disused physical objects merit different
treatment from disused functions.

> The only reason why there is a preference for 'disused=yes' is that the
> present 'standard' render is ignoring it.
>
Yep.  Freely admitted.

> If you want physical objects with tagging for disused, abandoned, etc
> rendered on the 'standard' map then put a pull request in.
>
I suggested that as an alternative the last time this was discussed.  I'm
happy
to use disused=yes as things stand at present and I'd be happy to use the
disused prefix if it no longer prevented the rendering of physical
objects.  Either
way is fine by me.

However, it seems that two people from the carto crowd think disused=yes is
the way to go.  Maybe there are others in the carto crowd who think it
better
to have the disused prefix behave differently for physical objects.  That's
one
of the reasons I'd like some sort of assurance that minds have been made up.

> Stop tagging for the render.
>
I'm not lying for the renderer.  I'm using one established way of tagging
something
in preference to a different, established way of tagging that thing.  So
are others.

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


Re: [Tagging] building=disused

2020-01-15 Thread Warin

On 16/1/20 12:08 pm, Paul Allen wrote:
On Thu, 16 Jan 2020 at 00:49, Joseph Eisenberg 
mailto:joseph.eisenb...@gmail.com>> wrote:


I'm one of the maintainers of the Openstreetmap-carto style, but I
think the community should make tagging decisions based on what works
best for mappers and what makes logical sense, without worrying what a
particular renderer will do.


Ummm, but what makes sense depends upon what popularly-used renderers
do, especially if there are two ways of doing things which renderers treat
differently.  If I map things that standard carto doesn't show, I 
can't spot

my mistakes.



If the 'standard map' starts rendering 'disused=yes' the same way as 
'disused:*=*' (presently not rendered) then what?




In this case I believe the decision to "deprecate" the tag disused=yes
was made hastily without thinking clearly about the cases when it
would make sense.


That seems likely, now you've explained the history.  It also applies to
abandoned and other lifecycle prefixes.



The problem is not with the tagging. The problem is with your 
requirement for rendering.



But this is not always sensible in the case of physical features like
a disused man_made=water_tower - the feature looks the same whether or
not it is full of water, and general database/map users are interested
in these features as orientations points in the landscape, not as part
of the water supply network, so it's sensible to use
man_made=water_tower + disused=yes.


That matches my thinking on the issue.  Others seem to agree.

So, at the very least, the wiki needs to be amended. However, I'd feel
happier if there were some assurance that we wouldn't have to amend
the wiki yet again at some future point because somebody at standard
carto decided that anything with disused=yes shouldn't be rendered.  An
assurance like that might also persuade other cartos to do the same
thing.




My thinking is that both 'disused=yes' and 'disused:*=* tag the same 
condition. As such they should be treated equally by renders.


The only reason why there is a preference for 'disused=yes' is that the 
present 'standard' render is ignoring it.


If you want physical objects with tagging for disused, abandoned, etc 
rendered on the 'standard' map then put a pull request in.


Stop tagging for the render.

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


Re: [Tagging] How to tag Landscaping tarpaper / weedblocking paper

2020-01-15 Thread Warin

On 16/1/20 11:59 am, John Willis via Tagging wrote:

here in Japan and other places where unwanted vegetation grows very quickly 
and/or has heavy rain, heavy tar paper / plastic or metal mesh / or plastic 
“weedblocking” sheeting is commonly used on embankments, traffic islands, and 
other places where people want to stop weeds from growing and to prevent 
erosion from heavy rain. Stakes or landscaping staples hold it in place, and 
sometimes seams are sealed with additional material (if the barrier is for 
weedblocking).  It is commonly seen in industrial settings (areas around 
factories), and in public areas around roads and other transportation 
infrastructure where people don’t walk. this is a permanent landcover, not 
temporary covering for construction, etc.

While I admit it is rare to tag a lot of this, when mapping public areas around 
some roads, I have found more and more of it.

looking in surface= and landcover= , I cant find anything that matches. “tar 
paper” as a roofing material is on the wiki, but noting else about 
“landscaping” or “weedblocking” is found.

What do people suggest is a good name to add to “surface” or “landcover” for 
such a surface?

Looking around the internet, there is a large variety of “erosion control” sheeting 
and materials (this tar paper, plastic & metal mesh, and other landcovers meant 
to control erosion on slopes), so perhaps a tag for all of them is appropriate.

Perhaps landcover=erosion_control is a good tag for all of these types of 
sheeting applied to the ground. if a further refinement is needed (and someone 
knows the proper names for these things, then a subtag can be added later  
(erosion_control=foo_bar).



Different things ;

erosion control,

weed block.

The weed block plastic here is called 'weed mat', it is designed so as not to 
allow sunlight through, well not enough for a plant to grow.

On a steep slope it will do nothing for erosion control as it sits above the 
soil. I have a few square meters of it at home.

Erosion control may well allow enough sunlight through to enable plants to grow 
.. including weeds.



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


Re: [Tagging] building=disused

2020-01-15 Thread Paul Allen
On Thu, 16 Jan 2020 at 00:49, Joseph Eisenberg 
wrote:

> I'm one of the maintainers of the Openstreetmap-carto style, but I
> think the community should make tagging decisions based on what works
> best for mappers and what makes logical sense, without worrying what a
> particular renderer will do.
>

Ummm, but what makes sense depends upon what popularly-used renderers
do, especially if there are two ways of doing things which renderers treat
differently.  If I map things that standard carto doesn't show, I can't spot
my mistakes.

>
> In this case I believe the decision to "deprecate" the tag disused=yes
> was made hastily without thinking clearly about the cases when it
> would make sense.
>

That seems likely, now you've explained the history.  It also applies to
abandoned and other lifecycle prefixes.


> But this is not always sensible in the case of physical features like
> a disused man_made=water_tower - the feature looks the same whether or
> not it is full of water, and general database/map users are interested
> in these features as orientations points in the landscape, not as part
> of the water supply network, so it's sensible to use
> man_made=water_tower + disused=yes.
>

That matches my thinking on the issue.  Others seem to agree.

So, at the very least, the wiki needs to be amended.  However, I'd feel
happier if there were some assurance that we wouldn't have to amend
the wiki yet again at some future point because somebody at standard
carto decided that anything with disused=yes shouldn't be rendered.  An
assurance like that might also persuade other cartos to do the same
thing.

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


[Tagging] How to tag Landscaping tarpaper / weedblocking paper

2020-01-15 Thread John Willis via Tagging
here in Japan and other places where unwanted vegetation grows very quickly 
and/or has heavy rain, heavy tar paper / plastic or metal mesh / or plastic 
“weedblocking” sheeting is commonly used on embankments, traffic islands, and 
other places where people want to stop weeds from growing and to prevent 
erosion from heavy rain. Stakes or landscaping staples hold it in place, and 
sometimes seams are sealed with additional material (if the barrier is for 
weedblocking).  It is commonly seen in industrial settings (areas around 
factories), and in public areas around roads and other transportation 
infrastructure where people don’t walk. this is a permanent landcover, not 
temporary covering for construction, etc. 

While I admit it is rare to tag a lot of this, when mapping public areas around 
some roads, I have found more and more of it. 

looking in surface= and landcover= , I cant find anything that matches. “tar 
paper” as a roofing material is on the wiki, but noting else about 
“landscaping” or “weedblocking” is found. 

What do people suggest is a good name to add to “surface” or “landcover” for 
such a surface? 

Looking around the internet, there is a large variety of “erosion control” 
sheeting and materials (this tar paper, plastic & metal mesh, and other 
landcovers meant to control erosion on slopes), so perhaps a tag for all of 
them is appropriate. 

Perhaps landcover=erosion_control is a good tag for all of these types of 
sheeting applied to the ground. if a further refinement is needed (and someone 
knows the proper names for these things, then a subtag can be added later  
(erosion_control=foo_bar).

Thoughts?

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


Re: [Tagging] building=disused

2020-01-15 Thread Joseph Eisenberg
I'm one of the maintainers of the Openstreetmap-carto style, but I
think the community should make tagging decisions based on what works
best for mappers and what makes logical sense, without worrying what a
particular renderer will do.

In this case I believe the decision to "deprecate" the tag disused=yes
was made hastily without thinking clearly about the cases when it
would make sense.

Looking at the history, it appears that back in 2011 a certain user
wanted to get "disused=yes" rendered, but was told it was a bad idea
as the general way to tag a disused feature, including functional
amenities and services like amenity=drinking_water, shop=, etc. The
community pointed out that this would be a problem because most
database users would not interpret the disused=yes tag, so it would be
better to use "disused:amenity=" and "disused:shop=" instead. So then
the wiki page was changed to suggest using disused: instead and
eventually a strong warning was added to never use disused=yes.

see 
https://wiki.openstreetmap.org/w/index.php?title=Key%3Adisused%3A=revision=646737=532373
and later it was moved to the namespace:
https://wiki.openstreetmap.org/w/index.php?title=Key%3Adisused%3A=revision=879007=839686

But this is not always sensible in the case of physical features like
a disused man_made=water_tower - the feature looks the same whether or
not it is full of water, and general database/map users are interested
in these features as orientations points in the landscape, not as part
of the water supply network, so it's sensible to use
man_made=water_tower + disused=yes.

I think part of the confusion was caused by moving the Key:disabled
(e.g. "disabled=yes") page straight to the namespaced version without
clarifying things. But disabled=yes should never have been described
as deprecated - it was always being used.

- Joseph Eisenberg

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


Re: [Tagging] Query regarding seasonal tag combined for outdoor water fountains.

2020-01-15 Thread Jarek Piórkowski
On Wed, 15 Jan 2020 at 01:19, Joseph Eisenberg
 wrote:
> On 1/15/20, European Water Project  wrote:
> > Would it be appropriate to use the tag "seasonal" for a water fountain
> > (whether tagged as "amenity=drinking_water" or "amenity = fountain and
> > drinking_water = yes" )?
>
> Since drinking fountains are man-made rather than natural features,
> they usually have a date when they are turned on or off.
> ...
> For a drinking fountain which is turned on sometime in April and is
> turned off sometime in November, you can use "opening_hours=Apr-Nov".
>
> If the fountain or drinking fountain will be turned on April 10th and
> turned off November 25th, you would use "opening_hours=Apr 10-Nov 25"

What is the recommendation in cases where the months when they are
turned on and off are not easily determined? I have been thinking of
seasonal=summer but happy to take a better tag instead.

Thanks,
--Jarek

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


Re: [Tagging] Cooker or Stove in the kitchen?

2020-01-15 Thread Paul Allen
On Thu, 16 Jan 2020 at 00:26, Joseph Eisenberg 
wrote:

> British English speakers:
>
> If you are mapping a device which burns fuel or uses electricity to
> cook food in a pot or pan, is this a "cooker" or a "stove" or
> something else?
>
> What if it has an oven included, or doesn't?
>

With oven, and using electricity or gas, a cooker.  Without an oven, using
electricity or gas, a hot plate or hob (US English means something
completely
different by "hob").

Wood or coal-burning, a stove.  Which used to be use for the electric and
gas variants too, but it seems to have dropped out of British English (well,
my idiolect) except for wood/coal burners.  And even then, the wood/coal
burner might be called a cooker anyway.  Or an Aga or other brand name.

Oh, and then there are microwaves, slow cookers, etc.

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


[Tagging] Cooker or Stove in the kitchen?

2020-01-15 Thread Joseph Eisenberg
British English speakers:

If you are mapping a device which burns fuel or uses electricity to
cook food in a pot or pan, is this a "cooker" or a "stove" or
something else?

What if it has an oven included, or doesn't?

- Joseph Eisenberg

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


Re: [Tagging] Tagging Free Water for cafés, bars, restaurant

2020-01-15 Thread Joseph Eisenberg
Thank you for pointing out the tag "drinking_water=yes/no"

Looking at the wiki page for this tag and for the related tag
amenity=drinking_water, it is strongly implied that this is for a
drinking water supply which is self-service.

Examples include water taps, drinking fountains, wells, and springs.
Features where this is commonly used include camping and wilderness
accomodations.

So it may be reasonable to have a different tag for the situation
where the drinking water is only available by requesting it from the
employees of a business.

I note that "drinking_water:fee" is not mentioned at
"Key:drinking_water" or "Tag:amenity=drinking_water" pages, and it has
only been used 7 times.

The only place that drinking_water:fee is mentioned is as an idea at
https://wiki.openstreetmap.org/wiki/Key:free_refill - the
"free_refill" proposal.

So I think a new tag like "free_water=" is sensible, since
"amenity=drinking_water" and "drinking_water=yes" have previously been
assumed to be both free of charge and accessible to the public without
needing to ask special permission.

- Joseph Eisenberg

On 1/16/20, Florimond Berthoux  wrote:
> Because https://wiki.openstreetmap.org/wiki/Any_tags_you_like
> Tags are already defined and used.
> free_water would be in conflict with tags fee and drinking_water.
> free_water is two words with two concepts (price and service)
> drinking_water:fee use the usual main:sub_propertie tagging pattern
>
> I have no opinion about container, but I can remember an old discussion
> about tagging the property of street food shop where you are able to bring
> you own "container" (food box).
> In my pattern it would be drinking_water:container=*
>
> Le mer. 15 janv. 2020 à 22:09, European Water Project <
> europeanwaterproj...@gmail.com> a écrit :
>>>
>>> 5. Re:  Tagging Free Water for cafés, bars, restaurant
>>>   (Florimond Berthoux)
>>>  Hello Florimond, While I don't necessarily feel the solution you
> propose is preferable, I do share your love of KISS though.
>>
>>
>> I have tried to fairly incorporate the main feedback from the tagging
> maillist discussion.
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Free_Water
>>
>> Why do you think your proposal is preferred to the one outlined in the
> draft proposal ?
>> free_water = 
>> free_water:container =
>>
>> Best regards,
>>
>> Stuart
>>
>>
>> -
>>>
>>>
>>> Message: 5
>>> Date: Wed, 15 Jan 2020 20:25:53 +0100
>>> From: Florimond Berthoux 
>>> To: "Tag discussion, strategy and related tools"
>>> 
>>> Subject: Re: [Tagging]  Tagging Free Water for cafés, bars,
>>> restaurant
>>> Message-ID:
>>>  nj7xbjp5htdah1zw9gfxhwh8c0jd...@mail.gmail.com>
>>> Content-Type: text/plain; charset="utf-8"
>>>
>>> Hi, I go quickly through the email thread and didn't saw the simple
>>> solution:
>>>
>>> use drinking_water
>>> https://wiki.openstreetmap.org/wiki/Key:drinking_water
>>> «drinking_water=* indicates whether a feature provides drinking water,
>>> specifically whether water is drinkable for humans. »
>>> So if a cafe provide the service of supplying drinking water, I would
>>> use
>>> the usual access values with this key
>>> drinking_water=yes/no/private/...
>>>
>>> and use fee
>>> https://wiki.openstreetmap.org/wiki/Key:fee
>>> «The fee tag is for specifying whether a fee is usually charged for a
>>> service, or for access. »
>>> the service here is the drinking water so
>>> drinking_water:fee=yes/no
>>> And if more precision is needed use drinking_water:fee:conditional=*
>>>
>>> Of course most of the cafe give drinking water (though may be not
>>> completely drinkable...) so drinking_water can be optional here.
>>>
>>> No new tag is needed here, KISS ;)
>>>
>>> Le lun. 13 janv. 2020 à 10:20, European Water Project <
>>> europeanwaterproj...@gmail.com> a écrit :
>>>
>>> > Dear All,
>>> >
>>> > I thought this subject could wait, but it is becoming pressing early
> than
>>> > I expected.
>>> >
>>> > As part of our project (and that of similar non-profits - most of
>>> > which
>>> > are not open data but nevertheless great organisations), we want to
>>> > voluntarily encourage cafés, bars and restaurants to offer free tap
> water
>>> > bottle refill to anyone off the street.  Refill has had significant
> success
>>> > in the UK and surprising the feedback is that the impact of increased
>>> > customer traffic far outweighs any issue of cannibalization.
>>> >
>>> > If it is not already the case, could we develop a tagging standard for
>>> > this case. Maybe "amenity = cafe & free_water = yes"
>>> >
>>> > It would be important to develop at the same time a distinct tag for
>>> > another cause, which we support but will not be targeting is
> restaurants
>>> > which offer free tap water for paying customers.
>>> > Maybe "amenity = restuarant & free_carafe = yes"
>>> >
>>> > Many thanks,
>>> >
>>> > Stuart
>>> >
>>> > PS :
>>> >
>>> > The European Water Project progressive web app powered 

Re: [Tagging] Tagging Free Water for cafés, bars, restaurant

2020-01-15 Thread Florimond Berthoux
Because https://wiki.openstreetmap.org/wiki/Any_tags_you_like
Tags are already defined and used.
free_water would be in conflict with tags fee and drinking_water.
free_water is two words with two concepts (price and service)
drinking_water:fee use the usual main:sub_propertie tagging pattern

I have no opinion about container, but I can remember an old discussion
about tagging the property of street food shop where you are able to bring
you own "container" (food box).
In my pattern it would be drinking_water:container=*

Le mer. 15 janv. 2020 à 22:09, European Water Project <
europeanwaterproj...@gmail.com> a écrit :
>>
>> 5. Re:  Tagging Free Water for cafés, bars, restaurant
>>   (Florimond Berthoux)
>>  Hello Florimond, While I don't necessarily feel the solution you
propose is preferable, I do share your love of KISS though.
>
>
> I have tried to fairly incorporate the main feedback from the tagging
maillist discussion.
> https://wiki.openstreetmap.org/wiki/Proposed_features/Free_Water
>
> Why do you think your proposal is preferred to the one outlined in the
draft proposal ?
> free_water = 
> free_water:container =
>
> Best regards,
>
> Stuart
>
>
> -
>>
>>
>> Message: 5
>> Date: Wed, 15 Jan 2020 20:25:53 +0100
>> From: Florimond Berthoux 
>> To: "Tag discussion, strategy and related tools"
>> 
>> Subject: Re: [Tagging]  Tagging Free Water for cafés, bars,
>> restaurant
>> Message-ID:
>> 
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hi, I go quickly through the email thread and didn't saw the simple
>> solution:
>>
>> use drinking_water
>> https://wiki.openstreetmap.org/wiki/Key:drinking_water
>> «drinking_water=* indicates whether a feature provides drinking water,
>> specifically whether water is drinkable for humans. »
>> So if a cafe provide the service of supplying drinking water, I would use
>> the usual access values with this key
>> drinking_water=yes/no/private/...
>>
>> and use fee
>> https://wiki.openstreetmap.org/wiki/Key:fee
>> «The fee tag is for specifying whether a fee is usually charged for a
>> service, or for access. »
>> the service here is the drinking water so
>> drinking_water:fee=yes/no
>> And if more precision is needed use drinking_water:fee:conditional=*
>>
>> Of course most of the cafe give drinking water (though may be not
>> completely drinkable...) so drinking_water can be optional here.
>>
>> No new tag is needed here, KISS ;)
>>
>> Le lun. 13 janv. 2020 à 10:20, European Water Project <
>> europeanwaterproj...@gmail.com> a écrit :
>>
>> > Dear All,
>> >
>> > I thought this subject could wait, but it is becoming pressing early
than
>> > I expected.
>> >
>> > As part of our project (and that of similar non-profits - most of which
>> > are not open data but nevertheless great organisations), we want to
>> > voluntarily encourage cafés, bars and restaurants to offer free tap
water
>> > bottle refill to anyone off the street.  Refill has had significant
success
>> > in the UK and surprising the feedback is that the impact of increased
>> > customer traffic far outweighs any issue of cannibalization.
>> >
>> > If it is not already the case, could we develop a tagging standard for
>> > this case. Maybe "amenity = cafe & free_water = yes"
>> >
>> > It would be important to develop at the same time a distinct tag for
>> > another cause, which we support but will not be targeting is
restaurants
>> > which offer free tap water for paying customers.
>> > Maybe "amenity = restuarant & free_carafe = yes"
>> >
>> > Many thanks,
>> >
>> > Stuart
>> >
>> > PS :
>> >
>> > The European Water Project progressive web app powered by
OpenStreetMap,
>> > Wikidata and Wikimedia Commons data can be found :
>> > https://europeanwaterproject.org
>> >
>> >
>> >
>>
>>
>>
>> --
>> Florimond Berthoux
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



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


Re: [Tagging] building=disused

2020-01-15 Thread Peter Elderson
TING

Best,
-- 
Peter Elderson


Op wo 15 jan. 2020 om 22:54 schreef Paul Allen :

> On Wed, 15 Jan 2020 at 21:17, Mateusz Konieczny 
> wrote:
>
> I would not consider disused=yes to be
>> deprecated for physical objects like
>> building, adits, quarries etc.
>>
>
> The wiki for the disused prefix has been amended since the last time this
> came
> up, and a long way down the page, after several mentions that disused=yes
> should
> not be used, it concedes that disused=yes could be used on those objects.
> I would
> suggest that explanation should be expanded to include all physical
> objects and those
> exceptions given the first time disused=yes is mentioned.
>
> OSM Carto will handle such objects,
>> without checking whatever tag disused=yes is set.
>>
>
> English usage of modal verbs has subtle differences from other Germanic
> languages,
> particularly with respect to "will."  OSM carto does currently ignore
> disused=yes.
> Are you telling me that it is guaranteed, by the core developers, that it
> always
> will ignore disused=yes (or, at most, render slightly differently)?  If
> OSM carto
> core developers can give that guarantee then we can amend the wiki
> accordingly,
> describing when it is appropriate to use disused;key=value and when to add
> disused=yes and what the effects of those two approaches will be on
> standard
> carto.
>
> If we have that guarantee, and document it, there's a chance other cartos
> will
> adopt the same approach.  Otherwise all we can do is document that it works
> that way on standard carto today, but there is no guarantee that it will
> work
> in the future.
>
> --
> 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] building=disused

2020-01-15 Thread Paul Allen
On Wed, 15 Jan 2020 at 21:17, Mateusz Konieczny 
wrote:

I would not consider disused=yes to be
> deprecated for physical objects like
> building, adits, quarries etc.
>

The wiki for the disused prefix has been amended since the last time this
came
up, and a long way down the page, after several mentions that disused=yes
should
not be used, it concedes that disused=yes could be used on those objects.
I would
suggest that explanation should be expanded to include all physical objects
and those
exceptions given the first time disused=yes is mentioned.

OSM Carto will handle such objects,
> without checking whatever tag disused=yes is set.
>

English usage of modal verbs has subtle differences from other Germanic
languages,
particularly with respect to "will."  OSM carto does currently ignore
disused=yes.
Are you telling me that it is guaranteed, by the core developers, that it
always
will ignore disused=yes (or, at most, render slightly differently)?  If OSM
carto
core developers can give that guarantee then we can amend the wiki
accordingly,
describing when it is appropriate to use disused;key=value and when to add
disused=yes and what the effects of those two approaches will be on standard
carto.

If we have that guarantee, and document it, there's a chance other cartos
will
adopt the same approach.  Otherwise all we can do is document that it works
that way on standard carto today, but there is no guarantee that it will
work
in the future.

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


Re: [Tagging] building=disused

2020-01-15 Thread Mateusz Konieczny

15 Jan 2020, 21:58 by pla16...@gmail.com:
> Currently, the best you can do is use the deprecated disused=yes for physical
> objects to get the desired behaviour with standard carto.  There is no 
> guarantee
> that other renderers will honour that.  There is no guarantee that standard 
> carto
> will continue to honour that.
>
I would not consider disused=yes to be
deprecated for physical objects like
building, adits, quarries etc.

OSM Carto will handle such objects,
without checking whatever tag disused=yes is set.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Tagging Free Water for cafés, bars, restaurant

2020-01-15 Thread European Water Project
>
> 5. Re:  Tagging Free Water for cafés, bars, restaurant
>   (Florimond Berthoux)
>  Hello Florimond, While I don't necessarily feel the solution you
> propose is preferable, I do share your love of KISS though.
>

I have tried to fairly incorporate the main feedback from the tagging
maillist discussion.
https://wiki.openstreetmap.org/wiki/Proposed_features/Free_Water

Why do you think your proposal is preferred to the one outlined in the
draft proposal ?
free_water = 
free_water:container =

Best regards,

Stuart


-

>
> Message: 5
> Date: Wed, 15 Jan 2020 20:25:53 +0100
> From: Florimond Berthoux 
> To: "Tag discussion, strategy and related tools"
> 
> Subject: Re: [Tagging]  Tagging Free Water for cafés, bars,
> restaurant
> Message-ID:
>  nj7xbjp5htdah1zw9gfxhwh8c0jd...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi, I go quickly through the email thread and didn't saw the simple
> solution:
>
> use drinking_water
> https://wiki.openstreetmap.org/wiki/Key:drinking_water
> «drinking_water=* indicates whether a feature provides drinking water,
> specifically whether water is drinkable for humans. »
> So if a cafe provide the service of supplying drinking water, I would use
> the usual access values with this key
> drinking_water=yes/no/private/...
>
> and use fee
> https://wiki.openstreetmap.org/wiki/Key:fee
> «The fee tag is for specifying whether a fee is usually charged for a
> service, or for access. »
> the service here is the drinking water so
> drinking_water:fee=yes/no
> And if more precision is needed use drinking_water:fee:conditional=*
>
> Of course most of the cafe give drinking water (though may be not
> completely drinkable...) so drinking_water can be optional here.
>
> No new tag is needed here, KISS ;)
>
> Le lun. 13 janv. 2020 à 10:20, European Water Project <
> europeanwaterproj...@gmail.com> a écrit :
>
> > Dear All,
> >
> > I thought this subject could wait, but it is becoming pressing early than
> > I expected.
> >
> > As part of our project (and that of similar non-profits - most of which
> > are not open data but nevertheless great organisations), we want to
> > voluntarily encourage cafés, bars and restaurants to offer free tap water
> > bottle refill to anyone off the street.  Refill has had significant
> success
> > in the UK and surprising the feedback is that the impact of increased
> > customer traffic far outweighs any issue of cannibalization.
> >
> > If it is not already the case, could we develop a tagging standard for
> > this case. Maybe "amenity = cafe & free_water = yes"
> >
> > It would be important to develop at the same time a distinct tag for
> > another cause, which we support but will not be targeting is restaurants
> > which offer free tap water for paying customers.
> > Maybe "amenity = restuarant & free_carafe = yes"
> >
> > Many thanks,
> >
> > Stuart
> >
> > PS :
> >
> > The European Water Project progressive web app powered by OpenStreetMap,
> > Wikidata and Wikimedia Commons data can be found :
> > https://europeanwaterproject.org
> >
> >
> >
>
>
>
> --
> Florimond Berthoux
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] building=disused

2020-01-15 Thread Paul Allen
On Wed, 15 Jan 2020 at 20:39, Warin <61sundow...@gmail.com> wrote:

> If the thing is still physically present then it is still of use from a
> navigation point of view.
>
+1

> From an ease of rendering it would be useful to have a way of rendering
> any disused:* object.
>
For physical objects, yes.  You wouldn't want
disused:amenity=place_of_worship
to be rendered as a place of worship but you do want disused:building=yes
to be
rendered.  Standard carto doesn't work that way, don't know about any of
the others
because as soon as I realized standard carto doesn't work that way, I
stopped
tagging physical objects with a disused: prefix.

Currently, the best you can do is use the deprecated disused=yes for
physical
objects to get the desired behaviour with standard carto.  There is no
guarantee
that other renderers will honour that.  There is no guarantee that standard
carto
will continue to honour that.

Cue the endless arguments about standard carto not being the only fruit,
don't
tag for the renderer, etc.  Because this is OSM, and rule one of OSM is that
we don't do joined-up thinking.  So give up any hope that we'll get an
agreement with the most common renderers to have a sensible way of tagging
disused buildings so that they render at all (better still would be some
sort of
slight difference from buildings that aren't disused, but that will
probably never
happen).

Yes, I'm feeling cynical right now.  That's because I remember the other
times
this has come up here.

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


Re: [Tagging] building=disused

2020-01-15 Thread Warin

On 15/1/20 7:27 pm, Martin Koppenhoefer wrote:
Am Mi., 15. Jan. 2020 um 08:03 Uhr schrieb Marc Gemis 
mailto:marc.ge...@gmail.com>>:


On Wed, Jan 15, 2020 at 5:16 AM Warin <61sundow...@gmail.com
> wrote:
> And that raises another point, how would you render disused
physical objects???

I would say that depends on the purpose of the map. A map that wants
to show buildings that were used as shop, but are now vacant/disused,
might show them very prominent.
A map showing windmills might show working windmills in black and
disused one in grey or without vanes or ...



it generally depends on the kind of object. Some might merit 
rendering, others would better be ignored all together (because 
there's very limited space on the map and they will generally not be 
worth showing even
if there would be sufficient space). On a general purpose map, a 
building is a building, and it doesn't matter whether it is used or 
not (and it could be reused any time), as long as it hasn't 
deteriorated to a ruin (has significantly changed nature), in which 
case a mere "disused" would be not appropriate any more. I am not 
saying it isn't interesting to anybody or there won't be subtle 
differences between an used and an unused building, just that it isn't 
sufficiently significant (IMHO) to merit different treatment.


On the other hand, many amenities, even though they often have a 
physical "body", are not useful or interesting to show at all when 
they are not in use, e.g. telephone booths, mail boxes, drinking 
fountains, generally small items, while bigger items (train stations, 
post offices, quarries etc.) are probably significant enough even for 
a general purpose map to be shown somehow.



If the thing is still physically present then it is still of use from a 
navigation point of view.


From an ease of rendering it would be useful to have a way of rendering 
any disused:* object.


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


Re: [Tagging] Tagging Free Water for cafés, bars, restaurant

2020-01-15 Thread Florimond Berthoux
Hi, I go quickly through the email thread and didn't saw the simple
solution:

use drinking_water
https://wiki.openstreetmap.org/wiki/Key:drinking_water
«drinking_water=* indicates whether a feature provides drinking water,
specifically whether water is drinkable for humans. »
So if a cafe provide the service of supplying drinking water, I would use
the usual access values with this key
drinking_water=yes/no/private/...

and use fee
https://wiki.openstreetmap.org/wiki/Key:fee
«The fee tag is for specifying whether a fee is usually charged for a
service, or for access. »
the service here is the drinking water so
drinking_water:fee=yes/no
And if more precision is needed use drinking_water:fee:conditional=*

Of course most of the cafe give drinking water (though may be not
completely drinkable...) so drinking_water can be optional here.

No new tag is needed here, KISS ;)

Le lun. 13 janv. 2020 à 10:20, European Water Project <
europeanwaterproj...@gmail.com> a écrit :

> Dear All,
>
> I thought this subject could wait, but it is becoming pressing early than
> I expected.
>
> As part of our project (and that of similar non-profits - most of which
> are not open data but nevertheless great organisations), we want to
> voluntarily encourage cafés, bars and restaurants to offer free tap water
> bottle refill to anyone off the street.  Refill has had significant success
> in the UK and surprising the feedback is that the impact of increased
> customer traffic far outweighs any issue of cannibalization.
>
> If it is not already the case, could we develop a tagging standard for
> this case. Maybe "amenity = cafe & free_water = yes"
>
> It would be important to develop at the same time a distinct tag for
> another cause, which we support but will not be targeting is restaurants
> which offer free tap water for paying customers.
> Maybe "amenity = restuarant & free_carafe = yes"
>
> Many thanks,
>
> Stuart
>
> PS :
>
> The European Water Project progressive web app powered by OpenStreetMap,
> Wikidata and Wikimedia Commons data can be found :
> https://europeanwaterproject.org
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


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


Re: [Tagging] recreational vs functional routes

2020-01-15 Thread Florimond Berthoux
Beside my proposal for bicycle subtype route, I read again the tourism wiki
page https://wiki.openstreetmap.org/wiki/Key:tourism
« Places and things of specific interest to tourists including places to
see, places to stay, things and places providing information and support to
tourists. »
and
« tourism=yes : To add tourist interest to something described by other
tags. »

So, if a route is a thing of specific interest to tourist, I see no good
reason to not tag it with tourism=yes.
(And I don't understand why it shouldn't be used on relation since here
it's the route relation which is touristic.)


Le mar. 7 janv. 2020 à 20:24, joost schouppe  a
écrit :

> Hi,
>
> Has there been any previous discussion regarding tagging recreational
> versus functional routes?
>
> Especially for car routes, I haven't seen any way to tag touristic routes
> for driving cars, like the Turist Veger in Norway or the Route des Cols in
> France. It is also of specific interest for cycling. For example, in
> Belgium we have a very dense "node network" for cycling for fun, but those
> routes aren't exactly interesting for commuting. On the other hand, we have
> "cycle highways" which can be boring and focus on actually getting
> somewhere.
>
> In the case of cars, the lack of clarity prevents mapping. In the case of
> cycling, it would be really useful for routers to be able to differentiate.
>
> Similar differences might exist for bus (fpr example for hop-on/hop-off
> tourist buses in cities) and maybe even for walking.
>
> I think maybe another optional tag for route relations might be useful,
> perhaps just function=recreational/practical or something.
>
> --
> Joost Schouppe
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>


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


Re: [Tagging] How to tag oneway restriction applying to pedestrians?

2020-01-15 Thread Martin Koppenhoefer


sent from a phone

> On 15. Jan 2020, at 12:05, Mateusz Konieczny  wrote:
> 
> Pedestrian walking on the carriageway or shoulder is obligated to walk on the 
> left side of the road.


right. Now show me a oneway street that hasn’t a left side ;-)

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


Re: [Tagging] How to revive a tag proposal?

2020-01-15 Thread António Madeira

Às 06:29 de 15/01/2020, Martin Koppenhoefer escreveu:



I would like to make a proper wiki and add that feature to iD


these are 2 completely unrelated actions, for inclusion in iD you do not need a 
wiki entry nor does it influence the decision to add it or not (according to 
one of the maintainers).
You could add a ticket to iD github asking for inclusion in iD.



I am aware of that, but I wouldn't propose something to github without
knowing the correct way of tagging it.




Às 16:23 de 14/01/2020, Markus escreveu:

I'm unsure whether taking over the proposal is a good idea, but you
could write a new proposal (see [1]).

However, note that there is already craft=oil_mill (although not
approved), which could be used together with product=olive_oil. [2]
For big industrial oil mills you may rather want to use man_made=works
+ product=olive_oil.

[1]:https://wiki.openstreetmap.org/wiki/Proposal_process
[2]:https://wiki.openstreetmap.org/wiki/Tag%3Acraft%3Doil_mill

Regards

Markus



I wasn't aware of this proposal, but I like it more than the olive-oil-mill.
Anyway, I can't find any proposal page for it. What would be the correct
way to try and advance with the proposal process? Or should I just
propose it at github's with craft=oil_mill + product=olive_oil?


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


Re: [Tagging] Query regarding seasonal tag combined for outdoor water fountains.

2020-01-15 Thread Jmapb

On 1/15/2020 10:26 AM, marc marc wrote:


Le 15.01.20 à 16:15, Jmapb via Tagging a écrit :


Don't forget about man_made=drinking_fountain!

omg, what's the diff with amenity=drinking_water ?
the direction of water flow upwards?
348 out of 371 objects also have an amenity tag, which
shows the problem.

it would indeed be a good idea not to forget it and to ask the user if
it is a fountain in the osm sense (a bit artistic) or a water jet. and
add the most current tag.


As I understand, amenity=drinking_water is really just referring to the
availability of potable water, and doesn't describe the form. It could
be a a drinking fountain, a bottle filler, spring, a well, a pump, a
water tap on the side of a building, a bottle filler, who knows?

J


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


Re: [Tagging] Query regarding seasonal tag combined for outdoor water fountains.

2020-01-15 Thread Philip Barnes


On Wednesday, 15 January 2020, marc marc wrote:
> Le 15.01.20 à 16:15, Jmapb via Tagging a écrit :
> > On 1/15/2020 12:55 AM, European Water Project wrote:
> >> Would it be appropriate to use the tag "seasonal" for a water fountain
> >> (whether tagged as "amenity=drinking_water" or "amenity = fountain and
> >> drinking_water = yes" )?
> > 
> > Don't forget about man_made=drinking_fountain!
> 
> omg, what's the diff with amenity=drinking_water ?
> the direction of water flow upwards?
> 348 out of 371 objects also have an amenity tag, which
> shows the problem.
> 
> it would indeed be a good idea not to forget it and to ask the user if
> it is a fountain in the osm sense (a bit artistic) or a water jet. and
> add the most current tag.
> 

Drinking fountains, water upwards can be drank from, whereas if the water is 
downwards from a tag a drinking vessel is needed.

Under UK law if the later is provided in the workplace then a supply of cups 
must be provided, the former doesn't.

Phil (trigpoint) 

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


Re: [Tagging] Query regarding seasonal tag combined for outdoor water fountains.

2020-01-15 Thread marc marc
Le 15.01.20 à 16:15, Jmapb via Tagging a écrit :
> On 1/15/2020 12:55 AM, European Water Project wrote:
>> Would it be appropriate to use the tag "seasonal" for a water fountain
>> (whether tagged as "amenity=drinking_water" or "amenity = fountain and
>> drinking_water = yes" )?
> 
> Don't forget about man_made=drinking_fountain!

omg, what's the diff with amenity=drinking_water ?
the direction of water flow upwards?
348 out of 371 objects also have an amenity tag, which
shows the problem.

it would indeed be a good idea not to forget it and to ask the user if
it is a fountain in the osm sense (a bit artistic) or a water jet. and
add the most current tag.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Query regarding seasonal tag combined for outdoor water fountains.

2020-01-15 Thread Jmapb via Tagging

On 1/15/2020 12:55 AM, European Water Project wrote:

Would it be appropriate to use the tag "seasonal" for a water fountain
(whether tagged as "amenity=drinking_water" or "amenity = fountain and
drinking_water = yes" )?


Don't forget about man_made=drinking_fountain!

J


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


Re: [Tagging] Query regarding seasonal tag combined for outdoor water fountains.

2020-01-15 Thread marc marc
Le 15.01.20 à 06:55, European Water Project a écrit :
> Would it be appropriate to use the tag "seasonal" for a water fountain

yes I think so.
I'm going to check/survey the nearby fountains: some are closed
in winter but don't have a precise opening/closing date.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] distance_from_road tag

2020-01-15 Thread marc marc
Of course this tag is a bad idea, which duplicates existing information
in osm and is therefore a source of conflict when one of the 2 data is
capitalized and not the other one.

if not, what next ?
distance_from_bus_stop ?
distance_from_tram_stop train station pub supermarket postoffice town
hall, capital, lake, ocean, forest, school and nearby addr (see
http://taginfo.openstreetmap.ch/keys/location:description:de#values )
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] building=disused

2020-01-15 Thread Mateusz Konieczny
14 Jan 2020, 18:59 by a...@pigsonthewing.org.uk:

> no easily-found documntation for this common use case?
>
BTW, thanks for reporting the issue. I was unaware that
wiki pages for this specific values would be useful.

I also created family of pages for
https://wiki.openstreetmap.org/wiki/Tag:building%3Dunknown
group of other problematic tags and I will probably
create for other similar values.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] distance_from_road tag

2020-01-15 Thread Colin Smale
On 2020-01-15 14:05, Philip Barnes wrote:

> On Wednesday, 15 January 2020, Colin Smale wrote: On 2020-01-15 13:52, Lionel 
> Giard wrote:
> 
> Yes this is something you can do with any distance algorithm in available in 
> any GIS tool. That's not something that i would ever map as it would vary 
> with any geometry change of the ways between the road the point you measure, 
> added to the fact that it add nothing to explicitly map it (in my opinion at 
> least). It is essentially what any routing app will calculate when you ask 
> "find the nearest POI" for example. 
> Surely the question is not about straight-line geometric distance/time
> but about route distance along paths etc. in pedestrian mode. "Nearest"
> is not nearest in terms of geometric distance, but the POI with the
> shortest route.
 It is, but surely in calculating that distance it is easier and better
to simply map the paths? 

Absolutely, but actually a router that can handle routing over a polygon
might be more versatile as it would not be restricted to the lines that
people have mapped as paths. Imagine an algorithm that can take a
polygon (town square, park, whatever), detect all ingress/egress points,
use visibility rules to get round concave bits and obstacles like
fountains and statues, create a temporary routing graph, deduplicate
common segments and otherwise optimise, and use that to route people
across the polygon. In this case the "pedestrian" can be guided to the
target POI without the necessity of having every possible pedestrian
path mapped while still respecting barriers (which we do have in OSM)
such as buildings, walls, fences, ditches etc.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Deleting template parameters copied to data items

2020-01-15 Thread Joseph Eisenberg
I just realized that if you try to edit a wiki data item, it records a
change every time you edit a single line. So if you delete 3
"combinations", you make 3 new edits in the history. I didn't see an
option to add a comment about my edits, but perhaps I missed it.

This makes it nearly impossible to "follow" the wiki data items like
you would follow a Tag: or Key: page.

- Joseph Eisenberg

On 1/15/20, Mateusz Konieczny  wrote:
>
>
>
> 15 Jan 2020, 14:10 by ajt1...@gmail.com:
>
>> On 15/01/2020 12:03, Mateusz Konieczny  wrote:
>>
>>>
>>> 15 Jan 2020, 12:57 by >> marc_marc_...@hotmail.com>> :
>>>
 I'm very unhappywith that.


>>> Please, please comment on the OSM Wiki if you want tocomment.
>>>
>>>
>>
>> What would be useful is a separate discussion about what wiki  "data
>> items" are and why there are a good (or bad) idea.  That  doesn't
>> really belong in >
>> https://wiki.openstreetmap.org/wiki/Talk:Wiki#Transition_to_use_data_items_when_this_can_be_done_without_loosing_information>
>>  because that seems tied up in the specifics of one particular tag
>> (and lets be honest, wiki pages aren't good at threaded  discussion).
>>
>>
> I kind of agree, but I am not someone who started the disussion.
>
> It is complaining about my specific edit as an example but proposes
> something more general.
>
>>
>> Maybe someone who thinks this particular change is a good (or  bad)
>> idea should write a diary entry or create a thread here  explaining
>> what the point of the change is and what the benefits  are, and what
>> the impact on people who use the wiki for reference  and on people who
>> edit it is?
>>
>>
> If someone wants to change current state (remove data from Wiki pages and
> move it somewhere
> else) then they should explain why it is worth doing.
>
> Change should not be done for a sake of change.
>
> Personally, I tried using data items and immediately encountered severe
> problems
> (some listed in the linked wiki discussion).
>
>>
>> There is a page > https://wiki.openstreetmap.org/wiki/Data_items>  but
>> that fails to communicate much of that to me (someone whose  first
>> language is English and has been reading technical  documentation for
>> 40 years).  Until that happens the rest of us  are just going to
>> assume that the OSM wiki is a series of pages  that we can just edit
>> to document things in OSM to help other  mappers (which presumably was
>> the original point) and ignore  anything else
>>
>>
> +1
>
>

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


Re: [Tagging] Deleting template parameters copied to data items

2020-01-15 Thread Mateusz Konieczny



15 Jan 2020, 14:10 by ajt1...@gmail.com:

> On 15/01/2020 12:03, Mateusz Konieczny  wrote:
>
>>
>> 15 Jan 2020, 12:57 by >> marc_marc_...@hotmail.com>> :
>>
>>> I'm very unhappywith that.
>>>  
>>>
>> Please, please comment on the OSM Wiki if you want tocomment.
>>
>>
>
> What would be useful is a separate discussion about what wiki  "data 
> items" are and why there are a good (or bad) idea.  That  doesn't really 
> belong in > 
> https://wiki.openstreetmap.org/wiki/Talk:Wiki#Transition_to_use_data_items_when_this_can_be_done_without_loosing_information>
>   because that seems tied up in the specifics of one particular tag  (and 
> lets be honest, wiki pages aren't good at threaded  discussion).
>
>
I kind of agree, but I am not someone who started the disussion.

It is complaining about my specific edit as an example but proposes something 
more general.

>
> Maybe someone who thinks this particular change is a good (or  bad) idea 
> should write a diary entry or create a thread here  explaining what the 
> point of the change is and what the benefits  are, and what the impact on 
> people who use the wiki for reference  and on people who edit it is?  
>
>
If someone wants to change current state (remove data from Wiki pages and move 
it somewhere
else) then they should explain why it is worth doing.

Change should not be done for a sake of change.

Personally, I tried using data items and immediately encountered severe 
problems 
(some listed in the linked wiki discussion).

>
> There is a page > https://wiki.openstreetmap.org/wiki/Data_items>  but that 
> fails to communicate much of that to me (someone whose  first language is 
> English and has been reading technical  documentation for 40 years).  
> Until that happens the rest of us  are just going to assume that the OSM 
> wiki is a series of pages  that we can just edit to document things in 
> OSM to help other  mappers (which presumably was the original point) and 
> ignore  anything else
>
>
+1

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


Re: [Tagging] Deleting template parameters copied to data items

2020-01-15 Thread Andy Townsend

On 15/01/2020 12:03, Mateusz Konieczny wrote:


15 Jan 2020, 12:57 by marc_marc_...@hotmail.com:

I'm very unhappy with that.

Please, please comment on the OSM Wiki if you want to comment.


What would be useful is a separate discussion about what wiki "data 
items" are and why there are a good (or bad) idea.  That doesn't really 
belong in 
https://wiki.openstreetmap.org/wiki/Talk:Wiki#Transition_to_use_data_items_when_this_can_be_done_without_loosing_information 
because that seems tied up in the specifics of one particular tag (and 
lets be honest, wiki pages aren't good at threaded discussion).


Maybe someone who thinks this particular change is a good (or bad) idea 
should write a diary entry or create a thread here explaining what the 
point of the change is and what the benefits are, and what the impact on 
people who use the wiki for reference and on people who edit it is?


There is a page https://wiki.openstreetmap.org/wiki/Data_items but that 
fails to communicate much of that to me (someone whose first language is 
English and has been reading technical documentation for 40 years).  
Until that happens the rest of us are just going to assume that the OSM 
wiki is a series of pages that we can just edit to document things in 
OSM to help other mappers (which presumably was the original point) and 
ignore anything else.


Best Regards,

Andy


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


Re: [Tagging] distance_from_road tag

2020-01-15 Thread Philip Barnes


On Wednesday, 15 January 2020, Colin Smale wrote:
> On 2020-01-15 13:52, Lionel Giard wrote:
> 
> > Yes this is something you can do with any distance algorithm in available 
> > in any GIS tool. That's not something that i would ever map as it would 
> > vary with any geometry change of the ways between the road the point you 
> > measure, added to the fact that it add nothing to explicitly map it (in my 
> > opinion at least). It is essentially what any routing app will calculate 
> > when you ask "find the nearest POI" for example.
> 
> Surely the question is not about straight-line geometric distance/time
> but about route distance along paths etc. in pedestrian mode. "Nearest"
> is not nearest in terms of geometric distance, but the POI with the
> shortest route.
It is, but surely in calculating that distance it is easier and better to 
simply map the paths?

Phil (trigpoint) 
> 
> > Le mer. 15 janv. 2020 à 12:45, Mateusz Konieczny  
> > a écrit : 
> > 
> >> I propose describing distance_from_road tag, defined as 
> >> "distance in meters from nearest road" as a misguided idea that should not 
> >> be used. 
> >> 
> >> https://wiki.openstreetmap.org/wiki/Key:distance_from_road was recently 
> >> created by PangoSE and claims 
> >> "Useful for indicating the distance to nearest road accessible by a 
> >> normal car for people who cannot walk very long because of illness or 
> >> pregnancy but anyway want to get out in nature. " 
> >> 
> >> "I'm quite sure there is a clever GIS way of calculating this using a 
> >> routing engine, 
> >> unfortunately no tool or website has yet been created to easily visualize 
> >> this yet. 
> >> When this is available we could probably get rid of this tag or generate 
> >> its values by bot." 
> >> 
> >> I am 100% sure that such tags are not welcomed and especially bot idea is 
> >> really 
> >> poor, but I want to ask other for confirmation. 
> >> ___
> >> Tagging mailing list
> >> Tagging@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/tagging
> > 
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/taggin

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


Re: [Tagging] distance_from_road tag

2020-01-15 Thread Colin Smale
On 2020-01-15 13:52, Lionel Giard wrote:

> Yes this is something you can do with any distance algorithm in available in 
> any GIS tool. That's not something that i would ever map as it would vary 
> with any geometry change of the ways between the road the point you measure, 
> added to the fact that it add nothing to explicitly map it (in my opinion at 
> least). It is essentially what any routing app will calculate when you ask 
> "find the nearest POI" for example.

Surely the question is not about straight-line geometric distance/time
but about route distance along paths etc. in pedestrian mode. "Nearest"
is not nearest in terms of geometric distance, but the POI with the
shortest route. 

> Le mer. 15 janv. 2020 à 12:45, Mateusz Konieczny  a 
> écrit : 
> 
>> I propose describing distance_from_road tag, defined as 
>> "distance in meters from nearest road" as a misguided idea that should not 
>> be used. 
>> 
>> https://wiki.openstreetmap.org/wiki/Key:distance_from_road was recently 
>> created by PangoSE and claims 
>> "Useful for indicating the distance to nearest road accessible by a 
>> normal car for people who cannot walk very long because of illness or 
>> pregnancy but anyway want to get out in nature. " 
>> 
>> "I'm quite sure there is a clever GIS way of calculating this using a 
>> routing engine, 
>> unfortunately no tool or website has yet been created to easily visualize 
>> this yet. 
>> When this is available we could probably get rid of this tag or generate its 
>> values by bot." 
>> 
>> I am 100% sure that such tags are not welcomed and especially bot idea is 
>> really 
>> poor, but I want to ask other for confirmation. 
>> ___
>> 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] distance_from_road tag

2020-01-15 Thread Lionel Giard
Yes this is something you can do with any distance algorithm in available
in any GIS tool. That's not something that i would ever map as it would
vary with any geometry change of the ways between the road the point you
measure, added to the fact that it add nothing to explicitly map it (in my
opinion at least). It is essentially what any routing app will calculate
when you ask "find the nearest POI" for example.


Le mer. 15 janv. 2020 à 12:45, Mateusz Konieczny 
a écrit :

> I propose describing distance_from_road tag, defined as
> "distance in meters from nearest road" as a misguided idea that should not
> be used.
>
> https://wiki.openstreetmap.org/wiki/Key:distance_from_road was recently
> created by PangoSE and claims
> "Useful for indicating the distance to nearest road accessible by a
> normal car for people who cannot walk very long because of illness or
> pregnancy but anyway want to get out in nature. "
>
> "I'm quite sure there is a clever GIS way of calculating this using a
> routing engine,
> unfortunately no tool or website has yet been created to easily visualize
> this yet.
> When this is available we could probably get rid of this tag or generate
> its values by bot."
>
> I am 100% sure that such tags are not welcomed and especially bot idea is
> really
> poor, but I want to ask other for confirmation.
> ___
> 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] building=disused

2020-01-15 Thread Mateusz Konieczny
14 Jan 2020, 18:59 by a...@pigsonthewing.org.uk:

> JOSM warns me that "building=disuse" is deprecated, but doesn't tell
> me what to use instead.
>
> On the wiki, nether [[Key:building=disused]] nor
> [[Tag:building=disused]] exist
>
It exists now.

> and [[Key:building]] says nothing aout
> how to tag "disused", "derelict" or "empty" buildings.
>
It is a good idea to mention this also at that page.

>
> Is JOSM correct, what's the preferred alternative
>
disused=yes
JOSM validator message probably can be improved to mention this,
but tag is a quite rare one

> why is there no
> easily-found documntation for this common use case?
>
Because noone created it so far.

It exists now at https://wiki.openstreetmap.org/wiki/Tag:building%3Ddisused

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


Re: [Tagging] Deleting template parameters copied to data items

2020-01-15 Thread Simon Poole
Yes I was just going to point out that
https://taginfo.openstreetmap.org/taginfo/apidoc#api_4_key_wiki_pages
wouldn't return the combination info if removed from the page.

That doesn't mean that we can't change the wiki, but it needs to be a
coordinated effort that includes adapting the most important tools.

Simon

Am 15.01.2020 um 12:57 schrieb marc marc:
> Le 15.01.20 à 12:49, Mateusz Konieczny a écrit :
>> Anyone with opinion on that topic is welcomed to comment in this
>> discussion on the OSM Wiki.
> I'm very unhappy with that.
> some tools use wiki and not data items (for ex taginfo)
> doing that destroy usefull information.
> in fact I'm unhappy with the write acces to data items that has been
> done too early, all major tools must first be migrated to the dataitems.
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Deleting template parameters copied to data items

2020-01-15 Thread Mateusz Konieczny



15 Jan 2020, 12:57 by marc_marc_...@hotmail.com:

> Le 15.01.20 à 12:49, Mateusz Konieczny a écrit :
>
>> Anyone with opinion on that topic is welcomed to comment in this
>> discussion on the OSM Wiki.
>>
>
> I'm very unhappy with that.
> some tools use wiki and not data items (for ex taginfo)
> doing that destroy usefull information.
> in fact I'm unhappy with the write acces to data items that has been
> done too early, all major tools must first be migrated to the dataitems.
>
Please, please comment on the OSM Wiki if you want to comment.

I posted about this discussion across several platforms (slack, mailing lists, 
telegram),
but it was intended to direct to a single discussion rather than start several 
separate ones.

Comments made outside the talk page thread on the Wiki are likely to be just 
ignored.

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


Re: [Tagging] building=disused

2020-01-15 Thread Mateusz Konieczny



14 Jan 2020, 19:42 by kevin.b.ke...@gmail.com:

> On Tue, Jan 14, 2020 at 1:22 PM Paul Allen  wrote:
>
>> Yes, I'm aware there are other cartos that may handle things differently.  
>> But the
>> standard carto is the one we use to check what we've done.
>>
>
> Whenever I raise a point like that, there is a chorus of 'don't tag
> for the renderer.'
>
Standard carto is useful to check whatever things went OK.
More than once thanks to rendering I spotted horrific mistakes in what I added.
But it should not be treated as an ultimate and the perfect judge.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Deleting template parameters copied to data items

2020-01-15 Thread marc marc
Le 15.01.20 à 12:49, Mateusz Konieczny a écrit :
> Anyone with opinion on that topic is welcomed to comment in this
> discussion on the OSM Wiki.

I'm very unhappy with that.
some tools use wiki and not data items (for ex taginfo)
doing that destroy usefull information.
in fact I'm unhappy with the write acces to data items that has been
done too early, all major tools must first be migrated to the dataitems.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Deleting template parameters copied to data items

2020-01-15 Thread Mateusz Konieczny
PangoSE started "Transition to use data items when this can be done without 
loosing information"
discussion at 
https://wiki.openstreetmap.org/wiki/Talk:Wiki#Transition_to_use_data_items_when_this_can_be_done_without_loosing_information
 


It is about whatever it is correct to delete data from the OSM Wiki page after 
it was copied to data items.

Anyone with opinion on that topic is welcomed to comment in this discussion on 
the OSM Wiki.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] distance_from_road tag

2020-01-15 Thread Mateusz Konieczny
I propose describing distance_from_road tag, defined as 
"distance in meters from nearest road" as a misguided idea that should not
be used.

https://wiki.openstreetmap.org/wiki/Key:distance_from_road was recently 
created by PangoSE and claims
"Useful for indicating the distance to nearest road accessible by a 
normal car for people who cannot walk very long because of illness or 
pregnancy but anyway want to get out in nature. "

"I'm quite sure there is a clever GIS way of calculating this using a routing 
engine,
unfortunately no tool or website has yet been created to easily visualize this 
yet.
When this is available we could probably get rid of this tag or generate its 
values by bot."

I am 100% sure that such tags are not welcomed and especially bot idea is really
poor, but I want to ask other for confirmation.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] How to tag oneway restriction applying to pedestrians?

2020-01-15 Thread Mateusz Konieczny
15 Jan 2020, 09:51 by dieterdre...@gmail.com:

> Like in "they may not legally walk in the oneway direction"? Which 
> jurisdiction is this?
> In the jurisdictions I am aware of, in absence of a pavement you have to walk 
> on the road / carriageway. You may not do so only if there are signs that 
> prohibit pedestrian usage.
>
Poland.

Pedestrian walking on the carriageway or shoulder is obligated to walk on the 
left side of the road.

Ustawa prawo o ruchu drogowym, rozdział 1, art 11

"2. Pieszy idący po poboczu lub jezdni jest obowiązany iść lewą stroną drogi."
Not going to be tagged in OSM, as shoulder is not going to be mapped separately 
from
the road.


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


Re: [Tagging] building=disused

2020-01-15 Thread Mateusz Konieczny
14 Jan 2020, 20:02 by selfishseaho...@gmail.com:

> On Tue, 14 Jan 2020 at 19:44, Kevin Kenny <> kevin.b.ke...@gmail.com> > wrote:
> Actually, i never use disused: on businesses because it feels wrong;
>
It is OK for shops that are closed, but where their signage still remains.

> either i remove them or i prefix them with was: . For example,
>
Shops that are gone without a trace almost always can be simply deleted.
I encountered cases of destroyed building remapped from aerials,
so leaving demolished:building=* geometry + note=* makes sense.

But is there a real danger of people mapping shops based on their outdated 
memories?

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


Re: [Tagging] building=disused

2020-01-15 Thread Mateusz Konieczny via Tagging



15 Jan 2020, 05:15 by 61sundow...@gmail.com:

> If you tag 'disused=yes' ... how is that rendered? 
>
It depends on what author of map style wanted.
For example it is unlikely to be supported in OSM Carto, as this style
is already rendering many different things and distinctions.


> And that raises another point, how would you render disused physical 
> objects??? They should not be the same as a physical object that is 'in use', 
> and some think they should be rendered
>
Again, depends on the map style.

And all of that is offtopic here in this mailing list.

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


Re: [Tagging] Query regarding seasonal tag combined for outdoor water fountains.

2020-01-15 Thread Joseph Eisenberg
According to the wiki page for "service_times":

"The key service_times=* is generally used for the times of service of
a given feature, if this is different from the opening hours or if a
special service (like in the case of churches) is offered in this
time. Otherwise please use opening_hours=*."

It is much, much less common than opening_hours (it's a 100 to 1
ratio). And it's almost always used with amenity=place_of_worship +
religion:
https://taginfo.openstreetmap.org/keys/service_times#combinations

This makes sense, because places of worship might be open every day
(e.g. catholic churches in Latin America) but the public worship
services are only held at certain times.

For a feature like a drinking fountain, opening_hours= would be the
standard tag to use, and this combination has already been used over
2000 times with amenity=drinking_water
(http://overpass-turbo.eu/s/PLd), while service_times has been used
exactly once (http://overpass-turbo.eu/s/PLc).

- Joseph Eisenberg

On 1/15/20, Martin Koppenhoefer  wrote:
> Am Mi., 15. Jan. 2020 um 07:20 Uhr schrieb Joseph Eisenberg <
> joseph.eisenb...@gmail.com>:
>
>> Since drinking fountains are man-made rather than natural features,
>> they usually have a date when they are turned on or off.
>>
>> This can be specified with the key "opening_hours=*" - this is the
>> common British English term used to say "when is this this feature
>> open and available".
>>
>> See https://wiki.openstreetmap.org/wiki/Key:opening_hours for details
>> on how this is used.
>>
>
>
> For a drinking fountain (or any other fountain), I would prefer
> "service_times" or conditional tagging and not "opening hours" (as long as
> the thing is still accessible when it is turned off). IMHO, seasonal could
> work as well (and doesn't require to know the date, if there is).
>
> Cheers
> Martin
>

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


Re: [Tagging] How to revive a tag proposal?

2020-01-15 Thread Martin Koppenhoefer


sent from a phone

>> On 14. Jan 2020, at 19:50, António Madeira  wrote:
> Sorry, I didn't get your point, Andy.
> The tag was used 32 times, that doesn't seem a "relatively popular" use
> of the tag.


if there aren’t proper alternatives I agree it is relatively popular. 



> Someone using iD (newbie or not) doesn't have any idea on how to map
> this structure.


correct 


> 
> I would like to make a proper wiki and add that feature to iD


these are 2 completely unrelated actions, for inclusion in iD you do not need a 
wiki entry nor does it influence the decision to add it or not (according to 
one of the maintainers).
You could add a ticket to iD github asking for inclusion in iD.

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


Re: [Tagging] How to tag oneway restriction applying to pedestrians?

2020-01-15 Thread Martin Koppenhoefer
Am Di., 14. Jan. 2020 um 15:55 Uhr schrieb Paul Allen :

> On Tue, 14 Jan 2020 at 14:35, Martin Koppenhoefer 
> wrote:
>
> Mine goes like this: leading the list is the completely meaningless (and I
>> guess most will agree with this judgement) oneway:foot=no
>>
>
> It's not meaningless at all.  It says that although the road is oneway to
> vehicular
> traffic, pedestrians may walk in either direction.
>


this is already the commonly agreed, documented since 15 years, meaning of
oneway=yes. Nothing added.



>   This is not always the case:
> single-lane roads without a pavement may require that pedestrians only
> walk in
> the opposite direction to oneway vehicular traffic on safety grounds.
>


Like in "they may not legally walk in the oneway direction"? Which
jurisdiction is this?
In the jurisdictions I am aware of, in absence of a pavement you have to
walk on the road / carriageway. You may not do so only if there are signs
that prohibit pedestrian usage.



>   The use
> of oneway:foot=no makes clear that no such restriction applies to
> pedestrians
> and that the onewayness of the road applies only to vehicular traffic.
>
> We use similar schemes for access tags.  Why are you having difficulty
> with this?
>


I do not have difficulty with it, it is just meaningless. A similar case
for access tags would be motor_vehicle=no and then add a motorcar=no. It
doesn't add anything.

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


Re: [Tagging] Query regarding seasonal tag combined for outdoor water fountains.

2020-01-15 Thread Martin Koppenhoefer
Am Mi., 15. Jan. 2020 um 07:20 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> Since drinking fountains are man-made rather than natural features,
> they usually have a date when they are turned on or off.
>
> This can be specified with the key "opening_hours=*" - this is the
> common British English term used to say "when is this this feature
> open and available".
>
> See https://wiki.openstreetmap.org/wiki/Key:opening_hours for details
> on how this is used.
>


For a drinking fountain (or any other fountain), I would prefer
"service_times" or conditional tagging and not "opening hours" (as long as
the thing is still accessible when it is turned off). IMHO, seasonal could
work as well (and doesn't require to know the date, if there is).

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


Re: [Tagging] building=disused

2020-01-15 Thread Martin Koppenhoefer
Am Mi., 15. Jan. 2020 um 08:03 Uhr schrieb Marc Gemis :

> On Wed, Jan 15, 2020 at 5:16 AM Warin <61sundow...@gmail.com> wrote:
> > And that raises another point, how would you render disused physical
> objects???
>
> I would say that depends on the purpose of the map. A map that wants
> to show buildings that were used as shop, but are now vacant/disused,
> might show them very prominent.
> A map showing windmills might show working windmills in black and
> disused one in grey or without vanes or ...



it generally depends on the kind of object. Some might merit rendering,
others would better be ignored all together (because there's very limited
space on the map and they will generally not be worth showing even
if there would be sufficient space). On a general purpose map, a building
is a building, and it doesn't matter whether it is used or not (and it
could be reused any time), as long as it hasn't deteriorated to a ruin (has
significantly changed nature), in which case a mere "disused" would be not
appropriate any more. I am not saying it isn't interesting to anybody or
there won't be subtle differences between an used and an unused building,
just that it isn't sufficiently significant (IMHO) to merit different
treatment.

On the other hand, many amenities, even though they often have a physical
"body", are not useful or interesting to show at all when they are not in
use, e.g. telephone booths, mail boxes, drinking fountains, generally small
items, while bigger items (train stations, post offices, quarries etc.) are
probably significant enough even for a general purpose map to be shown
somehow.

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


Re: [Tagging] building=disused

2020-01-15 Thread marc marc
Le 15.01.20 à 05:15, Warin a écrit :
> On 15/1/20 6:32 am, marc marc wrote:
>> Le 14.01.20 à 19:34, Markus a écrit :
>>> If i understand it correctly, building=* values describe how the
>>> building looks, not how it is used. For example, a church that is now
>>> used as a pub still remains a building=church.
>> I fully agree with that.
>> note that building:use may record the current use.
>> therefore building:use=vacant or =none or =no fit the request.
> 
> And I would disagree. 
> 
> A building that is 'in use' is maintained. 
> 
> A building that is 'disused' is not maintained, the paint work will weather, 
> glass become dirty .. roof leak, locks freeze. Generally they look 
> disheveled.  


The village church is not painted and i wonder when someone cleans the
windows of the church here.
Anyway I am unable to tell the difference in appearance between a church
whose windows have been cleaned and a church whose windows have not been
cleaned.
I'm not talking about a building whose roof is damaged, that's no longer
disused, the work to use it is much more consequent.
in the industrial zone, there's been a disused building for as long as
i've known it. yet the appearance is still that of an industrial
building. if i ask a passerby what that building looks like, that's
probably what he'll tell me. The difference with the next building
is there's a "for rent" sign.
what other appearance value do you want to create?
building=disused_industrial: an industrial building where windows
have not been maintained recently or with a "to rent" sign on it ?

> If you tag 'disused=yes' ... how is that rendered?

it depends on the wish of the map style, which is not the right place
to discuss.
one renderer may choose to ignore it, another may choose to use a
lighter color, another may choose to display it in red to highlight
areas to be reassigned.
all this is possible with building:use=vacant/no, disused:building=*
and disused=yes.
but to me, disused:building=* is a bad/yrong idea, there's still
a building present, so we should keep a building=*

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