Re: [Tagging] RFC: Defaults are paramount, abandoning Proposed_features/ is a HUGE mistake

[Neil Matthews]

I have some sympathy for expressing defaults within a bounded area.

However, some thought needs to be put into the logistics when mapping /
inputting data.

I would "hope" that there would be editor support -- otherwise how does
one determine whether a given tag/value combination can be omitted --
because it is the default!

Unfortunately, that means that every editor would have to iterate out to
find defaults in ever increasing areas -- unless defaults aren't allowed
to be nested, which imho reduces their usefulness significantly.

Similarly, I'm having trouble conceptualizing what adding / changing a
default value on a bounding area should mean -- are existing inherited
default values now implicitly updated, or do they need to be examined
individually.

Finally, how does one indicate that a value is not able to be determined
-- and should not immediately be inherited -- leaving it blank is no
longer an option!

Apologies, that was longer than I intended,
Neil



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

Re: [Tagging] shop=fashion shop=boutique

[Warin]

On 02-Sep-17 04:31 AM, Marc Gemis wrote:

Is ignoring what the community did so far, a guideline ? People have
used the tag boutique. So why cannot we take this practice and use
that as the guideline ? Why change the currently used tags, causing a
cost of all involved parties ?



This is a serious question. I want to understand why people think the
about differences are ok, but clothes and boutique not.


I lack the understanding of what is meant by 'boutique' and 'fashion'.

I think the terms could be used for a very wide variety of features.

The tag shop=cloths I understand and don't see any confusion over it.

If 'fashion' simply means cloths with some added parameters then I would think 
it should be a sub tag. The same for 'boutique'.

If they mean something different from cloths .. then what are they? And I don't 
want terms like - more expensive, finer materials, better design - these are 
either subjective and/or sub tags.

Fuel stations that do not sell diesel are not given a separate main tag - they 
get a sub tag.
And yes some things in OSM have been given main tags where, with more 
organisation, they could have been better with sub tags. 'Path' and footpath 
spring to mind.



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

Re: [Tagging] shop=fashion shop=boutique

[Warin]

On 02-Sep-17 06:33 AM, Philip Barnes wrote:


On 1 September 2017 19:35:01 BST, Marc Gemis  wrote:

Do you find the difference between supermarket and convenience store
helpful ? Or do you just search (as in OsmAnd) for places that sell
food ? So why bother to have 2 tags for those kind of shops ?


Actually that is one of the failings of Osmand in that mappers carefully map 
supermarkets or convenience shops but then the app I want to use to find a 
supermarket when away from home lumps the two together.

Supermarkets for example will have a fresh meat counter, fresh fish counter 
which is important stuff when you are camping.



When your far enough away from 'civilisation' the 'supermarket' has 'fresh' 
bread in the freezer and you ignore the date stamp.



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

Re: [Tagging] RFC: Defaults are paramount, abandoning Proposed_features/ is a HUGE mistake

[Tod Fitch]

In the jurisdiction I live, I would apply the state’s default residential speed 
to OSM residential and unclassified highways. I would apply the state’s default 
55 MPH for untagged roads to OSM tertiary, secondary, primary and trunk 
highways. I would apply the state 65 MPH limit for freeways to OSM motorways.

If defaults are at the smallest enclosing administrative boundary probably not 
required in my area: One of the characteristics of tertiary, secondary, primary 
and trunk highways within a incorporated municipality and even in built up but 
non-incorporated areas, is that by law each of those road types must have the 
speed limit set based on a traffic study and signs are posted based on the 
decision made following the study. The end result is that non-residential, 
non-unclassified (using OSM terms) are pretty well signed in urban areas.

Tod

