Re: [Tagging] Deprecation of associatedStreet-relations

[althio althio]

> It is not as formal as a proposal voting. I would like to know how the 
> community (those who vote) think about associatedStreet relations. I think 
> that in Germany the majority does not like them (anymore).
> I will announce a end date. This end date will be date of announcement of end 
> of voting + 14 days.
> German forum and talk-de have been notified by myself. You may notify your 
> local community if it will not read the next issue(s) of weeklyOSM.

Alright Michael, thanks for the details.
Now that the international tagging list is notified thanks to this
thread, I guess it does not really matter.
But the starting process looked biased towards the German community.

Mit freundlichen Grüssen

althio

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

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[althio althio]

> I even find the second example more difficult to visualize. It's just
worse
> than the first in every respect.

>From a mapper's point of view
My little +1 for key:subkey=*

In free text like this thread, several key:subkey=* may look more heavy and
complicated than key=values;separated;by;semicolon.
_However_ I think this is reversed in the context of editors (iD, JOSM...)
and elements lookup [1] where key and values are presented in tables.
+ key:subkey=* tabulated is easier to read
+ key:subkey=* tags are separated, it is slightly easier to select them and
update, to delete one only, to add by copy/paste.
+ key=values;separated;by;semicolon means less typing/keystrokes but this
is much mitigated by use of presets, auto-completion or copy/paste.


[1] http://www.openstreetmap.org/way/106464005
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[althio althio]

Hi Jo/Polyglot and list,

On 22 January 2015 at 12:01, Jo  wrote:
> Which too schemes? I think you'd need to be more specific.

1. key=values;separated;by;semicolon
2. several key:subkey=*

> route_ref:De_Lijn=1;2;3;4;5;6;7;8;9;284;285;310;315;316;317;333;334;335;337;351;352;358;370;371;372;373;374;380;395;520;524;525;537;586;597

I don't know if this is a real or fictitious example, but try not to
hit the limit of 255 characters for values. ;)

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

Re: [Tagging] Wiki Edit War on using/avoiding semicolon lists

[althio althio]

First point:
It is good that several people invent, propose and use various schemes.

Second point:
At some point, unification of schemes with similar intent would be great.
As usage grows, having the same kind of data treated differently is a pain
for everyone, mappers, developers, maintainers and data consumers alike.
I don't think one of the schemes is clearly superior to the other, only I
wish that it could be open to discussion, open to improvements and settled.
Once it is agreed upon (or enforced by any committee, anyone?), people can
start to work on unified tagging, clear documentation, adapted presets and
simpler algorithms with less cases or exceptions to handle.

Or it is decided that we continue with the two schemes, that both are
valid, accepted, documented for tagging and consumption.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Deprecation of associatedStreet-relations

[althio althio]

> Please vote here:
> https://wiki.openstreetmap.org/wiki/Talk:Relation:associatedStreet

Is this a formal voting?
Is there a date for start and end vote?

It looks strange, hidden on a Talk:page without the usual template or
RFC or call for votes on the international mailing lists.

althio

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

Re: [Tagging] Basic philosophy of OSM tagging

[althio althio]

Warin <61sundow...@gmail.com> wrote:
> What is the basic philosophy of OSM tagging at the top level?
> ...
> Is there an FAQ on this? Or has this never been documented

I do not have a FAQ on philosophy, only this and that...

A few entries about 'how to create/propose/use' tags:
http://wiki.openstreetmap.org/wiki/Proposal_process#Significance
http://wiki.openstreetmap.org/wiki/Any_tags_you_like#Syntactic_conventions_for_new_tags
http://wiki.openstreetmap.org/wiki/User:Joto/How_to_invent_tags
http://wiki.openstreetmap.org/wiki/Duck_tagging

New tagging scheme should also be designed so that Tagging good
practices make sense.
http://wiki.openstreetmap.org/wiki/Good_practice
http://wiki.openstreetmap.org/wiki/Tags
http://wiki.openstreetmap.org/wiki/Namespace

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

Re: [Tagging] Ethnic shops

[althio althio]

