Re: [Tagging] shop=fashion

2017-08-27 Thread Graeme Fitzpatrick
Hi

Just consulted with an authority in these matters - my wife! :-)

Her take:

shop=clothes is chain stores (ie same shop in multiple shopping centres /
towns) aimed at lower-middle end of the market

shop=fashion is middle - higher end, but still chain stores

shop=boutique is "one-off" shops eg selling hand-made rather than
mass-produced clothes; niche / speciality items etc

Hope that helps?


Thanks

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


Re: [Tagging] Fire hydrants vs suction_point

2017-08-27 Thread Warin

On 28-Aug-17 09:06 AM, Richard Welty wrote:

On 8/27/17 6:59 PM, Dave Swarthout wrote:

I can respond to tell you what seems most familiar to me, a native
American English speaker: flow_rate in gallons/sec or per minute. Now,
that being said, I am all in favor of avoiding the archaic system we
still use in the U.S. and using a default flow_rate in cubic
meters/second (or per minute) or alternatively cubic centimeters/sec
(cc/sec).

default to SI units is fine. local units should be permissable.

richard



The problem with gallons .. there are 2 of them!

US and UK ... about 0.5 litres difference between them ..the US one is 
smaller.


So if someone says 'gallons' .. you have to look at where they are (and 
hopefully they are not a tourist/immigrant).




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


Re: [Tagging] Fire hydrants vs suction_point

2017-08-27 Thread Richard Welty
On 8/27/17 6:59 PM, Dave Swarthout wrote:
> I can respond to tell you what seems most familiar to me, a native
> American English speaker: flow_rate in gallons/sec or per minute. Now,
> that being said, I am all in favor of avoiding the archaic system we
> still use in the U.S. and using a default flow_rate in cubic
> meters/second (or per minute) or alternatively cubic centimeters/sec
> (cc/sec). 

default to SI units is fine. local units should be permissable.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search


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


Re: [Tagging] Fire hydrants vs suction_point

2017-08-27 Thread Dave Swarthout
I can respond to tell you what seems most familiar to me, a native American
English speaker: flow_rate in gallons/sec or per minute. Now, that being
said, I am all in favor of avoiding the archaic system we still use in the
U.S. and using a default flow_rate in cubic meters/second (or per minute)
or alternatively cubic centimeters/sec (cc/sec).

Cheers,
Dave

On Sun, Aug 27, 2017 at 3:18 PM, Viking  wrote:

> Hi, I've been away for a week. I'll try to read all your comments.
> First of all: Dry riser is a device. Suction point another one. Hydrant
> another one. Three different things, three different tags. Ok?
> Then I agree to remove the use of : where possible.
> The word "capacity" is in most cases synonymous of "volume", not
> "volume/time". It is suitable for a park, for a tank, for a pond. Instead
> the term "Flow capacity" is sometimes used for streams or pipelines, but I
> think that the best words are "flow rate": is there a native Englishman
> that can confirm this? In any case, I would use the word "flow", because
> it's more intuitive for non British users.
> For hydrants or suction point we need to have l/min or gpm: it is
> necessary for quick calculations when we refill the water tank. So if we
> use the universal tag flow_capacity=* (or flow_rate=*) the international
> standard unit will be m3/s, that is suitable for river, streams, etc., but
> we'll need to specify each time l/min or gpm for hydrants and suction
> points.
> Do you think that it is better to use a universal tag (flow_capacity=* or
> flow_rate=*) and specify each time the unit of measure rather than have a
> hydrant specific tag (fire_hydrant:flow_capacity=* or
> fire_hydrant:flow_rate=*) with its own default unit (l/min)?
>
> > Currently a contributor can create a emergency=fire_hydrant.
> > It's right, it is usable if you don't care about pressure (for example
> if you have anyway a pump with you).
> > Another day, another contributor will add additional information.
> And if we divide emergency=fire_hydrant from emergency=suction_point what
> changes? Nothing.
> If a contributor (in some cases and in some countries) can't distinguish
> an hydrant from a suction point he will randomly use one tag or the other
> (more probably emergency=fire_hydrant).
> BUT, if you have anyway a pump with you, even if the tag is incorrect, you
> can take water from that point.
> And eventually another day, another contributor will fix the tag.
> The problem is not which way we choose to tag these objects, but the
> problem is in the real world where different object are not visually
> distinguishable by an inexperienced mapper.
>
> I will read other comments in the next days.
> Best regards,
> Alberto
>
>
>
> ---
> Questa e-mail è stata controllata per individuare virus con Avast
> antivirus.
> https://www.avast.com/antivirus
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Fire hydrants vs suction_point

