Re: [Tagging] Feature proposal - Voting - Gambling (reminder)

2014-01-09 Thread fly
On 08.01.2014 22:00, Matthijs Melissen wrote:
> Dear all,
> 
> This is a reminder that voting on the gambling proposal is currently
> open. Voting can be done here:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Gambling

Sorry, for the late answer but I hade to take some holidays.

Thanks for the nice summary. One small point I like to mention: Why do
we not deprecate amenity=gambling and only use gambling, especially as
it might collide with another value of amenity.

gambling=* could be used with all tags to define the different kind of
"games" available at the place.

cu fly


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


Re: [Tagging] Feature proposal - Voting - Gambling (reminder)

2014-01-09 Thread Martin Vonwald
Hi!

2014/1/9 fly 

>  and only use gambling, especially as
> it might collide with another value of amenity.
>

In my opinion we all really should start accepting that a key might have
more than one possible value. I don't see any problem in
amenity=pub;gambling .

-
Ok, you don't like the semi-colon, so lets move gambling to a different key
- now we have amenity=pub + gambling=yes -> problem solved. Fine. Oh, wait
- there's a pub that's also a nightclub! amenity=pub;nightclub? No way, so
lets move nightclub to a different key - problem solved! Again. One moment:
this pub sells ice_cream! No problem, just move ice_cream to a different
key
-

See what I mean?

The sooner we start to accept multiple values the less problems we will
have in the future. <--- my opinion!

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


Re: [Tagging] Feature Proposal - RFC - Bag shop, pet shop

2014-01-09 Thread fly
We are talking about two tags which are two different cases:

1. shop=pet seems to be established without voting and there is no need
of any proposal but documentation on the wiki is needed.

2. shop=bag is not used much and the numbers are similar e.g. a proposal
is useful to document it and decide about singular <-> plural form.

The proposals will not lead to a permission for automatic changes (there
are other steps to take) but we should talk to the editors' developers
to add the kind of shops and adjust the spelling if needed.

cu fly



