Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[European Water Project]

Dear Joseph,

A couple of questions as the use of a clean namespace will all data
segregated seems appealing :

1. If refugee_site were added to the local polygon_keys object you
mentioned, how long would it take for the effects of this updated object to
propagate  ? A couple of weeks, months ? Finding a durable long-term clean
solution should be the goal.

2. Assuming a couple of days delay for display of a refugee site is
acceptable for this use case, do you still have objections to this proposal
?

3. How about a non-KISS suboptimal tagging with a bit of reduncancy using
amenity = refugee_site plus the full namespace ?

for example :
amenity=refugee_site
refugee_site = yes
refugee_site:for = internally_displaced/refugee_only/mixed
refugee_site:operator = UNHCR/Red Cross/etc.
refugee_site:duration = permanent/temporary
refugee_site:population = 500,000
refugee_site:structure=shelters/tents/multifunctional/mixed
refugee_site:status=formal/informal



Best regards,

Stuart




On Sat, 4 Apr 2020 at 02:48, Joseph Eisenberg 
wrote:

> Thank you for being willing to work on this and listen to suggestions
> from the community.
>
> I agree that, under the current, very broad definition of
> "amenity=social_facility", a single building which is used as a
> shelter for refugees could be tagged as "amenity=social_facility", but
> a large camp would not be appropriate, nor would a huge, permanent
> area with many buildings which has all the characteristics of a
> village or town.
>
> The problem with just using "refugee_site=*" as the main tag is if it
> is used for mapping areas, because in this case database users would
> have to add special handling just for this key. Instead, it would be
> better to use "amenity=refugee_site" or "landuse=refugee_site" or
> "man_made=refugree_site", "emergency=refugee_site", or any other
> standard "key" which is already used for area features.
>
> Explanation:
>
> There is no native "area" object in the Openstreetmap database.
> Instead, to map areas we make a way (a line) which loops back to the
> first node. This called a "closed way", and it could represent a line
> (for example, a barrier=fence which loops around a field, or a
> highway=raceway which is a loop), or also an area.
>
> To distinguish between these two options for what a closed way can
> mean, database users have to look at the tags on the feature, and
> guess if it is meant to be an area or a line.
>
> For example, the iD editor on openstreetmap.org has a list of keys
> which are considered to be areas:
> https://github.com/osmlab/id-area-keys/blob/master/areaKeys.json
> (documented at https://github.com/osmlab/id-area-keys)
>
> This includes "amenity=*", "landuse=*", "place=*", "man_made=",
> "emergency=", "healthcare=" and many others, but of course it doesn't
> include "refugee_site=" since this key does not yet exist.
>
> Openstreetmap Carto, the style used to render the Standard map layer
> on openstreetmap.org, also has a list of keys and tags which represent
> areas:
> https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.lua
>
> "Objects with any of the following keys will be treated as polygon
> " local polygon_keys = {
> ...
> 'amenity',
> ...
> 'club',
> ...
> 'emergency',
> ...
> 'healthcare',
> ...
> 'landuse',
> ...
> 'man_made',
> etc.
>
> Also, relations with type=multipolygon and type=boundary are considered
> areas.
>
> To render a map of the whole planet, every closed way with one of
> these tags is imported into a special rendering database.
>
> If you want to add a new key to this list, all of the rendering
> servers have to reload the database. This process takes all day, so
> the servers are not reloaded very often.
>
> So, if you propose mapping refugee sites as areas and not only as
> nodes, they should use one of these common area feature keys, that
> database users will be able to start showing these features sooner and
> more easily.
>
> It would also be possible to map them as a boundary relation, but that
> only works for areas, not nodes, and I believe the proposal suggests,
> appropriately, that a node should be used when the boundaries of the
> area are not clearly defined
>
> (My preference would be for amenity=refugee_site, to fit with
> amenity=social_facility and similar area features. The key "amenity"
> is used for a very wide variety of features, and it's the best option
> for an area feature that does not fit into a more specific category.)
>
> -- Joseph Eisenberg
>
> On 4/4/20, European Water Project  wrote:
> > Dear Manon,
> >
> > This new proposal is a big improvement over the previous proposal and
> > properly addresses the many objections to place=refugee_site.
> >
> > A flexible namespace with segregated data related to refugee sites will
> > allow ongoing refugee site data maintenance by facilitating operator
> source
> > data comparison in addition to easy refugee site data extraction
> (objective
> > #3).
> 

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Snusmumriken]

On Fri, 2020-04-03 at 20:53 +0200, Florimond Berthoux wrote:
> For this one https://www.youtube.com/watch?v=B7wbi4wGbsg (Andrew's
> example)
> We're on the edge of tags definition : this a path limited cyclist,
> where a mountain bike almost mandatory to ride there. Some features
> help the cyclist.
> 
> I would tag may be that with :
> higway=path
> access=no
> bicycle=yes
> mtb=designated
> mtb:scale=2