2017-08-27 Thread Viking
Hi, I've been away for a week. I'll try to read all your comments.
First of all: Dry riser is a device. Suction point another one. Hydrant another 
one. Three different things, three different tags. Ok?
Then I agree to remove the use of : where possible.
The word "capacity" is in most cases synonymous of "volume", not "volume/time". 
It is suitable for a park, for a tank, for a pond. Instead the term "Flow 
capacity" is sometimes used for streams or pipelines, but I think that the best 
words are "flow rate": is there a native Englishman that can confirm this? In 
any case, I would use the word "flow", because it's more intuitive for non 
British users.
For hydrants or suction point we need to have l/min or gpm: it is necessary for 
quick calculations when we refill the water tank. So if we use the universal 
tag flow_capacity=* (or flow_rate=*) the international standard unit will be 
m3/s, that is suitable for river, streams, etc., but we'll need to specify each 
time l/min or gpm for hydrants and suction points.
Do you think that it is better to use a universal tag (flow_capacity=* or 
flow_rate=*) and specify each time the unit of measure rather than have a 
hydrant specific tag (fire_hydrant:flow_capacity=* or  
fire_hydrant:flow_rate=*) with its own default unit (l/min)?

> Currently a contributor can create a emergency=fire_hydrant.
> It's right, it is usable if you don't care about pressure (for example if you 
> have anyway a pump with you).
> Another day, another contributor will add additional information.
And if we divide emergency=fire_hydrant from emergency=suction_point what 
changes? Nothing.
If a contributor (in some cases and in some countries) can't distinguish an 
hydrant from a suction point he will randomly use one tag or the other  (more 
probably emergency=fire_hydrant).
BUT, if you have anyway a pump with you, even if the tag is incorrect, you can 
take water from that point.
And eventually another day, another contributor will fix the tag.
The problem is not which way we choose to tag these objects, but the problem is 
in the real world where different object are not visually distinguishable by an 
inexperienced mapper.

I will read other comments in the next days.
Best regards,
Alberto



---
Questa e-mail è stata controllata per individuare virus con Avast antivirus.
https://www.avast.com/antivirus


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


Re: [Tagging] oneway:bicycle

2017-08-27 Thread Paul Johnson
If it's physically seperate, sure.  Otherwise just oneway:bicycle=no

On Sun, Aug 27, 2017 at 8:20 AM, José G Moya Y.  wrote:

> In Madrid, in Puerta del Sol, there is a two-way bicycle way that shares
> space with a one-way car street. I haven't checked how it is mapped, but I
> guess a parallel line for bicycles would work.
>
> Regards,
> José Moya
>
> El 27/8/2017 14:01, "Adam Snape"  escribió:
>
>> An unknown value cannot be meaningfully used by routers etc. You could
>> add a fixme tag so that a local mapper can clarify the signs on the ground.
>> If there is no mention of cycles on signage then it should be assumed that
>> the one-way restriction applies equally to cycles (unless the country's
>> laws exclude cycles from one way restrictions).
>>
>> Regards,
>>
>> Adam
>>
>> On 26 Aug 2017 6:22 p.m., "Alexis Reynouard" 
>> wrote:
>>
>> Is there an accepted/good way to differ between *"it is a oneway for
>> everyone, including bicycles"* and *"it is a oneway, but it is unknown
>> if it is also a oneway for bicycles"*.
>>
>> From the OSM wiki:
>>
>> you can use oneway:bicycle=* to identify roads where the oneway rules
>> for cyclists differ from the general oneway restriction
>>
>>
>> ___
>> 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 mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] shop=fashion

2017-08-27 Thread Thilo Haug
Hi Simon,

I also can't see a difference
between boutique and fashion.
Both might be a shop
with other items than clothes
according to these definitions :

"A small shop selling fashionable clothes or accessories"
https://en.oxforddictionaries.com/definition/boutique
"a small store that sells stylish clothing, jewelry, or other usually
luxury goods".
https://en.wikipedia.org/wiki/Boutique

"A popular or the latest style of clothing, hair, decoration, or behaviour."
https://en.oxforddictionaries.com/definition/fashion
"Fashion is a popular style or practice, especially in clothing,
footwear, accessories, makeup, body, or furniture."
https://en.wikipedia.org/wiki/Fashion

Possibly a
shop=fashion
with
fashion:type=accessories;clothes

I think this system may be described properly
without causing confusion.
Please let me know which "lot of reasons" you mean.

Cheers,
Thilo


