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

[Jonathon Rossi]

On Sun, Apr 5, 2020 at 5:49 PM Andrew Harvey 
wrote:

> [...]
>

> bicycle= as an access tag should refer to any class of bicycles by
> default. Today I was walking a track which had a no bicycles sign, meaning
> all types of bikes are disallowed. Conversely bicycle=yes just means that
> bicycles are legally/physically allowed, it does not indicate suitability
> by a specific type of bicycle. I don't think I've ever seen signage which
> says no mountain bikes but you can use a road bike, or vice versa. If there
> is then we should use sub bicycle access tags like road_bike=, mtb=, bmx=
> etc. You could have a path which is clearly a mountain bike track but
> officially bicycles are not allowed. So based on this we can't use these
> kinds of access tags to define the type of path they must be kept
> independent.
>

Agreed, land managers don't define different access by type of bicycle,
because at the end of the day what is a MTB, I had a MTB without suspension
when I was a kid so it's not suspension, a MTB is just an advertised
bicycle with heaps of features which has continued to change heaps in the
last 15 years with technology, even today the range of features and price
is amazing; eMTB is another category that is different per region/country
whether land managers treat them as a bicycle or motorbike based on their
power output.

In my experience of riders I've met, the trails you can successfully ride
are much more determined by your skills and ability than the bicycle you
are on.

Not all mountain bike tracks are mtb=designated. Many paths are built for
> and used mostly by mountain bikes, key giveaways are jumps, corner banks
> and other technical features, but not officially signposted or marked for
> use by mountain bikes. Conversely the track could be signposted for use by
> mountain bikes but not actually be a mountain bike track, eg. it could be
> highway=track which is not a mountain bike track, but indicated as a way
> for use by mountain bikes so mtb=designated.
>
> So I'm proposing the access tags bicycle= refer to any/all bicycles. mtb=
> become an access tag (mtb=designated for signposted mountain bike).
> path=mtb become a tag to say the path on the ground here is designed=mostly
> used for mountain biking.
>

Around here 5 years ago there were few MTB trails actually signposted, they
had existed for many years but only as the parks got more use had land
managers spent money to signpost the trails. When would I use
mtb=designated when land managers just signpost for
bicycle=yes,foot=yes,horse=no?

I feel this is better than a new highway=singletrack tag since renderers,
> routers, etc can still interpret the path without making changes. If we
> move to a new tag, these tracks will disappear from routers and maps
> overnight.
>

Agreed, it wouldn't just disappear from renderers but it breaks the long
time documented scheme. My suggestion was playing devil's advocate because
I am still not sure what we can't do with the current tags.

All other tags like surface, smoothness, mtb:scale, route=mtb still apply.
> leisure=track would still apply to short loop tracks like a BMX pump track
> or a velodrome, but not to longer A to B tracks.
>
> Thoughts? I can help work on the wiki proposal for these tag changes (mtb=
> as an access tag and path=mtb) but keen to hear feedback here first.
>

*Summary:*
- When would/could I use the proposed mtb= access tag if land managers only
define bicycle=, and what is a MTB (as mentioned above)?
- Your proposed path=mtb would be a specialisation of highway=path (like
service=parking_aisle) which seems odd and against highway=path being a
non-specific path? Objectively how would I know what is a MTB path, many
signposted IMBA green trails don't have berms and rollovers? What does this
tag provide that just adding mtb:scale=* doesn't already? I think general
purpose routers should ignore highway=path if they don't want to understand
path grading, the same can be said for highway=track. Personally I've only
added mtb:scale:imba=* here from signposted trails, just never thought
adding mtb:scale=* was helping anyone so didn't put in the effort, but
could now.

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Kevin Kenny]

Does the current version look any better?  Obviously, once we're
seriously stitching things into the Wiki, we'll need to make
individual pages with titles like 'Key:protection_class=recreation',
but of course it's easier to have it all in one place for now.


On Sun, Apr 5, 2020 at 7:24 PM Joseph Eisenberg
 wrote:
>
> The only thing that the proposal page still needs is a couple more
> detailed definitions for some of the tags.
>
> The ones based on IUCN levels already have a fairly good description.
>
> But protection_class=recreation should be clarified - what exactly is
> protected here, and what sort of recreation are we talking about? It
> should be clear how this is different than a leisure=recreation_ground
> or sports_centre or =park.
>
> The tags protection_class=water, protection_class=culture,  and
> protection_class=hazard might need slightly improved definitions too.
>
> Besides that, everything looks pretty good.
>
> -- Joseph Eisenberg
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



-- 
73 de ke9tv/2, Kevin

___
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]

The only thing that the proposal page still needs is a couple more
detailed definitions for some of the tags.

The ones based on IUCN levels already have a fairly good description.

But protection_class=recreation should be clarified - what exactly is
protected here, and what sort of recreation are we talking about? It
should be clear how this is different than a leisure=recreation_ground
or sports_centre or =park.