> On Sep 1, 2017, at 2:21 PM, Marc Gemis  wrote:
> 
> Tod,
> 
> Can you clarify what residential and rural roads mean to you? Is a 
> residential road corresponding to the osm tag? When is a road rural? Can you 
> determine this for each osm way?
> 
> Regards
> 
> m
> 
> Op 1 sep. 2017 18:53 schreef "Tod Fitch"  >:
> I take exception to the comment that “there will be too many exceptions to 
> the rule”.
> 
> In the country I live in each state has a set of “prima facia” speed limits 
> for various types of roads. Those are basically default speed limits to be 
> enforced unless otherwise posted by sign. Virtually no residential road in my 
> state has a speed limit sign but if you exceed 25 MPH you can be ticketed for 
> speeding. Rural highways are signed only at infrequent intervals, but 
> exceeding 55 MPH can result in a ticket.
> 
> Given:
> A) We should only tag what is on the ground verifiable. By that rule we 
> should not currently tag these “prima facia” speed limits (no speed limit 
> sign to verify a maxspeed tag value).
> 
> B) A routing app currently has no way to determine a default speed (one to be 
> used if no maxspeed=* tag found on way). These can vary by jurisdiction and I 
> can imagine situations where a national default is overridden by a state 
> default and/or local municipality default. Should all routing apps go to a 
> different geographical database to get defaults? If so, why not go to that 
> other database for everything and ignore OSM?
> 
> It make perfect sense to me to allow administrative areas to be tagged with 
> default values for otherwise untagged items within the jurisdiction. If 
> something deviates from the default, as in your “speed limits varies 
> depending on local topography”, then it will be signed and we should tag per 
> the sign. But many, many roads in my area are not signed and yet have legally 
> set maximum speeds.
> 
> At present, I usually ignore the local verifiability constraint and simply 
> put a maxspeed value on residential roads after I’ve surveyed them even if 
> they are not signed. If I am feeling a bit more energetic than usual I may 
> also add a source:maxspeed with a value citing my state’s motor vehicle code. 
> It would be a lot easier if I could rely on a default value set on my state’s 
> administrative boundary.
> 
> 
>> On Sep 1, 2017, at 9:25 AM, Dave F > > wrote:
>> 
>> Hi André
>> 
>> Assuming or defining a default should be based on the number of different 
>> values within the set. 
>> 
>> For the examples you give:
>> 
>> maxspeed shouldn't have a default. Apart from on motorway classed roads, 
>> speed limits varies depending on local topography. There will be too many 
>> exceptions to the rule.
>> 
>> driving_side is defined nationally so has a default. (I'm sure now someone 
>> will now provide examples where that's not the case).  Any router worth its 
>> salt, should be able to check which country it is in.
>> 
>> DaveF 
>> 
>> 
>> On 31/08/2017 12:49, André Pirard wrote:
>>> Hi,
>>> 
>>> Examples: either each road is tagged with maxspeed=* 
>>>  speed limit and 
>>> driving_side=*  or 
>>> there are defaults.
>>> I'm reviving this remark because the examples are numerous:
>>> The Belgian Flemish community wants to tag maxspeed=* 
>>>  on every road instead of 
>>> using a default. Is this a new specification and where is it written? Must 
>>> that now be done in every country?
>>> The current language= proposition wants to do it without defining defaults. 
>>> Really? language= on every name= ?
>>> Other examples are maxheight in tunnels. Osmose just accused me of someone 
>>> else's omitting maxheight. It shouldn't be necessary if it's the default, 
>>> that is if there is no sign for it, but Osmose likes to yell just in case.
>>> countless etc.
>>> Please choose.
>>> 

Re: [Tagging] RFC: Defaults are paramount, abandoning Proposed_features/ is a HUGE mistake

[Marc Gemis]

Tod,

Can you clarify what residential and rural roads mean to you? Is a
residential road corresponding to the osm tag? When is a road rural? Can
you determine this for each osm way?

Regards

m

Op 1 sep. 2017 18:53 schreef "Tod Fitch" :

> I take exception to the comment that “there will be too many exceptions to
> the rule”.
>
> In the country I live in each state has a set of “prima facia” speed
> limits for various types of roads. Those are basically default speed limits
> to be enforced unless otherwise posted by sign. Virtually no residential
> road in my state has a speed limit sign but if you exceed 25 MPH you can be
> ticketed for speeding. Rural highways are signed only at infrequent
> intervals, but exceeding 55 MPH can result in a ticket.
>
> Given:
> A) We should only tag what is on the ground verifiable. By that rule we
> should not currently tag these “prima facia” speed limits (no speed limit
> sign to verify a maxspeed tag value).
>
> B) A routing app currently has no way to determine a default speed (one to
> be used if no maxspeed=* tag found on way). These can vary by jurisdiction
> and I can imagine situations where a national default is overridden by a
> state default and/or local municipality default. Should all routing apps go
> to a different geographical database to get defaults? If so, why not go to
> that other database for everything and ignore OSM?
>
> It make perfect sense to me to allow administrative areas to be tagged
> with default values for otherwise untagged items within the jurisdiction.
> If something deviates from the default, as in your “speed limits varies
> depending on local topography”, then it will be signed and we should tag
> per the sign. But many, many roads in my area are not signed and yet have
> legally set maximum speeds.
>
> At present, I usually ignore the local verifiability constraint and simply
> put a maxspeed value on residential roads after I’ve surveyed them even if
> they are not signed. If I am feeling a bit more energetic than usual I may
> also add a source:maxspeed with a value citing my state’s motor vehicle
> code. It would be a lot easier if I could rely on a default value set on my
> state’s administrative boundary.
>
>
> On Sep 1, 2017, at 9:25 AM, Dave F  wrote:
>
> Hi André
>
> Assuming or defining a default should be based on the number of different
> values within the set.
>
> For the examples you give:
>
> maxspeed shouldn't have a default. Apart from on motorway classed roads,
> speed limits varies depending on local topography. There will be too many
> exceptions to the rule.
>
> driving_side is defined nationally so has a default. (I'm sure now someone
> will now provide examples where that's not the case).  Any router worth its
> salt, should be able to check which country it is in.
>
> DaveF
>
>
> On 31/08/2017 12:49, André Pirard wrote:
>
> Hi,
>
> Examples: either each road is tagged with *maxspeed*=*
>  speed limit and
> *driving_side*=* 
> or there are defaults.
> I'm reviving this remark because the examples are numerous:
>
>- The Belgian Flemish community wants to tag *maxspeed*=*
> on every road
>instead of using a default. Is this a new specification and where is it
>written? Must that now be done in every country?
>- The current language= proposition wants to do it without defining
>defaults. Really? language= on every name= ?
>- Other examples are maxheight in tunnels. Osmose just accused me of
>someone else's omitting maxheight. It shouldn't be necessary if it's the
>default, that is if there is no sign for it, but Osmose likes to yell just
>in case.
>- countless etc.
>
> Please choose.
>
> Either the defaults are in the OSM database and it takes just a routinely
> map fetch to get them all updated timely,
> or each other router (GPS) writer implements them each their own way from
> various random other files. It's not well clear how contributors ca update
> all those files instead of OSM and it typically needs a full software
> update for each little default change, depending on writer's availability.
>
> Please choose.
>
> There is a Proposed_features/Defaults
>  that
> puts the defaults in OSM and it's an EXTREMELY HUGE mistake to have marked
> such a paramount good work as abandoned because nobody continued the work.
> For the sake of OSM, especially routing, please reopen it.
> I don't claim that it is the good solution but I do claim we should work
> on such a default database *in priority*.
>
> I didn't analyze it in full depth, but I have the following remarks:
> - Why not allow the def keyword in the border relation itself? But it
> could be called zzdef to cluster at the key end.
> - If a 

Re: [Tagging] Fire hydrants vs suction_point

[Viking]

If we want to remove fire_hydrant: namespace, what's about transform 
fire_hydrant:diameter=# in diameter=# ? It is already documented its use with 
hydrants: [0]
And about fire_hydrant:style=*, fire_hydrant:count=# and fire_hydrant:class=* ? 
I would keep these tags as they are now.

[0] https://wiki.openstreetmap.org/wiki/Key:diameter

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] shop=fashion shop=boutique

[Philip Barnes]

On 1 September 2017 19:58:10 BST, Marc Gemis  wrote:
>On Fri, Sep 1, 2017 at 8:25 PM, Andrew Hain
> wrote:
>> Let’s put it this way: how many people who use the map database,
>whether
>> working from planets, editing where these tags could already have
>been used,
>> searching for objects by tags or any other way, find the tags
>shop=boutique
>> or shop=fashion helpful or wish there were more of them?
>
>A more extreme example. Do you only use building=yes, or do you use
>any of the specific types of building ? Have you ever searched for one
>of those specific types, or know anyone who did ? (besides SK53)
>
Certainly use it, and from some of the discussions on #osm tonight, its 
something that streetcomplete should use to avoid daft questions like what is 
the house number of schools. 