> like:
> amenity=hairdresser
> name=Scalp
> culture=punk
> ?

Exactly, I provided other examples in my previous message such as
culture=country, culture=grunge, culture=shinto.

Using several keys ethnicity=* + nationality=* + subculture=* all together
would be unambiguous but I think culture=* does a good job of merging all
keys.
I am not sure ethnicity=* alone can cover all the cases such as your
hairdresser ethnicity=punk.
I think you know it and choose to discard punk / grunge / country / shinto
/ goth / kawaii tagging? ;)
But even with nationalities it sounds strange, eg. ethnicity=canadian /
irish / italian / ...
Furthermore I do not have examples at the moment but *maybe* ethnicity is
more connoted and may lead to awkward tagging for some groups.

> but culture=* is already used. 84 uses

It seems like the remnants of a old proposal [1].
So it looks to me as a bunch of tagging errors where culture=X should be
replaced by amenity=X or tourism=X or any appropriate key=X.

> Based on the current uses and the fact that culture may have several
> meanings, ethnicity=* seams to me the best choice

As far as I understand culture=* is available as a tagging option, the
current use is irrelevant.
cuisine=* allows to agglomerate two concepts: food ethnicity + food type.
This is outlined [2] and detailed [3] in the wiki.
This is why ethnicity=* is not a valid key to - in the unlikely event that
we wanted to - replace all the current uses of cuisine=*.
And I am trying to find the equivalent of cuisine=* for other types of
amenities/shops.

I appreciate the fact that 'culture' may have several meanings though.
I would still consider key culture=* as my preferred option. Within the
context of shops and with the associated values related to nationalities
and the like, the meaning of culture=* is rather unmistakable.

> with values as similar as possible to cuisine=*.

Whatever the choice I agree that values should be shared with cuisine=* as
much as possible.

[1] http://wiki.openstreetmap.org/wiki/Proposed_features/culture
[2] http://wiki.openstreetmap.org/wiki/Tag:amenity%3Drestaurant
[3] http://wiki.openstreetmap.org/wiki/Key:cuisine
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Ethnic shops

[althio althio]

John Willis  wrote:
> I think there should be ethnic=*, Nationality=* , or culture=*tag that
can be used [...]

I find culture=* the best so far.

I find it specialised enough (compared to _type=*, origin=*, category=*,
group=* ...)
I find it accurate enough.
I find it generic enough (compared to more restrictive nationality=* and
even ethnicity=*) so that it enables tagging for ethnic group but also
other types of social group and subcultures.

cuisine=* is well established for restaurant and can be extended for
everything related to food in convenience, deli...

cuisine=ramen / cuisine:asian:japanese=ramen
cuisine=sichuan / cuisine:asian:chinese=sichuan

For clothes, hairdresser, craft, bar... I think culture=* is well suited.

culture=indian / culture:asian=indian
culture=italian / culture:western:european=italian
culture=country / culture:western:american=country
culture=grunge / culture:western=grunge
culture=shinto / culture:asian=shinto
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] waterway=wadi problem

[althio althio]

On 19 January 2015 at 13:42, Eric SIBERT  wrote:
> One may also not that road are also subject to intermittent (un)usability.
> Some unpaved one are closed during rainy season. Some part of road have
> concrete parts that are flood_prone during cyclone.
>
> How can we (or not) extend it to roads?

something with conditional?

access:conditional  = no @ flood
access:conditional  = no @ (Jan-Apr)

http://wiki.openstreetmap.org/wiki/Conditional_restrictions

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

Re: [Tagging] waterway=wadi problem

[althio althio]

My main suggestion would be to re-use the same scheme as
Key:opening_hours to define the time when the waterway is likely to
flow.
I would also discard rare/frequent as too subjective. Instead:
approximate duration are not perfect but should improve mutual
understanding.

For instance as in:
waterway = *
+ intermittent = yes | no | periodical | random (default:no)
++ intermittent:periodical = [opening_hours scheme]
(likely to flow at this date) eg. Mar-Jun | OR | Nov 20-Feb 20 | OR | ...
++ intermittent:random:interval = [approximate duration]
(typical/assumed duration between two flowing events) eg. 2 weeks | OR
| 3 years | OR | ...
++ intermittent:random:duration = [approximate duration]
(typical/assumed duration of one flowing event) eg. 12 hours | OR | 3
days | OR | ...

