Re: [Tagging] Feature Proposal - RFC - Food sharing

[Markus Peloso]

https://wiki.openstreetmap.org/wiki/Proposed_features/food_sharing
A shelf/box/fridge where people drop off and pick up food in the sense of free 
sharing and/or to reduce food waste.

Hi

I have made some changes in the proposal of amenity=food_sharing to give more 
clarity about what you can expect in this facility. I want to start voting in a 
few days.

Does anyone have any additions or comments?

Best regards

Markus (ToastHawaii)

Von: Markus Peloso<mailto:mar@outlook.com>
Gesendet: Freitag, 28. Februar 2020 10:36
An: Tag discussion, strategy and related tools<mailto:tagging@openstreetmap.org>
Betreff: Re: [Tagging] Feature Proposal - RFC - Food sharing

Hi Hauke

Thank you for your inputs (and warnings ;) ). Free choice is important to me.

I added the covered=* tag to the list. And add contact:* as a possible 
combination.

I see the list of combinations more as a suggestion/inspiration, so that useful 
(or preferred) combinations can always be added to the POIs without being on 
the list.

Best regards, Markus

Von: Hauke Stieler<mailto:m...@hauke-stieler.de>
Gesendet: Donnerstag, 27. Februar 2020 19:41
An: tagging@openstreetmap.org<mailto:tagging@openstreetmap.org>
Betreff: Re: [Tagging] Feature Proposal - RFC - Food sharing

Hi,

sometimes people just use boxes or the basket of an old bicycle for food
sharing purposes. Because they are usually not inside a building or
something, I would add the "covered=*" tag to your list.

I also would use the "contact:*" keys (for the website, facebook, other
social media channels, etc.). The "contact:facebook" key is also used
more often and I personally like the contact scheme. Some boxed may also
have other contact options (email, phone, instagram, twitter, ...). I
know the whole contact-scheme-thing might end up in a large discussion,
but I just wanted to mention it.

But the general proposal looks good, the tagging is simple and
everything is straight forward :)

Hauke

On 26.02.20 09:47, Markus Peloso wrote:
> https://wiki.openstreetmap.org/wiki/Proposed_features/food_sharing
>
>
>
> «A shelf/box/fridge where people drop off and pick up food in the sense
> of free sharing and/or to reduce food waste.»
>
>
>
> Hi
>
>
>
> I added the current proposal for food sharing I made to the wiki.
>
>
>
> What do you think about it?
>
>
>
> Best regards
>
> Markus
>
>
> ___
> 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] Feature Proposal - Voting - give box

[Markus Peloso]

Hi

1.
The name is still something that bothers me. Clarity and transparency are 
importent for me.
I now understand that the name (and the description) of the feature must be 
very clear, easy to understand and general so that it can be used in different 
countries for similar concepts.

Thanks for the hint with ranked-choice voting, I am thinking about how we could 
implement this in OSM wiki. I'm open to suggestions.

2.
Currently I want to give more time for the Proposed features/food sharing.

I never seen a hiker box in the wild, I do not know if there is a similar thing 
in Switzerland. I can't say much about the nature of this thing. Based on the 
description, I would prefer to map them as a separate node, as we do with 
public bookcases located in a building. So we can add information on how Pepole 
can find them and other infos ("level=*", "description=*", "wheelchair=*"). I 
also not see the relation between a post office, shop, hotel or campsite and a 
hiker box. Are these places specialized for hikers?
As I have never seen a hiker box, I do not want to make a proposal of my own. 
But I would remove the amenity=give_box + hiking=yes from the description, like 
the public_bookcase, when someone makes a proposal.

As I understand, "blessing boxes" are more about food like a free pantry.
I agree I also think this is not a good name for this proposal.

Markus
Von: Philip Barnes<mailto:p...@trigpoint.me.uk>
Gesendet: Sonntag, 15. März 2020 18:54
An: tagging@openstreetmap.org<mailto:tagging@openstreetmap.org>
Betreff: Re: [Tagging] Feature Proposal - Voting - give box

On Sun, 2020-03-15 at 12:42 -0400, Jmapb via Tagging wrote:
On 3/15/2020 6:18 AM, Markus Peloso wrote:
https://wiki.openstreetmap.org/wiki/Proposed_features/give_box

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

Hi
After "Clarify whatever explicit abstaining is the same as no vote" and the 
change of the Proposal process page I reopen the voting, maybe someone wants to 
change their vote or add a comment.

In the meantime we have got some new inputs:

Summary
- We hade discuss about give box, hiker box, public refrigerator, free pantry 
and food sharing and how this things could be documented in OpenStreetMap. 
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/food_sharing#Arguments_and_comments_from_the_Tagging_.5BPublic_refrigerators.5D_E-Mails
- New Proposed feature "food sharing" 
https://wiki.openstreetmap.org/wiki/Proposed_features/food_sharing
- New Proposed feature "donation of goods" 
https://wiki.openstreetmap.org/wiki/Proposed_features/donation_of_goods
- Some mappers tag blessing boxes with new amenity=give_box tag 
https://overpass-turbo.eu/s/RAA


Thanks for your patience and perseverance, Markus!

It's clear that give boxes will be approved as a feature. The only remaining 
questions I see are:

1. What's the best tag for them? (Some people don't like "give_box" -- maybe an 
opportunity to experiment with ranked-choice voting?)

2. What related amenities are distinct enough that they deserve their own 
separate tags?
 - Public bookcase, obviously.
 - Separating the food sharing amenities seems like a good idea. I'd be in 
favor of a single tag to which refrigerated=yes could be added to indicate a 
public refrigerator.
 - I like the idea of a separate tag for hiker boxes, because (as I mentioned 
in the public refrigerator thread) it's very common to have them as part of 
another map feature like post office, shop, hotel, or campsite, so simply being 
able to add hiker_box=yes would be great.
 - I've never heard the term "blessing box" before but it seems like they'd 
best be classified as either food sharing or give box, depending on the 
inventory.
Blessing box sounds like some something religious to me, so not a good term for 
this proposal.

Phil (trigpoint)

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

[Tagging] Feature Proposal - Voting - give box

[Markus Peloso]

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

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

Hi
After "Clarify whatever explicit abstaining is the same as no vote" and the 
change of the Proposal process page I reopen the voting, maybe someone wants to 
change their vote or add a comment.

In the meantime we have got some new inputs:

Summary
- We hade discuss about give box, hiker box, public refrigerator, free pantry 
and food sharing and how this things could be documented in OpenStreetMap. 
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/food_sharing#Arguments_and_comments_from_the_Tagging_.5BPublic_refrigerators.5D_E-Mails
- New Proposed feature "food sharing" 
https://wiki.openstreetmap.org/wiki/Proposed_features/food_sharing
- New Proposed feature "donation of goods" 
https://wiki.openstreetmap.org/wiki/Proposed_features/donation_of_goods
- Some mappers tag blessing boxes with new amenity=give_box tag 
https://overpass-turbo.eu/s/RAA

Best regards
Markus (ToastHawaii)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - in-kind_donation

[Markus Peloso]

Hello

As a result of the discussion, I have changed the name from "donation in kind" 
to "donation of goods". "donation of goods" is easier to understand and is more 
specific for a place you can give physical things as donation.

If there are no more comments, I will start voting in a few days.

Best regards
Markus
Von: Martin Koppenhoefer<mailto:dieterdre...@gmail.com>
Gesendet: Donnerstag, 20. Februar 2020 12:00
An: Tag discussion, strategy and related tools<mailto:tagging@openstreetmap.org>
Betreff: Re: [Tagging] Feature Proposal - RFC - in-kind_donation

Am Mi., 19. Feb. 2020 um 23:50 Uhr schrieb Joseph Eisenberg 
mailto:joseph.eisenb...@gmail.com>>:
My concern is still that it might be hard to translate "donation in
kind" from English into some languages, and that people with limited
English vocabulary might not understand the phrase.

Automated translations by Google from "donation in kind" gets this:

I got the same with deepl.com<http://deepl.com> (for French, German, Spanish, 
Dutch)



German: "Sachspende"


is a precise and accurate term (no wonder, the OP has translated this to 
English).



Dutch: "donatie in natura" literally "donation in nature", from French?

French: "don en nature" - literally "gift in nature/kind" which seem
to be a phrase

So "donation in kind" will work for western European languages (and
Indonesian), though it would be nice if someone can check how it works
in Chinese, Japanese, Arabic, etc.

However, "donation of goods" works as well or better in most of these languages:

"Donation of goods" translates to:
= "sumbangan barang" (Indonesian)
= "donación de bienes" (Spanish)
= "don de biens" (French)
= "donatie van goederen" (Dutch)
= "Spende von Waren" (German)


no, "Spende von Waren" is not an established term, it doesn't sound natural 
(but would probably be understood anyway), the perfect term is "Sachspende". My 
guess is that also for the other languages, particularly Roman languagues with 
their reference to "nature", the established term is that and not the second 
alternative. No idea about Indonesian obviously ;)

Cheers
Martin

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

Re: [Tagging] Feature Proposal - Voting - drinking_water:refill_scheme

[Markus Peloso]

Hello

For step 3.
Replace the entire content/source from the «Proposed features/Free Water» with 
this snippet:
«
{{Approved feature link|link=Key:drinking_water:refill|name=Free Water}}
{{Archived proposal|archive_id=1962961}}
»
The archive_id comes from the «View history» page by clicking the last / newest 
entry and coping the value from the oldid parameter in the url.

Best regards,

Markus

Von: European Water Project<mailto:europeanwaterproj...@gmail.com>
Gesendet: Mittwoch, 26. Februar 2020 12:15
An: Tag discussion, strategy and related tools<mailto:tagging@openstreetmap.org>
Betreff: Re: [Tagging] Feature Proposal - Voting - drinking_water:refill_scheme

Hello,

Since no one has manifested an objection (still not too late), I am going to 
amend the final voted tag pair to :

drinking_water:refill=yes/drinking_water:refill=no
drinking_water:refill:network=network-name1;network-name2;network-name3;

Can someone please guide me on the below.  I appreciate your advice.  I would 
like to complete all tasks associated with this tag implementation.

1. How do I change the name of the proposal page to better match what was voted 
?... The page name corresponds to the one of the first interactions.
https://wiki.openstreetmap.org/wiki/Proposed_features/Free_Water

2. How do I create the permanent feature page ? (should I create a second one 
for "drinking_water:refill:network" or include it on the primary page ?)

3.  I will need guidance on the next three steps as well, but this can come 
after completion of 1 + 2.
*  Add a link back to the proposal by using the statuslink parameter of the 
feature template.
*  Add a link to the permanent feature page in the proposal page using 
Template:Approved feature 
link<https://wiki.openstreetmap.org/wiki/Template:Approved_feature_link>.
*  Archive the proposal using Template:Archived 
proposal<https://wiki.openstreetmap.org/wiki/Template:Archived_proposal>.

Best regards,

Stuart


On Thu, 20 Feb 2020 at 15:29, European Water Project 
mailto:europeanwaterproj...@gmail.com>> wrote:
Hello,

As per yesterday's note, I would like to make the following tweek to the tag 
pair as per the suggestion from Kovposch for the final write-up.

drinking_water:refill=yes/drinking_water:refill=no
drinking_water:refill:network=network-name1;network-name2;network-name3;

instead of :

drinking_water:refill=yes/drinking_water:refill=no
drinking_water:refill_scheme=scheme-name1;scheme-name2;scheme-name3;

Does anyone believe another round of voting is necessary for this small change 
?  I don't mind.

Best regards,

Stuart

On Wed, 19 Feb 2020 at 09:33, European Water Project 
mailto:europeanwaterproj...@gmail.com>> wrote:
Hi Again,

In addition to the previous email regarding voting outcome, I think it is worth 
discussing the suggestion of  Kovposch to make refill a namespace and use the 
word network.

This would change the second tag of the tag pair to
drinking_water:refill:network=network-name1;network-name2;network-name3;

Does anyone have an opinion on this? I personally prefer this namespace 
convention because of I find it more generic and I find the word "network" 
clearer than "scheme".

Best regards,

Stuart

On Wed, 19 Feb 2020 at 09:27, European Water Project 
mailto:europeanwaterproj...@gmail.com>> wrote:
Dear All,

The proposal for tagging bars, restaurants, cafés, kiosks, which refill water 
bottles for free as part of a refill scheme or as an independent passes with 13 
positive votes and three abstentions.  Please note, that to be tagged 
drinking_water:refill = yes, it is imperative that a sign is evident so that 
the tag is verifiable.

The tag that has been voted positively takes into account the clear preference 
for delimiting individual scheme names with semicolons - which is common with 
other tags.

· 
drinking_water:refill<https://wiki.openstreetmap.org/w/index.php?title=Key:drinking_water:refill=edit=1>=yes<https://wiki.openstreetmap.org/w/index.php?title=Tag:drinking_water:refill%3Dyes=edit=1>/drinking_water:refill<https://wiki.openstreetmap.org/w/index.php?title=Key:drinking_water:refill=edit=1>=no<https://wiki.openstreetmap.org/w/index.php?title=Tag:drinking_water:refill%3Dno=edit=1>
· 
drinking_water:refill_scheme<https://wiki.openstreetmap.org/w/index.php?title=Key:drinking_water:refill_scheme=edit=1>=scheme-name<https://wiki.openstreetmap.org/w/index.php?title=Tag:drinking_water:refill_scheme%3Dscheme-name=edit=1>1;
 
scheme-name<https://wiki.openstreetmap.org/w/index.php?title=Tag:drinking_water:refill_scheme%3Dscheme-name=edit=1>2;scheme-name3;

Can someone please guide me on next steps ?

