[Tagging] Feature Proposal - RFC - health_amenity:type
Simon Poole
simon at poole.ch
Fri Jul 26 08:15:37 UTC 2019
Am 26.07.2019 um 02:19 schrieb Joseph Eisenberg:
> There are still 2 problems with healthcare:equipment:
>
> 1) Healthcare:equipment is yet another new feature key for database
> users to support, if tagged on its own node at the location of the
> MRI. This requires Osm20gsql users like the main Openstreetmap-Carto
> style to reload the whole planet database before this key can be
> supported for rendering, routing or search applications. Using
> amenity=MRI or healthcare=MRI would be easier for current database
> users to support and it’s shorter for mappers to type.
That applies equally to health_amenity:type, in any case anybody wantig
nto support outlandish keys will be running with hstore enabled.
>
> 2) If you want to add this as a tag to an amenity=hospital, then you
> can’t add both an MRI and a CT scanner, for example, since a key can
> only have one value.
>
Multi-value keys are in widespread use, and when they represent lists
totally unproblematic.
Simon
PS: waiting for the first posts requiring that the absence of equipment
is taggable.
> So in that case you still need MRI=yes as an addition key to tag on an
> existing facility. I suspect this tagging will be more common than
> mapping the MRI separately, and it certainly will be more common for
> ultrasounds, which are on wheels (casters) usually and can move around
> the hospital.
>
> Joseph
>
> On Fri, Jul 26, 2019 at 4:01 AM Mhairi O'Hara <mhairi.ohara at hotosm.org
> <mailto:mhairi.ohara at hotosm.org>> wrote:
>
> Hello everyone!
>
> I completely agree with Warin that the *health_amenity:type* tag
> is pretty confusing as to what its referring to. I was trying to
> stay in line with what was proposed previously, but in retrospect
> it would be better to move away from previous efforts and vote in
> a tag that is straight forward and easy to understand (says what
> it is).
>
> The main aim for the tag is to encapsulate that its related to
> health equipment, so how about *healthcare:equipment*?
>
> Kind regards,
>
> Mhairi
>
> On Sun, Jul 14, 2019 at 4:43 PM Warin <61sundowner at gmail.com
> <mailto:61sundowner at gmail.com>> wrote:
>
> This is about the equipment available?
>
> Using the principle of 'say what it is' ...
>
> medical_equipment=MRI ??? Assuming the tag is for equipment.
>
> Calling the key health_amenity:type "in use" is a stretch - 40
> uses .. and most of these are for first aid kits!
> The next most popular is "scales".
> Fist aid kits have the tag emergency=first_aid_kit ... which
> is more popular (170) despite it being a "draft".
>
> No, I don't think is is "in use" nor has it been used in a
> sensible way. Probably because "type" can mean anything.
>
> health_facility:type has the same problem, despite being more
> popular, uses are for
> dispensary
> office
> clinic
> hospital
> etc
>
>
> On 14/07/19 23:18, François Lacombe wrote:
>> Hi Mark,
>>
>> I agree with your choice to specifiy which service are
>> available in a given facility.
>> This doesn't require to add :type in the name of the key.
>> Such suffixe don't bring any information.
>> Your proposal would be way better if you use
>> health_amenit=MRI at least instead
>>
>> All the best
>>
>> François
>>
>> Le jeu. 11 juil. 2019 à 21:10, Mark Herringer
>> <mark at healthsites.io <mailto:mark at healthsites.io>> a écrit :
>>
>> 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
>> <joseph.eisenberg at gmail.com
>> <mailto:joseph.eisenberg at gmail.com>> 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 <mhairi.ohara at hotosm.org
>> <mailto:mhairi.ohara at hotosm.org>> 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.ohara at hotosm.org
>> <mailto:mhairi.ohara at hotosm.org>
>> > @mataharimhairi
>> >
>> >
>> > *Humanitarian OpenStreetMap Team*
>> > *Using OpenStreetMap for Humanitarian Response &
>> Economic Development*
>> > web <http://hotosm.org/>
>> > | twitter <https://twitter.com/hotosm>
>> > | facebook <https://www.facebook.com/hotosm>
>> > | donate <http://hotosm.org/donate>
>> >
>>
>>
>>
>> --
>> Kind regards
>> Mark Herringer
>>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org <mailto:Tagging at openstreetmap.org>
> https://lists.openstreetmap.org/listinfo/tagging
>
>
>
> --
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20190726/ff847512/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20190726/ff847512/attachment-0001.sig>
More information about the Tagging
mailing list