Am 27.08.2017 um 15:04 schrieb Simon Poole:
>
> There is a big difference between a limited number of binary options
> and  essentially moving all values in to key space (and I can give a
> lot of reasons why it is a really really bad idea in a free form, user
> extendible tagging system).
>
> But it seems to be rather off-topic in this thread in any case: I
> simply wanted to know if there is a clear characterisation of
> shop=fashion that can serve as disambiguation between it and
> shop=boutique and shop=clothes (with appropriate additional tags).
>
> We have one voice saying that it should be considered a cheap variant
> of boutique limited to clothes, and the others suggesting that it is
> an upmarket shop=clothes and that shop=boutique should have a broader
> not only clothes definition.
>
> One takeaway is that adding the "clothes" tag both to fashion and
> boutique would be a good idea.
>
> Simon
>
> Am 26.08.2017 um 13:53 schrieb Thilo Haug:
>>
>> Hi all,
>>
>> I'm in favor of a namespace solution,
>> http://wiki.openstreetmap.org/wiki/Namespace
>> e.g.
>>
>> ski:clothes=yes
>> surfing:clothes=yes
>> motorcycle:clothes=yes
>> any_other_sport:clothes=yes
>>
>> and so on.
>>
>> This way you may also tag other shops (not just shop=clothes)
>> in a way which exactly describes their offers,
>> in this example possibly a shop=sports.
>>
>> The same works also for other services they offer,
>> like
>> ski:repair=yes
>> ski:rental=yes
>> ski:parts=yes
>>
>> This way there's no need to create a new shop type
>> or decide whether it's MORE one type of shop (bicycle vs. motorcycle
>> vs. car or similar)
>> in case they offer very various things.
>>
>> Cheers,
>> Thilo
>>
>>
>> Am 26.08.2017 um 13:13 schrieb Martin Koppenhoefer:
>>>
>>>
>>> sent from a phone
>>>
>>> On 26. Aug 2017, at 11:15, Simon Poole >> > wrote:
>>>
 the question turned up if shop=fashion (with 5000 something uses)
 should not be deprecated (==not offered for new use) due to overlap
 with
 shop=boutique (~11'000 uses) and shop=clothes, clothes=fashion (not
 particularly popular with roughly 200 uses). It just doesn't seem to
 have a good definition, which is already pointed out on the wiki page
 (but without a conclusion).
