Proposal talk:Vaccination

CSV vs name space

With the probably unavoidable discussion about using name space or CSV for multiple values, i.e.

vaccination:covid19 = yes
vaccination:influenza = yes
vs.
vaccination = covid19;influenza

my position is to follow the recommendation of the targeted primary key healthcare:speciality where the wiki says:
"If a medical practitioner or a medical facility covers several specializations, they could be separated by a semicolon", which was indeed part of the original approved healthcare proposal.
Thus I propose to use CSV for the vaccination key as well. --Polarbear w (talk) 17:20, 24 November 2020 (UTC)

While Semi-colon_value_separator is allowed, it is poorly supported by tools (as noted in the linked wiki). vaccination=covid19;influenza would cause many data consumers looking for vaccination=covid19 to not find it. Further, the specific case of influenza+covid19 is a combination that may be quite common in the future. I would urge you to reconsider semi-colon separation for a key that may have an indefinite number of values. Also, with multiple vendors producing vaccines, the vaccine:covid19=* might even be extended in the future to indicate whether a fee must be paid, which variant of the vaccine is being offered, etc. While I realize you are just attempting to define the first value of a new key, I think it's important to do a bit of future-proofing to consider how the tagging might grow over time. --ZeLonewolf (talk) 18:24, 24 November 2020 (UTC)

I see this as a clear case for which the CSV wiki page says In the case of additional, describing tags, there is often no better way to tag diverse properties and combinations of them. Here, semicolons are in wide use for these 'detail' tags where several values are common (e.g. cuisine=*, destination=*, material=*).
I am not convinced that querying a substring is particularly difficult for any data consumer, since every language has some substring() function, in a regular expression it is simply '.*searchterm.*' and in Overpass it is simply a tilde '~'.
I expect the number of potential values to be quite limited, in particular as group names of combinations are possible. For the flu+covid combination, society will coin a term when such things become available.
Finally I'd discourage mapping any manufacturers of vaccines since that is not ground-verifiable and can change rapidly. Also I'd discourage any payment schemes, this is not like a parking fee for everybody, it depends on insurance systems, being citizen/foreigner, temporary policies for mass participation etc. --Polarbear w (talk) 15:18, 4 December 2020 (UTC)

I agree that this is a valid and preferred use of semicolon-separated multiple values. It will be more work for mappers to add a whole list of separate tags. Consider that most clinics in Western countries will offer a dozen vaccinations to children and adults. My clinic currently offers vaccines for: 1) Polio, 2) Pertussis, 3) Tetanus, 4) Diphtheria, 5) Hepatitis B, 6) Pneumonia, 7) Measles, 8) Mumps, 9) Rubella, 10) Varicella, 11) Meningococcus, 12) HPV, 13) Influenza, 14) Herpes Zoster, 15) Rotavirus, 16) RSV... it would be easier to keep those all in one value rather than creating a key for each one. Another consideration is that many of these vaccinations are available in special combinations or different formulations: for example there are 2 major types of pneumonia vaccination which cover different strains for children and older adults. It's easier to add different possible values (for mappers and database users) rather than looking for a whole set of unique keys: vaccination=mmrv is easier to understand as a synonym for vaccination=measles;mumps;rubella;varicella rather than looking for vaccination:mmr=yes/no, vaccination=mmrv=yes/no, vaccination:meales=yes/no, vaccination:mumps=yes/no, and vaccination:rubella=yes/no --Jeisenbe (talk) 19:38, 4 December 2020 (UTC)

I'm sure it's been discussed before, but my issue with one key is the technical size limitations of OSM key value pairs. However even your example of vaccination=Polio;Pertussis;Tetanus;Diphtheria;Hepatitis B;Pneumonia;Measles;Mumps;Rubella;Varicella;Meningococcus;HPV;Influenza;Herpes Zoster;Rotavirus;RSV comes in at 144, so will comfortably fit. I'm voting to approve, but would have preferred a namespace. --CjMalone (talk) 22:58, 10 December 2020 (UTC)

CjMalone, thanks for your voting. On the topic here, I have strong doubts that there is an interest and/or ground evidence to map all individual diseases being vaccinated against. As said, it is possible to use group values such as tropical_diseases etc, and as Jeisenbe already pointed out, even vaccines themselves are combined for several applications. We could even say "=multi". Thus I'd consider a value overrun theoretically possible, but with no practical relevance. It's like we are not adding all diseases a hospital could cure, I'd say.--Polarbear w (talk) 15:59, 11 December 2020 (UTC)

You're actually chaining my option to oppose, when this tag isn't inclusive of all the vaccines it becomes impossible to negatively tag a vaccine. eg a centre that does multiple tropical vaccines, except for Malaria where you go to a different expert. Or if basically all doctors surgeries in a country give a influenza vaccine, how do you tag the one that does not? --CjMalone (talk) 17:32, 11 December 2020 (UTC)

Primary feature tag

We need a new main feature tag for vaccination-only locations

The proposed new tag, vaccination=<Illnesses against which vaccinations are available>, seems like a reasonable idea.

However, it might be necessary to discuss a main feature tag to use in the case when these are not administered by a clinic or doctor's office or hospital. There does not seem to be a widely used, suitable tag under healthcare=* or amenity=* for a place that specializes in administering immunizations only.