Phil (trigpoint) 

-- 
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] Fire hydrants vs suction_point

[Viking]

Hi Walter.

> when you say "hydrant", you meen "emergency=fire_hydrant"  ok?

Yes.

> and the substag fire_hydrant:type will specify the subtypes 
> (underground, pillar, ...)  ok?

Currently we think to put the subtype in fire_hydrant=underground/pillar... 
instead of using fire_hydrant:type=underground/pillar...

Thank you for your emergency map.

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] shop=fashion shop=boutique

[Philip Barnes]

On 1 September 2017 19:35:01 BST, Marc Gemis  wrote:
>
>Do you find the difference between supermarket and convenience store
>helpful ? Or do you just search (as in OsmAnd) for places that sell
>food ? So why bother to have 2 tags for those kind of shops ?
>
Actually that is one of the failings of Osmand in that mappers carefully map 
supermarkets or convenience shops but then the app I want to use to find a 
supermarket when away from home lumps the two together.

Supermarkets for example will have a fresh meat counter, fresh fish counter 
which is important stuff when you are camping.

Phil (trigpoint) 
-- 
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] RFC: Defaults are paramount, abandoning Proposed_features/ is a HUGE mistake

[Colin Smale]

On 2017-09-01 21:32, Nick Bolten wrote:

> I also don't know the best way to establish a hierarchy for *which* boundary 
> settings to honor, if a given street is within admin boundaries for city, 
> region, and national having different maxspeeds. It makes sense to assume 
> that the most-local administrative boundary should be honored, but that may 
> not be consistent with the law.

The boundary with the highest value of admin_level? 

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

Re: [Tagging] RFC: Defaults are paramount, abandoning Proposed_features/ is a HUGE mistake

[Nick Bolten]

I'd like to second Tod's point that defaults are difficult when they depend
on regional variation. When a tag's default has significant geographical
variation, one has to have corresponding regional geodata to figure out
what value to use - shouldn't that geodata be in OSM?

Perhaps a compromise would be to place defaults that vary by region on an
administrative boundary. This way, the default can be explicit without
needing to be on every single road. It is also how these default limits are
defined: unless otherwise marked, all roads (perhaps of a certain class) in
this administrative region have X speed limit.

To figure out the default, you'd need to get (potentially large) admin
boundaries and do point-in-polygon queries. But then again, this is what
you would have to do if this data weren't in OSM, using multiple external
datasets.

I also don't know the best way to establish a hierarchy for *which*
boundary settings to honor, if a given street is within admin boundaries
for city, region, and national having different maxspeeds. It makes sense
to assume that the most-local administrative boundary should be honored,
but that may not be consistent with the law.

Best,

Nick

On Fri, Sep 1, 2017 at 9:53 AM Tod Fitch  wrote:

> I take exception to the comment that “there will be too many exceptions to
> the rule”.
>
> In the country I live in each state has a set of “prima facia” speed
> limits for various types of roads. Those are basically default speed limits
> to be enforced unless otherwise posted by sign. Virtually no residential
> road in my state has a speed limit sign but if you exceed 25 MPH you can be
> ticketed for speeding. Rural highways are signed only at infrequent
> intervals, but exceeding 55 MPH can result in a ticket.
>
> Given:
> A) We should only tag what is on the ground verifiable. By that rule we
> should not currently tag these “prima facia” speed limits (no speed limit
> sign to verify a maxspeed tag value).
>
> B) A routing app currently has no way to determine a default speed (one to
> be used if no maxspeed=* tag found on way). These can vary by jurisdiction
> and I can imagine situations where a national default is overridden by a
> state default and/or local municipality default. Should all routing apps go
> to a different geographical database to get defaults? If so, why not go to
> that other database for everything and ignore OSM?
>
> It make perfect sense to me to allow administrative areas to be tagged
> with default values for otherwise untagged items within the jurisdiction.
> If something deviates from the default, as in your “speed limits varies
> depending on local topography”, then it will be signed and we should tag
> per the sign. But many, many roads in my area are not signed and yet have
> legally set maximum speeds.
>
> At present, I usually ignore the local verifiability constraint and simply
> put a maxspeed value on residential roads after I’ve surveyed them even if
> they are not signed. If I am feeling a bit more energetic than usual I may
> also add a source:maxspeed with a value citing my state’s motor vehicle
> code. It would be a lot easier if I could rely on a default value set on my
> state’s administrative boundary.
>
>
> On Sep 1, 2017, at 9:25 AM, Dave F  wrote:
>
> Hi André
>
> Assuming or defining a default should be based on the number of different
> values within the set.
>
> For the examples you give:
>
> maxspeed shouldn't have a default. Apart from on motorway classed roads,
> speed limits varies depending on local topography. There will be too many
> exceptions to the rule.
>
> driving_side is defined nationally so has a default. (I'm sure now someone
> will now provide examples where that's not the case).  Any router worth its
> salt, should be able to check which country it is in.
>
> DaveF
>
>
> On 31/08/2017 12:49, André Pirard wrote:
>
> Hi,
>
> Examples: either each road is tagged with *maxspeed*=*
>  speed limit and
> *driving_side*=* 
> or there are defaults.
> I'm reviving this remark because the examples are numerous:
>
>- The Belgian Flemish community wants to tag *maxspeed*=*
> on every road
>instead of using a default. Is this a new specification and where is it
>written? Must that now be done in every country?
>- The current language= proposition wants to do it without defining
>defaults. Really? language= on every name= ?
>- Other examples are maxheight in tunnels. Osmose just accused me of
>someone else's omitting maxheight. It shouldn't be necessary if it's the
>default, that is if there is no sign for it, but Osmose likes to yell just
>in case.
>- countless etc.
>
> Please choose.
>
> Either the defaults are in the OSM database and it takes just a routinely
> map fetch to 

Re: [Tagging] shop=fashion shop=boutique

[Marc Gemis]

On Fri, Sep 1, 2017 at 8:25 PM, Andrew Hain  wrote:
> Let’s put it this way: how many people who use the map database, whether
> working from planets, editing where these tags could already have been used,
> searching for objects by tags or any other way, find the tags shop=boutique
> or shop=fashion helpful or wish there were more of them?

A more extreme example. Do you only use building=yes, or do you use
any of the specific types of building ? Have you ever searched for one
of those specific types, or know anyone who did ? (besides SK53)

regards

m

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

Re: [Tagging] shop=fashion shop=boutique

[Marc Gemis]

On Fri, Sep 1, 2017 at 8:25 PM, Andrew Hain  wrote:
> Let’s put it this way: how many people who use the map database, whether
> working from planets, editing where these tags could already have been used,
> searching for objects by tags or any other way, find the tags shop=boutique
> or shop=fashion helpful or wish there were more of them?

we'll never know unless maps.me, OsmAnd etc start collecting those
numbers from their users and share it with the community.

Do you find the difference between supermarket and convenience store
helpful ? Or do you just search (as in OsmAnd) for places that sell
food ? So why bother to have 2 tags for those kind of shops ?

regards

m.

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

Re: [Tagging] shop=fashion shop=boutique

[Marc Gemis]

Is ignoring what the community did so far, a guideline ? People have
used the tag boutique. So why cannot we take this practice and use
that as the guideline ? Why change the currently used tags, causing a
cost of all involved parties ?

But forget about that for a moment. What are the
criteria/formula/checklist one has to use to decide whether 2
different tags are appropriate or when a subtag has to be used.

Can you and Jean-Marc give me those ?

Can we apply this criteria/formula/checklist  to the following group
of tags and see whether the have to be changed into subtags ?

shop=clothes, boutique
shop=supermarket, deli, convenience
man_made/power=tower, mast, pole, flag_pole
building=residential, house, semi-detached, apartment, villa
shop=car, car_repair, car_parts, tire

* is having a wikipedia page in 10 or more languages a criteria ? apparently no
* is having a large number of objects tagged like that in OSM a
criteria ? apparently no
* is knowing how many people have searched for each of those
individual items a criteria ? Don't know, wouldn't know how we can
count that.

This is a serious question. I want to understand why people think the
about differences are ok, but clothes and boutique not.

regards

m.

On Fri, Sep 1, 2017 at 6:04 PM, Daniel Koć  wrote:
> W dniu 01.09.2017 o 17:51, Marc Gemis pisze:
>
>> So no, this group is not really representative for the community as a
>> whole.
>
>
> But what is representative? And what about standardization? I would be happy
> if we find a way to communicate things with wider community, but this is
> what we have now. As I said - one can always disagree and use "any tag you
> like" rule and that's OK for me. Standardization does not mean anybody
> enforcing, just creating guidelines - and this is what we try to do.
>
> --
> "Probably it's an eternal problem - too many chiefs, too few Indians" [O.
> Muzalyev]
>
>
> ___
> 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 shop=boutique

[Andrew Hain]

Let’s put it this way: how many people who use the map database, whether 
working from planets, editing where these tags could already have been used, 
searching for objects by tags or any other way, find the tags shop=boutique or 
shop=fashion helpful or wish there were more of them?

--
Andrew

From: Marc Gemis 
Sent: 01 September 2017 12:27:38
To: Tag discussion, strategy and related tools
Subject: Re: [Tagging] shop=fashion shop=boutique

because other mappers thought it was needed to distinguish the two ?
Who are we (the people using this mailing list) to decide that other
mappers cannot tag a shop=boutique if it is already used 11.000 times
?
So if you want to tag that shop as shop=clothes with subtags fine, do
it. Document it, we'll see in a couple of years which one of the 2
methods is more popular.
But please do not write that one is better than the other at this
moment, nor  mark one as obsolete. Let the (whole) community decide.

and now we all go back to mapping :-)

m.

On Fri, Sep 1, 2017 at 12:48 PM, Jean-Marc Liotier  wrote:
> I still don't understand the need for anything other than shop=clothes
> used with assorted modifiers. Fashion is subjective and I do not see
> why exclusive distribution channels should be tagged differently as
> they are essentially clothes shop with no price tags and an attitude.
>
> shop=car covers both the average Volskwagen dealership and the workshop
> that sells handmade locally built overpriced exotics with golden urinal
> that you never heard of. Why should it be different for clothes ?
>
> ___
> 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] RFC: Defaults are paramount, abandoning Proposed_features/ is a HUGE mistake

[Clifford Snow]

I have been following this discussion on default maxspeed tagging.
Searching the wiki hasn't been helpful. There is an inactive proposal [1],
a wiki page on country default speeds [1] but nothing definitive on how to
map.

The default scheme seems to be a reasonable approach for jurisdictions that
have a maxspeed for unposted roads.

Can someone point to a wiki page that explains how to map?

[1] https://wiki.openstreetmap.org/wiki/Proposed_features/Defaults
[2] https://wiki.openstreetmap.org/wiki/Country_specific_default_values

Clifford
-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Tagging Digest, Vol 96, Issue 3

[Severin Menard]

> Date: Fri, 1 Sep 2017 12:48:25 +0200
> From: Jean-Marc Liotier 
> To: "Tag discussion, strategy and related tools"
> 
> Subject: Re: [Tagging] shop=fashion shop=boutique
> Message-ID: <20170901124825.76716...@manantali.encara.local.ads>
> Content-Type: text/plain; charset=US-ASCII
>
> I still don't understand the need for anything other than shop=clothes
> used with assorted modifiers. Fashion is subjective and I do not see
> why exclusive distribution channels should be tagged differently as
> they are essentially clothes shop with no price tags and an attitude.
>
> shop=car covers both the average Volskwagen dealership and the workshop
> that sells handmade locally built overpriced exotics with golden urinal
> that you never heard of. Why should it be different for clothes ?
>

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

Re: [Tagging] RFC: Defaults are paramount, abandoning Proposed_features/ is a HUGE mistake

[Tod Fitch]

I take exception to the comment that “there will be too many exceptions to the 
rule”.

In the country I live in each state has a set of “prima facia” speed limits for 
various types of roads. Those are basically default speed limits to be enforced 
unless otherwise posted by sign. Virtually no residential road in my state has 
a speed limit sign but if you exceed 25 MPH you can be ticketed for speeding. 
Rural highways are signed only at infrequent intervals, but exceeding 55 MPH 
can result in a ticket.