I am sure some people would like to go in more details, so why not:

+ intermittent:origin = rain | snowmelt | geothermal | ...
+ intermittent:effect = stream | torrential | flood | ...


Mateusz Konieczny  wrote:
> Please, no "intermittent=ephemeral". Key intermittent was defined to have 
> only a single valid value, turning it into free-form tag is a bad idea.
>
> Maybe intermittent=yes, intermittent:type=ephemeral?

Maybe other tags began with a key and a single valid value.
Afterwards they evolved to multiple valid values for added details and nuances.
Multiple valid values [option1|option2|...|optionN] is not the same as
free-form [name/note/source/description=*], is it?

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

Re: [Tagging] Basic philosophy of OSM tagging

[althio althio]

"Kotya Karapetyan"
> 2) Suggested tags functionality should be implemented.

I have seen that in the Android editor Vespucci.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature proposal - Voting - Water tap

[althio althio]

It seems that Pieren and I agree on most points.

@François
Maybe drinkable water is a very special case... but here service/use
is much more important than object/feature. The ability to find this
water on a map or from any data consumer is useful. It can even be
essential to many people from hikers and bikers to inhabitants and
humanitarian NGO where water is in short supply.

Also consider the possibility of a open data import of geolocalised
water points. We should import them for added value even if the
supporting physical man_made=* is unknown.

You must tag what you know and what is useful.
man_made=water_[object] is useful.
amenity=drinking_water/non_drinking_water is useful.

Let's tag one or the other and both when we can. For me there is no
conflict or hierarchy between these two keys.

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

Re: [Tagging] Feature proposal - Voting - Water tap

[althio althio]

I didn't follow every bits of the discussion, so sorry for
interrupting. Sorry also if my proposals are out of scope or already
reviewed. Maybe a fresh view can help.

@Marc amenity=drinking_water // amenity=non_drinking_water
It feels like a good start and compromise.
Either can be associated with a more physical feature that represents
an outlet of a water network.

A few tagging examples...

any point with drinking water:
amenity=drinking_water
+ [opt] man_made=*

a well:
man_made=water_well
+ [opt] amenity=drinking_water/non_drinking_water

a tap:
man_made=water_tap
+ [opt] amenity=drinking_water/non_drinking_water

a water point:
man_made=water_tap or man_made=water_point or man_made=water_supply or ...
+ [opt] amenity=drinking_water/non_drinking_water
* currently exists amenity=water_point ... I find it a bad tag, this
one I would consider to maybe deprecate and link as a equivalent
amenity=water_point <=> amenity=drinking_water + man_made=[to_be_chosen]

and it should not implies drinking_water=yes.

a fountain for cultural / decorational / recreational purposes [often
not suitable for drinking]:
amenity=fountain
(man_made=fountain is maybe more logical... and here 2x amenity can clash)
* if it is drinking water, a workaround would be two features, ideally
a node amenity=drinking_water within an area (however small)
amenity=fountain. Some fountains are also detailed with an area of
natural=water.

toilets with drinking water
amenity=toilets and amenity=drinking_water as two features (2 nodes or
area+node)

drinking fountain
amenity=drinking_water
+ [opt] man_made=* (man_made=fountain if there is a need?)



Either way, the slightly conflicting tag are
amenity=[non_]drinking_water and drinking_water=yes/no.
They should be linked and treated together in algorithms.
I think amenity=drinking_water is a valuable tag because it is useful
to people. It makes sense to use it alone.
drinking_water=yes alone on a node makes less sense IMO.

water_point and water_tap should not assume

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

Re: [Tagging] Feature proposal - Voting - Water tap

[althio althio]