On 05.01.2014 20:27, Janko Mihelić wrote:
> I think these two are pretty straightforward, no voting needed really.
> 
> Janko
> 
> 
> 2014/1/5 Peter Wendorff  >
> 
> Hi Matthijs,
> I agree on your opinion, but I don't imply from that any automatic
> re-tagging.
> 
> shop=bag is already documented in German [1] and Russion, the English
> page is empty yet unfortunately. But I don't think we need a proposal
> for that.
> 
> shop=pet is documented as well, in English [2], Spanish, Japanese (?
> cannot read the page so don't know what exactly is written there),
> Portuguese and Russian.
> 
> Forget the proposal and add the corresponding documentation if you want
> - just my few thoughts.
> 
> [1] http://wiki.openstreetmap.org/wiki/DE:Tag:shop%3Dbag
> [2] http://wiki.openstreetmap.org/wiki/Tag:shop%3Dpet
> 
> regards
> Peter
> 
> Am 01.01.2014 22:13, schrieb Matthijs Melissen:
> > Dear all,
> >
> > Currently the tags shop=bag (303) and shop=pet (4501) are used in
> > parallel to the less used tags shop=bags (177) and shop=pets (137). I
> > propose to agree on the defacto standard (the singular).
> >
> > In order to accomplish that, I have created two proposal pages:
> > http://wiki.openstreetmap.org/wiki/Proposed_features/Bag_shop
> > http://wiki.openstreetmap.org/wiki/Proposed_features/Pet_shop
> >
> > Please let me know what you think.
> >
> > With kind regards,
> > Matthijs
> >


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


Re: [Tagging] Feature proposal - Voting - Gambling (reminder)

2014-01-09 Thread Peter Wendorff
Hi Martin,
in general you're right, but in this case it's a bad choice.

we as a community, as the mappers, can accept multiple values - but even
we as the mappers don't have the tools to deal with multiple values,
that is: AFAIK editors create multiple-value-tags, but don't use them,
e.g. for their internal rendering of the map.

For other software it's worse: As far as I know you have to actively
deal with multiple-value-tags in Mapnik for any tag used in the
stylesheet, and on top of that it's slower than single-values.

For rendering apart from the technical issues (which are of course
solvable) you have to choose what to show on a value-level instead of on
a key-level:
Currently a shop=* is "more important" to the stylesheet than an address
(addr:*), so a shop icon is shown instead; but any shops that have a
dedicated item are on the same importance level.
With multiple values you have to decide, which is more important:
amenity=pub or amenity=gambling? shop=car or shop=car_repair,
amenity=fuel or amenity=car_wash?

I agree that fly's argument shouldn't be taken too seriously (the part
"...especially as it might collide with another value of amenity), but
as the gambling key is proposed, too it's better to use that one only
instead of spreading values across amenity, shop, leisure, gambling and
probably even more.

regards
Peter

Am 09.01.2014 15:07, schrieb Martin Vonwald:
> Hi!
> 
> 2014/1/9 fly 
> 
>>  and only use gambling, especially as
>> it might collide with another value of amenity.
>>
> 
> In my opinion we all really should start accepting that a key might have
> more than one possible value. I don't see any problem in
> amenity=pub;gambling .
> 
> -
> Ok, you don't like the semi-colon, so lets move gambling to a different key
> - now we have amenity=pub + gambling=yes -> problem solved. Fine. Oh, wait
> - there's a pub that's also a nightclub! amenity=pub;nightclub? No way, so
> lets move nightclub to a different key - problem solved! Again. One moment:
> this pub sells ice_cream! No problem, just move ice_cream to a different
> key
> -
> 
> See what I mean?
> 
> The sooner we start to accept multiple values the less problems we will
> have in the future. <--- my opinion!
> 
> Best regards,
> Martin
> 
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
> 


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


Re: [Tagging] Feature Proposal - RFC - Bag shop, pet shop

2014-01-09 Thread fly
On 09.01.2014 15:13, fly wrote:
> We are talking about two tags which are two different cases:

> 2. shop=bag is not used much and the numbers are similar e.g. a proposal
> is useful to document it and decide about singular <-> plural form.

Totally forgot to mention, that this proposal is a stub. Please, add a
picture and one or two more lines as description. A tag-info-box would
be nice, too.

Thanks
fly

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


Re: [Tagging] Feature proposal - Voting - Gambling (reminder)

2014-01-09 Thread fly
On 09.01.2014 15:07, Martin Vonwald wrote:
> Hi!
> 
> 2014/1/9 fly  >
> 
>  and only use gambling, especially as
> it might collide with another value of amenity.
> 
> 
> In my opinion we all really should start accepting that a key might have
> more than one possible value. I don't see any problem in
> amenity=pub;gambling .


I would decide between the major key and subkeys.
amenity=restaurant/bar/pub/nightclub might be a special case due to
history but can be solved in different was.

> -
> Ok, you don't like the semi-colon, so lets move gambling to a different
> key - now we have amenity=pub + gambling=yes -> problem solved. Fine.
> Oh, wait - there's a pub that's also a nightclub! amenity=pub;nightclub?
> No way, so lets move nightclub to a different key - problem solved!
> Again. One moment: this pub sells ice_cream! No problem, just move
> ice_cream to a different key
> -
> 
> See what I mean?

Yes

> The sooner we start to accept multiple values the less problems we will
> have in the future. <--- my opinion!

+1

I do not like all the tahes with yes/no as values either. Have a look at
the recycling wiki page for an example.

fly

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


Re: [Tagging] Feature proposal - Voting - Gambling (reminder)

2014-01-09 Thread Martin Vonwald
Hi!

I fully understand the technical and other difficulties. And I also don't
have any problem with using the gambling key _in this case_ (I simply don't
tag any of those). I just want to make anyone aware that it is _not_ a
solution to move from one key to another, because once we started we can't
stop this (and we already started...). We will always have some collisions.
So either (i) use for everything a separate key, or (ii) allow and support
multiple values for keys. I don't think that item (i) will work on the long
run. Lets face it: at some point we need to allow multiple values and the
longer we need to accept it the more problematic it will be for everyone
then.

We should start accepting and supporting multiple values. Preferable:
today. Today it's a just a big problem, tomorrow maybe one that we can't
solve at all.

Just my opinion.

Best regards,
Martin




2014/1/9 Peter Wendorff 

> Hi Martin,
> in general you're right, but in this case it's a bad choice.
>
> we as a community, as the mappers, can accept multiple values - but even
> we as the mappers don't have the tools to deal with multiple values,
> that is: AFAIK editors create multiple-value-tags, but don't use them,
> e.g. for their internal rendering of the map.
>
> For other software it's worse: As far as I know you have to actively
> deal with multiple-value-tags in Mapnik for any tag used in the
> stylesheet, and on top of that it's slower than single-values.
>
> For rendering apart from the technical issues (which are of course
> solvable) you have to choose what to show on a value-level instead of on
> a key-level:
> Currently a shop=* is "more important" to the stylesheet than an address
> (addr:*), so a shop icon is shown instead; but any shops that have a
> dedicated item are on the same importance level.
> With multiple values you have to decide, which is more important:
> amenity=pub or amenity=gambling? shop=car or shop=car_repair,
> amenity=fuel or amenity=car_wash?
>
> I agree that fly's argument shouldn't be taken too seriously (the part
> "...especially as it might collide with another value of amenity), but
> as the gambling key is proposed, too it's better to use that one only
> instead of spreading values across amenity, shop, leisure, gambling and
> probably even more.
>
> regards
> Peter
>
> Am 09.01.2014 15:07, schrieb Martin Vonwald:
> > Hi!
> >
> > 2014/1/9 fly 
> >
> >>  and only use gambling, especially as
> >> it might collide with another value of amenity.
> >>
> >
> > In my opinion we all really should start accepting that a key might have
> > more than one possible value. I don't see any problem in
> > amenity=pub;gambling .
> >
> > -
> > Ok, you don't like the semi-colon, so lets move gambling to a different
> key
> > - now we have amenity=pub + gambling=yes -> problem solved. Fine. Oh,
> wait
> > - there's a pub that's also a nightclub! amenity=pub;nightclub? No way,
> so
> > lets move nightclub to a different key - problem solved! Again. One
> moment:
> > this pub sells ice_cream! No problem, just move ice_cream to a different
> > key
> > -
> >
> > See what I mean?
> >
> > The sooner we start to accept multiple values the less problems we will
> > have in the future. <--- my opinion!
> >
> > Best regards,
> > Martin
> >
> >
> >
> > ___
> > Tagging mailing list
> > Tagging@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/tagging
> >
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] Winter sports share the same way

2014-01-09 Thread yvecai
Scott, I relay your question to the tagging mailing-list: As I am a 
mapper and a renderer, I may not be partial :)


I was face recently with a piste shared by alpine skiers and sleds and I 
choose the easy way: I just tagged the way for skiers.

This is not satisfactory, I know.

With relations, one can make one relation by activity, however it won't 
be appropriate to tag piste:difficulty for nordic.


Yves
 Original Message 

I really like your OSM renderer for ski areas.  I'm using it to map out some 
backcountry skiing
areas in Southwest British Columbia, particularly near Whistler BC.  I have 
some questions,
and some suggestions for improvements:
 
1. In my area it is very common for backcountry trails to be used for both backcountry skiing

and snowshowing.  Can a way (or relationship) be tagged for both snowshoeing 
and ski touring?
If so, how?  I was thinking that I would use 
piste:type=hiking;piste:grooming=backcountry for
snowshoe only, piste:type=nordic;piste_grooming=backcountry for ski only and 
piste\:type=skitour
for trails that permit both.  Or should I just tag the piste for the primary 
use and then add ski=yes
or snowshoe=yes?

 -Scott



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


Re: [Tagging] Winter sports share the same way

2014-01-09 Thread Tod Fitch
In the areas I cross country ski at in the California mountains many trails are 
used by both nordic skiers and snowshoers. Since I am ski centric I've tended 
to tag them as piste:type=nordic. Could one simply tag them as 
piste:type=nordic;snowshoe? A bit ugly and the difficulty is an issue as the 
skill level required for snowshoeing a trail can be quite different from skiing 
it.

For what it is worth, I have been using piste:type=skitour only on those 
general directions that are not groomed or obvious trails (in my area that 
would be summer roads and old logging drags). Decision being made based on the 
need for map and compass or route finding skills.

I could go for relations which would solve the multiple use and multiple 
difficulty issues. I would have to revise my paper map rendering software to 
support that though.

-Tod



On Jan 9, 2014, at 10:16 AM, yvecai wrote:

> Scott, I relay your question to the tagging mailing-list: As I am a mapper 
> and a renderer, I may not be partial :)
> 
> I was face recently with a piste shared by alpine skiers and sleds and I 
> choose the easy way: I just tagged the way for skiers.
> This is not satisfactory, I know.
> 
> With relations, one can make one relation by activity, however it won't be 
> appropriate to tag piste:difficulty for nordic.
> 
> Yves
>  Original Message 
> 
> I really like your OSM renderer for ski areas.  I'm using it to map out some 
> backcountry skiing
> areas in Southwest British Columbia, particularly near Whistler BC.  I have 
> some questions,
> and some suggestions for improvements:
> 1. In my area it is very common for backcountry trails to be used for both 
> backcountry skiing
> and snowshowing.  Can a way (or relationship) be tagged for both snowshoeing 
> and ski touring?
> If so, how?  I was thinking that I would use 
> piste:type=hiking;piste:grooming=backcountry for
> snowshoe only, piste:type=nordic;piste_grooming=backcountry for ski only and 
> piste\:type=skitour
> for trails that permit both.  Or should I just tag the piste for the primary 
> use and then add ski=yes
> or snowshoe=yes?
> 
> -Scott
> 
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