For a path like that I wouldn't add bicycle=yes, because I think that
it implies that an average person on an average bike could use it. 


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

Re: [Tagging] Feature Proposal - RFC - Refugee Site Location

[Joseph Eisenberg]

> If refugee_site were added to the local polygon_keys object you mentioned, 
> how long would it take for the effects of this updated object to propagate?

Now that I've re-read the full text of the new proposal, it looks like
the author is intending refugee_site=* to be added to a feature which
is also tagged with place=* or landuse=*, so that won't actually be a
problem in that case.

It's only an issue if there is no other main feature tag used on the
area. If this tag was only going to be used on place= nodes, that's
also not a problem.

But if used as the only main tag on a feature, map renderers which use
osm2pgsql or similar tools will need to reload their rendering
databases. This only happens about once a year for the servers that
render the standard style on openstreetmap.org, so I would expect at
least 2 years before you could imagine seeing this rendered, assuming
that it becomes quite popular in the next year.

Other map styles could be updated sooner, if they are specialized.

But I think it is better to use a main top-level key.

-- Joseph

On 4/4/20, European Water Project  wrote:
> Dear Joseph,
>
> A couple of questions as the use of a clean namespace will all data
> segregated seems appealing :
>
> 1. If refugee_site were added to the local polygon_keys object you
> mentioned, how long would it take for the effects of this updated object to
> propagate  ? A couple of weeks, months ? Finding a durable long-term clean
> solution should be the goal.
>
> 2. Assuming a couple of days delay for display of a refugee site is
> acceptable for this use case, do you still have objections to this proposal
> ?
>
> 3. How about a non-KISS suboptimal tagging with a bit of reduncancy using
> amenity = refugee_site plus the full namespace ?
>
> for example :
> amenity=refugee_site
> refugee_site = yes
> refugee_site:for = internally_displaced/refugee_only/mixed
> refugee_site:operator = UNHCR/Red Cross/etc.
> refugee_site:duration = permanent/temporary
> refugee_site:population = 500,000
> refugee_site:structure=shelters/tents/multifunctional/mixed
> refugee_site:status=formal/informal
>
>
>
> Best regards,
>
> Stuart
>
>
>
>
> On Sat, 4 Apr 2020 at 02:48, Joseph Eisenberg 
> wrote:
>
>> Thank you for being willing to work on this and listen to suggestions
>> from the community.
>>
>> I agree that, under the current, very broad definition of
>> "amenity=social_facility", a single building which is used as a
>> shelter for refugees could be tagged as "amenity=social_facility", but
>> a large camp would not be appropriate, nor would a huge, permanent
>> area with many buildings which has all the characteristics of a
>> village or town.
>>
>> The problem with just using "refugee_site=*" as the main tag is if it
>> is used for mapping areas, because in this case database users would
>> have to add special handling just for this key. Instead, it would be
>> better to use "amenity=refugee_site" or "landuse=refugee_site" or
>> "man_made=refugree_site", "emergency=refugee_site", or any other
>> standard "key" which is already used for area features.
>>
>> Explanation:
>>
>> There is no native "area" object in the Openstreetmap database.
>> Instead, to map areas we make a way (a line) which loops back to the
>> first node. This called a "closed way", and it could represent a line
>> (for example, a barrier=fence which loops around a field, or a
>> highway=raceway which is a loop), or also an area.
>>
>> To distinguish between these two options for what a closed way can
>> mean, database users have to look at the tags on the feature, and
>> guess if it is meant to be an area or a line.
>>
>> For example, the iD editor on openstreetmap.org has a list of keys
>> which are considered to be areas:
>> https://github.com/osmlab/id-area-keys/blob/master/areaKeys.json
>> (documented at https://github.com/osmlab/id-area-keys)
>>
>> This includes "amenity=*", "landuse=*", "place=*", "man_made=",
>> "emergency=", "healthcare=" and many others, but of course it doesn't
>> include "refugee_site=" since this key does not yet exist.
>>
>> Openstreetmap Carto, the style used to render the Standard map layer
>> on openstreetmap.org, also has a list of keys and tags which represent
>> areas:
>> https://github.com/gravitystorm/openstreetmap-carto/blob/master/openstreetmap-carto.lua
>>
>> "Objects with any of the following keys will be treated as polygon
>> " local polygon_keys = {
>> ...
>> 'amenity',
>> ...
>> 'club',
>> ...
>> 'emergency',
>> ...
>> 'healthcare',
>> ...
>> 'landuse',
>> ...
>> 'man_made',
>> etc.
>>
>> Also, relations with type=multipolygon and type=boundary are considered
>> areas.
>>
>> To render a map of the whole planet, every closed way with one of
>> these tags is imported into a special rendering database.
>>
>> If you want to add a new key to this list, all of the rendering
>> servers have to reload the database. This process takes all day, so
>> the servers are not reloaded very of

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Florimond Berthoux]