On Jan 14, 2015 5:53 PM, "Marc Gemis"  wrote:
>
>
> On Wed, Jan 14, 2015 at 12:45 AM, Warin <61sundow...@gmail.com> wrote:
>>
>> I appreciate you concerns. They should have been raised in the
commenting period of the proposal rather than the voting period that is
coming to a close.
>
>
> -1. Why would it be too late ? It is not because a small group of people
(1?) decides that is time to vote, that others cannot object.

Especially when they have raised early concerns
https://wiki.openstreetmap.org/wiki/Talk:Proposed_features/water_tap#amenity.3Ddrinking_water
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] religion=multi* ?

[althio althio]

> that is not a problem, as "multi" doesn't exclude "all", but "all" requires 
> "all"

Indeed, it is not a problem, it is a solution ! :)
Use two values for slightly different concepts.
multi == multifaith == multiconfessional == various == value1;value2;...
all == non-denominational == nondenominational == all_religions ==
every_religion

Anyway I hope that Andy aka SomeoneElse  can
give us his feedback.

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

Re: [Tagging] religion=multi* ?

[althio althio]

Martin Koppenhoefer  wrote:
> religion=multi looks OK to me, the similarity to sport makes it easier
> to remember than religion=all (and it is very likely more accurate, as "all"
> is too inclusive I guess).

Some airports REALLY wants to be that inclusive.
> "a prayer room for all faiths and denominations" at Stansted.
> "We welcome people of all faiths to join us in our chapel and prayer rooms" 
> at Gatwick.

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

Re: [Tagging] religion=multi* ?

[althio althio]

Jgpacker asks on the PoW talk page:
>> Are [Airports prayer rooms] really tagged with amenity=place_of_worship?
>> I would say it's quite a different place from a normal religious place,
>> and should get another tag.

I think they are definitively for worshiping and prayers.
amenity=place_of_worship is pretty clear for me.