The tags protection_class=water, protection_class=culture,  and
protection_class=hazard might need slightly improved definitions too.

Besides that, everything looks pretty good.

-- Joseph Eisenberg

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

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[François Lacombe]

Hi,

+1 with Joseph, proposed values are more usable than digits.

Le dim. 5 avr. 2020 à 20:02, Kevin Kenny  a écrit :

> I'm a little intimidated by the process, particularly the
> administration of the vote (Who's a qualified elector? Who can serve
> as scrutineer?) and the need to stitch the result into the Wiki.  Some
> of what's needed for the latter seems to require knowledge of the
> Wiki's templating conventions, which appear to be obscurely documented
> at best, and with which I'm unfamiliar. (Also, it brings up unpleasant
> memories. I've burnt my fingers on Wikipedia in the past.)
>

No problem : voting is a pretty simple phase :
Open the vote, announce it on mailing list (here), wait 15 days to have
some opinions and close it
Any wiki user can vote, cons vote should come with a little explanations.
If you get at least 74% of pros (without counting abstain as cons), the
proposal is adopted and cleanup can begin. Anyone can help you to move what
is proposed in tagging pages.
It is recommended to prepare this cleanup with a section like this one,
showing affected pages and replaced keys (if applicable) :
https://wiki.openstreetmap.org/wiki/Proposed_features/Lines_management#Edition_management

We are here to help if needed, keep going !

All the best

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

Re: [Tagging] Feature Proposal - RFC - Urgent Care

[Paul Allen]

On Sun, 5 Apr 2020 at 20:17, Andy Townsend  wrote:

> On 05/04/2020 16:36, Joseph Eisenberg wrote:
> > Can someone confirm if "urgent_care" makes sense in British English,
> > rather than "walk-in" or something else?
> >
> I'm English, and I would not know what "urgent_care" meant. After
> reading the wiki page, it is unclear whether refers to designated
> walk-in centres, or the "accident" end of "accident and emergency", or
> any other healthcare providers that offer non-appointment access?
>
> "Urgent care" wasn't a term familiar to me, but I can make a guess based on
my experiences with the NHS.

There is emergency care for people who have had a heart attack or an
accident
with a chainsaw or whatever: call an ambulance to take you to A  A doctor
can't sew your hand back on.

There are minor injuries units.  They can't handle anything like the full
range
of problems that an A can.  But they can deal with things your doctor
can't
and that need fairly immediate treatment.  Deep cut that needs sewing or
superglueing shut (been there, done that, tried my local doctor first and
was
told by the receptionist to go to the minor injuries unit).  Stuff like
that.  You
can't wait a couple of days for an appointment but you don't need the full
A
treatment.  I'd class those as urgent care.  Not only do you not need an
appointment,
they don't have an appointments system (that I'm aware of).

Then there are doctors.  Usually they require appointments.  They'll handle
walk-ins that meet certain criteria for urgency, because of the Hippocratic
Oath
thing.  Been there, done that, too.  More than once.  With the doctor's
blessing:
any time I'm in that condition, walk in.  Sometimes they decide all they
can do
is stabilize you (or try to slow down the rate at which you're
deteriorating) while
an ambulance shows up to take you to A (been there, done that, a couple
of months ago, had 12 days in hospital).

That said, I'd be reluctant to tag any doctors' surgery as providing urgent
care:
it's something they do but they don't want people turning up with minor
injuries,
let alone those in need of emergency care.

I'd say the only real use for this tag is minor injuries units.  They don't
really
fit into the emergency category but it's useful to be able to find them in
a hurry.
These are places that don't just accept walk-ins, that's all they usually
handle.

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

Re: [Tagging] Feature Proposal - RFC - Urgent Care

[Colin Smale]

On 2020-04-05 21:16, Andy Townsend wrote:

> On 05/04/2020 16:36, Joseph Eisenberg wrote:Can someone confirm if 
> "urgent_care" makes sense in British English,
> rather than "walk-in" or something else?
> 
> I'm English, and I would not know what "urgent_care" meant. After reading the 
> wiki page, it is unclear whether refers to designated walk-in centres, or the 
> "accident" end of "accident and emergency", or any other healthcare providers 
> that offer non-appointment access?

More likely to be towards the "emergency" end of A I would think...
Just because something is caused by an accident, doesn't make it
life-threatening. "urgent care" sounds like something that couldn't wait
for your GP to open tomorrow morning.___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Urgent Care

[Andy Townsend]

On 05/04/2020 16:36, Joseph Eisenberg wrote:

Can someone confirm if "urgent_care" makes sense in British English,
rather than "walk-in" or something else?

I'm English, and I would not know what "urgent_care" meant. After 
reading the wiki page, it is unclear whether refers to designated 
walk-in centres, or the "accident" end of "accident and emergency", or 
any other healthcare providers that offer non-appointment access?


Best Regards,

Andy


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

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

[Volker Schmidt]