Le sam. 4 avr. 2020 à 10:18, Snusmumriken 
a écrit :

> On Fri, 2020-04-03 at 20:53 +0200, Florimond Berthoux wrote:
> > For this one https://www.youtube.com/watch?v=B7wbi4wGbsg (Andrew's
> > example)
> > We're on the edge of tags definition : this a path limited cyclist,
> > where a mountain bike almost mandatory to ride there. Some features
> > help the cyclist.
> >
> > I would tag may be that with :
> > higway=path
> > access=no
> > bicycle=yes
> > mtb=designated
> > mtb:scale=2
>
> For a path like that I wouldn't add bicycle=yes, because I think that
> it implies that an average person on an average bike could use it.
>

bicycle=yes is an access tag it says only that cyclist has a legal right to
ride there.
«Key:bicycle  Legal restriction for bicycles. »
https://wiki.openstreetmap.org/wiki/Key:bicycle
It doesn't say anything about it difficulties, that the job of mtb:scale
key.

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Marc M.]

Le 04.04.20 à 11:26, Florimond Berthoux a écrit :
> 
> Le sam. 4 avr. 2020 à 10:18, Snusmumriken a écrit :
> 
> On Fri, 2020-04-03 at 20:53 +0200, Florimond Berthoux wrote:
> > For this one https://www.youtube.com/watch?v=B7wbi4wGbsg (Andrew's
> > example)
> > We're on the edge of tags definition : this a path limited cyclist,
> > where a mountain bike almost mandatory to ride there. Some features
> > help the cyclist.
> 
> bicycle=yes is an access tag

+1
without a traffic sign related to access (I can't read the pannel),
I only use
higway=path
mtb:scale=2
incline=yes
mtb=designated <- if the pannel is related to mtb

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Morten Lange via Tagging]

On Saturday, 4 April 2020, 11:55:01 CEST, Marc M. 
 wrote:  
 
 > Le 04.04.20 à 11:26, Florimond Berthoux a écrit :
> > 
> > Le sam. 4 avr. 2020 à 10:18, Snusmumriken a écrit :
> > 
> >    On Fri, 2020-04-03 at 20:53 +0200, Florimond Berthoux wrote:
> >    > For this one https://www.youtube.com/watch?v=B7wbi4wGbsg (Andrew's
> >    > example)
> >    > We're on the edge of tags definition : this a path limited cyclist,
> >    > where a mountain bike almost mandatory to ride there. Some features
> >    > help the cyclist.
> > 
> > bicycle=yes is an access tag
> 
> +1