· Create the permanent feature description page:
· A new page for the feature should be created and the relevant map 
features 
template<https://wiki.openstreetmap.org/wiki/Category:Features_template> 
(dependi

Re: [Tagging] How to map an OpenStreetMap map?

[Markus Peloso]

Thanks for the idea.
I love it. :D

https://priceless.zottelig.ch/#offers=trip%2Fopenstreetmap

https://priceless.zottelig.ch/#offers=trip%2Fopenstreetmap=50.556607%2C12.6785266

Von: Rory McCann
Gesendet: Samstag, 29. Februar 2020 12:00
An: tagging@openstreetmap.org; 
t...@openstreetmap.org
Betreff: [Tagging] How to map an OpenStreetMap map?

In OSM, large map boards can be mapped as 
`tourist=information,information=map`. OSM is
pretty good quality, so now some of these maps are based on OSM data.

Is there anyway to record this in OSM?

IMO, you don't need a reason to map something, but one benefit is to help 
people promote OSM. If someone thinks you have a weird hobby with this map 
thing, and you bring them to big map showing our map, then that's pretty cool.

The `map_type` and `map_size` tags are used on these sort of maps. Do yous 
think `map_source=openstreetmap` is a good tag?
The long standing OSM convention of semicolons can be used if there's more than 
one source.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

Re: [Tagging] Public refrigerators

[Markus Peloso]

I find amenity=give_box is different from amenity=food_sharing as a 
shop=general is different from shop=supermarket.

In Switzerland if I go into a supermarket I found products of daily hygiene but 
the main thing is about shopping for food.

The main thing by a give box is about sharing items. In the description I 
explicit excluded amenity=give_box + food=only because if you go to e give box 
you expect some items like clothes, small appliances, dishes, toys.

--

Does a free pantry have some social aspect? Like given food to underprivileged 
or homless people 
social_facility:for<https://wiki.openstreetmap.org/wiki/DE:Key:social_facility:for>=underprivileged,
 
social_facility:for<https://wiki.openstreetmap.org/wiki/DE:Key:social_facility:for>=homeless,
 …

Based on the description on this website http://www.littlefreepantry.org/ I 
think the main thing is about sharing food and it is some kind of social 
service.

Markus

Von: Jmapb<mailto:jm...@gmx.com>
Gesendet: Samstag, 29. Februar 2020 06:34
An: tagging@openstreetmap.org<mailto:tagging@openstreetmap.org>
Betreff: Re: [Tagging] Public refrigerators

On 2/26/2020 4:32 PM, Martin Koppenhoefer wrote:
>> On 26. Feb 2020, at 08:56, Markus Peloso  wrote:
>>
>> The amenity=give_box tag is specific for sharing and reusing none food 
>> items. Please do not use it for food sharing
>
> +1, although these are somehow similar features from a certain point of view, 
> they are also significantly different features from another point of view. I 
> am in favor of keeping a distinction on the main tag level.

The give_box proposal specifically said that food sharing was *not* to
be included in the give_box schema.

I voted for that, but since then, with the proposal stalled, I ran into
what I'd called a give box for "packaged food & personal care items."
It's labeled "free pantry" but it's not just for food.
https://i.imgur.com/UzhuIBo.jpg (Non-refrigerated, obviously. There were
actually cans of food in here but not visible in this shot.)

Also hiker boxes -- which were explicitly part of the give_box proposal
-- often have food as well as clothing, gear, books, maps, and fuel. So
maybe the prohibition of food in give_box isn't ideal.

Regardless, though, I don't think a public refrigerator should be a
subtag of give_box -- it's too distinct. I think
amenity=public_refrigerator makes sense. Using amenity=social_facility
plus a subtag would also be fine I guess.

Jason


___
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] Clarify explicit abstention when voting on a proposal

[Markus]

On Thu, 27 Feb 2020 at 20:29, Paul Allen  wrote:
>
> Wikipedia is not noted for its consistency.  From 
> https://en.wikipedia.org/wiki/Abstention
>
> Abstentions do not count in tallying the vote negatively or positively; when 
> members abstain, they are in effect attending only to contribute to a quorum. 
> White votes, however, may be counted in the total of votes, depending on the 
> legislation.
>
> Note that abstentions can only contribute to a quorum in things like 
> parliamentary
> votes where people are required to attend.  As far as ordinary voters in 
> elections
> go, there may be no requirement to attend or vote (depending on legislation) 
> and
> no quorum.

I've just realised that i mixed up quorum (minimum number of votes for
a vote to be valid) and number of votes for calculating the majority.
While abstentions and invalid votes do contribute to the quorum (if
one exist), they usually aren't counted when calculating the majority.
At least this is the situation in Switzerland. Example [1]:

Distributed ballots: 244
Received ballots: 244
Empty: 25
Invalid: 1
Valid: 218
Absolute majority: 110

[1]: 
https://www.parlament.ch/de/über-das-parlament/archiv/wahlen-im-rueckblick/bundesratswahlen/2019-12-11

Please excuse the confusion.

Regards


Markus

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

Re: [Tagging] Feature Proposal - RFC - Food sharing

[Markus Peloso]

Hi Hauke

Thank you for your inputs (and warnings ;) ). Free choice is important to me.

I added the covered=* tag to the list. And add contact:* as a possible 
combination.

I see the list of combinations more as a suggestion/inspiration, so that useful 
(or preferred) combinations can always be added to the POIs without being on 
the list.

Best regards, Markus

Von: Hauke Stieler<mailto:m...@hauke-stieler.de>
Gesendet: Donnerstag, 27. Februar 2020 19:41
An: tagging@openstreetmap.org<mailto:tagging@openstreetmap.org>
Betreff: Re: [Tagging] Feature Proposal - RFC - Food sharing

Hi,

sometimes people just use boxes or the basket of an old bicycle for food
sharing purposes. Because they are usually not inside a building or
something, I would add the "covered=*" tag to your list.

I also would use the "contact:*" keys (for the website, facebook, other
social media channels, etc.). The "contact:facebook" key is also used
more often and I personally like the contact scheme. Some boxed may also
have other contact options (email, phone, instagram, twitter, ...). I
know the whole contact-scheme-thing might end up in a large discussion,
but I just wanted to mention it.

But the general proposal looks good, the tagging is simple and
everything is straight forward :)

Hauke

On 26.02.20 09:47, Markus Peloso wrote:
> https://wiki.openstreetmap.org/wiki/Proposed_features/food_sharing
>
>
>
> «A shelf/box/fridge where people drop off and pick up food in the sense
> of free sharing and/or to reduce food waste.»
>
>
>
> Hi
>
>
>
> I added the current proposal for food sharing I made to the wiki.
>
>
>
> What do you think about it?
>
>
>
> Best regards
>
> Markus
>
>
> ___
> 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] Clarify explicit abstention when voting on a proposal

[Markus]

On Thu, 27 Feb 2020 at 15:06, Paul Allen  wrote:
>
> However, despite the option being labelled an abstention, it is NOT an 
> abstention.
> Technically, it is a "spoiled ballot."  Spoiled ballots DO contribute to a 
> quorum in
> most voting systems. [...]

Really? Wikipedia says [1]:

In voting, a ballot is considered spoilt, spoiled, void, null,
informal, invalid or stray if a law declares or an election authority
determines that it is invalid and thus **not included in the vote
count**.

[1]: https://en.wikipedia.org/wiki/Spoilt_vote

I can confirm this for Switzerland (for elections and votings by the
people and in the parliaments).

> As I see it, we have three options:
>
> 1. Treat it as an abstention, and continue to call it an abstention.  It does
> not count towards the quorum.  In which case it should appear separately
> from the yes/no votes (or at least placed before yes/no votes) to avoid 
> confusion.
> The talk page would theoretically be the best place for abstentions, but
> practically would mean that any points raised would be less likely to be
> seen by other voters.  Approval would be based on total yes/no votes
> and ratio of yes to no votes.

+1 for option 1

Markus aka SelfishSeahorse

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

Re: [Tagging] Feature Proposal - RFC - Food sharing

[Markus Peloso]

Thanks, Markus, for your feedback.

I agree with you, network fit better then brand.

I remove charity I think it is not usefull because it do not fit. The little 
free pantry is more about food for people in need. My intention was to document 
this with charity=yes.

Best regards

Markus aka ToastHawaii

Von: Markus<mailto:selfishseaho...@gmail.com>
Gesendet: Mittwoch, 26. Februar 2020 12:03
An: Tag discussion, strategy and related tools<mailto:tagging@openstreetmap.org>
Betreff: Re: [Tagging] Feature Proposal - RFC - Food sharing

Thanks, Markus, for writing this proposal. I like the proposed tag.

Just two minor things regarding tags that can be used in combination:

- brand=* Optional. Name of the brand or network of the facility if
there is one visible. eg.

I would change this to network=* as it seems to fit better. brand=* is
mainly used for the brand of items being sold while we're already
using network=* for bicycle sharing networks.

- charity=* Optional. Add charity=yes if the food for those in need.

It's not clear to me what you mean: a place where you can only donate
food or a place where you can bring food but only poor people are
allowed to take it away? If you have the first scenario in mind
(donating only), i would rather use amenity=recycling, analogous to
recycling:clothes=yes.

Regards

Markus aka SelfishSeahorse

___
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] Feature Proposal - RFC - Food sharing

[Markus]

Thanks, Markus, for writing this proposal. I like the proposed tag.

Just two minor things regarding tags that can be used in combination:

- brand=* Optional. Name of the brand or network of the facility if
there is one visible. eg.

I would change this to network=* as it seems to fit better. brand=* is
mainly used for the brand of items being sold while we're already
using network=* for bicycle sharing networks.

- charity=* Optional. Add charity=yes if the food for those in need.

It's not clear to me what you mean: a place where you can only donate
food or a place where you can bring food but only poor people are
allowed to take it away? If you have the first scenario in mind
(donating only), i would rather use amenity=recycling, analogous to
recycling:clothes=yes.

Regards

Markus aka SelfishSeahorse

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

[Tagging] Feature Proposal - RFC - Food sharing

[Markus Peloso]

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

«A shelf/box/fridge where people drop off and pick up food in the sense of free 
sharing and/or to reduce food waste.»

Hi

I added the current proposal for food sharing I made to the wiki.

What do you think about it?

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

Re: [Tagging] Public refrigerators

[Markus Peloso]

Hello Markus

Thank you for starting this discussion. I have plans to start a feature propose 
for food sharing.

I found four tags that people use for food sharing 
social_facility=food_sharing, amenity=food_sharing, 
social_facility=community_fridge and recycling:food=yes.

https://taginfo.openstreetmap.org/compare/social_facility=food_sharing/amenity=food_sharing/social_facility=community_fridge/recycling:food=yes

Food related sharing boxes are common:

  *   http://mapping.littlefreepantry.org/ (~800 documented)
  *   https://foodsharing.de/karte (~750 documented)

In my opinion, food released boxes deserve their own tag. Give boxes and foot 
related boxes have a different concept in detail. Some foot related boxes eg. 
have a fridge, some disallows meat or only a group of people is allowed to fill 
it up. Little free pantry seems for giving food to poor people. Foodsharing 
seems for reduce food waste.

The amenity=give_box tag is specific for sharing and reusing none food items. 
Please do not use it for food sharing.

Currently I use and suggest amenity=food_sharing [+ fridge=yes] to tag this 
kinds of facility.

Best regards
Markus

Von: Markus<mailto:selfishseaho...@gmail.com>
Gesendet: Dienstag, 25. Februar 2020 19:56
An: Tag discussion, strategy and related tools<mailto:tagging@openstreetmap.org>
Betreff: Re: [Tagging] Public refrigerators

On Tue, 25 Feb 2020 at 19:44, Jan Michel  wrote:
>
> Hi,
> isn't this exactly what a amenity=give_box is? Just for food and not for
> toys or clothes.

Yes, similar. On the other hand, public bookcases, which have their
own tag, are also kind of give boxes.

> With your proposed tags, we would need yet another one for non-cooled
> food, so this is a bad idea in my opinion.
>
> So, I suggest:
> amenity = give_box
> food = only
> refrigerated = yes

Not perfect, but way better than amenity=recycling or
amenity=social_facility in my opinion.

Markus

___
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] Public refrigerators

[Markus]

On Tue, 25 Feb 2020 at 19:44, Jan Michel  wrote:
>
> Hi,
> isn't this exactly what a amenity=give_box is? Just for food and not for
> toys or clothes.

Yes, similar. On the other hand, public bookcases, which have their
own tag, are also kind of give boxes.

> With your proposed tags, we would need yet another one for non-cooled
> food, so this is a bad idea in my opinion.
>
> So, I suggest:
> amenity = give_box
> food = only
> refrigerated = yes

Not perfect, but way better than amenity=recycling or
amenity=social_facility in my opinion.

Markus

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

Re: [Tagging] Public refrigerators

[Markus]

On Tue, 25 Feb 2020 at 18:31, Robert Whittaker (OSM lists)
 wrote:
>
> I agree with your thoughts re not using amenity=recycling. I've tagged
> a couple of Community Fridges near me as
>
> amenity=social_facility + social_facility=community_fridge
>
> as this tagging (although not documented anywhere) mirrors that for
> Clothing Banks, Food Banks and Soup Kitchens, which are listed at
> https://wiki.openstreetmap.org/wiki/Key:social facility , and seem to
> be related sorts of things. (Though I'm not sure how much these
> community fridges are designed to provide useful items for those in
> need, versus just help reduce waste versus. The balance is probably
> slightly different for each implementation.)

The primary aim of the public fridges here in Switzerland (example
[1]) are clearly to reduce food waste by sharing food (give something
and take something else), not to provide food for the poor (although
they can of course use them too). Therefore, amenity=social_facility
doesn't fit.

[1]: https://www.madamefrigo.ch/en/

On Tue, 25 Feb 2020 at 18:39, Tim Magee  wrote:
>
> I would agree with tagging as
>
> amenity=social_facility
>
> rather than
>
> amenity=public_fridge
>
> because I would prefer not to add to many more amenity types. Rather I would
> want to subclass existing amenity types.

Is there a problem with more amenity=* keys?

Maybe it would have made sense to put all reusing facilities together
in amenity=reuse or similar, but with already 5,538 uses of
amenity=public_bookcase it's probably too late.