>>>
>>>
>>> I'd see shop=fashion similar with shop=boutique, while shop=clothes
>>> is not particularly helpful if you're looking to buy clothes (too
>>> generic). I'd roughly see it like this: boutique expensive, fashion
>>> cheap(er), department store both, supermarket cheap ;-)
>>>
>>> What would I search for if I wanted to buy a suit or a shirt
>>> (department shops apart which will sell you anything)? Maybe a
>>> "boutique for men"? To buy gloves I'd try with a  shop=bags? Or
>>> shop=leather? Or shop=sports? Or an outdoor shop? There are many
>>> places to buy clothes, cheap, casual, formal, according to the
>>> material, for work, gender, age, style, one brand/designer or
>>> multiple, or no (known) designer, discounter, different types of
>>> clothing (underwear, shirts, etc.
>>> I'm rather against reduction of top level shop types, there's IMHO a
>>> clear distinction between fashion shops and boutiques, with maybe
>>> some edge cases, but still useful overall. Nonetheless I agree that
>>> shop=clothes does require subtags to be more useful, but the current
>>> situation in the clothes key is not working:
>>> https://taginfo.openstreetmap.org/keys/clothes#values
>>> There are many orthogonal, specific properties tagged, e.g. target
>>> group (women, men, children, babies), for specific occasions/uses
>>> (sports/wedding/workwear), materials (denim/fur), type
>>> (underwear/lingerie). Fashion would be yet another new category in
>>> this cauldron (with 111 uses it isn't really significant).
>>>
>>> cheers,
>>> Martin 
>>>
>>>
>>> ___
>>> Tagging mailing list
>>> Tagging@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>
>> -- 
>>
>> Thilo Haug
>> Bismarckstr.37
>> 72764 Reutlingen
>>
>> Mobil: +49 177 3185856
>> 

Re: [Tagging] oneway:bicycle

2017-08-27 Thread José G Moya Y .
In Madrid, in Puerta del Sol, there is a two-way bicycle way that shares
space with a one-way car street. I haven't checked how it is mapped, but I
guess a parallel line for bicycles would work.

Regards,
José Moya

El 27/8/2017 14:01, "Adam Snape"  escribió:

> An unknown value cannot be meaningfully used by routers etc. You could add
> a fixme tag so that a local mapper can clarify the signs on the ground. If
> there is no mention of cycles on signage then it should be assumed that the
> one-way restriction applies equally to cycles (unless the country's laws
> exclude cycles from one way restrictions).
>
> Regards,
>
> Adam
>
> On 26 Aug 2017 6:22 p.m., "Alexis Reynouard" 
> wrote:
>
> Is there an accepted/good way to differ between *"it is a oneway for
> everyone, including bicycles"* and *"it is a oneway, but it is unknown if
> it is also a oneway for bicycles"*.
>
> From the OSM wiki:
>
> you can use oneway:bicycle=* to identify roads where the oneway rules for
> cyclists differ from the general oneway restriction
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] shop=fashion

2017-08-27 Thread Simon Poole
There is a big difference between a limited number of binary options
and  essentially moving all values in to key space (and I can give a lot
of reasons why it is a really really bad idea in a free form, user
extendible tagging system).

But it seems to be rather off-topic in this thread in any case: I simply
wanted to know if there is a clear characterisation of shop=fashion that
can serve as disambiguation between it and shop=boutique and
shop=clothes (with appropriate additional tags).

We have one voice saying that it should be considered a cheap variant of
boutique limited to clothes, and the others suggesting that it is an
upmarket shop=clothes and that shop=boutique should have a broader not
only clothes definition.

One takeaway is that adding the "clothes" tag both to fashion and
boutique would be a good idea.

Simon

Am 26.08.2017 um 13:53 schrieb Thilo Haug:
>
> Hi all,
>
> I'm in favor of a namespace solution,
> http://wiki.openstreetmap.org/wiki/Namespace
> e.g.
>
> ski:clothes=yes
> surfing:clothes=yes
> motorcycle:clothes=yes
> any_other_sport:clothes=yes
>
> and so on.
>
> This way you may also tag other shops (not just shop=clothes)
> in a way which exactly describes their offers,
> in this example possibly a shop=sports.
>
> The same works also for other services they offer,
> like
> ski:repair=yes
> ski:rental=yes
> ski:parts=yes
>
> This way there's no need to create a new shop type
> or decide whether it's MORE one type of shop (bicycle vs. motorcycle
> vs. car or similar)
> in case they offer very various things.
>
> Cheers,
> Thilo
>
>
> Am 26.08.2017 um 13:13 schrieb Martin Koppenhoefer:
>>
>>
>> sent from a phone
>>
>> On 26. Aug 2017, at 11:15, Simon Poole > > wrote:
>>
>>> the question turned up if shop=fashion (with 5000 something uses)
>>> should not be deprecated (==not offered for new use) due to overlap with
>>> shop=boutique (~11'000 uses) and shop=clothes, clothes=fashion (not
>>> particularly popular with roughly 200 uses). It just doesn't seem to
>>> have a good definition, which is already pointed out on the wiki page
>>> (but without a conclusion).
>>
>>
>> I'd see shop=fashion similar with shop=boutique, while shop=clothes
>> is not particularly helpful if you're looking to buy clothes (too
>> generic). I'd roughly see it like this: boutique expensive, fashion
>> cheap(er), department store both, supermarket cheap ;-)
>>
>> What would I search for if I wanted to buy a suit or a shirt
>> (department shops apart which will sell you anything)? Maybe a
>> "boutique for men"? To buy gloves I'd try with a  shop=bags? Or
>> shop=leather? Or shop=sports? Or an outdoor shop? There are many
>> places to buy clothes, cheap, casual, formal, according to the
>> material, for work, gender, age, style, one brand/designer or
>> multiple, or no (known) designer, discounter, different types of
>> clothing (underwear, shirts, etc.
>> I'm rather against reduction of top level shop types, there's IMHO a
>> clear distinction between fashion shops and boutiques, with maybe
>> some edge cases, but still useful overall. Nonetheless I agree that
>> shop=clothes does require subtags to be more useful, but the current
>> situation in the clothes key is not working:
>> https://taginfo.openstreetmap.org/keys/clothes#values
>> There are many orthogonal, specific properties tagged, e.g. target
>> group (women, men, children, babies), for specific occasions/uses
>> (sports/wedding/workwear), materials (denim/fur), type
>> (underwear/lingerie). Fashion would be yet another new category in
>> this cauldron (with 111 uses it isn't really significant).
>>
>> cheers,
>> Martin 
>>
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>
> -- 
>
> Thilo Haug
> Bismarckstr.37
> 72764 Reutlingen
>
> Mobil: +49 177 3185856
> Festnetz : +49 7121 3826414
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



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


Re: [Tagging] oneway:bicycle

2017-08-27 Thread Adam Snape
An unknown value cannot be meaningfully used by routers etc. You could add
a fixme tag so that a local mapper can clarify the signs on the ground. If
there is no mention of cycles on signage then it should be assumed that the
one-way restriction applies equally to cycles (unless the country's laws
exclude cycles from one way restrictions).

Regards,

Adam

On 26 Aug 2017 6:22 p.m., "Alexis Reynouard" 
wrote:

Is there an accepted/good way to differ between *"it is a oneway for
everyone, including bicycles"* and *"it is a oneway, but it is unknown if
it is also a oneway for bicycles"*.

>From the OSM wiki:

you can use oneway:bicycle=* to identify roads where the oneway rules for
cyclists differ from the general oneway restriction


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