-1

1. Although the sentence about it being an access tag, is technically true, 
whar is meant is a primarily a normal bicycle, not sports equipment.  
 bicycle=yes is much more widely used, and various tools and users will expect 
that to pertain to transportation and touring, not extreme-sports (in some 
sense) or adventure.
In addition I would say that a small grain adding weight to the argument of 
viewing this from the viewpoint of "normal utility cycling"  is that normal 
cycling for transport is more important for the greater good. Everyday or 
utility ccyling is more important for  for public health, for the environment 
and supports a majority of the 17  UN Sustainable Development Goals 
https://sustainabledevelopment.un.org/sdg17

(And incidentally cycling for transport is widely regarded as being a valuable 
tool now during the Covid-19 crisis , when people are advised not to use public 
transport. (And to not travel far) ). 


2. As has been said several times previously, the main tags should convey 
consistent, predictable information.
mtb:scale is a speciality / niche tag.  Those that want to find information 
about sports tracks / routes will be able to use that alone. mtb:scale implies 
bicycle=yes (but in practice only for special bikes and/or skills )   

Best Regards,Morten Lange
> without a traffic sign related to access (I can't read the pannel),
> I only use
> higway=path
> mtb:scale=2
> incline=yes
> mtb=designated <- if the pannel is related to mtb> 






-- Regards / Kveðja / Salaam za dhati / Hilsen Morten Lange



___
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 - Refugee Site Location

[European Water Project]

Hi Joseph,

Yes, agree that given the above constraints it makes sense to use this
namespace as an attachment to a node or an area which has a main top-level
key already included in the local polygon keys object.What is the
process for requesting to have a new key added to the local polygon_keys
object ?

I now have another question, not directly related to this thread.

How are nodes which have multiple top level keys contained in the local
polygon_keys object rendered ? Does each map renderer choose a preference
order if a node has more than one top-level key ? For example, if a node
has amenity = , harbour = Y, and waterway = Z ?

Best regards,

Stuart



On Sat, 4 Apr 2020 at 11:16, Joseph Eisenberg 
wrote:

> > If refugee_site were added to the local polygon_keys object you
> mentioned, how long would it take for the effects of this updated object to
> propagate?
>
> Now that I've re-read the full text of the new proposal, it looks like
> the author is intending refugee_site=* to be added to a feature which
> is also tagged with place=* or landuse=*, so that won't actually be a
> problem in that case.
>
> It's only an issue if there is no other main feature tag used on the
> area. If this tag was only going to be used on place= nodes, that's
> also not a problem.
>
> But if used as the only main tag on a feature, map renderers which use
> osm2pgsql or similar tools will need to reload their rendering
> databases. This only happens about once a year for the servers that
> render the standard style on openstreetmap.org, so I would expect at
> least 2 years before you could imagine seeing this rendered, assuming
> that it becomes quite popular in the next year.
>
> Other map styles could be updated sooner, if they are specialized.
>
> But I think it is better to use a main top-level key.
>
> -- Joseph
>
> On 4/4/20, European Water Project  wrote:
> > Dear Joseph,
> >
> > A couple of questions as the use of a clean namespace will all data
> > segregated seems appealing :
> >
> > 1. If refugee_site were added to the local polygon_keys object you
> > mentioned, how long would it take for the effects of this updated object
> to
> > propagate  ? A couple of weeks, months ? Finding a durable long-term
> clean
> > solution should be the goal.
> >
> > 2. Assuming a couple of days delay for display of a refugee site is
> > acceptable for this use case, do you still have objections to this
> proposal
> > ?
> >
> > 3. How about a non-KISS suboptimal tagging with a bit of reduncancy using
> > amenity = refugee_site plus the full namespace ?
> >
> > for example :
> > amenity=refugee_site
> > refugee_site = yes
> > refugee_site:for = internally_displaced/refugee_only/mixed
> > refugee_site:operator = UNHCR/Red Cross/etc.
> > refugee_site:duration = permanent/temporary
> > refugee_site:population = 500,000
> > refugee_site:structure=shelters/tents/multifunctional/mixed
> > refugee_site:status=formal/informal
> >
> >
> >
> > Best regards,
> >
> > Stuart
> >
> >
> >
> >
> > On Sat, 4 Apr 2020 at 02:48, Joseph Eisenberg <
> joseph.eisenb...@gmail.com>
> > wrote:
> >
> >> Thank you for being willing to work on this and listen to suggestions
> >> from the community.
> >>
> >> I agree that, under the current, very broad definition of
> >> "amenity=social_facility", a single building which is used as a
> >> shelter for refugees could be tagged as "amenity=social_facility", but
> >> a large camp would not be appropriate, nor would a huge, permanent
> >> area with many buildings which has all the characteristics of a
> >> village or town.
> >>
> >> The problem with just using "refugee_site=*" as the main tag is if it
> >> is used for mapping areas, because in this case database users would
> >> have to add special handling just for this key. Instead, it would be
> >> better to use "amenity=refugee_site" or "landuse=refugee_site" or
> >> "man_made=refugree_site", "emergency=refugee_site", or any other
> >> standard "key" which is already used for area features.
> >>
> >> Explanation:
> >>
> >> There is no native "area" object in the Openstreetmap database.
> >> Instead, to map areas we make a way (a line) which loops back to the
> >> first node. This called a "closed way", and it could represent a line
> >> (for example, a barrier=fence which loops around a field, or a
> >> highway=raceway which is a loop), or also an area.
> >>
> >> To distinguish between these two options for what a closed way can
> >> mean, database users have to look at the tags on the feature, and
> >> guess if it is meant to be an area or a line.
> >>
> >> For example, the iD editor on openstreetmap.org has a list of keys
> >> which are considered to be areas:
> >> https://github.com/osmlab/id-area-keys/blob/master/areaKeys.json
> >> (documented at https://github.com/osmlab/id-area-keys)
> >>
> >> This includes "amenity=*", "landuse=*", "place=*", "man_made=",
> >> "emergency=", "healthcare=" and many others, but of course it doesn't
> >> i

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Kevin Kenny]

On Sat, Apr 4, 2020 at 5:28 AM Florimond Berthoux
 wrote:
> bicycle=yes is an access tag it says only that cyclist has a legal right to 
> ride there.
> «Key:bicycle  Legal restriction for bicycles. » 
> https://wiki.openstreetmap.org/wiki/Key:bicycle
> It doesn't say anything about it difficulties, that the job of mtb:scale key.

The key issue with that approach: how does a mapper who isn't expert
enough to grade accurately the difficulty of a MTB trail, but can
clearly see, 'a road bike wouldn't work here', tag the thing
appropriately?  Simple 'highway=path foot=yes bicycle=yes' invites
routing disasters. I can, and do, add 'surface=ground
smoothness=horrible', but is that enough? How many tags must a router
take into consideration before deciding that a cycleway is actually
usable?

-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Volker Schmidt]