Markus

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

[Tagging] Public refrigerators

[Markus]

Hello all

I've noticed that recycling:food= has been added [1] to
amenity=recycling wiki page with the meaning "community fridge [2] to
help reduce food waste".

[1]: 
https://wiki.openstreetmap.org/w/index.php?title=Tag:amenity%3Drecycling=1908674=1906084
[2]: https://en.wikipedia.org/wiki/Community_fridge

In my opinion, it's not a good idea to tag community fridges (public
refrigerators) amenity=recycling, because containers for recycling or
reuse are only for depositing and not for picking up. What if there
are also containers where food can only be deposited, but not picked
up (similar to containers for clothing donations)? We couldn't tell
them apart any more.

As we already use amenity=public_bookcase and amenity=give_box for two
very similar facilities, it seems better to use something like
amenity=public_refrigerator or amenity=community_fridge.

What do you think?

Thanks in advance for your feedback.

Best regards

Markus

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

Re: [Tagging] Feature Proposal - RFC - in-kind_donation

[Markus Peloso]

Hi Hauke,

Thank you for your support and contributions. Clarity and transparency are 
important to me.

1.) I'm also not a native English speaker. I have translated the German word 
"Sachspende". I improve the definition, add a link to a wikipedia article and 
add a section for translations and synonyms.

2.) Maybe the native English speakers could help with a good British English 
tag name. As a Swiss person from the German speaking part I can say that it is 
helpful to have “donation” as part of the tag. Because that is something we 
understand and if I search for a tag that describes what I’m looking for I will 
search for “donation”.

3.) I add a section with tagging examples.

Best regards,

Markus


Von: Hauke Stieler<mailto:m...@hauke-stieler.de>
Gesendet: Samstag, 15. Februar 2020 18:45
An: tagging@openstreetmap.org<mailto:tagging@openstreetmap.org>
Betreff: Re: [Tagging] Feature Proposal - RFC - in-kind_donation

Hi,

I have some feedback for you:

1.)
I'm not a native English spearker and personally never heard of "in-kind
donations" before, so maybe a short description/definition might be
needed/helpful.

2.)
According to [0] the convention for separation word in a key is the
underscore. So I would change the key to "in_place_donations".

3.)
Maybe give some examples for tagging. Something like: "A shop accepting
X in-kind donation for organization Y would be tagged like this: ..."

Hauke

[0]
https://wiki.openstreetmap.org/wiki/Any_tags_you_like#Syntactic_conventions_for_new_tags

On 15.02.20 17:56, Markus Peloso wrote:
> https://wiki.openstreetmap.org/wiki/Proposed_features/in-kind_donation
>
>
>
> For a place that takes in-kind donations.
>
>
>
> Hi
>
>
>
> I describe a tag for shop and amenity that takes in-kind donations. I'm
> interested in your opinions.
>
>
>
> Best regards,
>
> Markus
>
>
> ___
> 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] Feature Proposal - RFC - in-kind_donation

[Markus Peloso]

https://wiki.openstreetmap.org/wiki/Proposed_features/in-kind_donation

For a place that takes in-kind donations.

Hi

I describe a tag for shop and amenity that takes in-kind donations. I'm 
interested in your opinions.

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

[Tagging] Feature Proposal - Voting closed - give box

[Markus Peloso]

Hi

I close voting for 
give_box<https://wiki.openstreetmap.org/wiki/Proposed_features/give_box>. 
Because the current documentation of the proposal process is ambiguous how 
"abstain" should be counted, I set the status to "undefined" until this is 
clarified. 
Talk:Proposal_process#Clarify_whatever_explicit_abstaining_is_the_same_as_no_vote<https://wiki.openstreetmap.org/wiki/Talk:Proposal_process#Clarify_whatever_explicit_abstaining_is_the_same_as_no_vote>

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

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

[Markus Peloso]

Hello Joseph Eisenberg

Thanks for your input and your intention to keep this wiki clear.

I did not count "abstain" as part of the vote total and I don't see any good 
reason for doing that.

The discussion about the name, was early in the voting. After that the people 
still voted "yes".

There are good reasons to use "give box" because it is a well-known and 
existing concept in several European countries.

But maybe some people want a different Name:

I had extended the voting period until 8 February. Feel free to change your 
mind and vote "no" if you want another name.

Please give a clear statement. I will only count "yes" and "no" as part of the 
total.
It is also helpful if you vote "yes" and give a clear comment about the name.

Currently my second choice would be "free box".

Best regards,
Markus Peloso
Von: Joseph Eisenberg<mailto:joseph.eisenb...@gmail.com>
Gesendet: Mittwoch, 5. Februar 2020 15:00
An: Tag discussion, strategy and related tools<mailto:tagging@openstreetmap.org>
Betreff: Re: [Tagging] Feature Proposal - Voting - give box

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

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

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

- Joseph Eisenberg

On 2/5/20, Markus Peloso  wrote:
> https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dgive_box
>
> A small facility where people drop off and pick up various types of items in
> the sense of free sharing and reuse.
>
> Hi
>
> Thanks for voting and for the inputs. Based on the result «13 votes for, 1
> vote against and 5 abstentions» I set the status to approved :D.
>
> Best regards,
> Markus
>
> Von: Markus Peloso<mailto:mar@outlook.com>
> Gesendet: Dienstag, 21. Januar 2020 09:42
> An: Tag discussion, strategy and related
> tools<mailto:tagging@openstreetmap.org>
> Betreff: Feature Proposal - Voting - give box
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/give_box
>
> A small facility where people drop off and pick up various types of items in
> the sense of free sharing.
>
> Hi
>
> Thanks for the discussion, inputs and improvement to this tag.
>
> I request for voting now.
>
> Feel free to give also a negative answer if you only don’t like the name.
> Then please write in the comments what name you prefer. Based on the result
> I will made a second vote with a new name. Other suggested names are:
> • amenity=free_box
> • amenity=free_goods
> • amenity=give_take_box
> • shop=freeshop
>
> Best regards,
> Markus
>
> Von: Markus Peloso<mailto:mar@outlook.com>
> Gesendet: Donnerstag, 9. Januar 2020 21:26
> An: tagging@openstreetmap.org<mailto:tagging@openstreetmap.org>
> Betreff: Re: [Tagging] Feature Proposal - RFC - give box
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/give_box
>
> A small facility where people drop off and pick up various types of items in
> the sense of free sharing.
>
> Hi
>
> Thank you for your inputs to improve this documentation and make it easy to
> understand what this tag is all about. I have removed all references and
> notes to give away shops, because those are not helpful for a clear
> specification of this tag.
>
> Thanks for the hint with the hiker boxes and the other type of boxes. Good
> to see that there are similar projects all over the world. I have included a
> section with suggestions on how this boxtypes could be handled with existing
> tags (the goods tag is already taken). I want this tag to be more specific
> then the reuse tag. I do not want to cover all existing variations with it.
> IMO someone like food boxes for example deserve their own tag.
>
> Von: Markus Peloso<mailto:mar@outlook.com>
> Gesendet: Dienstag, 7. Januar 2020 13:04
> An: tagging@openstreetmap.org<mailto:tagging@openstreetmap.org>
> Betreff: AW: Feature Proposal - RFC - give box
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/give_box
>
> A facility where people drop off and pick up various types of goods in the
> sense of free sharing.
>
> Many thanks for your helpful Feedback and your support. :D
>
> I have updated the proposed.
>
> I like the idea of using the shop=charity icon. Maybe the icon could be a
> combination of the shop=charity icon and the shop=gif

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

[Markus]

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

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

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

Regards

Markus

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

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

[Markus Peloso]

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

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

Hi

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

Best regards,
Markus

Von: Markus Peloso<mailto:mar@outlook.com>
Gesendet: Dienstag, 21. Januar 2020 09:42
An: Tag discussion, strategy and related tools<mailto:tagging@openstreetmap.org>
Betreff: Feature Proposal - Voting - give box

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

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

Hi

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

I request for voting now.

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

Best regards,
Markus

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

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

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

Hi

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

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

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

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

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

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

I have updated the proposed.

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

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

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

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

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

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

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

Von: Markus Peloso<mailto:mar@outlook.com>
Gesendet: Montag, 6. Januar 2

Re: [Tagging] RFC free_water

[Markus Peloso]

Thanks for that. Now it's clear for me.

+1 from me for drinking_water:refill_scheme

I found three national programs (with maps) that I think are related to this 
tag.
- https://refill.org.uk/refill-schemes/
- https://refill-deutschland.de/
- http://www.fillitup.ch/karte.html

Von: European Water Project
Gesendet: Donnerstag, 23. Januar 2020 08:02
An: Tag discussion, strategy and related tools
Betreff: Re: [Tagging] RFC free_water

Dear All,

I have amended the proposal with the tag and a simplified example.

The proposal is definitely more KISS.

drinking_water:refill_scheme = 

Best regards,

Stuart

On Wed, 22 Jan 2020 at 14:21, Philip Barnes 
mailto:p...@trigpoint.me.uk>> wrote:


On Wednesday, 22 January 2020, European Water Project wrote:
> Hi Paul et. al,
>
> I would also be very supportive of this straightforward approach which
> would address many of the concerns regarding an over complicated tagging
> scheme covering cases that are often mandated by local legislation.
>
> One clean solution could be the following or something similar.
>
> drinking_water:refill_scheme=
>

Thank you.

Paul's response did clear up my reservations on the idea.

The webpage makes it clear there is a sticker that is verifiable without going 
in a asking. Not sure if that was mentioned before or if I had simply missed it.

This meets the gold osm standard of Verifable.

Now I know there is something to look out for I can start looking when I'm out.

Its a shame the website doesn't have location, I do not use Google play, but I 
guess thats why you want to put them into OSM.

As its a UK scheme, discussion on the talk-gb list would be more focussed and 
you will reach more mappers who are able to survey and contribute.

Cheers
Phil  (trigpoint)

--
Sent from my Sailfish device
___
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] Feature Proposal - Voting - give box

[Markus Peloso]

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

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

Hi

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

I request for voting now.

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

Best regards,
Markus

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

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

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

Hi

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

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

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

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

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

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

I have updated the proposed.

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

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

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

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

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

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

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

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

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

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

Hi

Based on the https://wiki.openstreetmap.org/wiki/Proposed_features/Reuse and 
the  https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpublic_bookcase tag I 
describe a tag for facilities similar to public bookcases but with all kinds of 
(none food) goods.





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

Re: [Tagging] Tagging ideas for a non-profit ”course center”

[Markus Peloso]

Hello Jyri-Petteri Paloposki

Maybe amenity=coworking_space combined with operator:type=private_non_profit
fits for a place like that?

Best regards,

Markus

Von: Jyri-Petteri Paloposki<mailto:jyri-petteri.palopo...@iki.fi>
Gesendet: Samstag, 18. Januar 2020 00:13
An: tagging@openstreetmap.org<mailto:tagging@openstreetmap.org>
Betreff: Re: [Tagging] Tagging ideas for a non-profit ”course center”

On 21.9.2019 12.52, Tom Pfeifer wrote:
> I'd see that very suitable. You can define the subtype by tagging
> community_centre=*, and I would not see a requirement that the facility
> needs to be open to everybody, it can be for a specific user group,
> which can be tagged with community_centre:for=* .

This is the one that seems most suitable from the current tags, but I'm
still a bit stuck on the idea that a community centre should also have
some communal functions. These course centres I'm referring to don't
really belong to the community, but basically just provide space for
rent for users, which are usually non-profit because of the low-end
facilities.

When I look at the definition of a community centre in Wikipedia
(https://en.wikipedia.org/wiki/Community_centre#Uses_and_activities),
the only one that matches IMO is the one about renting a space. Is it
thus really a community centre?

Best regards,
--
Jyri-Petteri Paloposki

___
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] Tagging Free Water for cafés, bars, restaurant

[Markus Peloso]

Hello Stuart

Can you describe the difference between free_water and drinking_water better? 
Based on the wiki drinking_water means free potable water.

Best regards,
Markus
Von: European Water Project<mailto:europeanwaterproj...@gmail.com>
Gesendet: Mittwoch, 15. Januar 2020 22:09
An: tagging@openstreetmap.org<mailto:tagging@openstreetmap.org>
Betreff: Re: [Tagging] Tagging Free Water for cafés, bars, restaurant

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 
mailto:florimond.berth...@gmail.com>>
To: "Tag discussion, strategy and related tools"
mailto:tagging@openstreetmap.org>>
Subject: Re: [Tagging]  Tagging Free Water for cafés, bars,
restaurant
Message-ID:

mailto: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<mailto: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

[Markus]

On Tue, 14 Jan 2020 at 20:21, Kevin Kenny  wrote:
>
> I think that the point has just been reinforced that debates over
> subtle ontologic questions, such as "is the building that the shop
> occupies a shop, or not?" are the usual outcome of this sort of
> discussion,

My point was that the different uses of disused: and disused=yes may
not be as problematical ("tagging for the renderer") as they seem, but
that there seem to be valid reasons for it.

Regards

Markus

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

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

[Markus]

Hi!

On Tue, 14 Jan 2020 at 18:35, António Madeira via Tagging
 wrote:
>
> What can I do to revive this proposal and implement this tag?

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

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

Re: [Tagging] building=disused

[Markus]

