Won't work in the US, as values have a size limit of 255 bytes, and there are more *insurance plans* than that in the US. You might be able to pack everything in by treating the value as a bitfield.
-- Mark On Fri, 2 Aug 2019 16:52:22 +0900 Joseph Eisenberg <joseph.eisenb...@gmail.com> wrote: > I’m normally not in favor of semi-colon separated values, but this > seems like a situation where it is better, since there would be > hundreds or thousands of keys otherwise. > > eg =Medicare;Medicaid;Blue_Cross (USA) > =BPJS_Kesehatan;Papua_Sehat (Indonesia) > > It will still be hard to keep this sort of data maintained, either > way, in some countries, but it may work ok in places with only a > handful of insurance options. > > Joseph > > On Fri, Aug 2, 2019 at 4:41 PM Simon Poole <si...@poole.ch> wrote: > > > > > Am 02.08.2019 um 09:26 schrieb Rory McCann: > > > On 02/08/2019 08:42, Warin wrote: > > >> It is possibly that some will only accept certain insurance > > >> firms and reject others. I am thinking of insurance firms that > > >> run some medical facilities. > > > > > > We use subkeys for payment types (`payment:american_express=no`), > > > wouldn't this work for insurance companies? `insurance:vhi=no`, or > > > `insurance:health:vhi=no`? > > > > The problem with this, just as with payment, that it creates a > > (practically) unbounded list of keys, that rely on being able to do > > a search on keys to be discoverable. > > > > Simon > > > > > > > > > > > > > _______________________________________________ > > > 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