> The key issue with that approach: how does a mapper who isn't expert
> enough to grade accurately the difficulty of a MTB trail, but can
> clearly see, 'a road bike wouldn't work here', tag the thing
> appropriately?  Simple 'highway=path foot=yes bicycle=yes' invites
> routing disasters. I can, and do, add 'surface=ground
> smoothness=horrible', but is that enough? How many tags must a router
> take into consideration before deciding that a cycleway is actually
> usable?
>

This is not the correct tagging anyway for a (countryside or mountain)
path, at least for those countries where the default access for
highway=path implies bicycle=yes and horse=yes (legal access!).
And: the router should ignore the bicycle=yes tag on a highway=path.
highway=path on its own does not imply any indication about the suitability
for using it on foot, on bicycle, or on horse.
The suitability can be indicated by a variety of tags:
surface; smoothness; sac:scale; mtb:scale; incline; width; trail_visibility
(leaving aside the special cases of bicycle|foot=designated|official which
are, unfortunately, an established way of tagging mixed foot-cycle paths in
general)
The mapper should insert those tags that she can assess on the ground or
from other available sources.
It is these tags that a trekking bicycle router should assess:
it should put a severe penalty on highpath=path without any additional
tagging, or with bad surface, or with steep incline, or with mtb:scale>0,
or with poor trail_visibility.
it should assign a very low penalty to a highway=path with
bicycle=designated, or to highway=cycleway
(most likely my tag examples are not complete, but this illustrates the
concept)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Martin Koppenhoefer]