On Tue, 14 Jan 2020 at 19:44, Kevin Kenny  wrote:
>
> For a vacant shop, I might tag 'building=yes' for the renderer (it is
> indeed a building, I'm not lying!) and 'disused:building=shop' or
> 'disused:shop=*' I don't have quite as good an answer for buildings
> that fall in the area of, 'is a structure this decrepit still a
> building?' - and that ontologic question triggers endless debates
> here.

Is it really the shop that is disused and not the building in which
the shop is located?

Actually, i never use disused: on businesses because it feels wrong;
either i remove them or i prefix them with was: . For example,
building=commercial + disused=yes on the area and was:shop=supermarket
+ name=* on a node within.

Regards

Markus

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

Re: [Tagging] building=disused

[Markus]

Tue, 14 Jan 2020 at 19:02, Andy Mabbett  wrote:
>
> 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, and [[Key:building]] says nothing aout
> how to tag "disused", "derelict" or "empty" buildings.
>
> Is JOSM correct, what's the preferred alternative, and why is there no
> easily-found documntation for this common use case?

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.

Therefore, for a disused building, i'd leave the building=* tag and
add disused=yes. (The alternative tagging using lifecycle prefixes,
disused:building=*, isn't rendered.)

Regards

Markus

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

Re: [Tagging] amenity=tourist_bus_parking

[Markus]

Hi John

On Thu, 9 Jan 2020 at 22:37, John Willis via Tagging
 wrote:
>
> https://www.openstreetmap.org/#map=17/36.31737/139.61884
>
> Here is a good example of the kind of situations I have in my area:
>
> - a service area with two different lots, car and HGV (bus/lorry) adjacent to 
> each other, with a satellite bathroom for the busses.
> - service area is segregated by motorway direction, and labeled as such. This 
> makes duplicates of everything.  They are usually not adjacent, but are in 
> this case.
> - dedicated separated handicap parking
> - separate “permissive” lots for people outside the toll system to park and 
> enter on foot.
> - loading zones for deliveries (untagged).

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

amenity=parking
access=customers
bus=designated
hgv=designated
motorcar=no
parking=surface
ref=
surface=asphalt

As amenity=parking currently is defined as a car park, data users
would assume that this is a car park for customers (they likely don't
evaluate motorcar=no).

Even if amenity=parking weren't exclusive for cars, but for any
vehicles, your tagging doesn't mean what you likely had in mind (i.e.
a customer parking for buses and HGVs), but a designated parking
facility for buses and HGVs (not only for customers) that other
vehicles except cars (e.g. tourist buses or motorcycles) can use if
they are customers.

In order that data understand your example and before we've found a
solution for parkings for multiple vehicle classes, i would recommend
to tag it as follows:

amenity=parking
access=no
bus=customers
hgv=customers

Regards

Markus

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

Re: [Tagging] Special traffic signs - still highway=traffic_signals?

[Markus]

Hi Mateusz

On Mon, 13 Jan 2020 at 17:06, Mateusz Konieczny  wrote:
>
> There are some special traffic signals near me
>
> - usually flashing yellow, that has no meaning
> - turning red in case of an incoming
> special vehicle
>
> Special vehicle may be
>
> (1) emergency vehicle leaving fire department
> in this case it gets activated probably once or
> twice a day
>
> (2) tram on a level crossing
> - in peak about over every four minutes,
> during day about once 15 minutes
>
> How to tag this cases?
> Like any other traffic light?

There are already some secondary tags in use and documented for these
kinds of traffic signals:

  * traffic_signals=emergency (902 uses): a normal-looking traffic
signal, often in front of a fire station, that turns red only to give
emergency vehicles right-of-way. Color details may be different (e.g.
flashing yellow instead of solid green in the bottom lens). Often a
sign mounted next to the signals states 'emergency signal'.

  * traffic_signals=bus_priority/tram_priority (321/160 uses):
normally off, but whenever a bus or a tram approaches, it first blinks
yellow and then changes to red to allow or facilitate passage for the
bus or tram

https://wiki.openstreetmap.org/wiki/Key:traffic_signals

I'm going to adjust the documentation for the normal state of these
special case of traffic signals, as they may be off or blinking
yellow.

Regards

Markus

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

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

[Markus Peloso]

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

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

Hi

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

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

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

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

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

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

I have updated the proposed.

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

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

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

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

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

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

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

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

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

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

Hi

Based on the https://wiki.openstreetmap.org/wiki/Proposed_features/Reuse and 
the  https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpublic_bookcase tag I 
describe a tag for facilities similar to public bookcases but with all kinds of 
(none food) goods.




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

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

[Markus Peloso]

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

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

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

I have updated the proposed.

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

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

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

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

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

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

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

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

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

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

Hi

Based on the https://wiki.openstreetmap.org/wiki/Proposed_features/Reuse and 
the  https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpublic_bookcase tag I 
describe a tag for facilities similar to public bookcases but with all kinds of 
(none food) goods.



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

[Tagging] Feature Proposal - RFC - Givebox

[Markus Peloso]

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

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

Hi

Based on the https://wiki.openstreetmap.org/wiki/Proposed_features/Reuse and 
the  https://wiki.openstreetmap.org/wiki/Tag:amenity%3Dpublic_bookcase tag I 
describe a tag for facilities similar to public bookcases but with all kinds of 
(none food) goods.


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

Re: [Tagging] nomoj de internaciaj objektoj / nazwy obiektów międzynarodowych / names of international objects

[Markus]

On Sun, 5 Jan 2020 at 23:27, Tomek  wrote:
>
> I plan to remove the "name" and "wikipedia" tags from places that are not 
> associated with a specific nation or language:
> * continents
> * north and south poles
> * seas and bays, but exceptionally leaving the "name" tag for seas with a 
> maximum of two (or three) languages of neighboring countries, so for example 
> "Белое море" will not change.
> The purpose of this edition is to make the OSM map more neutral and not 
> humiliate people from any country. There is no reason for the Baltic Sea to 
> be the "Baltic Sea" or for South America to be "South America" - this is an 
> example of English imperialism.

I support removing the name=* tag from these places, but for a different reason:

The name=* tag is used to store the local name: "Note that OSM follows
the On the Ground Rule. Names recorded in name=* tag are ones that are
locally used, especially ones typically signposted." [1]

For places where it's impossible to identify a local name, the name
tag should not have been filled out (or at least not set to a single
language).

[1]: https://wiki.openstreetmap.org/wiki/Key:name

Regards

Markus

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

Re: [Tagging] addresses on buildings

[Markus]

On Sun, 5 Jan 2020 at 19:39, Marc Gemis  wrote:
>
> This depends on the country.
> It is "forbidden" to put the address on the building in Denmark,

Says who? And why?

I agree with Martin and others: if every building has an own number,
it makes the most sense to tag it on the building=* way (also because
of inheritance to objects within), if entrances have their own
numbers, tag it on the entrance=* node.

Regards

Markus

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

Re: [Tagging] amenity=tourist_bus_parking

[Markus]

On Sun, 5 Jan 2020 at 17:29, Florimond Berthoux
 wrote:
>
> Using access tags is the good way to go, so we can use
> [vehicle]=yes/no/designated.
> Designated is to explicitly say that the place is specifically made for them.

How would you tag a designated car park for customers only? designated
seems to be orthogonal to yes/no/private/customers/visitors....

Regards

Markus

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

Re: [Tagging] amenity=tourist_bus_parking

[Markus]

On Sat, 4 Jan 2020 at 22:12, Volker Schmidt  wrote:
>
> In particular I would like some tagging scheme that allows you to identify a 
> parking facility, and within that same facility (which carries the name) the 
> parking sub-facilities for cars,  buses, HGVs, motorcycles, ...That would 
> make more sense.

I agree that the current tagging scheme doesn't work well with
mixed-type parking facilities.

However, a new tagging scheme would likely mean that we need a new tag
for parking facilities as i don't think that an automated edit (e.g.
changing access=* to motorcar=*) on over 3 million amenity=parking
would be accepted.

As for the areas within a parking facility, we could use something
similar to building:part: for example amenity=parking_facility:part if
the parking facility is tagged amenity=parking_facility.

Regards

Markus

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

Re: [Tagging] depreciate recycling:metal in favor of recycling:scrap_metal

[Markus]

On Wed, 1 Jan 2020 at 22:35, Martin Koppenhoefer  wrote:
>
> then my suggestion would be the deprecation of scrap_metal in favor of metal. 
> I could imagine though that the term scrap metal was introduced to 
> distinguish it from other kinds of metal collection, like e.g. aluminum cans 
> or aluminum foil
> so for me it seems plausible to have different tags for metal recycling, 
> generally.

I can't see a difference between recycling:scrap_metal and
recycling:metal. If a distinction was intended, then a more clear tag
should have been chosen (e.g. recycling:iron or
recycling:magnetic_metal). Actually i would have preferred
recycling:metal (the additional scrap_ is unnecessary), but as
recycling:scrap_metal has been used nine times more often, it seems
sensible to deprecate it instead.

As for more specific metal recycling: some recycling containers for
tin and aluminum cans also accept small metal items like screws, nails
or chains. Maybe it makes sense to tag this. But how? Using
recycling:scrap_metal (or recycling:metal) would likely make people
wrongly assume that they can also dispose of larger pieces of metal
there (e.g. pots, pans, metal shelves or bicycle frames). What about
recycling:small_metal_items?

By the way, am i right that recycling:cans is for both tin and
aluminium cans (and thus implies recycling:aluminium)? Or is it only
for tin cans?

Wishing everyone a happy new year!

Best regards

Markus

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

Re: [Tagging] footway=crossing in detailed tagging

[Markus]

On Sun, 15 Dec 2019 at 23:06, Volker Schmidt  wrote:
>
> Not unclear at all.
>
> The only thing that both the foot-cycle crossing and the foot-cycle sidepath 
> are tagged as single ways (highway=path, bicycle=designated, foot=designated, 
> segregated=yes).
> And there are hundreds of these around the city.
> So "my" tagging ignores the relative positions of foot and cycle lanes, and 
> there is only one kerb on each side of the crossing. The crossing way extends 
> to the centre line of the sidepath way, the kerb is on the crossing way.

In both examples, the cycleway is physically separated from the
footway by a row of trees except at the crossing. Therefore mapping
them as separate ways makes sense.

Regards

Markus

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

Re: [Tagging] footway=crossing in detailed tagging

[Markus]

On Sun, 15 Dec 2019 at 19:22, Volker Schmidt  wrote:
>
> This is, at least in some cases, more complicated.
> Take a road that has a parallel segregated foot-cycle path and the crossing 
> itself is a segregated foot-cycle path, as in these two examples:
> https://www.mapillary.com/map/im/S6U2AoBM5Q3jI3b-hKP5_A
> https://www.mapillary.com/map/im/x-7IO3FbbtFLB0NKpCZSUQ
> As shown in the two images they come also in two variants (same street!) 
> which illustrate the point I want to make: the pedestrian crossing crosses 
> also the bicycle part of the foot-cycle sidepath, i.e. crossing pedestrians 
> have priority also over the cyclists.
> I would say the the crossing should be mapped to the joining point of the 
> ways.

There are actually two crossings: one from kerb to kerb (street
crossing) and one from kerb to the right lateral end of the red
cycleway. The way from the right lateral end of the cycleway to the
centre of the sidewalk could be mapped as footway=link or, for
simplicity, you could extend the footway=crossing to that point.

(Tell me if this was unclear and you need a diagram.)

Regards

Markus

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

Re: [Tagging] Business names in capital letters

[Markus]

On Sat, 14 Dec 2019 at 21:30, Clifford Snow  wrote:
>
> I would favor adding the name exactly as it appears in a sign, even including 
> punctuation marks if it's in their sign. [...]
>
> Newspapers have a different reason for changing case and even dropping 
> punctuation marks, readability. OSM is interested in capturing ground truth.

If we enter names exactly as they appear on signs, we would have to
change all place names to all caps in Italy, France and likely in
other countries too. But ground truth would also mean that in one and
the same city, some street names would be in normal case, others in
all caps and some in historical spellings not used anymore.

Regarding business names, in the city i live, approximately 50% of
shop names that aren't acronyms are written in all caps on the signs.
However, i could only find two that write their name in all caps in
running text on their homepage and only one with all caps in its
official business name.

Note also that some logos can't be recorded in text-only, because they
use non-Unicode characters (examples [1] [2] [3]) or because the text
is mirrored, compressed or otherwise graphically altered (examples [4]
[5] [6]).

[1]: https://de.wikipedia.org/wiki/Datei:Royal_Dutch_Shell.svg
[2]: https://commons.wikimedia.org/wiki/File:Apple_logo_black.svg
[3]: 
https://gatewayjuniorstorage.blob.core.windows.net/images/R_Logo_7ce3031b-4210-443f-bbeb-25666c95299a.png
[4]: https://commons.wikimedia.org/wiki/File:Desigual.svg
[5]: https://commons.wikimedia.org/wiki/File:Coop.svg
[6]: https://commons.wikimedia.org/wiki/File:Bernmobil_Logo.svg

A logo is a graphical element, not a name.

> For example AT AT at one time was an abbreviation for American Telephone 
> & Telegraph but they dropped the full name for AT sometime back. It 
> technically isn't an acronym anymore.

Former acronyms are usually still written in all caps. Besides, AT
is still pronounced /eɪ tiː ənd tiː/.

> TCBY (The Countries Best Yogurt) is a yogurt shop that is widely recognized 
> in the US. If you wrote Tcyb, I doubt most people would even recognize it. If 
> written out, The Countries Best Yogurt, people probably would recognize it 
> either. See https://www.openstreetmap.org/node/2304474733 for an example.

TCBY is an acronym, therefore it should of course be written in all caps.

Regards

Markus

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

Re: [Tagging] footway=crossing in detailed tagging

[Markus]

Hi Mateusz!

On Sun, 15 Dec 2019 at 12:32, Mateusz Konieczny  wrote:
>
> Let's say that we have footway mapped separately from the road, road has 
> footways on both sides.
>
> Footway has surface=paving_stones, road has surface=asphalt.
>
> There is a crossing, made from three ways:
> - (1) highway=footway surface=paving_stones (for a bit from centerline of 
> sidewalk to the curb)
> - (2) highway=footway surface=asphalt (for part on the carriageway)
> - (3) again highway=footway surface=paving_stones for part from curb to the 
> centerline
>
> How footway=crossing tag should be applied?
>
> To all three or just carriageway surface - (2) segment?

The same question came up in the ongoing discussion "Feature Proposal
- RFC - footway=link".