smime.p7s
Description: S/MIME cryptographic signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Winter sports share the same way

2014-01-09 Thread yvecai

On 01/09/2014 07:27 PM, Tod Fitch wrote:


I could go for relations which would solve the multiple use and multiple 
difficulty issues.

Unless you map difficulties like it should: by section, or in OSM, by ways.

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


Re: [Tagging] Winter sports share the same way

2014-01-09 Thread Martin Koppenhoefer
2014/1/9 Tod Fitch 

> In the areas I cross country ski at in the California mountains many
> trails are used by both nordic skiers and snowshoers. Since I am ski
> centric I've tended to tag them as piste:type=nordic. Could one simply tag
> them as piste:type=nordic;snowshoe? A bit ugly and the difficulty is an
> issue as the skill level required for snowshoeing a trail can be quite
> different from skiing it.



rather than multiple semicolon separated values I'd suggest multiple
relations (one for each sport).

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


Re: [Tagging] Winter sports share the same way

2014-01-09 Thread Tod Fitch
A single trail, even a single section of a trail, represented by a single way 
could have one difficulty rating for a person on snowshoes and a different 
difficulty rating for a person on skis.

-Tod



On Jan 9, 2014, at 11:08 AM, yvecai wrote:

> On 01/09/2014 07:27 PM, Tod Fitch wrote:
>> 
>> I could go for relations which would solve the multiple use and multiple 
>> difficulty issues.
> Unless you map difficulties like it should: by section, or in OSM, by ways.
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



