Re: [Tagging] insurance health

[Marc Gemis]

I think so, yes.

On Thu, Apr 16, 2020 at 4:12 PM Martin Koppenhoefer
 wrote:
>
>
>
> sent from a phone
>
> > On 16. Apr 2020, at 11:41, Marc Gemis  wrote:
> >
> > It's a health fund, and every adult Belgian needs to have one
>
>
> judging by their names, are they all mutual insurance companies?
>
> 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] Definition and usage of Key:mtb:scale:imba?

[brad]

I'm going to change my mind.   I don't think mtb:scale:imba should be 
deprecated.   It should be used instead of mtb:scale because it is 
better.   The IMBA Trail Difficulty Rating System was designed for all 
trails, not just bike park trails or trails with features. It follows 
that OSM should use it for all trails too, not just IMBA signed trails, 
or bike park trails.      I agree with everything that user Opadeira is 
proposing and I'll add some comments to the wiki talk page.



On 4/22/20 7:12 PM, Andrew Harvey wrote:
On Thu, 23 Apr 2020 at 03:03, brad > wrote:


I've never seen an official IMBA rating on a sign.


I have, 
https://wiki.openstreetmap.org/w/images/9/96/Serrata_Mountain_Bike_Track_Board_Map.jpeg


I see both mtb:scale and mtb:scale:imba both used. The wiki for
mtb:scale doesn't make sense.   It's either skewed for extremely
extreme riding or they don't understand gradient.   It says that
for mtb:scale=1, gradient<40%.   This is meaningless.   Nobody can
ride up an unpaved grade that is 40%, or probably even 30%.   A
steep trail is 15%.   A really steep, almost unrideable, very
difficult hiking, trail is 20%.    Going downhill, anything above
25% is a double black, only a small percentage of riders can ride,
unless it is very smooth with really good traction.


I agree, I find it very hard to set mtb:scale confidently based on the 
descriptions on the wiki.


In my opinion, mtb:scale:imba could be deprecated, and the wiki
for mtb:scale updated & clarified.


I would disagree on that, mtb:scale:imba is still useful to mark 
officially signposted or designated ratings of the track made 
according to the IMBA system, like in the first photo I posted.


I'd be very keen to review any improvements to mtb:scale though, I 
have very low confidence in all the ones I've tagged so far as I feel 
like every time I read the wiki I have a different opinion



___
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] Definition and usage of Key:mtb:scale:imba?

[Andrew Harvey]

On Thu, 23 Apr 2020 at 03:03, brad  wrote:

> I've never seen an official IMBA rating on a sign.
>

I have,
https://wiki.openstreetmap.org/w/images/9/96/Serrata_Mountain_Bike_Track_Board_Map.jpeg


> I see both mtb:scale and mtb:scale:imba both used.   The wiki for
> mtb:scale doesn't make sense.   It's either skewed for extremely extreme
> riding or they don't understand gradient.   It says that for mtb:scale=1,
> gradient<40%.   This is meaningless.   Nobody can ride up an unpaved grade
> that is 40%, or probably even 30%.   A steep trail is 15%.   A really
> steep, almost unrideable, very difficult hiking, trail is 20%.Going
> downhill, anything above 25% is a double black, only a small percentage of
> riders can ride, unless it is very smooth with really good traction.
>

I agree, I find it very hard to set mtb:scale confidently based on the
descriptions on the wiki.

In my opinion, mtb:scale:imba could be deprecated, and the wiki for
> mtb:scale updated & clarified.
>

I would disagree on that, mtb:scale:imba is still useful to mark officially
signposted or designated ratings of the track made according to the IMBA
system, like in the first photo I posted.

I'd be very keen to review any improvements to mtb:scale though, I have
very low confidence in all the ones I've tagged so far as I feel like every
time I read the wiki I have a different opinion
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Too many different features lumped together under amenity=social_facility?

[Tom Pfeifer]

On 20.04.2020 16:52, Paul Allen wrote:
> Amenity is much larger and much more of an eclectic hodge-podge than
> social_facility.  I'm not even sure that amenity=social_facility is a good
> idea, but at least you can then refine it with social_facility=*.  Moving
> do amenity=nursing_home just makes amenity a bigger mess than it
> already is.  And a nursing home is a social facility, not some sort of
> recreational POI for the general public.