Strictly speaking, the pedestrian crossing goes from kerb to kerb. The
two extra ways (1 and 3) are only needed because we map roads and
paths as lines for simplification and routers. The question is how to
tag these extra ways. They aren't sidewalks, as there is only one
sidewalk running parallel to the street. Because of a lack of an
alternative and for simplification, i've always extended the
footway=crossing to the centre of the sidewalks (i.e.,
footway=sidewalk). But it seems that footway=link (or how the tag
finally will be called) is a possibility to tag the extra ways 1 and
3.

The whole discussion "Feature Proposal - RFC - footway=link" can be found here:

https://lists.openstreetmap.org/pipermail/tagging/2019-November/thread.html#49311
https://lists.openstreetmap.org/pipermail/tagging/2019-December/thread.html#49527

Regards

Markus

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

Re: [Tagging] Business names in capital letters

[Markus]

On Sat, 14 Dec 2019 at 01:44, Graeme Fitzpatrick  wrote:
>
> When that is how the business name is shown, what is our policy for it?

I thought we had a policy for it, but i can't fine one. It's probably
rather an observation that names in all caps are mapped in title case
except for acronyms. I think this makes sense because it doesn't give
these names more importance than other names in title case. By the
way, newspapers do the same.

Regards

Markus

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

Re: [Tagging] Feature Proposal - RFC - footway=link

[Markus]

On Sun, 8 Dec 2019 at 21:55, Allroads  wrote:

> Draw this image over the example, JOSM changes (not uploaded) drawn in.
> https://i.postimg.cc/t70p6WXm/Neubr-ckcrossing.png
> The area:highway=footway is correctly drawn in, but the footway is all
> footway=sidewalk, your still walking on the sidewalk.

I agree that you are on the sidewalk after coming down the steps, but
i don't agree that every way inside area:highway=footway +
footway=sidewalk (sidewalk area) is a highway=footway +
footway=sidewalk, because there is only *one* sidewalk, not multiple.
Otherwise, following your logic, all ways inside area:highway=tertiary
– including ways from the centre of the road to kerbs (which you
tagged footway=connection) – would have to be tagged highway=tertiary.

In my opinion, the way from the end of the steps to the kerb is also a
connection.

> Other perpendicular waylines inside a area:highway does not need that, if so
> then a other kind of value (I do not see the need for that)
>
> [...]
>
> Where do you need it, I think where kerbs are it is more important, and when
> you use area:highway, *=connection we could render visualise it slightly
> different.
> https://i.postimg.cc/D0n5S70G/tpath.jpg
> > [5]: https://www.openstreetmap.org/node/413988097

There's no kerb at this place. The only difference to the nearby T
crossing with the track is the width of the two ways.

Why should we need to tag the part of the path inside road area
specifically (e.g. as footway=connection), but not the part of the
track inside the road area?

Regards

Markus

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

Re: [Tagging] Feature Proposal - RFC - (changing_table:location)

[Markus]

Hi Sören

Multiple tags are only needed if each of them describes a different
property, which is not the case for changing_table:location. I don't
see a problem with adding two or more values separated by a semicolon
in this case. In the contrary: a value list is clearer and it seems
that it can be used more easily by data users (see this discussion [1]
and its continuation [2]). The wiki page on Semi-colon value separator
[3], which you referred to, seems to be overly strict when it says
that "avoid ';' separated values whenever possible".

[1]: https://lists.openstreetmap.org/pipermail/tagging/2018-December/041650.html
[2]: https://lists.openstreetmap.org/pipermail/tagging/2019-January/041884.html
[3]: https://wiki.openstreetmap.org/wiki/Semi-colon_value_separator

Regards

Markus

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

Re: [Tagging] Feature Proposal - Voting result - Pedestrian lane

[Markus]

On Wed, 4 Dec 2019 at 01:31, Alessandro Sarretta
 wrote:
>
> And in case on the left we have a shared cycle/foot lane?
>
> cycleway:left=lane
> pedestrian_lane=left
> segregated=no
>
> or
>
> cycleway:left=lane
> footway:left=lane
> segregated=no
>
> I think discussing of specific examples could help us clarifying which
> solution is better (or more usable).

A shared foot and cycle–lane is only one feature, therefore there
should only be one lane tag IMHO, not two. Because this is a separate
feature, likely with its own legal rules (i guess that pedestrians
have priority over cyclists?), i think a separate tag like
foot_cycle_lane=left/right/both would make most sense.

Another possibility were pedestrian_lane:bicycle=designated, but this
would imply that a shared foot and cycle–lane is a subtype of a
pedestrian lane. I'm unsure if this is sensible.

Regards

Markus

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

Re: [Tagging] Feature Proposal - Voting result - Pedestrian lane

[Markus]

On Wed, 4 Dec 2019 at 13:06, Marc Gemis  wrote:
>
> On Tue, Dec 3, 2019 at 9:36 PM Markus  wrote:
> >
> > In my opinion, footway[:left/right]=lane isn't a good idea for the
> > following reasons: 1. footway=lane is a contradiction, as a lane (part
> > of a road/path) isn't a footway (separate path).
>
> But isn't this exactly the same as we do for cycleway=lane?

Yes, it is, and it doesn't make much sense either, as a cycle lane
isn't a cycleway. (Oddly enough, the very similar US term bikeway
includes cycle lanes according to some definitions, while it excludes
them according to other definitions.)

I would have chosen cycle_lane=left/right/both instead, also because
"lane" (the type) is more important than left/right/both (the detail)
and would therefore belong to the key instead of the value. (Besides,
cycleway is already a value in highway=cycleway.)

> I would love to see consistency between cycleway and footway mapping.

There's already an inconsistency: separated footpaths are tagged
sidewalk=left/right/both while separated cycle paths are tagged
cycleway[:left/right]=track. Therefore i think it would be better to
not introduce more inconsistencies in pedestrian infrastructure
tagging.

Regards

Markus

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

[Tagging] Feature Proposal - Voting result - Pedestrian lane

[Markus]

Dear all,

The voting on the proposal for a new key pedestrian_lane=* for lanes
designated for pedestrians is over. 8 people voted for the proposal, 5
against it and 1 person abstained. This is an approval by 62%, which
is below the required 75% majority. Therefore the proposal has been
rejected.

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

The following reasons for opposing the proposal were given:

  - footway[:left/right]=lane should be used instead of the proposed
pedestrian_lane=left/right/both. (mentioned twice)

  - More discussion is needed. (mentioned twice)

  - Disagreement with the definition of sidewalk=* being a raised or
otherwise physically separated footpath at the side of a road.
(mentioned once)

In my opinion, footway[:left/right]=lane isn't a good idea for the
following reasons: 1. footway=lane is a contradiction, as a lane (part
of a road/path) isn't a footway (separate path). 2.
sidewalk=left/right/both and footway[:left/right]=lane would have two
different syntaxes, which were confusing. 3. lane would be the only
value which were a departure from the usual tag syntax where the value
is variable and the key remains constant.

Many thanks to the (unfortunately rather few) people who took part in the vote.

Best regards

Markus

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

Re: [Tagging] Foot or foot.cycle crossing

[Markus]

On Wed, 27 Nov 2019 at 17:36, marc marc  wrote:
>
> I don't see a physical séparator between the road and the sidewalk
> so it's controversial to separate these different lanes into several ways

There's a curb, although a very low one. (Ironically, it is highest at
the zebra crossing ... not the best example of accessible and safe
pedestrian infrastructure ...)

Regards

Markus

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

Re: [Tagging] Foot or foot.cycle crossing

[Markus]

On Wed, 27 Nov 2019 at 16:13, Volker Schmidt  wrote:
>
> (1)
> way with:
> crossing=uncontrolled
> footway=crossing
> highway=footway
> plus node with:
> crossing=uncontrolled
> highway=crossing

I'd tag it like that. I don't see any problems. You don't need a
crossing node for the cycle lane as it is part of the carriageway of
Via Egidio Forcellini. This is different form the sidewalk that is
interrupted by the unnamed one-way road.

Regards

Markus

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

Re: [Tagging] Feature Proposal - RFC - footway=link

[Markus]

On Mon, 25 Nov 2019 at 11:22, Allroads  wrote:
>
> Then there is a tag as placement=transition.
>
> This have also a kind of connection link function.
>
> [...]
>
> If we think about it further, where more does this tag fit?

The two tags are similar, but different:

The key placement gives information about the placement of a highway=*
way relative to the lanes. placement=transition means that the
placement is changing along the highway=* way. It doesn't say whether
the highway=* way is part of the carriageway of another highway=*. (It
can, e.g. when the road forks, but it doesn't have to, e.g. when the
road doesn't fork but the number of lanes changes.)

In contrast, *=link (or *=connection or how will finally be called)
means that the highway=* way is located inside the carriageway of
another highway=* way and thus has no length or doesn't really exist.
It is only used to connect the roads or paths to make routing
possible.

Regards

Markus

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

Re: [Tagging] Feature Proposal - RFC - Pedestrian lane

[Markus]

On Sun, 24 Nov 2019 at 23:19, Paul Allen  wrote:
>
> Depends on jurisdiction too (if I'm following all this correctly, which I may 
> not be).  In
> some jurisdictions, crossing is legal only at specified crossings and they 
> tend to
> be frequent.  In other jurisdictions, like the UK, crossing is legal almost 
> anywhere, but
> there may also be (infrequent) designated crossings.

The examples in my previous message are from 30 km/h zones in
Switzerland, where there are no marked or signalised pedestrian
crossings except near schools or homes for senior or handicapped
people and where pedestrians therefore are allowed to cross the road
everywhere. The general rule here is that pedestrians must use a
designated pedestrian crossing, underpass or bridge if there is one
within 50 m. [1] As far as i know, the situation is similar in other
countries that follow the Vienna Convention on Road Signs and Signals,
except that the distance varies (often being 100 m).

[1]: https://www.admin.ch/opc/fr/classified-compilation/19620246/index.html#a47

> I'm a little worried we could end up with the situation in the UK where it is 
> legal for me to
> cross the road where I am but the routeing engine tells me I have to walk a 
> mile to a
> designated crossing then walk a mile back.  That can probably be solved by 
> adding
> jurisdiction heuristics to routeing engines.  But it needs to be thought 
> about before
> we paint ourselves into any corners.

That's exactly the big problem with sidewalks being mapped as separate
ways in areas where there are no or few designated pedestrian
crossings and where it is allowed to cross the road everywhere. Even
when, at intersections, you map unmarked crossings that are logical
continuations of the sidewalks (which are more or less verifiable
because used by many people) (example [2]), you still get unnatural
routes that are long detours (example [3]). At least in these areas,
mapping sidewalks (and pedestrian lanes) with separate ways seems more
problematical than tagging them on the street way.

[2]: https://www.openstreetmap.org/way/536404830
[3]: 
https://www.openstreetmap.org/directions?engine=fossgis_osrm_foot=46.93737%2C7.44928%3B46.93757%2C7.44893

Regards

Markus

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

Re: [Tagging] Feature Proposal - RFC - footway=link

[Markus]

Many thanks for your thoughts, Nick!

On Sat, 23 Nov 2019 at 02:36, Nick Bolten  wrote:
>
> I would propose that under an expansive definition it be thought of this way: 
> a "footway link" is a path connecting pedestrian-accessible ways that is not, 
> itself, a centerline of a designated physical pedestrian space.

Wouldn't this mean that any footpath leading into a road would need to
be split for its last few metres, like the last 3 m of the path here?:

https://www.openstreetmap.org/node/413988097

I doubt that this were very useful, but would only complicate mapping.
If you want to know the precise location where the footpath begins or
ends, it should be possible to get that information from the road
width or area:highway=*.

Besides, only defining footway links, but e.g. not connections of
tracks with roads (example [1]) or of roads with other roads (example
[2]) seems quite arbitrary.

I think the only situation where such links are really required is
when connecting two adjacent parallel ways (your point 1), like for
example a road and a sidewalk, a parallel cycle path [3] or parallel
steps, as such a connection isn't an extension of either way (the 3 m
in the example above is the extension of the foot path, but the
connection of an ending sidewalk with the road is neither sidewalk nor
road).

I am thinking about a definition like "a footway/cycleway/path=link is
a way that is used to change from a road to an adjacent parallel
path".

> 3. Transitioning from a sidewalk to a crossing, where both are separately 
> mapped: [...] It's that short path that extends from the sidewalk to the 
> street.

That short way definitely isn't a separate sidewalk (no lateral kerb,
not parallel to the road), but the extension of the crosswalk. In my
opinion there isn't a necessity tag it differently – if the width of
the sidewalk is specified, it is clear where the crosswalk begins.
While it wouldn't harm if people tag that short way or the extension
of a path that is inside the area of a road as footway=link, i think
that this shouldn't be a requirement.

> 4. Plazas. While it is possible to extract many plausible paths through 
> pedestrian area features, there is value in simply mapping the most direct 
> paths and not requiring data consumers to become intimately familiar with 
> skeletonization algorithms or robotics pathfinding. Mapping canonical paths 
> through plazas as links allows both options: they can be ignored (as they are 
> acknowledged to be connections rather than distinct paths) or consumed 
> directly.

This is a very different situation from the connections i have in
mind. Besides, these aid ways likely aren't verifiable.

> 5. Short paths to building entrances from sidewalks, other footways. [...]
>
> 6. Short paths that deviate slightly from centerlines to make use of 
> facilities, but are still related to those other footways. [...]

Could you please give me some examples for these two points?

[1]: https://www.openstreetmap.org/node/893450790
[2]: https://www.openstreetmap.org/node/506223281
[3]: https://www.openstreetmap.org/way/518400616

Best regards

Markus

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

Re: [Tagging] Feature Proposal - RFC - Pedestrian lane

[Markus]

On Sat, 23 Nov 2019 at 01:03, Nick Bolten  wrote:
>
> These errors are an artifact of not knowing where the sidewalks and crossings 
> actually interface and having to guess about them.

It should be possible to solve this problem by specifying the width of
the carriageway (width=*) and of the sidewalk(s)
(sidewalk[:left/right]:width=*), shouldn't it? (This may be useful
information anyway, no matter if the sidewalks are mapped separately
or not.) If it isn't possible to specify the widths, the information
to which sidewalk a crosswalk belongs could be given with a relation.