smime.p7s
Description: S/MIME cryptographic signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Winter sports share the same way

2014-01-09 Thread fly
Do not really understand your problem.

As already mentioned you can use a semicolon for the piste_type values
and tag the difficulty with addidtional keys like difficulty:sled=*

cu fly

On 09.01.2014 21:44, Tod Fitch wrote:
> A single trail, even a single section of a trail, represented by a single way 
> could have one difficulty rating for a person on snowshoes and a different 
> difficulty rating for a person on skis.
> 
> -Tod
> 
> 
> 
> On Jan 9, 2014, at 11:08 AM, yvecai wrote:
> 
>> On 01/09/2014 07:27 PM, Tod Fitch wrote:
>>>
>>> I could go for relations which would solve the multiple use and multiple 
>>> difficulty issues.
>> Unless you map difficulties like it should: by section, or in OSM, by ways.


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


Re: [Tagging] Winter sports share the same way

2014-01-09 Thread Tod Fitch
I thought the discussion was how the tagging described at 
http://wiki.openstreetmap.org/wiki/Proposed_features/Piste_Maps could be made 
better. That tagging does not have piste:difficulty:snowshoe, etc. So one 
option would be to add that. Another would be to have separate relations for 
each activity type.

-Tod



On Jan 9, 2014, at 12:55 PM, fly wrote:

> Do not really understand your problem.
> 
> As already mentioned you can use a semicolon for the piste_type values
> and tag the difficulty with addidtional keys like difficulty:sled=*
> 
> cu fly
> 
> On 09.01.2014 21:44, Tod Fitch wrote:
>> A single trail, even a single section of a trail, represented by a single 
>> way could have one difficulty rating for a person on snowshoes and a 
>> different difficulty rating for a person on skis.
>> 
>> -Tod
>> 
>> 
>> 
>> On Jan 9, 2014, at 11:08 AM, yvecai wrote:
>> 
>>> On 01/09/2014 07:27 PM, Tod Fitch wrote:
 
 I could go for relations which would solve the multiple use and multiple 
 difficulty issues.
>>> Unless you map difficulties like it should: by section, or in OSM, by ways.
> 
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



smime.p7s
Description: S/MIME cryptographic signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Unsuitable?

2014-01-09 Thread John F. Eldredge
Pieren  wrote:
> On Wed, Jan 8, 2014 at 2:24 PM, Martin Vonwald 
> wrote:
> 
> > Since when is "unsuitable" an accepted value for the access keys? I
> always
> > thought that the access keys describe legal restrictions.
> 
> It says "usage is discouraged (e.g. HGVs on narrow lanes) . Often
> marked by a traffic sign "
> 
> So maybe, there is a traffic sign for "unsuitable" which is different
> from "no". An example would be appreciated.
> 
> Pieren
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

Residential neighborhoods will often have a sign banning trucks (heavy goods 
vehicles) unless they are making a delivery in that neighborhood. They don't 
want heavy vehicles using the road as a through route.

Also, a road may be unsuitable for large vehicles because of limited overhead 
clearances, small-radius curves or intersections, or because the pavement 
wasn't constructed strongly enough for a vehicle that heavy.  Dump trucks, in 
particular, will break up the surface of a roadway because the weight on each 
axle is so great.

-- 
John F. Eldredge -- j...@jfeldredge.com
"Darkness cannot drive out darkness: only light can do that.
Hate cannot drive out hate: only love can do that."
Dr. Martin Luther King, Jr.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging