[Tagging] leisure=garden for private front/back gardens

2019-07-11 Thread Pee Wee
Hi all


I would like your opinion on the next issue.


On the Dutch forum (googletranslate
)
I started a thread about the tag leisure=garden for private front/back
gardens. Reason was that I saw mappers using this for whole blocks of
houses that were not publicly accessible. That usage seemed completely
different from all the other leisure values
.

In the first versions

of the wiki page of leisure=garden there was no mentioning of private
front/back gardens.  It seems to me that OSM leisure=garden wiki changed
meaning on may 3, 2010 when someone added a description of “Garden” from
the Wikipedia garden description that refers to private gardens. In order
to differentiate from the publicly accessible gardens (with or without fee)
sometime additional tags like “access=private”  and
“garden:type=residential” are added. To me this seems better then no
additional tags at all but in fact I think private gardens (not accessible)
should not be tagged with the leisure key. On the talk page I saw that
there are more objections

to using this tag for private (non accessible) gardens.




My question to you experts are:



1.   Has this issue been discussed before and if so … what was the
outcome?

2.   If not… do you agree with me that private front/back garden should
not be tagged with leisure=garden but with a non-leisure tag? (if so… any
suggestions? And what about private "gardens" that are partially/completely
paved?)




(PS: it is not my intention to discuss the relevance of tagging private
front/back gardens. I just want to know how this should be tagged in case
someone wants to. )


Cheers

Peter (PeeWee32)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] shop=window(s) incorrectly deprecated in favor of craft=window_construction ?

2019-07-11 Thread ael via Tagging
On Thu, Jul 11, 2019 at 12:33:15PM -0700, Michael Patrick wrote:
> > The obvious tag is
> >  shop=trade
> >  and
> >  trade= ???  ...
> 
> The most obvious tagging scheme for a world wide database like OSM would be
> to use the commercial classification system in effect in a particular
> jurisdiction.

I had not come across this sort of classification before. I see that
there are "SIC" codes in the UK.

They don't seem to cater for shops selling to both the trade and
ordinary customers, but maybe I have not looked carefully.

I would think that these sort of specialist tags might be useful in addition to
more user-friendly tags like those at
https://wiki.openstreetmap.org/wiki/Tag:shop%3Dtrade .

Perhaps something along the lines of the fhrs:id tag used in the UK for
food hygience:
https://wiki.openstreetmap.org/wiki/UK_Food_Hygiene_Rating_Scheme?

Maybe naics:id = in USA, sic:id in UK, and so on?

So they could be useful in addition to the trade=whatever when
appropriate.

ael


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


Re: [Tagging] shop=window(s) incorrectly deprecated in favor of craft=window_construction ?

2019-07-11 Thread Michael Patrick
> The obvious tag is
>  shop=trade
>  and
>  trade= ???  ...

The most obvious tagging scheme for a world wide database like OSM would be
to use the commercial classification system in effect in a particular
jurisdiction.

In the U.S. that's NAICS, the U.K. has one, the EU and practically every
country in the world has one or uses on of the broader ones. The U.N. has a
very generic one. And there are published crosswalk tables and utilities
between the different systems.

They are all hierarchical, i.e. they have very very broad simple generic
categories at the top ( 20 for NAICS ) but also allow one to drill down to
the very, very specific - and the common search engines will provide the
detailed label with a simple query like Googling "NAICS Code NAICS code
bubble tea stand" gives "NAICS Code 722515 - Snack and Nonalcoholic
Beverage Bars",  '... establishments primarily engaged in (1) preparing
and/or serving a specialty snack, such as ice cream, frozen yogurt,
cookies, or popcorn, or (2) serving nonalcoholic beverages, such as coffee,
juices, or sodas for consumption on or near the premises. These
establishments may carry and sell a combination of snack, nonalcoholic
beverage, and other related products (e.g., coffee beans, mugs, coffee
makers) but generally promote and sell a unique snack or nonalcoholic
beverage." with examples.

They also provide links to alternative and related, more general, and more
specific categories. Even if someone goofs a designation, the goof will
usually still be very close to the actual one.

Also, to some degree, usually the code(s) for a particular business is
public record at the municipal, county, state/province, and national level,
it's on their posted business license, it appears on a roll or listing
somewhere. If the business is ad hoc or unlicensed, it's trivial to get the
classification by looking up the code for a similar licensed business.

It accommodates the very common situation where an establishment provides
multiple levels, like manufactures cabinets from raw materials, ships them
and distributes them wholesale regionally, and retails them over the
counter to individuals from their showroom.

The benefits to data providers and consumers are fairly obvious.

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


Re: [Tagging] Feature Proposal - RFC - Tag:insurance:health

2019-07-11 Thread Mark Herringer
We would like to support the following user story, ' As a pregnant mother I
would like to know if a clinic will cover my health costs through the
government health plan or not so that I can select the best clinic for me.'

Perhaps the values for this tag should be localised per country, just as
medicare would be an option for the insurance:health tag in the United
States. This information would be invaluable in African countries where it
could really make a difference for individuals to know where their
treatment is covered.
ᐧ

On Thu, 20 Jun 2019 at 08:17, Joseph Eisenberg 
wrote:

> 5) insurance:health
>
> The proposal suggests values of "no", "public", "private" and "unknown".
>
> Most of these values are not very helpful in most countries.
>
> "insurance:health=no" might be useful in the rare instance that a
> private clinic or facility does not directly accept any form of health
> insurance for payment, however this is rare.
>
> "insurance:health=public" is not very specific. This might be
> sufficient in a country where there is only one public,
> government-administered insurance plan. However, here in Indonesia
> there are 2 common public insurance plans in my province, so it would
> be much more useful to use the name of the insurance as the value, eg
> "insurance:health=BPJS" and "insurance:health=Papua_Sehat". In the USA
> there is Medicare and various local versions of Medicaid in each
> state, in addition to hmo-managed Medicare and Medicaid plans.
>
> "insurance:health=private" is even less useful. I don't think this tag
> is helpful at all, because each private insurance plan is different.
> Similarly, "insurance:health=unknown" should not be used, because it
> doesn't provide any information.
>
> This suggests a problem for counties like the USA or Germany where
> there are dozens or hundreds of health insurance companies with many
> different health plans, each of which may be accepted by a different
> list of physicians and health facilities. Would a USA hospital be
> tagged with a list of 100 different insurance company and plan
> combinations? This would be hard to manage and maintain by most
> openstreetmap mappers.
>
> -Joseph Eisenberg M.D.
>
> On 6/20/19, Mhairi O'Hara  wrote:
> > Hello Tagging Mailing List,
> >
> > We would like to bring your attention and comments on the proposal for
> the
> > staff_count:doctors and staff_count:nurses tags, which helps identify the
> > number of doctors and nurses at a given health facility [1][2]. The
> > operational_status tag, which has been proposed before and I would like
> to
> > highlight again, as this is used to document an observation of the
> current
> > functional status of a mapped feature (i.e. health facility) [3]. The
> > health_amenity:type tag is also being proposed, as this indicates what
> type
> > of speciality medical equipment is available at the health facility [4]
> and
> > the final tag is insurance:health which describes the type of health
> > insurance accepted at a health facility [5].
> >
> > Some of these are already in use but have never been formally accepted,
> or
> > properly described as to how they should be applied, which we would like
> to
> > try and achieve if possible for the Healthsites.io project. Please take a
> > look at the proposal pages on the OSM Wiki, as well as the Global
> > Healthsites Mapping Project page [2] which is at the core of the recent
> > work focused on creating a health facility data model. We look forward to
> > discussing these proposals on the respective Wiki discussion pages.
> >
> > Kind regards,
> >
> > Mhairi
> >
> > [1]
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:staff_count:doctors
> > [2]
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:staff_count:nurses
> > [3]
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:operational_status
> > [4]
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:health_amenity:type
> > [5]
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:insurance:health
> > [6]
> >
> https://wiki.openstreetmap.org/wiki/Global_Healthsites_Mapping_Project#Tag_Proposal
> >
> >
> > --
> > *Mhairi O'Hara*
> > Project Manager
> > mhairi.oh...@hotosm.org
> > @mataharimhairi
> >
> >
> > *Humanitarian OpenStreetMap Team*
> > *Using OpenStreetMap for Humanitarian Response & Economic Development*
> > web 
> >  |  twitter 
> >  |  facebook 
> >  |  donate 
> >
>


-- 
Kind regards
Mark Herringer
www.healthsites.io
https://medium.com/healthsites-io
@sharehealthdata 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - health_amenity:type

2019-07-11 Thread Mark Herringer
The intention of the tag is to specify physical equipment
(health_amenity:type=MRI) and should be used in conjunction with
amenity=clinic to show that the health facility contains that specialised
equipment. This will enable mappers say that "this clinic contains an MRI"
ᐧ

On Thu, 20 Jun 2019 at 08:15, Joseph Eisenberg 
wrote:

> 4) health_amenity:type
>
> I think the key "healthcare" should be used instead of the new key
> health_amenity:type". If it's necessary to tag an MRI facility
> separately, then create a tag like "healthcare=mri".
>
>  However, it may be more useful to use a tag like "mri=yes" on the
> main amenity=hospital or the radiology department within the medical
> centre - this tag would let mappers say that "this hospital contains
> an MRI" without requiring mappers to precisely locate the MRI
> equipment within the building. This would also make it easier for
> database users: they can just check for "amenity=hospital" + "mri=yes"
> rather than doing a spacial query to find MRI nodes within or near an
> amenity=hospital feature
>
>
> On 6/20/19, Mhairi O'Hara  wrote:
> > Hello Tagging Mailing List,
> >
> > We would like to bring your attention and comments on the proposal for
> the
> > staff_count:doctors and staff_count:nurses tags, which helps identify the
> > number of doctors and nurses at a given health facility [1][2]. The
> > operational_status tag, which has been proposed before and I would like
> to
> > highlight again, as this is used to document an observation of the
> current
> > functional status of a mapped feature (i.e. health facility) [3]. The
> > health_amenity:type tag is also being proposed, as this indicates what
> type
> > of speciality medical equipment is available at the health facility [4]
> and
> > the final tag is insurance:health which describes the type of health
> > insurance accepted at a health facility [5].
> >
> > Some of these are already in use but have never been formally accepted,
> or
> > properly described as to how they should be applied, which we would like
> to
> > try and achieve if possible for the Healthsites.io project. Please take a
> > look at the proposal pages on the OSM Wiki, as well as the Global
> > Healthsites Mapping Project page [2] which is at the core of the recent
> > work focused on creating a health facility data model. We look forward to
> > discussing these proposals on the respective Wiki discussion pages.
> >
> > Kind regards,
> >
> > Mhairi
> >
> > [1]
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:staff_count:doctors
> > [2]
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:staff_count:nurses
> > [3]
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:operational_status
> > [4]
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:health_amenity:type
> > [5]
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:insurance:health
> > [6]
> >
> https://wiki.openstreetmap.org/wiki/Global_Healthsites_Mapping_Project#Tag_Proposal
> >
> >
> > --
> > *Mhairi O'Hara*
> > Project Manager
> > mhairi.oh...@hotosm.org
> > @mataharimhairi
> >
> >
> > *Humanitarian OpenStreetMap Team*
> > *Using OpenStreetMap for Humanitarian Response & Economic Development*
> > web 
> >  |  twitter 
> >  |  facebook 
> >  |  donate 
> >
>


-- 
Kind regards
Mark Herringer
www.healthsites.io
https://medium.com/healthsites-io
@sharehealthdata 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] Feature Proposal - RFC - Tag:staff_count:nurses

2019-07-11 Thread Mark Herringer
We understand there to be three approaches we can take here:

1 - Generalised numbers: In this approach we would specify and approximate
range for the nurse staff count e.g. 0-5, 5-10 etc.
2 - Aggregated numbers: In this approach we would specify an exact (e.g.
12) count of the nurses who work at the facility, without providing any
breakdown as to their speciality.
3 - Specific numbers: In this approach we would specify exact numbers per
discipline e.g. 2 Certified nursing assistants (CNAs), 4 Nurse
Practitioners (NPs), 5 Certified Nurse Midwives (CNMs)  etc.

Whilst 3 would probably be the idea we need to approach this in terms of
how likely we are going to be able to collect the data with rea,sonable
effort and potentially limited access.

In our approach we would like to work together with health ministries and
staff from organisations in the health cluster such as WHO or MSF which
would grant us more organisational access than a casual OSM user might
typically have. There are also issues with data maintenance that we should
consider - how do we ensure the information provided is current and correct
(this is also raised in the nurses section below). Thus we have some
dynamic tension between the desire to be completely accurate and current,
whilst still keeping our mapping goals attainable and practical.

Our proposed strategy to deal with this dilemma is to take an incremental
approach: establish a simple, workable, model to start with and start
populating it to keep momentum. Concurrently we will work on improving the
data model based on feedback from the people who would like to use the data
and the feedback of those collecting the data.

So may we propose that 2) above (aggregated numbers) would provide an
attainable and useful initial start and work with that whilst concurrently
engaging in discussions on how a richer, more useful data model might look
that we could adopt in the future?
ᐧ

On Thu, 20 Jun 2019 at 08:13, Joseph Eisenberg 
wrote:

> 2) "staff_count:nurses="
>
> *A. Source of information for this tag?
>
> How should individual mappers find out the number of nurses at a
> healthcare facility? If this information is imported from an external
> source, how can it be kept up-to-date?
>
> Most clinics in the USA do not show a list of nurses who work at the
> facility. While large hospitals may provide this information to the
> government, it may not be easy to find.
>
> Here in Indonesia there is often an organizational chart at the clinic
> which shows the staff who are supposed to work at the facility, but
> often only 1 or 2 or 0 of these staff members will actually be in the
> clinic on any given week. Sometimes they have been gone all year
>
> *B. Total staff or average number each day?
>
> Should this number be the total number of nurses employed at the
> facility or the total who are working each day?
>
> *C. RNs, CNAs, NPs, Midwives?
>
> In some countries there are many types of nurses. For example in the
> USA there are RNs (Registered Nurses), CNAs (certified nursing
> assistants), NPs (Nurse Practitioners), Nurse midwives, etc. - and
> here in Indonesia there are midwives, official nurses, and lower-level
> nursing care providers.
>
> Which of these categories is to be included in the number of nurses?
>
> -Joseph Eisenberg M.D.
>
> On 6/20/19, Mhairi O'Hara  wrote:
> > Hello Tagging Mailing List,
> >
> > We would like to bring your attention and comments on the proposal for
> the
> > staff_count:doctors and staff_count:nurses tags, which helps identify the
> > number of doctors and nurses at a given health facility [1][2]. The
> > operational_status tag, which has been proposed before and I would like
> to
> > highlight again, as this is used to document an observation of the
> current
> > functional status of a mapped feature (i.e. health facility) [3]. The
> > health_amenity:type tag is also being proposed, as this indicates what
> type
> > of speciality medical equipment is available at the health facility [4]
> and
> > the final tag is insurance:health which describes the type of health
> > insurance accepted at a health facility [5].
> >
> > Some of these are already in use but have never been formally accepted,
> or
> > properly described as to how they should be applied, which we would like
> to
> > try and achieve if possible for the Healthsites.io project. Please take a
> > look at the proposal pages on the OSM Wiki, as well as the Global
> > Healthsites Mapping Project page [2] which is at the core of the recent
> > work focused on creating a health facility data model. We look forward to
> > discussing these proposals on the respective Wiki discussion pages.
> >
> > Kind regards,
> >
> > Mhairi
> >
> > [1]
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:staff_count:doctors
> > [2]
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:staff_count:nurses
> > [3]
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:operational_status

Re: [Tagging] Feature Proposal - RFC - Tag:staff_count:doctors

2019-07-11 Thread Mark Herringer
Hi Joseph,

Thank you for your feedback.

We understand there to be three approaches we can take here:

1 - Generalised numbers: In this approach we would specify and approximate
range for the doctor staff count e.g. 0-5, 5-10 etc.
2 - Aggregated numbers: In this approach we would specify an exact (e.g.
12) count of the doctors who work at the facility, without providing any
breakdown as to their speciality.
3 - Specific numbers: In this approach we would specify exact numbers per
discipline e.g. 2 paediatric doctors, 4 general physicians etc.

Whilst 3 would probably be the idea we need to approach this in terms of
how likely we are going to be able to collect the data with reasonable
effort and potentially limited access.

In our approach we would like to work together with health ministries and
staff from organisations in the health cluster such as WHO or MSF which
would grant us more organisational access than a casual OSM user might
typically have. There are also issues with data maintenance that we should
consider - how do we ensure the information provided is current and correct
(this is also raised in the nurses section below). Thus we have some
dynamic tension between the desire to be completely accurate and current,
whilst still keeping our mapping goals attainable and practical.

Our proposed strategy to deal with this dilemma is to take an incremental
approach: establish a simple, workable, model to start with and start
populating it to keep momentum. Concurrently we will work on improving the
data model based on feedback from the people who would like to use the data
and the feedback of those collecting the data.

So may we propose that 2) above (aggregated numbers) would provide an
attainable and useful initial start and work with that whilst concurrently
engaging in discussions on how a richer, more useful data model might look
that we could adopt in the future?

On Thu, 20 Jun 2019 at 08:10, Joseph Eisenberg 
wrote:

> 1) staff_count:doctors
>
> Please clarify how this tag is to be used and how mappers can
> determine the information.
>
> Should it be the total number of physician's names listed on a sign at
> a clinic, or the average number of doctors in the clinic on a
> particular day? At large hospitals how should this information be
> checked and updated?
>
> For example, would it include only staff physicians, all physicians
> with admitting privileges, or all physicians that can come as
> consultants? What about medical doctors who serve in purely
> administrative roles?
>
> Are NPs and PAs included (i.e. mid-level providers)?
>
> While it may be reasonable to count the number of physician names
> listed on a sign at the entrance to a clinic or specialty office, it
> might not be possible to confirm the number of physicians employed by
> a large medical center. See Verifiability -
> https://wiki.openstreetmap.org/wiki/Verifiability - approved tags
> should be things that an ordinary mapper can confirm to be true or
> false.
>
> - Joseph Eisenberg, M.D.
>
> On 6/20/19, Mhairi O'Hara  wrote:
> > Hello Tagging Mailing List,
> >
> > We would like to bring your attention and comments on the proposal for
> the
> > staff_count:doctors and staff_count:nurses tags, which helps identify the
> > number of doctors and nurses at a given health facility [1][2]. The
> > operational_status tag, which has been proposed before and I would like
> to
> > highlight again, as this is used to document an observation of the
> current
> > functional status of a mapped feature (i.e. health facility) [3]. The
> > health_amenity:type tag is also being proposed, as this indicates what
> type
> > of speciality medical equipment is available at the health facility [4]
> and
> > the final tag is insurance:health which describes the type of health
> > insurance accepted at a health facility [5].
> >
> > Some of these are already in use but have never been formally accepted,
> or
> > properly described as to how they should be applied, which we would like
> to
> > try and achieve if possible for the Healthsites.io project. Please take a
> > look at the proposal pages on the OSM Wiki, as well as the Global
> > Healthsites Mapping Project page [2] which is at the core of the recent
> > work focused on creating a health facility data model. We look forward to
> > discussing these proposals on the respective Wiki discussion pages.
> >
> > Kind regards,
> >
> > Mhairi
> >
> > [1]
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:staff_count:doctors
> > [2]
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:staff_count:nurses
> > [3]
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:operational_status
> > [4]
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:health_amenity:type
> > [5]
> >
> https://wiki.openstreetmap.org/wiki/Proposed_features/Tag:insurance:health
> > [6]
> >
> https://wiki.openstreetmap.org/wiki/Global_Healthsites_Mapping_Project#Tag_Proposal
> >
> 

Re: [Tagging] Rethinking Map Features

2019-07-11 Thread Martin Koppenhoefer


sent from a phone

> On 11. Jul 2019, at 10:53, Paul Allen  wrote:
> 
> Oh, you mean how do you create a page for an in-use, but undocumented, key or 
> value
> in a way that won't cause somebody to throw a wobbler and insist you delete 
> the page?
> That's probably not possible. :)


People are setting up new pages continuously, most of them are not contested as 
a whole, but likely will be modified and amended in the details by other 
mappers. If someone insists on deletion there may be serious issues (but not 
necessarily). You can (and probably should) still set up a formal proposal for 
a definition at this point.

Cheers Martin 


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


Re: [Tagging] Rethinking Map Features

2019-07-11 Thread Paul Allen
On Thu, 11 Jul 2019 at 00:47, Graeme Fitzpatrick 
wrote:

>
> So how do we go with creating a page for a tag that is "in use" but has
> apparently never been discussed?
>

Same way you create any page.  Search for the key, or key=value and if it
doesn't already
exist the Wiki offers to let you create it.

Oh, you mean how do you create a page for an in-use, but undocumented, key
or value
in a way that won't cause somebody to throw a wobbler and insist you delete
the page?
That's probably not possible. :)

Last week, I asked about a Christmas shop, thinking about tagging it as
> shop=party, but it was pointed out that shop=christmas has actually been
> used 14 times, but apparently has never been discussed anywhere?
>
> Does that make it "in use" / "de facto"?
>

Yes.  One of those.  Probably.

Am I OK to just create a page for shop=christmas, so other people know it
> exists, or should it go through the full RFC / voting procedure to be
> "approved"?
>

>From  https://wiki.openstreetmap.org/wiki/Key:shop#Others you are allowed
to have user-defined
values for shops.  There's a bit of a chicken and egg situation, because it
implies you can only
use a user-defined value if it is commonly used (how common?) in taginfo,
which it won't be
until somebody uses it, which they can't because it's not in taginfo.

That said, if it is commonly used, or obviously (to most) sensible, then
I'd just add it to the shop
page and possibly create a page for the value.  Argument for: some editors
interrogate the
OSM wiki and/or OSM wikidata to populate drop-downs, so adding a page for
the value ensures
(maybe) it will appear in the drop-down.  Argument against: same as the
argument for, except
with things like denomination it ends up being a very large drop-down
(except denomination
appears no longer to get the drop-down populated by that mechanism).

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