> In contrast,  pedestrian ways that are directly connected to one another can 
> be analyzed using any transportation network software and are compatible with 
> common OSM routers.

This is true, but mapping sidewalks with separate ways isn't
unproblematical either, especially if there aren't any marked
crosswalks: mapping unmarked crossings is often impossible because not
verifiable, but not mapping crossings results in disconnected
sidewalks. A particular problem are T crossings with sidewalks on both
sides of both streets, as for example here:

https://www.openstreetmap.org/node/32860990

Besides, mapping sidewalks with separate ways requires quite good
aerial imagery, which unfortunately isn't available everywhere
(example [1]). Furthermore it takes much more time than adding
sidewalk=* tags and you can break more – people that map sidewalks
ways often don't map unmarked crossings, which results in unusable
sidewalks (example [2]).

Compared to sidewalk, mapping pedestrian lanes with separate
highway=footway ways would even be more problematical, because the
pedestrian lanes are a part of the carriageway of the road and (in
some countries) can also be used by vehicles in order to make way for
oncoming traffic.

[1]: https://www.openstreetmap.org/#map=19/47.04825/8.30513
[2]: https://www.openstreetmap.org/way/682152784

Regards

Markus

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

Re: [Tagging] Feature Proposal - RFC - footway=link

[Markus]

On Wed, 20 Nov 2019 at 13:54, Martin Koppenhoefer
 wrote:
>
> the issue with steps being represented too long is not related to the 
> proposal of adding a specific subtag. I generally map highway=steps only for 
> the (approximated) actual projection of the steps (first to last riser of 
> each steps part) and add highway=footway for the landings and for the 
> connections on the bottom and top.

If the steps end in the street (as in the examples in my previous
message [1] [2]), then there isn't a real highway=footway; this
connection is completely part of the road area. The aim of this
proposal is to indicate data users that this is a connection instead
of a footpath.

[1]: https://www.openstreetmap.org/way/86205950
[2]: https://www.openstreetmap.org/way/416303537
(Set 
https://mapproxy.osm.ch/tiles/bern2016/EPSG900913/{zoom}/{x}/{y}.png?origin=nw
as background layer.)

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

Re: [Tagging] Feature Proposal - RFC - footway=link

[Markus]

On Tue, 19 Nov 2019, 04:43 Joseph Eisenberg,  wrote:
>
> I'm skeptical about the need to tag this differently.
>
> If we do this, wouldn't we also need to tag differently a "T"
> intersection of a `highway=residential` into a `highway=trunk`?
>
> Doing this for every intersection between a path and road, or lower
> classification road with a high classification road, would be a large
> amount of extra work for mappers, so it should only be done if there
> is no other way to get this information.

In my opinion, there's only little use in splitting roads at
intersections only to indicate that a short part of a highway=* way is
part of the carriageway of another road.

However, this is a bit different with ending sidewalks or steps that
run parallel to the road: tagging the connection with the road
highway=footway + footway=sidewalk or highway=steps would pretend that
there were an abrupt change of the direction of the sidewalk or steps
by 90°, which is a bad representation of the actual geometry (example
[1]). Besides, continuing steps up to the highway=* way would distort
the steps, which is especially problematical with short steps and a
wide road. For example, continuing highway=steps of 4 steps with a
length of 35 cm each to the centre of the road that is 8.4 m away from
the last step would let you assume that one step is 2.45 m long
(example [2]).

[1]: https://www.openstreetmap.org/way/86205950
[2]: https://www.openstreetmap.org/way/416303537

Thanks you all for your feedback so far!

Best regards

Markus

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

Re: [Tagging] Feature Proposal - RFC - footway=link

[Markus]

On Mon, 18 Nov 2019 at 23:05, Graeme Fitzpatrick  wrote:
>
> Markus
>
> Will this fix the "error" of "Footpaths are disconnected from other roads"?

It may, but this really depends on the situation. Could you give me examples?

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

Re: [Tagging] Feature Proposal - RFC - footway=link

[Markus]

On Mon, 18 Nov 2019 at 23:40, Allroads  wrote:
>
> All waylines inside a area:highway=footway footway=sidewalk is a
> highway=footway footway=sidewalk
> When there is a connection to the road, inside the area:highway=footway,
> footwalk=sidewalk is till the barrier=kerb.

I'm unsure if this is a good idea. Wouldn't this mean that there's a
short separate sidewalk that runs perpendicular to the real sidewalk?
Wouldn't we consequently have (1) to split a sidewalk at a driveway
and tag a part highway=service + service=driveway and (2) the part of
the driveway inside the carriageway of the residential road
highway=residential?

Example (to be displayed with a fixed-width font):

  ┃  ┆  ┃
  ┃  ┆  ┃ <- driveway
  ┃  ┆  ┃
━━┛  ┆  ┗━━
┄┄┄1┄┄┄ <- sidewalk
─┆─
 2
 2
┈┈┈ <- residential road


━━━


1: highway=service + service=driveway?

2: highway=residential?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - footway=link

[Markus]

On Tue, 19 Nov 2019 at 04:24, Clifford Snow  wrote:
>
> First off I like this proposal and agree that it be applied more broadly. 
> However there is a difference between a motorway=link (and similar) and a 
> footway=link. A motorway=link is a physical feature unlike a footway=link. A 
> footway=link is more of an attempt to bridge vector representation of a 
> footway and how it connects to a vector representation of a road. In reality, 
> they are adjacent features. If highways=* were drawn as areas, we wouldn't 
> need a footway link but still need a motorway=link. Then there is the 
> question of how footway=link should be rendered. I would be happy with a 
> dashed gray line to indicate that it's just a connection for a router.

You're right, the value "link" isn't optimal as it can lead to
confusion with highway=*_link roads. What alternative value should we
choose? footway=connection?

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

[Tagging] Feature Proposal - RFC - footway=link

[Markus]

Hello everyone

As the discussion has moved from pedestrian lanes to linking ending
sidewalks with a road and as there haven't been any more changes or
suggestions to the proposal on pedestrian lanes, i'm opening the vote
on that proposal and requesting comments on the proposal on
footway=link:

https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:footway%3Dlink

Definition: to link steps or a sidewalk with a road

Best regards

Markus

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

[Tagging] Feature Proposal - Voting - Pedestrian lane

[Markus]

Hello everyone

As the discussion has moved from pedestrian lanes to linking ending
sidewalks with a road and as there haven't been any more changes or
suggestions to the proposal on pedestrian lanes, i'm opening the
proposal for vote:

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

Definition: a marked lane on the roadway, designated for pedestrians

Thank you in advance for taking part in the vote.

Best regards

Markus

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

Re: [Tagging] Feature Proposal - RFC - Pedestrian lane

[Markus]

On Mon, 18 Nov 2019 at 02:48, John Willis via Tagging
 wrote:
>
> I use “unmarked crossing” for all connections of sidewalks where they 
> dead-end and have to be connected into the road.

If there's a second sidewalk or a pedestrian lane on the opposite side
of the road, this may make sense. But if there's just a sidewalk that
ends and pedestrians don't cross the road there (example [1]),
footway=crossing + crossing=unmarked seems wrong to me.

[1]: https://www.openstreetmap.org/way/547007384

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

Re: [Tagging] shop selling trucks

[Markus]

On Sun, 17 Nov 2019 at 19:23, Marc Gemis  wrote:
>
> AFAIK, VW does not sell lorries/hgv/trucks. Their commercial vehicles
> are pick ups and vans (caddy/transporter/crafter) The largest, has a
> GVW of 5t.
>
> Which tags do we have to use in case the shop only sells those vehicles?

It seems we don't have one, but it may make sense to use
shop=utility_vehicle or something similar.

Regards

Markus

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

Re: [Tagging] Feature Proposal - RFC - Pedestrian lane

[Markus]

On Sun, 17 Nov 2019 at 17:32, Martin Koppenhoefer
 wrote:
>
> Generally, if this was agreed, wouldn’t we have to split every footway that 
> connects to a road for its last 2 or so meters, because that’s actually the 
> road (in a model that takes the extension of the ways into account)?

That's a good question. I think it's useful to do so with steps,
because otherwise they're distorted too much (especially the very
short ones), and with connections of a sidewalk with a road, to
indicate that these connections aren't sidewalks. On the other hand, i
think it's less useful to do so for footpaths or any path or road that
connects with another. But i probably wouldn't prevent people from
doing so.

Regards

Markus

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

Re: [Tagging] Feature Proposal - RFC - Pedestrian lane

[Markus]

On Tue, 12 Nov 2019 at 23:54, Nick Bolten  wrote:
>
> > You mean a situation like this?:
>
> > https://wiki.openstreetmap.org/wiki/File:Sidewalk_and_crossing.svg
>
> One very similar to that, yes! I think I normally wouldn't add sidewalk=both 
> to any length of the highway=residential. Is that a typical thing to do? I 
> would assume that meant the highway=residential street had its own short 
> piece of sidewalk, when it actually doesn't.

You're right, sidewalk=both doesn't make sense in that example. I use
this tagging only when the junction and the sidewalks are curved. I've
updated the drawing to better represent the situation.

> The challenge I'm describing is in reliably associating the crosswalk with 
> the pedestrian paths. After all, the crosswalk is a node on a different 
> street way. I know that I could do it 99.x% of the time, but it will require 
> using some graph traversal approaches that most people aren't familiar with. 
> Plus, those cases where I couldn't reliably determine it could be very 
> important. I suspect this is one of the reasons I haven't found anyone using 
> these data in concert (sidewalk=both + highway=crossing) to do pedestrian 
> routing.

The following pedestrian router already seems to work quite well with
sidewalk=* tags and highway=crossing nodes (examples):

https://www.routago.de/pedestrian-routing/?map=46.9802955,7.421488,19=46.9798388,7.4200845=46.9800291,7.4229276
https://www.routago.de/pedestrian-routing/?map=46.9932946,7.4567288,18=46.9936495,7.4545938=46.9927603,7.4568951

(However, it seems that it prefers minor roads and paths over distance too much:

https://www.routago.de/pedestrian-routing/?map=46.9931482,7.4576354,17=46.9936495,7.4545938=46.991809,7.4570239)

> > I would simply connect the sidewalk way with the road where the
> sidewalk ends (and map a barrier=kerb + kerb=* node) and add
> pedestrian_lane=* to the road starting from where the pedestrian lane
> begins.
>
> So there would be a segment of footway=sidewalk that is not actually on a 
> sidewalk? I've been unsure about what to do in similar situations, like how 
> to connect footways to roads without implying there's literally a footway on 
> top of the road. Probably worth its own, separate discussion (it was 
> discussed previously, but without conclusion), so I won't elaborate.

I use highway=footway + footway=link connect steps and sidewalks to a
road, in order to retain the real length and geometry of the steps or
sidewalks and to indicate that these aren't steps or a sidewalk
anymore, but part of the carriageway of the road. Other mappers seem
to use this scheme too (already 743 uses and only every 7th is from
me).

https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:footway%3Dlink

Best regards and a nice weekend to all of you

Markus

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

Re: [Tagging] shop=ice_cream vs amenity=ice_cream and OSM Wiki vs tagging

[Markus]

On Tue, 12 Nov 2019 at 14:15, Paul Allen  wrote:
>
> On Tue, 12 Nov 2019 at 00:23, Martin Koppenhoefer  
> wrote:
>>
>> from the description, light meals aren’t a hard requirement, or it could be 
>> seen as satisfied by selling cakes (or ice cream cups in the case of cuisine 
>> =ice_cream):
>
> I suspect that, over the years, people have forced things into cafe because 
> it came closest
> to what they wanted without having to create a new value and then somebody 
> later documented
> it.  Or people bring different cultural assumptions to the term "cafe."
>
> Question.  You've had a busy day.  No time to eat breakfast or lunch.  You're 
> hungry.  You're
> in a strange town.  You're looking for somewhere to eat.  You look at the map 
> for cafes.
> Would you be happy if you went to one and it sold only ice cream or only cake?

I wouldn't look for a café if i were hungry. Instead i would look for
a restaurant, pub or fast food booth.

In mainland Europe i expect from a café that i can drink a coffee
there and maybe have a sweet snack. While some also serve salty snacks
(like panini) or alcoholic drinks (like apéritifs), i wouldn't expect
that every café serves this.

> Questions.  We already have tags that can distinguish between a shop selling 
> ice cream
> to take out and a place with tables and seats where you buy ice cream to eat 
> inside
> (possibly with a takeaway option).  What purpose does it serve to collapse 
> these into
> a single tag?  What purpose does it serve to replace one of them with a cafe? 
>  Are you
> willing to fix up all the existing usage?  Or is it easier all around to fix 
> up the documentation
> and live with the fact that some existing places may be mismapped?

It is questionable that these two tags are really used the way you define them.

What we know is that when amenity=ice_cream was proposed in 2009, both
tags were used about 50 times each [1], but were undocumented, and
that the approved proposal defined amenity=ice_cream as "a shop which
sells ice creams; an ice-cream parlour" and intended it to be used
"for all places that sell (only or mainly) ice cream ready to eat".
This also includes ice cream parlours/booths without tables and seats.
It, however, excludes shops that only or mainly sell ice cream in
packaging to be taken home, but it is unclear whether such shops even
exist.

[1]: https://taghistory.raifer.tech
[2]: https://wiki.openstreetmap.org/wiki/Proposed_features/Ice_cream

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

Re: [Tagging] Feature Proposal - RFC - Pedestrian lane

[Markus]

n which side of the road they should walk.

> ## Other sources
>
> A potentially helpful resource during these international comparisons: 
> https://www.fhwa.dot.gov/environment/bicycle_pedestrian/publications/small_towns/page05.cfm.
>  The FHWA defines standards in the United States.

Thanks. The content of this page seems to be identical to this PDF
document by the FHWA i mentioned in some of my earlier messages:

https://www.fhwa.dot.gov/environment/bicycle_pedestrian/publications/small_towns/fhwahep17024_lg.pdf

Best regards

Markus

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

Re: [Tagging] shop=ice_cream vs amenity=ice_cream and OSM Wiki vs tagging

[Markus]

On Mon, 11 Nov 2019 at 11:55, Mateusz Konieczny  wrote:
>
> Is there some consistent difference how
> this two tags are actually used?

Unfortunately i can't answer your question (too little
amenity=ice_cream and no shop=ice_cream around where i live), but i
just discovered that 349, that's 15.2%, of all 2,293 shop=ice_cream
also have an amenity=ice_cream tag.

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