It sounds as we have not yet made clear the difference between MTB routes
and MTB leisure tracks. The former are routes that are suitable for
mountain bikers, but they are on ways shared with other users, whereas the
latter are for the exclusive use with MTBs - no other user is admitted.
That is a similar distinction as between a road and a motor racing track.

On Sun, 5 Apr 2020, 19:27 Adam Franco,  wrote:

> On Sun, Apr 5, 2020 at 3:49 AM Andrew Harvey 
>> wrote:
>> ...
>>
> Although that feels most logical to me, since the sentiment here is
>> strongly against this view about highway=cycleway including mountain bike
>> tracks, I'm proposing instead:
>>
>> Designed/mostly used for city cycling (excluding mountain biking) ->
>> highway=cycleway
>> Designed/mostly used for mountain biking (excluding city cycling) ->
>> highway=path + path=mtb
>> Not designed for any specific mode/mixed use -> highway=path
>>
>
> Thank you for putting together this  highway=path + path=mtb suggestion,
> Andrew. This is first suggestion on this thread that has felt like a good
> direction forward. First and foremost, mountain bike trails are paths,
> anything further is a qualifier that adds precision, but not a
> contradiction.
>
> In contrast, proposals to change to leisure=track feel wrong because these
> are routable ways and dropping highway=* removes them from the routable
> network. Similarly, fiddling with access tags to imply mountain-biking
> trails feels like adding too much inference and dual-purpose to these tags
> that then complicate the access scheme. In general, I think expanding the
> path=* key would be a good way to add additional precision for other
> "special purpose" paths.
>
> I'm a long-time mountain biker and also a bicycle commuter, so I can
> sympathize with both camps. While my area (Vermont, USA) has some
> special-purpose mountain-bike trails (with ramps and the like) that are
> built at ski areas, most of our trails are built and cut by and for
> mountain bikers, but are also used by trail-runners and walkers. The "built
> for mountain bikers" part means that they have been sculpted to follow the
> terrain in a way that is fun on a mountain bike, with turn radii and grades
> that allow a flowing cadence. Often elevation gains/drops are managed to
> optimize for time coasting downhill, rather than dropping steeper than is
> needed only to have to climb again. These trails are also usually great for
> hiking/running, but also feel great on a bike. In contrast, a trail "built
> for hiking" might not worry about twisting between some large jumbled rocks
> that tires simply can't traverse, or might use steep, straight grades and
> stairs that "waste" elevation gains in a way that is less-fun on wheels.
> Long story short the vast majority of specialized mountain-bike trails
> *are* highway=path, they are just a particular flavor of highway=path.
>
> I would strongly support a formalized proposal based on what you put
> together.
>
> Best,
> Adam
>
> On Sun, Apr 5, 2020 at 3:49 AM Andrew Harvey 
> wrote:
>
>>
>> Thanks for everyone's good feedback and discussion. I feel we are getting
>> closer to a conclusion.
>>
>> Before this discussion my view on how it should work was:
>>
>> Designed/mostly used for vehicles, forestry, agriculture, bush fire
>> trucks (known as fire trails in Australia) -> highway=track
>> Designed/mostly used for walking (including hiking) -> highway=footway
>> Designed/mostly used for bicycles (including mountain biking) ->
>> highway=cycleway
>> Designed/mostly used for horses -> highway=bridleway
>> Not designed for any specific mode/mixed use (no formal designation) ->
>> highway=path
>>
>> Although that feels most logical to me, since the sentiment here is
>> strongly against this view about highway=cycleway including mountain bike
>> tracks, I'm proposing instead:
>>
>> Designed/mostly used for city cycling (excluding mountain biking) ->
>> highway=cycleway
>> Designed/mostly used for mountain biking (excluding city cycling) ->
>> highway=path + path=mtb
>> Not designed for any specific mode/mixed use -> highway=path
>>
>> The reasoning behind this takes into consideration:
>>
>> bicycle= as an access tag should refer to any class of bicycles by
>> default. Today I was walking a track which had a no bicycles sign, meaning
>> all types of bikes are disallowed. Conversely bicycle=yes just means that
>> bicycles are legally/physically allowed, it does not indicate suitability
>> by a specific type of bicycle. I don't think I've ever seen signage which
>> says no mountain bikes but you can use a road bike, or vice versa. If there
>> is then we should use sub bicycle access tags like road_bike=, mtb=, bmx=
>> etc. You could have a path which is clearly a mountain bike track but
>> officially bicycles are not allowed. So based on this we can't use these
>> kinds of access tags to define the type of path they must be kept
>> independent.
>>
>> Not all mountain bike tracks are 

Re: [Tagging] Feature Proposal - RFC - protection_class=* (Words, not numeric codes)

[Kevin Kenny]

I suppose, now.  It seems to be gaining some traction, at long last.
When I floated it, it was not nearly as popular, largely because of
the way it tied into the flood of words exchanged between Adamant(some
digits) and stevea in various media. The discussion at the time shed
more heat than light.