amenity=social_facility with subkeys social_facility=* and social_facility:for=*
was voted in favour in 2010 with an unusual 96% on a quorum of 28.
The only vote against was just about dropping the amenity key above.
It turned out as a big help to keep values out of the top-level amenity=* space.
The proposal explicitly excluded facilities for the "treatment of specific 
acute medical
conditions", giving hospitals as example.

With about a dozen values that have significant usage I cannot see that there
were "too many different features lumped together", quite in contrast to 
amenity=* itself.

The problem comes with the the dynamics of amenity=nursing_home and 
social_facility=group_home:

If you look into the history graphs [1] you see that in 2011 there was 
apparently a massive import
of amenity=nursing_home;
which was partially removed in 2012, and partially converted
into social_facility=group_home and social_facility=assisted_living

social_facility=group_home was an over-ambitious attempt, coming from the 
examples of the
social_facility proposal, to tag a "Retirement Home" as amenity=social_facility 
+
social_facility=group_home + social_facility:for=senior, which blurred the 
distinction
of which homes provide nursing.

The new value social_facility=nursing_home provides clarity and is becoming 
organically popular
without mechanical changes.

It would be helpful if somebody could provide insight in the 2011 import and 
the 2012 mechanical
edit, and by which criteria the nursing_homes were separated into group_home 
vs. assisted_living.

It appears to me that in particular the imported objects nobody knows and 
nobody cares about.

Tom


[1]
https://taghistory.raifer.tech/#***/social_facility/nursing_home&***/amenity/nursing_home&***/social_facility/group_home&***/social_facility/assisted_living

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

Re: [Tagging] Definition and usage of Key:mtb:scale:imba?

[brad]

I've never seen an official IMBA rating on a sign.
I see both mtb:scale and mtb:scale:imba both used.   The wiki for 
mtb:scale doesn't make sense.   It's either skewed for extremely extreme 
riding or they don't understand gradient.   It says that for 
mtb:scale=1, gradient<40%.   This is meaningless.   Nobody can ride up 
an unpaved grade that is 40%, or probably even 30%.   A steep trail is 
15%.   A really steep, almost unrideable, very difficult hiking, trail 
is 20%.    Going downhill, anything above 25% is a double black, only a 
small percentage of riders can ride, unless it is very smooth with 
really good traction.


The tag has been used with common sense, but inconsistently, instead of 
the wiki definition.


In the US, we us a green/blue/black/doubleBlack system which I would not 
consider an IMBA system, but merely a subjective rating by whoever made 
the map,  usually a local mtb club or land manager. IMBA probably 
clarified it, but it probably predates IMBA.   The apps trailforks and 
mtbproject use green/blue/black/doubleBlack ratings as determined by the 
users.  For the most part it's consistent, but one does have to be 
cognizant of the local bias.
The imba rating system was not invented for bike parks, so the OSM use 
for bike parks doesn't make much sense.


In my opinion, mtb:scale:imba could be deprecated, and the wiki for 
mtb:scale updated & clarified.


On 4/22/20 5:00 AM, Simon Poole wrote:


IMHO, the problem is using mtb:scale:imba 
 in place 
of mtb:scale for normal trails which I suspect the intent of the 
original wording was to avoid that happening.


Simon

Am 22.04.2020 um 10:53 schrieb Andrew Harvey:
I've been using mtb:scale:imba on any kind of trail where signage at 
the site notes an IMBA rating, in this way it's verifiable based on 
the sign. I don't know what "bikepark" and "north shore" mean here 
but while some of these trails which have an IMBA rating can be 
consider together as part of a collection of trails and that 
collection does have a name sperate to the individual tracks (which I 
guess is what bikepark means) others which do have signposted IMBA 
ratings are standalone and not part of a named collection of trails.


So if it has an official or signposted IMBA rating, it should be 
tagged regardless of the trail being "natural" or with "artificial 
obstacles" and regardless if it's part of a mountain bike "park" or not.


On Wed, 22 Apr 2020 at 17:29, Joseph Eisenberg 
mailto:joseph.eisenb...@gmail.com>> wrote:


Another user would like to redefine the definition of
"Key:mtb:scale:imba"

See suggestions at
https://wiki.openstreetmap.org/wiki/Talk:Key:mtb:scale:imba:

This tag was approved in the proposal
https://wiki.openstreetmap.org/wiki/Proposed_features/mtb:scale -
with the description "The IMBA Trail Difficulty Rating System
shall be used for bikeparks. Especially for North Shore. It is
adapted to mtb trails with artificial obstacles. For "natural"
trails it is advised to use the mtb:scale/mtb:uphill:scale." -
linked to
http://www.imba.com/resources/trail_building/itn_17_4_trail_difficulty.html

Can other mappers who use this tag frequently confirm whether it
is limited to specifically designed and built bike trails, like
those found in "bikeparks"?

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


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


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


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

Re: [Tagging] Points vs Polygons

[Paul Allen]

On Wed, 22 Apr 2020 at 12:40, Martin Koppenhoefer 
wrote:

>
> but the building is also a thing, it has its own properties, e.g.
> start_date, wikipedia reference, architect, operator, name, height, etc
>

This is all true.  And in an ideal world we'd map the building and its
occupying
object as  two separate-but-coincident objects.  This isn't an ideal world.
:(

Problem 1.  A popular editor makes it VERY hard to deal with coincident
objects.  All it would take would be a modifier key (such as control) to
cycle
through all coincident objects sharing the node or way clicked on.  Instead
you get whichever object it decides to give you and can't get at the
other(s).
The only way I've found is to disconnect a node, drag that node so it is
no longer coincident with other objects, click on the now separated
objects until I find the one I want, modify it, move the node back to
where it was.

Maybe there's a simple, obvious way of doing it that I'm missing, but I
haven't found it.  For as long as that editor makes it painful to have
coincident objects then people will avoid using them unless forced
to for other reasons (there is no other way of mapping some aspect
of one of the objects that they consider a necessary feature).

Problem 2: Duplication of address info.  The building has an address
irrespective of the occupying object.  But it is convenient for
consumers querying the occupying object to get the address of
the occupying organization in a single step.  "Don't repeat yourself"
is a good maxim, but one we must flout with coincident objects.
Unless you want the pain of not putting an address on the building
if it is occupied, but transferring the address from the occupier to
the building prior to deleting the occupier when the building
becomes vacant.

Using a node for the occupying entity gets rid of problem 1 but
does not get rid of problem 2.  And introduces problem 3: some
types of entity render if they have an area and building=yes
but do not render (not even a label) if they are nodes.  Clubs and crafts
are two examples I can think of.  As for healthcare=alternative, if
the building has an addr;housename then that is used as the label
rather than the name=*.

Our tagging practices are heavily influenced by the limitations of
the tools we use...

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

Re: [Tagging] Points vs Polygons

[Martin Koppenhoefer]

sent from a phone

> On 22. Apr 2020, at 07:51, John Willis via Tagging 
>  wrote:
> 
> -1  I really like tagging info onto landuses and buildings because that is 
> *exactly* what I’m trying to convey - everything in this area or building is 
> *this thing*


but the building is also a thing, it has its own properties, e.g. start_date, 
wikipedia reference, architect, operator, name, height, etc 

yes, often you can understand which tag belongs to which object, when several 
objects are represented by one OpenStreetMap object (and that’s why we tolerate 
this kind of representation), but strictly, you can’t even know whether the 
name belongs to the building or to the occupant (it “works” because you assume 
that buildings mostly don’t have names).

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

Re: [Tagging] Definition and usage of Key:mtb:scale:imba?

[Simon Poole]

IMHO, the problem is using mtb:scale:imba
 in place
of mtb:scale for normal trails which I suspect the intent of the
original wording was to avoid that happening.

Simon

Am 22.04.2020 um 10:53 schrieb Andrew Harvey:
> I've been using mtb:scale:imba on any kind of trail where signage at
> the site notes an IMBA rating, in this way it's verifiable based on
> the sign. I don't know what "bikepark" and "north shore" mean here but
> while some of these trails which have an IMBA rating can be
> consider together as part of a collection of trails and that
> collection does have a name sperate to the individual tracks (which I
> guess is what bikepark means) others which do have signposted IMBA
> ratings are standalone and not part of a named collection of trails.
>
> So if it has an official or signposted IMBA rating, it should be
> tagged regardless of the trail being "natural" or with "artificial
> obstacles" and regardless if it's part of a mountain bike "park" or not.
>
> On Wed, 22 Apr 2020 at 17:29, Joseph Eisenberg
> mailto:joseph.eisenb...@gmail.com>> wrote:
>
> Another user would like to redefine the definition of
> "Key:mtb:scale:imba" 
>
> See suggestions
> at https://wiki.openstreetmap.org/wiki/Talk:Key:mtb:scale:imba:
>
> This tag was approved in the
> proposal https://wiki.openstreetmap.org/wiki/Proposed_features/mtb:scale
> - with the description "The IMBA Trail Difficulty Rating System
> shall be used for bikeparks. Especially for North Shore. It is
> adapted to mtb trails with artificial obstacles. For "natural"
> trails it is advised to use the mtb:scale/mtb:uphill:scale." -
> linked
> to 
> http://www.imba.com/resources/trail_building/itn_17_4_trail_difficulty.html
>
> Can other mappers who use this tag frequently confirm whether it
> is limited to specifically designed and built bike trails, like
> those found in "bikeparks"?
>
> -- Joseph Eisenberg
> ___
> Tagging mailing list
> Tagging@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/tagging
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging


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

Re: [Tagging] Definition and usage of Key:mtb:scale:imba?

[Jonathon Rossi]

On Wed, Apr 22, 2020 at 6:54 PM Andrew Harvey 
wrote:

> I've been using mtb:scale:imba on any kind of trail where signage at the
> site notes an IMBA rating
>
Same here. If a land manager has signed an IMBA rating I'll tag it. These
ratings are generally relative to other trails in the same bike park/area
(not just based on the guidelines), so it is of lesser value to make these
up just for a single trail, use other specific physical tags (surface, etc)
for observations.

> The Trail Difficulty Rating System shall be used for bikeparks, this
applies for instance to North Shore [from wiki page history]
Either referring to the trails in Canada (
https://en.wikipedia.org/wiki/North_Shore_(Greater_Vancouver)), or the
style of trails that originated in this area. Either way, it didn't add
anything useful to the description so good that it is gone.

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

Re: [Tagging] Definition and usage of Key:mtb:scale:imba?

[Andrew Harvey]

I've been using mtb:scale:imba on any kind of trail where signage at the
site notes an IMBA rating, in this way it's verifiable based on the sign. I
don't know what "bikepark" and "north shore" mean here but while some of
these trails which have an IMBA rating can be consider together as part of
a collection of trails and that collection does have a name sperate to the
individual tracks (which I guess is what bikepark means) others which do
have signposted IMBA ratings are standalone and not part of a named
collection of trails.

So if it has an official or signposted IMBA rating, it should be tagged
regardless of the trail being "natural" or with "artificial obstacles" and
regardless if it's part of a mountain bike "park" or not.

On Wed, 22 Apr 2020 at 17:29, Joseph Eisenberg 
wrote:

> Another user would like to redefine the definition of "Key:mtb:scale:imba"
>
> See suggestions at
> https://wiki.openstreetmap.org/wiki/Talk:Key:mtb:scale:imba:
>
> This tag was approved in the proposal
> https://wiki.openstreetmap.org/wiki/Proposed_features/mtb:scale - with
> the description "The IMBA Trail Difficulty Rating System shall be used for
> bikeparks. Especially for North Shore. It is adapted to mtb trails with
> artificial obstacles. For "natural" trails it is advised to use the
> mtb:scale/mtb:uphill:scale." - linked to
> http://www.imba.com/resources/trail_building/itn_17_4_trail_difficulty.html
>
> Can other mappers who use this tag frequently confirm whether it is
> limited to specifically designed and built bike trails, like those found in
> "bikeparks"?
>
> -- Joseph Eisenberg
> ___
> 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] Definition and usage of Key:mtb:scale:imba?

[Joseph Eisenberg]

Another user would like to redefine the definition of "Key:mtb:scale:imba"

See suggestions at
https://wiki.openstreetmap.org/wiki/Talk:Key:mtb:scale:imba:

This tag was approved in the proposal
https://wiki.openstreetmap.org/wiki/Proposed_features/mtb:scale - with the
description "The IMBA Trail Difficulty Rating System shall be used for
bikeparks. Especially for North Shore. It is adapted to mtb trails with
artificial obstacles. For "natural" trails it is advised to use the
mtb:scale/mtb:uphill:scale." - linked to
http://www.imba.com/resources/trail_building/itn_17_4_trail_difficulty.html

Can other mappers who use this tag frequently confirm whether it is limited
to specifically designed and built bike trails, like those found in
"bikeparks"?

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