healthcare:speciality=vaccination is not a primary feature tag, but a secondary tag which needs to be added to something under the key amenity=* or healthcare=*. Perhaps amenity=vaccination_centre would work? --Jeisenbe (talk) 06:38, 26 November 2020 (UTC)

I agree that a main physical tag is useful, however it is intentionally not part of the voting part of this proposal. I'd prefer to let that develop on the ground, or maybe in a separate discussion. I consider different approaches as valid, in particular:

• keeping the main tag as is from the facility that is temporarily used, e.g. the centre is in a sports facility, leisure=stadium + healthcare:speciality=vaccination + vaccination=covid19, in particular when it fully occupies the facility
• using a main tag from the healthcare or amenity key for a new POI. Your amenity=vaccination_centre might work, I have also seen healthcare=centre being mentioned.

--Polarbear w (talk) 15:27, 4 December 2020 (UTC)

Unfortunately healthcare=centre has never been defined. It has been used for anything from large inpatient "medical centers" (usually known as "hospitals") to outpatient "surgery centers" (usually called "clinics" or a "surgeon's office") to "village health centers" which don't have a physician on staff, depending on the country. That is why I recommend picking a tag. I expect that either amenity=vaccination_centre or healthcare=vaccination_site or anything similar would work; the exact value is not so important. --Jeisenbe (talk) 19:27, 4 December 2020 (UTC)

Hm that's a pity. I hadn't checked the tag when somebody mentioned it. It would be nice to have a physical tag that is agnostic of the activity, specify the activity in healthcare:speciality, and finally the disease being fought in the vaccination=* tag. --Polarbear w (talk) 20:58, 4 December 2020 (UTC)

Usage observations

As of 2020-12-05, 17 features have been tagged with "vaccination=covid19", in conjunction with the following tagging:

Primary tag:

• "healthcare": "yes" 1
• "healthcare": "centre" 14
• "amenity": "hospital" 1
• "healthcare": "hospital" 1 (in addition)
• "amenity": "vaccination_center" 1 (AmE spelling)

Speciality tag:

• "healthcare:speciality": "vaccination" 16
• none 1

Simplicity and visibility

We should try, to develop a tagging as simple as possible

It seems, that in the future we will need vaccination centres not only for covid-19. As I wrote in the German forum, therefore the tags should have the following features.

• It should be included the name of the epidemic e.g. vaccination=covid19
• If necessary it shoul include the name of the city or region to provide for e.g. name= Covid19Impfzentrum_Kreis_Hintertupfingen
• A navigational-app should be able to route to this POI
• These POI's should be visible also on the mean-map and the H.O.T.-map (I know, that is tagging for renderers, but it is necessary in this special case)

and last but not least

• after the end of the pandemics the prevailing Tags should be removable by a bot (This can be realised, if the name of the epidemic is included in the tags)

Please read also the really interesting suggestions concerning this in the German forum --Aeonesa (talk) 14:10, 3 December 2020 (UTC)

I had cited the German forum and answered there already, a day before you recommended me to read it.
Regarding your points:
Yes the name of the disease is included in this proposal. The name of a vaccination centre, if there is a specific one, can be given in the name tag as usual (not condensed and not with underscores). Generic descriptions can be given in the 'description' tag. How a router finds the POI is up to them, typically via their search function. How maps show such centres is up to them, however an agreed tagging scheme is helpful here. We should, as always, NOT "tag for the renderer', in the sense that we should not abuse a different tag just to enforce particular rendering. There were maps being produced during the first lockdown (stays open), they will most easily embrace the vaccination development. As the pandemic will not end on a particular day, I expect temporary facilities to be closed over a larger period of time, which will be followed by the local mappers. I do not see this as a case for a bot. --Polarbear w (talk) 16:22, 4 December 2020 (UTC)

Why I think the Covid-19 have to be visible

I did not ask especially you to read the forum. It was only for the common information of all readers of this proposal, that there are interesting ideas.

That I separated the name-Tag by an underline, was only taught as an explanation, which items should be included in the name. So you can see I am rather an user of tags, than a developer.

Yes it is up to the router how to find a POI and ap to the renderer to make it visible. But IMHO it is very important, as a participation and a support of the OSM community to the fight against Covid-19, that a router will find it and that it will be visible on the relevant maps (like written above). So it makes sense, to develop tags, that they will be found on the relevant maps and by routers. That makes it easier for a lot of peoples, to find these centres, with our help. Wasn't that the aim of this proposal, was it?

I am afraid, that a lot of such centres will be forgotten after the pandemics; especially in regions with only a few mappers. For that case we have bots. And IMHO it is so easy, to develop te tags, that bots can find them. About this theme I wrote explicitly in the German forum. So I do not want,to explain it again and again.--Aeonesa (talk) 11:18, 5 December 2020 (UTC)

Any tag can be found by a bot, there is no specific property of a tag to make it "bot-findable". Here is an overpass search for the proposed vaccination tag, there are 17 mapped already: https://overpass-turbo.eu/s/10Tu --Polarbear w (talk) 17:34, 5 December 2020 (UTC)

Please tell me, how a bot can find such tagging, if each mapper will use another tagging scheme. At the end of the day for me it does not matter, what is written in your proposal. I wrote my opinion about your tagging scheme. If you do not want to take in consideration even only a few ideas, it is your option. I can not do more than bring in ideas.

B.t.w. The test centre and the vaccination centre in Pirmasens is not visible on the osm.org-map --Aeonesa (talk) 19:04, 5 December 2020 (UTC)