I'm a little intimidated by the process, particularly the
administration of the vote (Who's a qualified elector? Who can serve
as scrutineer?) and the need to stitch the result into the Wiki.  Some
of what's needed for the latter seems to require knowledge of the
Wiki's templating conventions, which appear to be obscurely documented
at best, and with which I'm unfamiliar. (Also, it brings up unpleasant
memories. I've burnt my fingers on Wikipedia in the past.)

I've been hoping against hope that someone will help me with the
mechanics. I'm considerably better at data modeling than I am at
Wiki-gnoming!

On Sun, Apr 5, 2020 at 12:39 AM Joseph Eisenberg
 wrote:
>
> 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



-- 
73 de ke9tv/2, Kevin

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

Re: [Tagging] Feature Proposal - RFC - Urgent Care

[Michael Patrick]

> Can someone confirm if "urgent_care" makes sense in British English,
> rather than "walk-in" or something else?
>

It isn't like there isn't already a categorization scheme, harmonized
globally, with translations available in most languages ( not only English
). Or, alternatively, spend the next decade organically expanding an ad hoc
tagging scheme that eventually collapses under edge cases. Neither of those
terms are definitive, they are flavors of ambulatory care which range from
flu shots given by pharmacists to actual minor surgery capable ( non-IV,
non-anesthesia ) housed in major retail chains - like
https://washington.providence.org/locations-directory/e/express-care-walgreens-mukilteo
. Pandemic-wise, one could probably perceive the utility in harmonization
with everybody else's established categorization schemes rather than
inventing an incomplete new one. IMHO, at least.

*United Nations Standard Products and Services Code® (UNSPSC®), managed by
GS1 US™ for the UN Development Programme (UNDP), is an open, global,
multi-sector standard for efficient, accurate classification of products
and services. UNSPSC is an efficient, accurate and flexible classification
system for achieving company-wide visibility of spend analysis, as well as,
enabling procurement to deliver on cost-effectiveness demands and allowing
full exploitation of electronic commerce capabilities. Encompassing a five
level hierarchical classification codeset, UNSPSC enables expenditure
analysis at grouping levels relevant to your needs. You can drill down or
up to the codeset to see more or less detail as is necessary for business
analysis. *

Repost below, regarding the term 'clinic', a previous 'definition' issue:
Subject: Re: [Talk-us] When is your doctor a clinic?

There are international taxonomies that define standards for the various
terms involved in healthcare provision ( like
*https://www.hl7.org/about/index.cfm?ref=nav*
 ). These are important for
many reasons, like Drs Without Borders may draw personnel from many
countries and integrate with local medical staff. For example:

*Definition:  *A facility or distinct part of one used for the diagnosis
and treatment of outpatients. "Clinic/center" is irregularly defined,
either including or excluding physician's offices and allied health
professionals, sometimes being limited to organizations serving specialized
treatment requirements or distinct patient/client groups (e.g., radiology,
poor, public health). *Source: * *Rhea, Ott, and Shafritz, The Facts On
File Dictionary of Health Care Management, New York: Facts On File
Publications, 1988; Lexikon: Dictionary of Health Care Terms, Organizations
and Acronyms for the Era of Reform, The Joint Commission on Accreditation
of Healthcare Organizations, Oakbrook Terrace, Illinois: 1994, p. 185*"

( from
https://www.hl7.org/documentcenter/public/standards/vocabulary/vocabulary_tables/infrastructure/vocabulary/nuccProviderCodes.html
)

United Nations Standard Products and Services Code (UNSPSC)  at
https://catalog.data.gov/dataset/unspsc-codes ) has a medical portion, but
fairly limited.There are some sites with easier to use interfaces:
http://www.wpc-edi.com/reference/codelists/healthcare/health-care-provider-taxonomy-code-set/

Yes, it's complicated. Most things in the real world are.

Michael Patrick
Data Ferret
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Adam Franco]

>
> On Sun, Apr 5, 2020 at 3:49 AM Andrew Harvey 
> wrote:
> ...
>
Although that feels most logical to me, since the sentiment here is
> strongly against this view about highway=cycleway including mountain bike
> tracks, I'm proposing instead:
>
> Designed/mostly used for city cycling (excluding mountain biking) ->
> highway=cycleway
> Designed/mostly used for mountain biking (excluding city cycling) ->
> highway=path + path=mtb
> Not designed for any specific mode/mixed use -> highway=path
>

Thank you for putting together this  highway=path + path=mtb suggestion,
Andrew. This is first suggestion on this thread that has felt like a good
direction forward. First and foremost, mountain bike trails are paths,
anything further is a qualifier that adds precision, but not a
contradiction.

In contrast, proposals to change to leisure=track feel wrong because these
are routable ways and dropping highway=* removes them from the routable
network. Similarly, fiddling with access tags to imply mountain-biking
trails feels like adding too much inference and dual-purpose to these tags
that then complicate the access scheme. In general, I think expanding the
path=* key would be a good way to add additional precision for other
"special purpose" paths.

I'm a long-time mountain biker and also a bicycle commuter, so I can
sympathize with both camps. While my area (Vermont, USA) has some
special-purpose mountain-bike trails (with ramps and the like) that are
built at ski areas, most of our trails are built and cut by and for
mountain bikers, but are also used by trail-runners and walkers. The "built
for mountain bikers" part means that they have been sculpted to follow the
terrain in a way that is fun on a mountain bike, with turn radii and grades
that allow a flowing cadence. Often elevation gains/drops are managed to
optimize for time coasting downhill, rather than dropping steeper than is
needed only to have to climb again. These trails are also usually great for
hiking/running, but also feel great on a bike. In contrast, a trail "built
for hiking" might not worry about twisting between some large jumbled rocks
that tires simply can't traverse, or might use steep, straight grades and
stairs that "waste" elevation gains in a way that is less-fun on wheels.
Long story short the vast majority of specialized mountain-bike trails *are*
highway=path, they are just a particular flavor of highway=path.

I would strongly support a formalized proposal based on what you put
together.

Best,
Adam

On Sun, Apr 5, 2020 at 3:49 AM Andrew Harvey 
wrote:

>
> Thanks for everyone's good feedback and discussion. I feel we are getting
> closer to a conclusion.
>
> Before this discussion my view on how it should work was:
>
> Designed/mostly used for vehicles, forestry, agriculture, bush fire trucks
> (known as fire trails in Australia) -> highway=track
> Designed/mostly used for walking (including hiking) -> highway=footway
> Designed/mostly used for bicycles (including mountain biking) ->
> highway=cycleway
> Designed/mostly used for horses -> highway=bridleway
> Not designed for any specific mode/mixed use (no formal designation) ->
> highway=path
>
> Although that feels most logical to me, since the sentiment here is
> strongly against this view about highway=cycleway including mountain bike
> tracks, I'm proposing instead:
>
> Designed/mostly used for city cycling (excluding mountain biking) ->
> highway=cycleway
> Designed/mostly used for mountain biking (excluding city cycling) ->
> highway=path + path=mtb
> Not designed for any specific mode/mixed use -> highway=path
>
> The reasoning behind this takes into consideration:
>
> bicycle= as an access tag should refer to any class of bicycles by
> default. Today I was walking a track which had a no bicycles sign, meaning
> all types of bikes are disallowed. Conversely bicycle=yes just means that
> bicycles are legally/physically allowed, it does not indicate suitability
> by a specific type of bicycle. I don't think I've ever seen signage which
> says no mountain bikes but you can use a road bike, or vice versa. If there
> is then we should use sub bicycle access tags like road_bike=, mtb=, bmx=
> etc. You could have a path which is clearly a mountain bike track but
> officially bicycles are not allowed. So based on this we can't use these
> kinds of access tags to define the type of path they must be kept
> independent.
>
> Not all mountain bike tracks are mtb=designated. Many paths are built for
> and used mostly by mountain bikes, key giveaways are jumps, corner banks
> and other technical features, but not officially signposted or marked for
> use by mountain bikes. Conversely the track could be signposted for use by
> mountain bikes but not actually be a mountain bike track, eg. it could be
> highway=track which is not a mountain bike track, but indicated as a way
> for use by mountain bikes so mtb=designated.
>
> So I'm proposing the access tags bicycle= refer to any/all bicycles. 

Re: [Tagging] Feature Proposal - RFC - (Unifying playground equipment tagging)

[Sven Geggus]

Sören Reinecke via Tagging  wrote:

> Proposal:
> I propose the key playground to be deprecated and the use of key
> playground:* instead. That would mean that on both playground and
> playground equipment objects in OSM the key playground:* applies. This
> then would also allow to map playgrounds and their equipment in
> situations where a playground just has one equipment and this equipment
> fills up the whole area of the playground.

I do not like the idea of pseudo namespacing signle keys at all. I would even go
further to say that I generally prefer generic keys over special ones.

We already had this discussion in tourism=camp_pitch vs.
camp_site=camp_pitch.

Using the former instead of the latter will make live easier for database
imports.

Thus your proposal will make imports even more complicated as it will need
wildcard processing for keys like this:

"import all objects tagged playgroud:"
instead of just
"import all objects tagged playground".

Regards

Sven

-- 
"Thinking of using NT for your critical apps?
  Isn't there enough suffering in the world?"
   (Advertisement of Sun Microsystems in Wall Street Journal)
/me is giggls@ircnet, http://sven.gegg.us/ on the Web

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

Re: [Tagging] Feature Proposal - RFC - Urgent Care

[Ty S]

Thank you. First, I already changed from “pharmacy.” Second, no other tags that 
I know of would be affected, but I don’t think that’s a big deal. Some keys 
only affect one tag. Third, I did some research, and it seems based on webpages 
that British English speakers also call it urgent care.


---Floridaeditor

Sent from Mail for Windows 10

From: Joseph Eisenberg
Sent: Sunday, April 5, 2020 11:37 AM
To: Tag discussion, strategy and related tools
Subject: Re: [Tagging] Feature Proposal - RFC - Urgent Care

This still needs a clearer definition.

Please define what is and what is not "walk-in service"

How would a pharmacy have "urgent care", if it is not also a doctor's
surgery (office)?

Please clarify what features can be tagged with this - I gather it is
for amenity=clinic and amenity=doctors and amenity=dentist, but what
other pages will be affected?

Can someone confirm if "urgent_care" makes sense in British English,
rather than "walk-in" or something else?

-- Joseph Eisenberg

On 4/6/20, Ty Stockman  wrote:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Urgent_care
>
> The urgent care tag is used at, for example, clinics, that offer walk-in
> service
>
>
>
>

___
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 - Urgent Care

[Joseph Eisenberg]

This still needs a clearer definition.

Please define what is and what is not "walk-in service"

How would a pharmacy have "urgent care", if it is not also a doctor's
surgery (office)?

Please clarify what features can be tagged with this - I gather it is
for amenity=clinic and amenity=doctors and amenity=dentist, but what
other pages will be affected?

Can someone confirm if "urgent_care" makes sense in British English,
rather than "walk-in" or something else?

-- Joseph Eisenberg

On 4/6/20, Ty Stockman  wrote:
> https://wiki.openstreetmap.org/wiki/Proposed_features/Urgent_care
>
> The urgent care tag is used at, for example, clinics, that offer walk-in
> service
>
>
>
>

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

[Tagging] Feature Proposal - RFC - Urgent Care

[Ty Stockman]

https://wiki.openstreetmap.org/wiki/Proposed_features/Urgent_care

The urgent care tag is used at, for example, clinics, that offer walk-in service



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

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

[Yves]

Yes, but it need at least an attempt to reach to a few big contributors of this 
tag to discuss it. As often with specialized tags, this list may lacks some 
experts.
Actually I found one reference of mtb=* as an access tag here:
https://wiki.openstreetmap.org/wiki/Bicycle_tags_map
So maybe it isn't worth it. 
Yves 


Le 5 avril 2020 11:52:26 GMT+02:00, Andrew Harvey  a 
écrit :
>I agree with Martin here, if tags are used but not documented on the
>wiki,
>discussion on the mailing lists or through a proposal process, how
>would
>such tags hold any meaning? Different editors probably add it to mean
>different things. We can't really make any assumptions about what they
>mean, which is why this whole discussion exists so we can have some
>kind of
>contract between people entering tags and people consuming data, so we
>have
>a shared understanding of the meaning of those tags.
>
>Anyone who's used the mtb= tags so far, it would be great to hear what
>this
>was meant to mean.
>
>On Sun, 5 Apr 2020 at 19:08, Martin Koppenhoefer
>
>wrote:
>
>>
>>
>> Am So., 5. Apr. 2020 um 11:03 Uhr schrieb Yves :
>>
>>> As a side note: I would be worried to redefine the mtb=yes/no tag
>that is
>>> not documented but widely used.
>>>
>>
>>
>> how can it be "redefined" if there isn't documentation about it?
>>
>> Cheers
>> Martin
>>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Andrew Harvey]

Yep that's all complementary to what's being discussed and proposed here.

On Sun, 5 Apr 2020 at 20:04, Volker Schmidt  wrote:

> We need also to look at this wiki page:
> Mountain biking 
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Florimond Berthoux]

mtb:scale=yes is like surface=yes it has no real meaning, mtb:scale is a
scale from 0 flat surface to 6 obstacle taller than a human.

Actually I think mtb:scale is easier to use than smoothness : it's a more
objective tag.
(Sometime I think stating smoothness with average size of gravel/obstacle
in cm would be much easier and objective tagging, but that is an other
subject.)

Le sam. 4 avr. 2020 à 23:57, Marc M.  a écrit :

> 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
>


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

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

[Volker Schmidt]

We need also to look at this wiki page:
Mountain biking 







<#m_2511257917808460956_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Feature Proposal - RFC - Tag:amenity=motorcycle_taxi

[Joseph Eisenberg]

Are there any more comments about the proposal for amenity=motorcycle_taxi?

https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:amenity%3Dmotorcycle_taxi

As expected, there were a few critical remarks about the use of
"amenity=" - however, this is the key used for "amenity=taxi", a
motorcar taxi cab stand, so it makes sense to use the same key for
ojek and boda-boda ("motorcycle taxi") stands.

There was also a suggestion to use amenity=taxi + motorcycle=yes or
some other similar tag. However, the proposal page explains why this
is not a good idea:

"Why not use amenity=taxi?"

While some have proposed using amenity=taxi plus the additional tags
motorcar=no + motorcycle=yes for motorcycle taxi stands, this has
several disadvanages:

* implies that a taxicab and a hired motorcyle "ojek" are the same feature.

* requires using 3 tags instead of one.

* If only amenity=taxi is tagged, it would now become ambiguous: is
this actually a taxicab stand, or might it be a motorcycle taxi stand
which is missing a tag?

* Confusing for travelers who generally expect a "taxicab" to be
4-wheeled motorcar capable of carrying at least 4 passengers and their
luggage. This is quite different than a motorcycle which can only
carry one passenger with a small amount of baggage.

* Motorcyles have different abilities: In contrast to a family or
group which needs a 4 to 6 seat taxicab, single travelers may strongly
prefer to hire motorcycles when available, due to their lower cost and
ability to fit through smaller spaces in congested cities and rural
areas with narrow roads and paths. Motorcar taxicabs with 4 wheels in
2 tracks cannot access highway=path features and narrow roads, but
motorcycles may be permitted and feasible due to their narrow width
and single track.

* Many database users currently interpret amenity=taxi as a motorcar
taxicab via use of a standard "taxi" icon such as
https://en.wikipedia.org/wiki/File:Taxi_Icon.png - this would be
broken by such a change.

So a different tag is proposed to avoid confusion and more precisely
tag these features. The value "motorcycle_taxi" is not a very common
term in British (or American) English, but that's because these
features are not found in Europe or North America.

I would like to bring this to a vote soon.

-- Joseph Eisenberg

On 2/20/20, Joseph Eisenberg  wrote:
> I would like to formally request comments on the proposal for
> amenity=motorcycle_taxi:
>
> "A place where motorcycle taxis wait for passengers"
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:amenity%3Dmotorcycle_taxi
>
> In many countries, motorcycles for hire are much more common than
> automobile taxis.
>
> In these places, motorcycle drivers wait at stands, often with a small
> shelter, and they can be hired to take one or more passengers to
> various destinations. A fare is paid for a one-way trip. The passenger
> usually rides behind the driver. In some countries two or even three
> passengers can be carried on one motorcycle "taxi".
>
> Motorcycle taxis are also known as "motos" or "bike taxi", or by other
> local names, such as "ojek" here in Indonesia and in Singapore,
> "boda-boda" in Uganda, and "okada" in Nigeria.
>
> While some have proposed using amenity=taxi plus additional tags for
> motorcycle taxi stands, this is quite confusing for travelers who
> generally expect a "taxi" to be 4-wheeled motorcar capable of carrying
> 4 people and luggage. So a different tag is proposed to avoid
> confusion and more precisely tag these features.
>
> - Joseph Eisenberg
>

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

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

[Andrew Harvey]

I agree with Martin here, if tags are used but not documented on the wiki,
discussion on the mailing lists or through a proposal process, how would
such tags hold any meaning? Different editors probably add it to mean
different things. We can't really make any assumptions about what they
mean, which is why this whole discussion exists so we can have some kind of
contract between people entering tags and people consuming data, so we have
a shared understanding of the meaning of those tags.

Anyone who's used the mtb= tags so far, it would be great to hear what this
was meant to mean.

On Sun, 5 Apr 2020 at 19:08, Martin Koppenhoefer 
wrote:

>
>
> Am So., 5. Apr. 2020 um 11:03 Uhr schrieb Yves :
>
>> As a side note: I would be worried to redefine the mtb=yes/no tag that is
>> not documented but widely used.
>>
>
>
> how can it be "redefined" if there isn't documentation about it?
>
> Cheers
> Martin
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Martin Koppenhoefer]

Am So., 5. Apr. 2020 um 11:03 Uhr schrieb Yves :

> As a side note: I would be worried to redefine the mtb=yes/no tag that is
> not documented but widely used.
>


how can it be "redefined" if there isn't documentation about it?

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

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

[Yves]

As a side note: I would be worried to redefine the mtb=yes/no tag that is not 
documented but widely used. I do agree that makes sense to define it as an 
access tag, though.
Yves 