Re: [Tagging] shop=ice_cream vs amenity=ice_cream and OSM Wiki vs tagging

[Markus]

On Sun, 10 Nov 2019 at 18:21, Paul Allen  wrote:
>
>> However, shop=ice_cream says to take home, not to take away.
>
>
> Then the wiki is unclear and misleading.  And it looks like somebody has 
> taken an
> alread-misleading page, decided it was a synonym of amenity=ice_cream and then
> made it even more misleading.

Regardless of what the wiki says, i wouldn't call a takeaway a shop.

> "Take home" and "take away" share an important property: "not for consumption 
> on
> the premises."  Whether you take the stuff home or take it off the premises 
> and
> consume it nearby, you are not consuming it on the premises.
>
> Try a related situation: a chip shop near me.  Some chip shops are takeaway
> only.  This one happens to have seats and tables, so it gets tagged as a
> cafe with take_away=yes.  Some people who buy fish and chips to take away
> go across the road, sit on one of the two benches there, and eat them.  Others
> take their fish and chips all the way home.  Taking the fish and chips home
> is one of the subsets of things you can do if you take the fish and chips 
> away.

Correct me if i'm wrong, but it seems that fast food restaurants or
takeaways are currently both tagged amenity=fast_food and that the
distinction whether they have seats and tables or not is made with
takeaway=no/yes/only. (At least this seems to be the case in middle
and southern Europe.)

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

Re: [Tagging] shop=ice_cream vs amenity=ice_cream and OSM Wiki vs tagging

[Markus]

On Sun, 10 Nov 2019 at 17:56, Mateusz Konieczny  wrote:
>
> nitpick: tag is without underscore 
> https://wiki.openstreetmap.org/wiki/Key:takeaway

Sorry and thanks for correcting me!

Markus

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

Re: [Tagging] shop=ice_cream vs amenity=ice_cream and OSM Wiki vs tagging

[Markus]

On Sun, 10 Nov 2019 at 17:00, Paul Allen  wrote:
>
> Me neither.  But that's a bit of a false dichotomy.  It isn't just eat on 
> premises or take home.
> There's also take away.  As in an ice cream van on a fixed pitch.  Rather 
> common at the
> seaside.  Or a kiosk selling only, or mainly,. ice cream.  You buy the ice 
> cream to eat on
> the beach.

However, shop=ice_cream says to take home, not to take away. Besides,
it's probably very rare that an ice cream parlour doesn't allow ice
cream to be taken away. And if so, this can be take_away=no. No need
to use a different tag for this situation, in my opinion.

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

Re: [Tagging] shop=ice_cream vs amenity=ice_cream and OSM Wiki vs tagging

[Markus]

Strangely enough, the page

https://wiki.openstreetmap.org/wiki/Tag:shop%3Dice_cream

says that shop=ice_cream is "for places selling ice cream to take
home", but shows an image of an ice cream parlour.

Are there really shops that only or mainly sell packaged ice cream for
taking home?

Otherwise, it seems to make sense to deprecate shop=ice_cream in
favour of the more used amenity=ice_cream.

Regards

Markus

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

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

[Markus]

On Tue, 5 Nov 2019 at 18:25, Volker Schmidt  wrote:
>
> This a well-known (small) problem that from time to time turns up in OSM 
> discussions. And then the discussion fizzles out again.

Which is also a well-known problem ...

I guess that bicycle=no almost always means that *driving* a bicycle
isn't allowed. So it seems just logical to use a new tag for places
where pushing (or transporting) bicycles isn't allowed too. Maybe
bicycle=total_ban or bicycle_pushed=no?

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

Re: [Tagging] Is there a good way to indicate "pushing bicycle not allowed here"?

[Markus]

On Tue, 5 Nov 2019 at 17:28, Martin Koppenhoefer  wrote:
>
> do you have an example for a street where pushing the bicycle is not allowed? 
> What about pushing a broken bicycle? Carrying a bicycle? Monocycles? 
> Tricycles? Pushing big boxes? Wearing a red hat?
> I would be interested to see a law discriminating particularly against 
> pushing bicycles.

https://www.ansa.it/english/news/general_news/2016/10/25/venice-bans-pushing-bikes_e4ad7248-970e-49a8-b9a1-73efe5716101.html

And there are some elevators at the train station in Bern where it's
not allowed to take bicycles.

Regards
Markus

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

Re: [Tagging] Feature Proposal - RFC - Pedestrian lane

[Markus]

On Sat, 2 Nov 2019 at 20:37, Clifford Snow  wrote:
>
> I like your proposal but think it needs to clarify the difference between a 
> pedestrian lane and a shoulder [1]. In the US, most (many?) states allow 
> pedestrians to walk on shoulders if there is no sidewalk/footway, with the 
> exception of motorways. How would a mapper know if this is a shoulder or a 
> pedestrian lane?

Thanks for your input. I didn't think about that because here in
Switzerland shoulders only seem to exist on motorways and trunk roads
and because of their difference in appearance (shoulder: continuous
white line [1], pedestrian lane: continuous yellow line with yellow
diagonal stripes [2]). In the United States, it seems that pedestrian
lanes are marked accordingly. [3] I guess that in other countries,
pedestrian lanes are also marked or signed accordingly or have a
different appearance like in Switzerland, but when in doubt, it is
certainly better to not tag a lane as pedestrian lane. I'll add a
warning to the proposal page.

[1]: https://www.mapillary.com/map/im/vhd1RZj0JXfpHIZ1uHj0xA
[2]: https://www.mapillary.com/map/im/6NiPeYEe87G_ex49SqwFtg
[3]: 
https://www.fhwa.dot.gov/environment/bicycle_pedestrian/publications/small_towns/fhwahep17024_lg.pdf,
p. 102 (5-7).

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

Re: [Tagging] Feature Proposal - RFC - Pedestrian lane

[Markus]

On Fri, 1 Nov 2019 at 22:54, Martin Koppenhoefer  wrote:
>
> currently your proposal is a description of the physical appearance of the 
> feature, but for highways what is needed are usually functional and legal 
> definitions. A cycleway is a way designated for bicycles, a motorway excludes 
> slow traffic, and so on.

And a pedestrian lane is a designated lane for pedestrians. Sorry, but
i don't understand how the way i defined it differs from how the
features you mentioned are defined.

> To make sense of a pedestrian lane it would either have to bear implications 
> on different modes of transport (e.g. in Switzerland motor vehicles can use 
> this lane, unlike sidewalks or other footways), or we would have to state 
> these for every instance of it (like we do for example with gates).
> currently the proposal doesn’t say anything about it.

Adding all the legal informations (use by all vehicles/bicycles
allowed/prohibited, use by pedestrians mandatory/encouraged) to every
single pedestrian lane in one country would be highly inefficient and
is also discouraged in our "Don't map your local legislation, if not
bound to objects in reality" rule. [1] I'd suggest collecting the
legal informations in a table on the wiki. Later, when we will
hopefully have a way to tag defaults, this informations could then be
transferred to the boundary=administrative relation.

Of course, if a single pedestrian lane has a locally marked or signed
exception, that single pedestrian lane should be tagged accordingly.

[1]: 
https://wiki.openstreetmap.org/wiki/Good_practice#Don.27t_map_your_local_legislation.2C_if_not_bound_to_objects_in_reality

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

[Tagging] Feature Proposal - RFC - Pedestrian lane

[Markus]

Hi everyone,

Following the recent discussion about pedestrian lanes (marked lanes
on a roadway, designated for pedestrians), i've now written a proposal
page for a new key pedestrian_lane=*:

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

Best regards

Markus

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

Re: [Tagging] How to tag pedestrian lanes?

[Markus]

On Mon, 21 Oct 2019 at 23:01, John Willis via Tagging <
tagging@openstreetmap.org> wrote:
>
> Is "foot:lanes" An established value?

There are only 32 uses according to Taginfo and the tag isn't mentioned in
the wiki. However, there are 4,450 uses of bicycle:lanes and that tag is
briefly mentioned in the wiki. [1][2]

I'm unsure if foot:lanes works as a alternative to pedestrian_lane or if
this is only an addition for more complex situations. In any case i don't
see a problem with it as opposed to sidewalk:right:kerb=no.

Besides, i just realised that sidewalk:right:kerb=no could also mean a
parallel footpath without kerb but with another physical barrier, like for
example here [3].

[1]:
https://wiki.openstreetmap.org/wiki/Bicycle#Cycle_lanes_and_bus.2Ftaxi_lanes
[2]:
https://wiki.openstreetmap.org/wiki/Lanes#Crossing_with_a_designated_lane_for_bicycles
[3]: https://www.mapillary.com/map/im/i-yuqBv2liMpsG4mWNyiew

Regards

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

Re: [Tagging] How to tag pedestrian lanes?

[Markus]

On Mon, 21 Oct 2019 at 18:14, Tobias Knerr  wrote:
>
> In general, I don't think the definition of OSM keys should
> automatically duplicate all nuances of the English dictionary,
> especially ones that many non-native speakers will be unaware of.

It isn't a nuance of one English dictionary. I've checked definitions
of a sidewalk in a few other languages (German, French, Spanish,
Italian, Serbo-Croatian, Swedish, Chinese and Japanese) – they mention
either that a sidewalk is raised [1][2][3][4][5], usually raised [6],
usually about 10 cm raised [7] or structurally divided from the
roadway [8].

Besides, the US Federal Highway Administration (FHWA) differentiates
between sidewalks, pedestrian lanes and shoulders [9]:

"Sidewalks are physically separated from the roadway by a curb or
unpaved buffer space." [9, p. 82]

"Pedestrian lanes provide interim or temporary pedestrian
accommodation on roadways lacking sidewalks. They are not intended to
be an alternative to sidewalks and often will fill short gaps between
other higher quality facilities." [9, p. 102].

[1]: https://www.duden.de/rechtschreibung/Buergersteig
[2]: https://www.larousse.fr/dictionnaires/francais/trottoir/79993
[3]: 
https://www.dizionario-italiano.it/dizionario-italiano.php?parola=marciapiede
[4]: https://zh.wikipedia.org/wiki/人行道
[5]: https://sr.wikipedia.org/wiki/Тротоар
[6]: https://dle.rae.es/?id=0NdwO9h
[7]: https://sv.wikipedia.org/wiki/Trottoar
[8]: https://ja.wikipedia.org/wiki/歩道
[9]: 
https://www.fhwa.dot.gov/environment/bicycle_pedestrian/publications/small_towns/fhwahep17024_lg.pdf

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

Re: [Tagging] How to tag pedestrian lanes?

[Markus]

On Sun, 20 Oct 2019 at 19:52, Jan Michel  wrote:
>
> I also prefer this kind of tagging. I don't see a reason to invent a
> fully new tag for this - it is an area meant just for pedestrians just
> like a sidewalk. [...]

I don't know how it is elsewhere, but in Switzerland vehicles are
allowed to drive on the pedestrian lane as long as pedestrians aren't
impeded. However, they aren't allowed to drive on sidewalks. (Aside
from the fact that it's not really possible.) Therefore, "an area
meant just for pedestrians just like a sidewalk" isn't true here.

> For me, a kerb is not a necessary feature of a sidewalk, e.g. here
> https://www.mapillary.com/map/im/Hx17IpF-pZWl6AakpYUc2g
> There is no kerb or other barrier at all, but still it's obviously a
> sidewalk.

I wouldn't call that a sidewalk and thus wouldn't tag it sidewalk=*.

> I don't see how a 2-3 cm high kerb provides any kind of safety for a
> pedestrian.

Not much, but luckily most kerbs (at least those i came across) are
much higher (usually 10 cm and more). They are only lowered at
pedestrian crossings or at driveways. Cars and buses sometimes
accidentally touch kerbs while driving (on narrow roads) and then get
thrown in the other direction. So i'd say that they definitely provide
some safety to pedestrians.

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

Re: [Tagging] How to tag pedestrian lanes?

[Markus]

On Sun, 20 Oct 2019 at 12:24, Georg Feddern  wrote:
>
> Why not in analogy to cycleway=track|lane|...
> sidewalk=track|lane|...

This would require a huge amount of retagging. (There are currently
over 1.5 millions uses of sidewalk=*.)

On Sun, 20 Oct 2019 at 19:11, Volker Schmidt  wrote:
>
> We have a widely used scheme for tagging cycle lanes/paths on the road way:
> cycleway=lane|track with variants.
> Extrapolating from that for the pedestrian "lane" seems obvious to me:
> sidewalk=lane (plus variants).
> For separate sidewalks there is
> sidewalk=yes (plus variants)
>
> Why invent something different?

"yes" isn't the only value of sidewalk=*, there's also "right",
"left", "both", "no" (plus "none") and "separate". [1] This isn't
compatible with sidewalk=lane.

Why not inventing something different for a different feature? :)

[1]: As well as some less useful values like "this" (156 uses!?),
"bad", "both;right", "right;none", "10" or "forest". :D

Markus

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

Re: [Tagging] How to tag pedestrian lanes?

[Markus]

On Sun, 20 Oct 2019 at 12:42, Tobias Zwick  wrote:
>
> How about:
>
> sidewalk=right
> sidewalk:right:kerb=no

I dislike using these tags for pedestrian lanes for the following
reasons (sorry if i repeat myself):

  * It doesn't make sense: if it doesn't have a kerb (or any other
physical barrier) it isn't a sidewalk.

  * Blind people are able to make out a sidewalk, but not a pedestrian lane.

  * It's misleading: Data users may not know the tag