Being different from the regular religious place, not consecrated, no
significant architecture, they are not
building=church/mosque/temple/*.
Indoor mapping might tell you room=chapel or room=prayer_room instead.
Besides amenity=place_of_worship.

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

Re: [Tagging] religion=multi* ?

[althio althio]

John Willis  wrote:
> "multi" fits the sports tagging scheme well, and I think it is best for the 
> religion tag too.
>
> "All"is not good, as most sports places don have a clay sumo ring or a sandy 
> pit for beach volleyball set up, so "all" would be wrong.

@John
I guess this is a reply to my idea of separate tagging:

A.
> non-denominational places (Airport chapels ...)
religion=all
(OR religion=nondenominational)

B.
> places shared between faiths (but specific faiths, not all faiths)
religion=multi + religion:religion1=yes + religion:religion2=yes
(OR religion=religion1;religion2 but you are into semi-colon value separator)

My idea was to answer to SomeoneElse in
https://lists.openstreetmap.org/pipermail/tagging/2015-January/020865.html

I don't propose to discard "multi" for "all". Instead I consider if
there is value to use both, religion=all in some cases and
religion=multi in other cases.


> "All"is not good, [...]
> Similarly, animal sacrifice and practicing voodoo at the airport's prayer 
> room might get you arrested.

Oh my. It does not mean voodoo practionners are not allowed into the
prayer room as long as they respect country and airport laws and
regulations. This is not a question of restricted access or restricted
faith/religion but of adaquate behaviour.
I have never seen a sign 'no voodoo' on the prayer room of any
airport. If this prayer room with this sign does exist, then it could
be defined as multi. Or all + religion:voodoo=no.
[[[ [heavy sarcasm] Did you know that every religion has at least one
practice not suitable for a prayer room, name it: flogging
(self-inflicted flagellation), stoning (lapidation), circumcision, ...
Should we ban every religion from prayer rooms? ]]]

I think the spirit of these prayer rooms is to welcome anyone, from all faiths.
From the website of airports:
"multi-faith prayer rooms in each terminal" at Heathrow. (against voodoo?) ;-)
"a prayer room for all faiths and denominations" at Stansted.
"We welcome people of all faiths to join us in our chapel and prayer
rooms" at Gatwick.

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

Re: [Tagging] kind of a shop=ticket

[althio althio]

This is very related to

amenity=vending_machine (taginfo = 54 000)
with its associated key:
vending=* (taginfo = 50 000)
http://taginfo.openstreetmap.org/keys/vending#values

Maybe we could come up with something that unite the used keys.


On 12 January 2015 at 09:55, k4r573n  wrote:
> Hi,
>
> I wonder how to map the kind of a ticket shop.
> It would be practical to see ticket shops for concerts on a culture map
> and such shops for aerialway on a skiing map.
>
> for now I've 2 ideas
>
> tickets:ski=yes/no
> tickets:concert=yes/no
> tickets:public_transport=yes/no
> ...
>
> or
>
> ticket=ski
> ticket=concert
> ticket=public_transport
> ticket=...
>
> tagwatch lists
> 49 entries of ticket=*
> 48 entries of tickets=*
> 15 entries of tickets:public_transport=*
> 16 entries of tickets:bus=*
> 10 entries of tickets:subway=*
>
> this wiki page [1] recommends to use tickets:*=*
>
> What should I document in the wiki?
> ___
> Karsten
>
> [1] http://wiki.openstreetmap.org/wiki/RU:Tag:shop=ticket
>
>
>
> ___
> 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: Reverse Vending Machine

[althio althio]

Building on Janko's comment, is this acceptable or lacking in some way?

amenity=shop/vending_machine/...
service:refund=yes
refund:plastic_bottles=*
refund:*=*
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] religion=multi* ?

[althio althio]

How about...

> non-denominational places (Airport chapels ...)

religion=all

> places shared between faiths

religion=multi
Optionally more details with a scheme similar to:
religion:christian
=yes/*
religion:muslim 
=yes/*
religion:buddhist 
=yes/*
religion:hindu =yes/*
religion:jewish 
=yes/*
religion:shinto 
=yes/*
religion:taoist 
=yes/*
religion:sikh =yes/*
religion:*=*
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] barrier=net ?

[althio althio]

On 07/01/2015 11:42 am, "johnw"  wrote:
>> There are 544 uses of barrier=net, and I want to add it into the wiki.

On 7 January 2015 at 05:50, Andrew Harvey  wrote:
> I've also used it to tag nets in the water used to provide swimming areas 
> safe from sharks.

Andrew your case is more specialized so I feel barrier=net is lacking.
How about
barrier=fence
fence_type=shark_net

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

Re: [Tagging] barrier=net ?

[althio althio]

TLDR: consider fence_type=net

I think that these huge nets on poles are barriers, then fences and
then nets. So it fits well within barrier=fence.

from wiki osm [1]: A fence is a freestanding structure designed to
restrict or prevent movement across a boundary. It is generally
distinguished from a wall by the lightness of its construction.
[distinguished by the lightness i.e. lighter relative to a wall, not
light in absolute terms]
See also wikipedia with several examples of what a fence can be,
inclunding high wire fence. [2]

I see no reason to use barrier=net as it implies a net is not a fence.
So I think barrier=fence and then adding tags for type of fence and
height is more clear and could be used by renderers and data users.

barrier=net is indeed used (~500) and fence=net is logical but
consider fence_type=net.
I think you should just update the documentation and recommended usage
into fence_type=net (133).
Indeed fence_type is well documented [3] and in good use if you look
at other common types of fence.

taginfo
fence_type=net 133
fence_type=wire 5 000 >> fence=wire 57
fence_type=chain_link 14 000 >> fence=chain_link 12

[1] http://wiki.openstreetmap.org/wiki/Tag:barrier%3Dfence
[2] http://en.wikipedia.org/wiki/Fence
[3] http://wiki.openstreetmap.org/wiki/Key:fence_type

http://taginfo.openstreetmap.org/tags/fence_type=net 133
http://taginfo.openstreetmap.org/tags/fence_type=wire 5 000
http://taginfo.openstreetmap.org/tags/fence_type=chain_link 14 000
http://taginfo.openstreetmap.org/tags/fence=wire 57
http://taginfo.openstreetmap.org/tags/fence=chain_link 12
http://taginfo.openstreetmap.org/tags/barrier=net 544

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