Given:
A) We should only tag what is on the ground verifiable. By that rule we should 
not currently tag these “prima facia” speed limits (no speed limit sign to 
verify a maxspeed tag value).

B) A routing app currently has no way to determine a default speed (one to be 
used if no maxspeed=* tag found on way). These can vary by jurisdiction and I 
can imagine situations where a national default is overridden by a state 
default and/or local municipality default. Should all routing apps go to a 
different geographical database to get defaults? If so, why not go to that 
other database for everything and ignore OSM?

It make perfect sense to me to allow administrative areas to be tagged with 
default values for otherwise untagged items within the jurisdiction. If 
something deviates from the default, as in your “speed limits varies depending 
on local topography”, then it will be signed and we should tag per the sign. 
But many, many roads in my area are not signed and yet have legally set maximum 
speeds.

At present, I usually ignore the local verifiability constraint and simply put 
a maxspeed value on residential roads after I’ve surveyed them even if they are 
not signed. If I am feeling a bit more energetic than usual I may also add a 
source:maxspeed with a value citing my state’s motor vehicle code. It would be 
a lot easier if I could rely on a default value set on my state’s 
administrative boundary.


> On Sep 1, 2017, at 9:25 AM, Dave F  wrote:
> 
> Hi André
> 
> Assuming or defining a default should be based on the number of different 
> values within the set. 
> 
> For the examples you give:
> 
> maxspeed shouldn't have a default. Apart from on motorway classed roads, 
> speed limits varies depending on local topography. There will be too many 
> exceptions to the rule.
> 
> driving_side is defined nationally so has a default. (I'm sure now someone 
> will now provide examples where that's not the case).  Any router worth its 
> salt, should be able to check which country it is in.
> 
> DaveF 
> 
> 
> On 31/08/2017 12:49, André Pirard wrote:
>> Hi,
>> 
>> Examples: either each road is tagged with maxspeed=* 
>>  speed limit and 
>> driving_side=*  or 
>> there are defaults.
>> I'm reviving this remark because the examples are numerous:
>> The Belgian Flemish community wants to tag maxspeed=* 
>>  on every road instead of 
>> using a default. Is this a new specification and where is it written? Must 
>> that now be done in every country?
>> The current language= proposition wants to do it without defining defaults. 
>> Really? language= on every name= ?
>> Other examples are maxheight in tunnels. Osmose just accused me of someone 
>> else's omitting maxheight. It shouldn't be necessary if it's the default, 
>> that is if there is no sign for it, but Osmose likes to yell just in case.
>> countless etc.
>> Please choose.
>> 
>> Either the defaults are in the OSM database and it takes just a routinely 
>> map fetch to get them all updated timely,
>> or each other router (GPS) writer implements them each their own way from 
>> various random other files. It's not well clear how contributors ca update 
>> all those files instead of OSM and it typically needs a full software update 
>> for each little default change, depending on writer's availability.
>> 
>> Please choose.
>> 
>> There is a Proposed_features/Defaults 
>>  that puts 
>> the defaults in OSM and it's an EXTREMELY HUGE mistake to have marked such a 
>> paramount good work as abandoned because nobody continued the work.  For the 
>> sake of OSM, especially routing, please reopen it.
>> I don't claim that it is the good solution but I do claim we should work on 
>> such a default database in priority.
>> 
>> I didn't analyze it in full depth, but I have the following remarks:
>> - Why not allow the def keyword in the border relation itself? But it could 
>> be called zzdef to cluster at the key end.
>> - If a separate relation is preferred, it should be pointed at by a 
>> "defaults" role in the corresponding border or other relations so that it 
>> can be found.
>> - to ease scanning a border tree upwards, a "parent" relation should exist 
>> in border relations.
>> 
>> In hope of a well 

Re: [Tagging] shop=fashion shop=boutique

[Dave F]

On 31/08/2017 17:40, Daniel Koć wrote:
It's the same word, just nested, so it doesn't help, because we still 
don't know what it really means. =}


But we do know basically what it means. Putting it on a subtag allows 
renderers to ignore the minutiae and foibles of the fashion industry & 
tag it with their standard 'clothes' icon.




If we think that accessories are the core feature, it probably won't 
fit in clothes anyway,


I claimed the opposite of that.

but it's not clear yet. It's also interesting how being an outlet and 
selling second hand or handmade items relates to boutique.


I'm not convinced those are important criteria.

DaveF.

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

Re: [Tagging] RFC: Defaults are paramount, abandoning Proposed_features/ is a HUGE mistake

[Dave F]

Hi André

Assuming or defining a default should be based on the number of 
different values within the set.


For the examples you give:

maxspeed shouldn't have a default. Apart from on motorway classed roads, 
speed limits varies depending on local topography. There will be too 
many exceptions to the rule.


driving_side is defined nationally so has a default. (I'm sure now 
someone will now provide examples where that's not the case).  Any 
router worth its salt, should be able to check which country it is in.


DaveF


On 31/08/2017 12:49, André Pirard wrote:

Hi,

Examples: either each road is tagged with *maxspeed*=* 
 speed limit and 
*driving_side*=* 
 or there are 
defaults.

I'm reviving this remark because the examples are numerous:

  * The Belgian Flemish community wants to tag *maxspeed*=*
 on every road
instead of using a default. Is this a new specification and where
is it written? Must that now be done in every country?
  * The current language= proposition wants to do it without defining
defaults. Really? language= on every name= ?
  * Other examples are maxheight in tunnels. Osmose just accused me of
someone else's omitting maxheight. It shouldn't be necessary if
it's the default, that is if there is no sign for it, but Osmose
likes to yell just in case.
  * countless etc.

Please choose.

Either the defaults are in the OSM database and it takes just a 
routinely map fetch to get them all updated timely,
or each other router (GPS) writer implements them each their own way 
from various random other files. It's not well clear how contributors 
ca update all those files instead of OSM and it typically needs a full 
software update for each little default change, depending on writer's 
availability.


Please choose.

There is a Proposed_features/Defaults 
 that 
puts the defaults in OSM and it's an EXTREMELY HUGE mistake to have 
marked such a paramount good work as abandoned because nobody 
continued the work.  For the sake of OSM, especially routing, please 
reopen it.
I don't claim that it is the good solution but I do claim we should 
work on such a default database *in priority*.


I didn't analyze it in full depth, but I have the following remarks:
- Why not allow the def keyword in the border relation itself? But it 
could be called zzdef to cluster at the key end.
- If a separate relation is preferred, it should be pointed at by a 
"defaults" role in the corresponding border or other relations so that 
it can be found.
- to ease scanning a border tree upwards, a "parent" relation should 
exist in border relations.


In hope of a well structured OSM,

Cheers

André.






___
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 shop=boutique

[Daniel Koć]

W dniu 01.09.2017 o 17:51, Marc Gemis pisze:

So no, this group is not really representative for the community as a 
whole. 


But what is representative? And what about standardization? I would be 
happy if we find a way to communicate things with wider community, but 
this is what we have now. As I said - one can always disagree and use 
"any tag you like" rule and that's OK for me. Standardization does not 
mean anybody enforcing, just creating guidelines - and this is what we 
try to do.


--
"Probably it's an eternal problem - too many chiefs, too few Indians" [O. 
Muzalyev]


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

Re: [Tagging] shop=fashion shop=boutique

[Marc Gemis]

> The community is also this list.
>

I don't believe that. This list certainly lacks diversity. Most
participants here can discuss fluently in English, most are male (if
not all). So a huge group is missing.

I've met several people that do not want to participate in this
mailing list as they do not believe in the way this group defines
tags.

You might have seen that in the past a proposal didn't get any
comments from this mailing list anymore, but was still rejected when
it was opened for voting. This means that not everybody is
participating in this discussion via the mailing list.

I mentioned this tag to some other mappers, and they said, o no,
didn't see it we only use telegram.

So no, this group is not really representative for the community as a whole.

m.

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

Re: [Tagging] RFC: Defaults are paramount, abandoning Proposed_features/ is a HUGE mistake

[Martin Koppenhoefer]

2017-08-31 13:49 GMT+02:00 André Pirard :

>
>- The Belgian Flemish community wants to tag *maxspeed*=*
> on every road
>instead of using a default. Is this a new specification and where is it
>written? Must that now be done in every country?
>
>


We are doing this in Italy for many years now, and it is quite robust and
reliable. We are adding the source:maxspeed tags additionally to explain
whether the maxspeed is explicit (sign / road marking etc.) or implicit
(usually derived from a zone like "inside a settlement", "on a motorway",
"outside of a settlement", etc.). In all countries I am aware of you can't
reliably detect default limits without knowing if the road is inside or
outside of a settlement, which is typically not dependent on the actual
settlement but on street signs that tell you when you enter or leave a
(traffic code related) settlement. It has also proven useful for
maintenance and verification to map actual speed limit signs
(traffic_sign=maxspeed, maxspeed=n ) at the side of the road (to have the
direction stored).



>
Either the defaults are in the OSM database and it takes just a routinely
> map fetch to get them all updated timely,
> or each other router (GPS) writer implements them each their own way from
> various random other files. It's not well clear how contributors ca update
> all those files instead of OSM and it typically needs a full software
> update for each little default change, depending on writer's availability.
>


it really depends on the kind of "default" you are after. What about a
maxspeed=50 sign in Germany inside a settlement (i.e. it is a sign which
states the default). If the law for the default changes, this 50ies sign
will not have to change (unless they are going to modify the sign). If the
road is simply tagged with "highway=tertiary" you can't know whether this
is incomplete data, or the mapper had a lot of defaults in mind like
lit=yes, lanes=2, surface=asphalt, maxspeed=50, sidewalk=both, oneway=no,
smoothness=good, etc. (assuming a smaller road in a city).  You can't even
know whether the road is (legally) inside a city.

I guess you would have to define really complex defaults / processing to
cater just for the more used properties. A tag like source:maxspeed allows
to change all speed limit defaults in a country at once because they are
explicitly marked as defaults.

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

Re: [Tagging] shop=fashion shop=boutique

[Daniel Koć]

W dniu 01.09.2017 o 13:27, Marc Gemis pisze:

because other mappers thought it was needed to distinguish the two ?


But what if "distinguishing" is just an illusion? We had about 700k+ 
uses of landuse=farm, but now it's deprecated (with about 45k uses), 
because it was not clear.



Who are we (the people using this mailing list) to decide that other
mappers cannot tag a shop=boutique if it is already used 11.000 times
?


This list is about tagging issues. One can always use "any tag you 
like", but standardization and defining things is important.



But please do not write that one is better than the other at this
moment, nor  mark one as obsolete. Let the (whole) community decide.


The community is also this list.

--
"Probably it's an eternal problem - too many chiefs, too few Indians" [O. 
Muzalyev]


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

Re: [Tagging] shop=fashion shop=boutique

[Marc Gemis]

because other mappers thought it was needed to distinguish the two ?
Who are we (the people using this mailing list) to decide that other
mappers cannot tag a shop=boutique if it is already used 11.000 times
?
So if you want to tag that shop as shop=clothes with subtags fine, do
it. Document it, we'll see in a couple of years which one of the 2
methods is more popular.
But please do not write that one is better than the other at this
moment, nor  mark one as obsolete. Let the (whole) community decide.

and now we all go back to mapping :-)

m.

On Fri, Sep 1, 2017 at 12:48 PM, Jean-Marc Liotier  wrote:
> I still don't understand the need for anything other than shop=clothes
> used with assorted modifiers. Fashion is subjective and I do not see
> why exclusive distribution channels should be tagged differently as
> they are essentially clothes shop with no price tags and an attitude.
>
> shop=car covers both the average Volskwagen dealership and the workshop
> that sells handmade locally built overpriced exotics with golden urinal
> that you never heard of. Why should it be different for clothes ?
>
> ___
> 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] RFC: Defaults are paramount, abandoning Proposed_features/ is a HUGE mistake

[François Lacombe]

Hi Andre,

i wasn't aware of this proposal and read it right now.
It's a good explanation and pretty easy to understand

But question : Why do we need to put conditions to set a default values to
a collection of features ?
The only purpose is to activate the default on matching features only. Then
: simply don't add as member the mismatching ones :)

It sounds like a try to move part of a data consuming logic in the data
themselves. What if I need a different set of defaults ? Will I have to
create a second or third relation inside main OSM dataset ?

I don't agree to this sentence in the Why chapter : "It seems easier to
insert those metadata into the database in a special kind of relation.".
Your defaults are not necessarily mine.

All the best

François

2017-08-31 13:49 GMT+02:00 André Pirard :

> Hi,
>
> Examples: either each road is tagged with *maxspeed*=*
>  speed limit and
> *driving_side*=* 
> or there are defaults.
> I'm reviving this remark because the examples are numerous:
>
>- The Belgian Flemish community wants to tag *maxspeed*=*
> on every road
>instead of using a default. Is this a new specification and where is it
>written? Must that now be done in every country?
>- The current language= proposition wants to do it without defining
>defaults. Really? language= on every name= ?
>- Other examples are maxheight in tunnels. Osmose just accused me of
>someone else's omitting maxheight. It shouldn't be necessary if it's the
>default, that is if there is no sign for it, but Osmose likes to yell just
>in case.
>- countless etc.
>
> Please choose.
>
> Either the defaults are in the OSM database and it takes just a routinely
> map fetch to get them all updated timely,
> or each other router (GPS) writer implements them each their own way from
> various random other files. It's not well clear how contributors ca update
> all those files instead of OSM and it typically needs a full software
> update for each little default change, depending on writer's availability.
>
> Please choose.
>
> There is a Proposed_features/Defaults
>  that
> puts the defaults in OSM and it's an EXTREMELY HUGE mistake to have marked
> such a paramount good work as abandoned because nobody continued the work.
> For the sake of OSM, especially routing, please reopen it.
> I don't claim that it is the good solution but I do claim we should work
> on such a default database *in priority*.
>
> I didn't analyze it in full depth, but I have the following remarks:
> - Why not allow the def keyword in the border relation itself? But it
> could be called zzdef to cluster at the key end.
> - If a separate relation is preferred, it should be pointed at by a
> "defaults" role in the corresponding border or other relations so that it
> can be found.
> - to ease scanning a border tree upwards, a "parent" relation should exist
> in border relations.
>
> In hope of a well structured OSM,
>
> Cheers
>
> André.
>
>
>
> ___
> 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 shop=boutique

[Jean-Marc Liotier]

I still don't understand the need for anything other than shop=clothes
used with assorted modifiers. Fashion is subjective and I do not see
why exclusive distribution channels should be tagged differently as
they are essentially clothes shop with no price tags and an attitude.

shop=car covers both the average Volskwagen dealership and the workshop
that sells handmade locally built overpriced exotics with golden urinal
that you never heard of. Why should it be different for clothes ?

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

Re: [Tagging] shop=fashion shop=boutique

[Marc Gemis]

As for all the things I listed, the word "typical" was important, it
would certainly not require them all. Maybe some were not well chosen.
The idea was that is you see a shop that has a number of those
features, it is more likely to be a boutique

As for the linked with fashion houses, Isn't it possible that e.g.
Escada (*), Dior, YvesSaintLaureant have shops that exclusively sell
items from their brand ? Those shops will always be boutiques for me.

m.

(*) no, my nickname was not inspired by this brand. :-)

On Fri, Sep 1, 2017 at 10:36 AM, Martin Koppenhoefer
 wrote:
>
>
> 2017-09-01 7:58 GMT+02:00 Marc Gemis :
>>
>> Let's try to find some characteristics for boutique
>>
>> typically
>>
>> * has "boutique" somewhere on the window or logo (as Dave F wrote)
>
>
>
> wouldn't require this
>
>
>>
>> * smaller than shops from chains (limited collections)
>
>
>
> not sure this is a good criterion, would drop it
>
>
>>
>> * not part of a chain
>
>
>
> +1
>
>
>>
>> * only for women
>
>
>
> not sure either, surely there are many shops for men calling themselves
> "boutique"
>
>
>>
>> * sells only certain "expensive" brands
>
>
>
> might sell also "no brand" or "no common / well-known" brand.
>
>
>>
>> * no denim nor sports
>
>
>
> there are "exclusive" denim products you might find in a boutique, maybe
> true for sports though
>
>
>>
>> * side-line for other products (as Dave F also wrote)
>
>
>
> might be, not a requirement IMHO
>
>
>>
>> * might be linked with fashion houses
>
>
>
> What do you mean by "linked"? How I understand this, I'd rather say no.
>
>
>> * owner in the shop (?)
>
>
>
> Not a strict requirement, but more likely than in other clothing shops.
>
>
> * personnel/owner will advice you
>
>
> yes, but I'd expect this from any clothing shop save the cheapest clothing
> discounters
>
>
>
>>
>> * has no racks/bags with cheap stuff ("pick 3 for the price of 2")
>
>
>
> +1
>
>
>> * no racks outside the store
>>
>>
>
>
>
> +1, likely not
>
>
>
> Cheers,
> 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] shop=fashion

[Marc Gemis]

there are specialty shops that sell outfits for emergency services,
construction workers, kitchen personnel, etc (e.g.
http://www.belprotect.be/) Certainly not a shop where the average
family goes for an outfit :)

m.

On Fri, Sep 1, 2017 at 10:14 AM, Martin Koppenhoefer
 wrote:
>
>
> 2017-08-30 9:37 GMT+02:00 Simon Poole :
>>
>> Naturally in the end this doesn't actually answer my question as to what
>> the defining aspects of shop=fashion are :-).
>
>
>
> IMHO it indicates a shop selling very "fashionable"/trendy things.
> Naturally, most shops selling clothes will follow current trends (even
> second hand shops typically do), but some clothes are more timeless than
> others and some are so trendy that you likely would want to wear them in
> 5-10 years. I also agree with a previous comment, that a "boutique" is
> usually not a chain store (e.g. I wouldn't a an H, C, Orsay, GAP, Zara
> etc. a "boutique"), a fashion store might be.
>
> Brands (key brand) and prize section aside, I would like to be able to
> distinguish (sorry, not sure about English words, so am using German here):
> - Herrenausstatter / Bekleidungshaus / Damenausstatter (i.e. men, women,
> kids or all of a shop type which has everything from underwear to
> pants/trousers, socks, t-shirts, shirts, jackets/coats, but isn't a
> department store because it is specialized in clothes).
> - a shirts shop (shirts and ties)
> - underwear / pyjamas (only)
> - chain retailers like the above mentioned
> - boutiques (small individual shops, usually specialized for either men or
> women, usually higher quality at higher prices)
>
> and maybe some more (e.g. jeans shop, sports shop, outdoor clothing, ...).
>
> Cheers,
> 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] shop=fashion shop=boutique

[Martin Koppenhoefer]

2017-09-01 7:58 GMT+02:00 Marc Gemis :

> Let's try to find some characteristics for boutique
>
> typically
>
> * has "boutique" somewhere on the window or logo (as Dave F wrote)
>


wouldn't require this



> * smaller than shops from chains (limited collections)
>


not sure this is a good criterion, would drop it



> * not part of a chain
>


+1



> * only for women
>


not sure either, surely there are many shops for men calling themselves
"boutique"



> * sells only certain "expensive" brands
>


might sell also "no brand" or "no common / well-known" brand.



> * no denim nor sports
>


there are "exclusive" denim products you might find in a boutique, maybe
true for sports though



> * side-line for other products (as Dave F also wrote)
>


might be, not a requirement IMHO



> * might be linked with fashion houses
>


What do you mean by "linked"? How I understand this, I'd rather say no.


* owner in the shop (?)
>


Not a strict requirement, but more likely than in other clothing shops.


* personnel/owner will advice you


yes, but I'd expect this from any clothing shop save the cheapest clothing
discounters




> * has no racks/bags with cheap stuff ("pick 3 for the price of 2")
>


+1


* no racks outside the store
>
>
>


+1, likely not



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

Re: [Tagging] shop=fashion shop=boutique

[Martin Koppenhoefer]

2017-08-31 15:30 GMT+02:00 Daniel Koć :

> Important questions to decide:
>
>> - Can a boutique sell second hand items - or just the new ones?
>>
>

IMHO they wouldn't typically sell second hand items, on the other hand,
second hand is a property in OSM and can be added to everything




> - What about "hand made" - is it the core property of boutique or just an
>> option?
>>
>

Aren't all clothes "hand made"? Nowadays typically in countries with low
wages and weak labor unions.



> We should also answer these questions:
> - is every boutique an outlet or is it not required?
>


Following this definition: "a brick and mortar or online store in which
manufacturers sell their stock directly to the public, cutting out the
middle-men." I'd say that not every boutique is an outlet.



> - if there are no accesories, just elegant clothes, is it still boutique
> or just a shop=clothes?
>


IMHO a "boutique" doesn't have to sell accessories.



> - do we need the outlet=* tag?
>
>

I'd see it as an additional property and would keep it.

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

Re: [Tagging] shop=fashion

[Martin Koppenhoefer]

2017-08-30 9:37 GMT+02:00 Simon Poole :

> Naturally in the end this doesn't actually answer my question as to what
> the defining aspects of shop=fashion are :-).
>


IMHO it indicates a shop selling very "fashionable"/trendy things.
Naturally, most shops selling clothes will follow current trends (even
second hand shops typically do), but some clothes are more timeless than
others and some are so trendy that you likely would want to wear them in
5-10 years. I also agree with a previous comment, that a "boutique" is
usually not a chain store (e.g. I wouldn't a an H, C, Orsay, GAP, Zara
etc. a "boutique"), a fashion store might be.

Brands (key brand) and prize section aside, I would like to be able to
distinguish (sorry, not sure about English words, so am using German here):
- Herrenausstatter / Bekleidungshaus / Damenausstatter (i.e. men, women,
kids or all of a shop type which has everything from underwear to
pants/trousers, socks, t-shirts, shirts, jackets/coats, but isn't a
department store because it is specialized in clothes).
- a shirts shop (shirts and ties)
- underwear / pyjamas (only)
- chain retailers like the above mentioned
- boutiques (small individual shops, usually specialized for either men or
women, usually higher quality at higher prices)

and maybe some more (e.g. jeans shop, sports shop, outdoor clothing, ...).

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

Re: [Tagging] shop=fashion

[Martin Koppenhoefer]

2017-08-30 5:17 GMT+02:00 Marc Gemis :

> >>
> >> Especially if it's a man tagging women's clothing stores! :-)
> >>
> >> From these comments, I would agree with dropping both =boutique &
> >> =fashion,...
> Furthermore I find that non-experts should not discuss dropping a tag.
> What's the problem having 3 different tags ?



+1, IMHO writing that you don't think you know enough about the topic and
in the next sentence advocate "dropping tags" from this very domain doesn't
make sense. Also there aren't definitions that restrict those shops to
women's clothes.

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

Re: [Tagging] shop=fashion shop=boutique

[Marc Gemis]

Let's try to find some characteristics for boutique

typically

* has "boutique" somewhere on the window or logo (as Dave F wrote)
* smaller than shops from chains (limited collections)
* not part of a chain
* only for women
* sells only certain "expensive" brands
* no denim nor sports
* side-line for other products (as Dave F also wrote)
* might be linked with fashion houses
* owner in the shop (?)
* personnel/owner will advice you
* has no racks/bags with cheap stuff ("pick 3 for the price of 2")
* no racks outside the store


these are just some characteristics that we could look at.


On Thu, Aug 31, 2017 at 2:44 PM, Daniel Koć  wrote:
> W dniu 31.08.2017 o 14:07, marc marc pisze:
>
>> for shop=boutique, I think you are wrong.
>> A shop=boutique (except from the translation+wiki being corrected)
>> is something totally different from a shop=clothes.
>> You can define the additional tags needed to have a shop=boutique
>> (handmade, high range), but even so, in my opinion it is not
>> enough to move all shop=boutique to shop=clothes.
>> I think that shop=boutique must continue to exist
>
>
> OK, it's possible, but _how_ is it different then? How can we tune/replace
> the current definition to make it easier to recognize, because we have some
> problems with showing the difference:
>
> "small shopping outlet, especially one that specializes in elite and
> fashionable items like clothing and accessories."
>
> Important questions to decide:
> - Can a boutique sell second hand items - or just the new ones?
> - What about "hand made" - is it the core property of boutique or just an
> option?
> - What other hints would be useful for a mapper?
>
> --
> "Probably it's an eternal problem - too many chiefs, too few Indians" [O.
> Muzalyev]
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging

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