sidewalk:right:kerb=no and thus may make wrong assumptions. For
example, a navigation application may guide a pedestrian along a route
with only pedestrian lanes instead of safer route with sidewalks.

  * pedestrian_lane= is simpler for mappers and data users.

  * The distinction between physical separation or road markings is
already made for cycleways.

As sidewalk:right:kerb=no sidewalk:left:kerb=no has only been used 4
and 9 times respectively, almost no retagging were required.

> The most important thing is to tag whether there is a sidewalk or not. 
> Regardless of whether it has a keen [kerb] or not.

I disagree: as already written, a sidewalk offers some safety for
pedestrians because of the kerb, while a pedestrian lane doesn't.

Regards

Markus

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

Re: [Tagging] How to tag pedestrian lanes?

[Markus]

On Sat, 19 Oct 2019 at 23:02, Martin Koppenhoefer
 wrote:
>
> +1, or e.g. sidewalk:right=lane
> there are a few instances tagged like this: 
> https://taginfo.openstreetmap.org/tags/sidewalk%3Aright=lane

18 out of 30 are additionally tagged sidewalk=right. I think it's
better to keep "sidewalk" out, otherwise it gets too confusing.

On Sun, 20 Oct 2019 at 08:41, John Willis via Tagging
 wrote:
>
> I tag the green line as a highway=path and add a note=* to the way.
>
> One example I have seen is much larger, and is a new “lane” created by 
> converting a 2-way road to 1-way and giving the margin to pedestrians.
> https://www.openstreetmap.org/way/667338935.

Mapping a lane as a separate way isn't ideal, because this separates
the lane from the rest of the roadway, leading to routing problems:

https://www.openstreetmap.org/directions?engine=fossgis_osrm_foot=36.40695%2C139.33347%3B36.40655%2C139.33423

Cheers

Markus

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

[Tagging] How to tag pedestrian lanes?

[Markus]

Hello everyone

I have a disagreement with another mapper (changeset comments in
German [1]) regarding the mapping of pedestrian lanes, i.e. lanes on a
roadway reserved for pedestrians (example [2]), and would like to hear
more opinions.

[1]: https://www.openstreetmap.org/changeset/75900746
[2]: https://commons.wikimedia.org/wiki/File:Pedestrian_lane.jpg

The other mapper thinks that pedestrian lanes should be tagged like
sidewalks (pavements), because sidewalk=* or footway=sidewalk just
means a footpath along a road, and that the absence of a kerb can be
tagged [sidewalk::]kerb=no.

However i think that a sidewalk requires a physical separation to the
roadway (usually a kerb). While a sidewalk provides some safety for
pedestrians, a pedestrian lanes does not. In order that data consumers
know that it may be less safe for pedestrians to use a road with a
pedestrian lane compared to a road with a sidewalk, i think it is
important to tag pedestrian lanes differently. (The tag i used was
pedestrian_lane=). Besides, the distinction between
physical separation or road markings is already made for cycleways: if
there is a physical separation we tag it cycleway=track, if there are
only road markings cycleway=lane. So it only seems logical to also
make the same distinction for sidewalks and pedestrian lanes.

Thank you in advance for your replies.

Best regards and have a nice Sunday,

Markus

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

Re: [Tagging] Feature Proposal - RFC - sunbathing

[Markus]

On Mon, 14 Oct 2019 at 17:51, Vɑdɪm  wrote:
>
> OK. Any more comments or we better go for a vote?

It's a detail, but i think that leisure=sunbathing_area (or
leisure=sunbathing_place) were a more descriptive tag than
leisure=sunbathing. Besides, most leisure=* values are nouns.

Regards
Markus

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

Re: [Tagging] Feature Proposal - Voting - Utility markers

[Markus]

On Sun, 13 Oct 2019 at 20:30, Paul Allen  wrote:
>
> Edit the source, to vote, and you'll see there's a bit of a mess:
>
> {{Template:Proposed feature voting}} {{vote|yes}} 
> --[[User:Eric Bie|Eric B.]] ([[User talk:Eric Bie|talk]]) 15:03, 12 October 
> 2019 (UTC)

It was a visual edit that added the  tags to the {{vote}}
template, thus disabling the template. I've fixed it by removing the
 tags.

Regards
Markus

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

Re: [Tagging] Divided highways, and not so divided highways, one way or two

[Markus]

On Fri, 11 Oct 2019, 22:00 Peter Elderson,  wrote:

> But where pedestrian crossing is not allowed at all, as in the case I
> described, two ways tagging does not give this routing problem.
>

No, but it's again not the only solution: the information that crossing the
road isn't permitted can also be added to the highway=* way (using
crossing=no, if i'm not wrong).
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Divided highways, and not so divided highways, one way or two

[Markus]

On Fri, 11 Oct 2019, 11:21 Snusmumriken, 
wrote:

>
> That tag is about lane changing, I don't see how it could be applied to
> my example
>

If i understand the wiki page correctly,

lanes=2
lanes:forward=1
lanes:backward=1
change:lanes:forward=not_left
change:lanes:backward=not_left

would mean that on both lanes it isn't allowed to turn left onto the lane
of the oncoming traffic.

And for the case i misunderstand that tag, we can invent a new tag.
Splitting the road into two parallel ways isn't the only possible solution.

My assumption is that pedestrian routing engine would stick to
> sidewalks and crossings and not to tell the pedestrian to cross a
> street where there is no crossing. The individual pedestrian can of
> course make up his own mind what legal/physical risks are acceptable to
> save a bit of time
>

As Kevin already pointed out, there are many places without pedestrian
crossings. Therefore pedestrian routing wouldn't work where a road with
painted lane separation is mapped with two ways.

I wish you all a nice weekend

Markus

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

Re: [Tagging] Divided highways, and not so divided highways, one way or two

[Markus]

On Thu, 10 Oct 2019 at 16:10, Snusmumriken
 wrote:
>
> For example if you try to create a routing advice for a car journey.
> Let's say that the journey starts at Main street number 10 and that
> Main street is a two way street where the two directions are legally
> separated. Let's say that number 10 is on the right-hand side of the
> road and we are in a country that drives on the right side. Let's
> further say that the shortest way to the destination would be to cross
> the legal separation and take left. But that would be illegal. But
> there is no way the routing engine could know that. Unless the two
> directions are separated.

That's not true. There's another way to tell routers that it is
illegal to change lanes: by adding that information to the highway=*
way. There's already a tag for this: change:langes [1] (> 90 000
uses).

While mapping separate ways where there is no physical barrier works
for car routing, it breaks pedestrian routing and there's likely no
way to fix this. Pedestrians usually are allowed to cross a painted
line that cars aren't allowed to cross (at least in Europe).
Therefore, if the road in your example is mapped with two separate
ways, a routing engine would make pedestrians do a detour (possibly a
long detour), even though they could just cross the street.

[1]: https://wiki.openstreetmap.org/wiki/Proposed_features/change

Regards
Markus

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

Re: [Tagging] Divided highways, and not so divided highways, one way or two

[Markus]

Hi Frederik, hi everyone,

On Thu, 10 Oct 2019 at 08:40, Frederik Ramm  wrote:
>
> The question is basically two-fold; one, what are the established
> standards and rules concerning this situation, and two, in how far is it
> acceptable to deviate from these standards if a local mapper thinks it
> is a good idea.

To your first question: i have the impression that the "physical
division -> separate ways; no physical division -> shared way"
principle usually is followed. One situation where it is not always
followed are motorway exits divided only by road markings.

To your second question: i think that local mapping deviations make
our map less usable. I would prefer if people who think that a rule
doesn't make sense don't simply ignore it, but discuss it on this
global mailing list.

Regards
Markus

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

Re: [Tagging] Pedestrian and highway crossings of tramways

[Markus]

On Wed, 9 Oct 2019 at 18:37, Markus  wrote:
>
> The problem here is that pedestrians are routed along the highway=*
> way and, as you wrote, tram tracks are usually (unfortunately) mapped
> as separate ways. Consequently, the railway=crossing node is
> disconnected from the highway=* way with the highway=crossing node
> (that is, on another way). Therefore a router doesn't know that trams
> also pass this pedestrian crossing (except if pavements and pedestrian
> crossings are mapped as separate ways, which, however, has other
> drawbacks).

I just realised that this problem can be solved by adding a
embedded_rails=tram [1] tag to the highway=* way. So it seems that
there's no need for a new crossing:tram=yes tag.

[1]: https://wiki.openstreetmap.org/wiki/Key:embedded_rails

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

Re: [Tagging] Pedestrian and highway crossings of tramways

[Markus]

On Wed, 9 Oct 2019 at 14:58, Vɑdɪm  wrote:
>
> You're assuming here some default features of a crossing which is not
> railway=crossing is about. It's a mere indication that a crossing exists at
> a specific location along the railway=* way. [...]

You're right. In that case, it probably makes most sense to use only
railway=crossing and drop the others (as Richard suggested).

> The thing is that if even if tramway track is embedded into a roadbed and it
> looks obvious at the Mapnik in the OSM they are usually mapped as separate
> ways. Crossing of each of them are separate nodes: one at the
> highway=something another one at the railway=something.

The problem here is that pedestrians are routed along the highway=*
way and, as you wrote, tram tracks are usually (unfortunately) mapped
as separate ways. Consequently, the railway=crossing node is
disconnected from the highway=* way with the highway=crossing node
(that is, on another way). Therefore a router doesn't know that trams
also pass this pedestrian crossing (except if pavements and pedestrian
crossings are mapped as separate ways, which, however, has other
drawbacks).

Regards
Markus

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

Re: [Tagging] Pedestrian and highway crossings of tramways

[Markus]

Hi Vɑdɪm

I don't know the situation in other countries, but in Switzerland,
pedestrian train crossing are signalised (example [1]), while
pedestrian tram crossings usually aren't (example [2]), even if the
tram runs on a reserved track (i.e. separated form the road). Thus i
think it may make sense to use a different tag for pedestrian tram
crossings.

Besides, most pedestrian tram crossing where the tram runs on the road
aren't exclusively pedestrians + trams crossings, but pedestrians +
road traffic + trams crossings, and are already tagged
highway=crossing. I think these tram crossings are best tagged as a
property on the highway=crossing node (and, if mapped, on the
footway=crossing way), e.g. crossing:tram=yes (using the already used
crossing: prefix).

[1]: https://www.mapillary.com/map/im/1AnE8ii19ml0maXTr1Hokw
[2]: https://www.mapillary.com/map/im/WIrjmoDPM8yTP96TfXpY9g

Regards
Markus

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

Re: [Tagging] Feature Proposal - RFC - (Phone)

[Markus]

On Tue, 8 Oct 2019, 11:29 marc marc,  wrote:

> Le 07.10.19 à 23:07, Martin Koppenhoefer a écrit :
> > let’s bury the contact: - prefix
>
> in this case, be logical and also propose to bury the prefix addr:
>

There's a difference between the two prefixes: several addr: tags together
form a complete address (a single addr: tag only gives part of an address),
while a single contact: tag already is a complete contact information. Thus
i think the addr: prefix makes more sense that the contact: prefix.

Regards
Markus

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

Re: [Tagging] Tagging meadow orchards

[Markus]

On Fri, 4 Oct 2019 at 20:43, Tom Pfeifer  wrote:
>
> On 04.10.2019 19:10, Markus wrote:
> > While orchard=meadow_orchard is the most used way of tagging a meadow 
> > orchard (2 748 uses), there
> > are also 668 uses of the other subtag meadow=meadow_orchard. That means 
> > that people don't agree that
> > the orchard is more important than the meadow.
>
> Apparently there is a semantic difference. When someone counts 3 apple trees 
> on a hectare, it is
> more a meadow. If there are 35 varieties of old sorts in the backyard, it is 
> more an orchard, and
> the farmer needs the small mower to cut the grass.
>
> Thus the subtagging allows to preserve the subtle differences, while a new 
> catch-all high-level tag
> doesn't. Subtle, from Latin subtilis ‘fine, delicate.’ ;-)

I agree that there such differentiation in tagging would make sense in
these extreme cases and i hope that mappers had this in mind and
didn't just randomly choose a subtag.

However, at many places it's impossible to say which land use is more
dominant (example: [1]). How to tag these? I were very surprised if
these places make only 1.4% (= share of landuse=meadow_orchard in all
three tags) of all meadow orchards.

[1]: 
https://commons.wikimedia.org/wiki/File:Gebenstorf_Blühende_Kirschbäume_1874.JPG

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

Re: [Tagging] Tagging meadow orchards

[Markus]

On Fri, 4 Oct 2019, 16:18 Tom Pfeifer,  wrote:

> I reviewed the thread and found the most convincing argument that the
> subtagging solution is already
> the preferred tagging in 2787 cases (according to overpass, most of them
> in Germany). It helps to
> prevent tag fragmentation and will not lead to crying how to render it. I
> also think it is the best
> option semantically.
>
> This contrasts 48 cases of landuse=meadow_orchard, only in DE and CH.


While orchard=meadow_orchard is the most used way of tagging a meadow
orchard (2 748 uses), there are also 668 uses of the other subtag
meadow=meadow_orchard. That means that people don't agree that the orchard
is more important than the meadow.

Compared to landuse=meadow_orchard (48 uses), the two subtags certainly
only have such a high usage because they render, while
landuse=meadow_orchard doesn't.

In my opinion, high usage doesn't guarantee that the tagging is sensible.

Markus

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

Re: [Tagging] Tagging meadow orchards

[Markus]

How shall we remain now? Can we agree on on a single way of tagging in
order that this discussion doesn't come up again in a year or two?

I still think that landuse=meadow_orchard (as well as
landuse=silvopasture for forest and pasture) is the best option. The
other used or proposed tags demand from mappers that they define which
land use is more important than the other. However, such a choice is
arbitrary.

Best regards
Markus

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