Am Sa., 4. Apr. 2020 um 13:21 Uhr schrieb Morten Lange via Tagging <
tagging@openstreetmap.org>:

> > >> We're on the edge of tags definition : this a path limited
> cyclist,
> > >> where a mountain bike almost mandatory to ride there. Some
> features
> > >> help the cyclist.
> > >
> > > bicycle=yes is an access tag
> >
> > +1
>
> -1
>
>
> 1. Although the sentence about it being an access tag, is technically
> true, whar is meant is a primarily a normal bicycle, not sports equipment.
>
>  bicycle=yes is much more widely used, and various tools and users will
> expect that to pertain to transportation and touring, not extreme-sports
> (in some sense) or adventure.
>
>

it doesn't change that bicycle=yes is an access tag, it is about legal
accessibility. It is up to your local government to decide to whom bicycle
access tags apply.

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Marc M.]

Le 04.04.20 à 15:47, Kevin Kenny a écrit :
> how does a mapper who isn't expert enough to grade accurately
> the difficulty of a MTB trail, but can
> clearly see, 'a road bike wouldn't work here'

it's very subjective
an example of a situation that was not well described with
surface/inclined/... tags ?

you may use =yes as default value when you don't use a more precise
value -> mtb:scale=yes ?

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

Re: [Tagging] Can highway=cycleway be limited to MTB?

[Volker Schmidt]

mtb:scale is not mandatory.
If you are not familiar with the MTB scale don't put it. Put what you see:
surface; smoothness; width; visibility ; ...


Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sat, 4 Apr 2020 at 23:57, Marc M.  wrote:

> Le 04.04.20 à 15:47, Kevin Kenny a écrit :
> > how does a mapper who isn't expert enough to grade accurately
> > the difficulty of a MTB trail, but can
> > clearly see, 'a road bike wouldn't work here'
>
> it's very subjective
> an example of a situation that was not well described with
> surface/inclined/... tags ?
>
> you may use =yes as default value when you don't use a more precise
> value -> mtb:scale=yes ?
>
> ___
> 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] Can highway=cycleway be limited to MTB?

[Marc M.]

building=* is also not mandatory,
that doesn't prevent a lot of ppl to use building=yes :)

any better idea to solve Kevin's question?

Le 05.04.20 à 00:13, Volker Schmidt a écrit :
> mtb:scale is not mandatory.
> If you are not familiar with the MTB scale don't put it. Put what you
> see: surface; smoothness; width; visibility ; ...
> 
> 
> On Sat, 4 Apr 2020 at 23:57, Marc M. wrote:
> 
> Le 04.04.20 à 15:47, Kevin Kenny a écrit :
> > how does a mapper who isn't expert enough to grade accurately
> > the difficulty of a MTB trail, but can
> > clearly see, 'a road bike wouldn't work here'
> 
> it's very subjective
> an example of a situation that was not well described with
> surface/inclined/... tags ?
> 
> you may use =yes as default value when you don't use a more precise
> value -> mtb:scale=yes ?
> 
> ___
> 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] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Joseph Eisenberg]

Kevin,

Would you have time to move this proposal forward?

I've been looking at the protected_area classes, and there are several
that are confusing and overlap with other features, especially
protected_class = 7, 19, 21, 29, 97, 98, 99.

And several are duplicates of more common tags:

boundary=national_park (de facto) for protect_class=2

boundary=aboriginal_lands (approved) for protect_class=24

landuse=military + military= for protect_class=25

I like the way your proposal has suggested changing these all to more
memorable and intelligible words as values of "protection_class=",
like "protection_class=recreation" instead of "21"

-- Joseph Eisenberg

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