Le 5 avril 2020 09:48:07 GMT+02:00, Andrew Harvey  a 
écrit :
>Thanks for everyone's good feedback and discussion. I feel we are
>getting
>closer to a conclusion.
>
>Before this discussion my view on how it should work was:
>
>Designed/mostly used for vehicles, forestry, agriculture, bush fire
>trucks
>(known as fire trails in Australia) -> highway=track
>Designed/mostly used for walking (including hiking) -> highway=footway
>Designed/mostly used for bicycles (including mountain biking) ->
>highway=cycleway
>Designed/mostly used for horses -> highway=bridleway
>Not designed for any specific mode/mixed use (no formal designation) ->
>highway=path
>
>Although that feels most logical to me, since the sentiment here is
>strongly against this view about highway=cycleway including mountain
>bike
>tracks, I'm proposing instead:
>
>Designed/mostly used for city cycling (excluding mountain biking) ->
>highway=cycleway
>Designed/mostly used for mountain biking (excluding city cycling) ->
>highway=path + path=mtb
>Not designed for any specific mode/mixed use -> highway=path
>
>The reasoning behind this takes into consideration:
>
>bicycle= as an access tag should refer to any class of bicycles by
>default.
>Today I was walking a track which had a no bicycles sign, meaning all
>types
>of bikes are disallowed. Conversely bicycle=yes just means that
>bicycles
>are legally/physically allowed, it does not indicate suitability by a
>specific type of bicycle. I don't think I've ever seen signage which
>says
>no mountain bikes but you can use a road bike, or vice versa. If there
>is
>then we should use sub bicycle access tags like road_bike=, mtb=, bmx=
>etc.
>You could have a path which is clearly a mountain bike track but
>officially
>bicycles are not allowed. So based on this we can't use these kinds of
>access tags to define the type of path they must be kept independent.
>
>Not all mountain bike tracks are mtb=designated. Many paths are built
>for
>and used mostly by mountain bikes, key giveaways are jumps, corner
>banks
>and other technical features, but not officially signposted or marked
>for
>use by mountain bikes. Conversely the track could be signposted for use
>by
>mountain bikes but not actually be a mountain bike track, eg. it could
>be
>highway=track which is not a mountain bike track, but indicated as a
>way
>for use by mountain bikes so mtb=designated.
>
>So I'm proposing the access tags bicycle= refer to any/all bicycles.
>mtb=
>become an access tag (mtb=designated for signposted mountain bike).
>path=mtb become a tag to say the path on the ground here is
>designed=mostly
>used for mountain biking.
>
>I feel this is better than a new highway=singletrack tag since
>renderers,
>routers, etc can still interpret the path without making changes. If we
>move to a new tag, these tracks will disappear from routers and maps
>overnight.
>
>All other tags like surface, smoothness, mtb:scale, route=mtb still
>apply.
>leisure=track would still apply to short loop tracks like a BMX pump
>track
>or a velodrome, but not to longer A to B tracks.
>
>Thoughts? I can help work on the wiki proposal for these tag changes
>(mtb=
>as an access tag and path=mtb) but keen to hear feedback here first.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Andrew Harvey]

Thanks for everyone's good feedback and discussion. I feel we are getting
closer to a conclusion.

Before this discussion my view on how it should work was:

Designed/mostly used for vehicles, forestry, agriculture, bush fire trucks
(known as fire trails in Australia) -> highway=track
Designed/mostly used for walking (including hiking) -> highway=footway
Designed/mostly used for bicycles (including mountain biking) ->
highway=cycleway
Designed/mostly used for horses -> highway=bridleway
Not designed for any specific mode/mixed use (no formal designation) ->
highway=path

Although that feels most logical to me, since the sentiment here is
strongly against this view about highway=cycleway including mountain bike
tracks, I'm proposing instead:

Designed/mostly used for city cycling (excluding mountain biking) ->
highway=cycleway
Designed/mostly used for mountain biking (excluding city cycling) ->
highway=path + path=mtb
Not designed for any specific mode/mixed use -> highway=path

The reasoning behind this takes into consideration:

bicycle= as an access tag should refer to any class of bicycles by default.
Today I was walking a track which had a no bicycles sign, meaning all types
of bikes are disallowed. Conversely bicycle=yes just means that bicycles
are legally/physically allowed, it does not indicate suitability by a
specific type of bicycle. I don't think I've ever seen signage which says
no mountain bikes but you can use a road bike, or vice versa. If there is
then we should use sub bicycle access tags like road_bike=, mtb=, bmx= etc.
You could have a path which is clearly a mountain bike track but officially
bicycles are not allowed. So based on this we can't use these kinds of
access tags to define the type of path they must be kept independent.

Not all mountain bike tracks are mtb=designated. Many paths are built for
and used mostly by mountain bikes, key giveaways are jumps, corner banks
and other technical features, but not officially signposted or marked for
use by mountain bikes. Conversely the track could be signposted for use by
mountain bikes but not actually be a mountain bike track, eg. it could be
highway=track which is not a mountain bike track, but indicated as a way
for use by mountain bikes so mtb=designated.

So I'm proposing the access tags bicycle= refer to any/all bicycles. mtb=
become an access tag (mtb=designated for signposted mountain bike).
path=mtb become a tag to say the path on the ground here is designed=mostly
used for mountain biking.

I feel this is better than a new highway=singletrack tag since renderers,
routers, etc can still interpret the path without making changes. If we
move to a new tag, these tracks will disappear from routers and maps
overnight.

All other tags like surface, smoothness, mtb:scale, route=mtb still apply.
leisure=track would still apply to short loop tracks like a BMX pump track
or a velodrome, but not to longer A to B tracks.

Thoughts? I can help work on the wiki proposal for these tag changes (mtb=
as an access tag and path=mtb) but keen to hear feedback here first.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging