Proposal talk:Additional Food Shelf Tags

Existing alternatives

social_facility:for=* might be suffixed as social_facility:for:max_income=* etc, so that there's no need to create a bunch of raw top-level attributes. This keeps what's relevant to the targeted group together to be more organized.
That said, its scalability/extensibility now is not good enough. It mixes demographics and the social conditions. This means can't handle a combination of those factors facing those conditions. Underscore causes a conflict with other vals, and isn't really flexible or structured. The meaning of comma isn't reliable, and may be misunderstood as mistakes.
Over-namespacing is a concern. If the attributes is generic that they can be used in other features, they can be kept short by being non-namespaced.
Therefore the future of social_facility:for=* better be considered together. Only then can we see what method is better.
In case *:for=* is not good or not enough, I can think of *criteria:*=* from heritage:criteria=* . That's close enough. No need to invent that eligibility:*=* separately.
Ideas mostly based on using social_facility:for:*=* :

• max_income=*
  • I'm hesitant about having *=yes . In theory, an income level may ultimately be entered. Basically all other max*=* has an exact restriction specified, except *=unlimited , *=default , and *=unknown . Format-wise, mixing different data types is not ideal.
  • Fundamentally, whether this info belongs to OSM in the first place needs to be considered carefully. It may be better placed in the linked website, or eg Wikidata.
  • Furthermore, it can't show how strong the requirement is. Cf reservation=* , membership=* , and snow_chains=* having *=required , *=recommended , andoptional=* . *=yes is reserved for an unspecified positive there, when we don't know more.
    • Standalone (eligible if low income alone) : This partially overlaps with social_facility:for=underprivileged in the "poor" sense
    • Combination (low income people facing other conditions)
    • Prioritized (higher in a wait list if there's one)
    • Negotiable (Can be reviewed case-by-case depending on your other circumstances even if you exceeded the limit)
  • So one possibility is for this to be split with eg social_facility:for:income=* . This is where changing to eg *criteria:income=* would be more logical. *max_income=* can then be reserved for entering the actual income level, or ignored if concluded to be out-scope in OSM.
  • The other
• location_restriction=* → service_area=* : It has been used in Taipei for what residents the emergency:*=* contingency facilities receive. However, listing different locations of different levels together here is unorganized. I suggest to refer to the above for what service_area=* may take.
  • location_restriction:location=* → service_area:*=*
    • location=* is used for pre-defined positions. Having a different meaning in suffix is not ideal when there are alternatives. There are offenders viz defibrillator:location=* , but it should really be fixed and not allowed to spread further. Besides, that's described in freeform text, not individual locations. There would no uniformity in how *:location=* should be used.
    • service_area:street=* and/or service_area:suburb=* etc would be well-supportable as addr:*=* and post:*=* are. (not to mention other derivations contact:*=* , object:*=* , fire_hydrant=* ; however I see other problems in them)
• collection_type:*=* : It is mixing many aspects here, self-served vs handed by staff, on-site vs online vs phone ordering, and free vs fixed selections. They should be separated. collection_type:phone=* also makes it seem you can call and have it delivered to you.
  • collection_type:self_service=* , collection_type:in_person_checklist=* → self_service=*  : This is already prevalent. While some question remains as to what exactly it means, it's still usable. Talk:Key:self_service#Untitled
  • collection_type:online_checklist=* , collection_type:phone=*
    • Honestly I recently dissuaded Proposal:Add ability to specify ordering-only phone number, sms-only phone numbers and related tags from creating ordering:*=* , including ordering:url=* and ordering:phone=* . Maybe it's needed here, but I'm unsure whether the process in food banks should be considered as registering or "pre-ordering" what you will pickup instead.
    • I'm assuming reservation=* should be reserved for a time slot you visi. However there are also reservations where you have to pre-order what you eat, get, or receive together. Submitting to or calling the food bank beforehand reminds me of this.
    • A far-fetched option would be to co-opt takeaway:*=* for takeaway:url=* and takeway:phone=* !... I believe food banks can offer delivery=* as well.
  • collection_type:in_person_checklist=* , collection_type:standardized=*  : This is difficult.
• emergency_bay=* : Don't know what it is. Await your definition.
• usage_limit=* : Same concern as max_income=* above. Ideally, specify the limit from start.
  • usage_limit:frequency=* → maxvisit=* : In street parking, there is a common restriction of no revisit in the day. A generic attribute can be proposed for use in all features. The format can be similar to charge=* , use maxvisit:conditional=* similar to maxstay:conditional=* . Using max*=* makes it more consistent with max_income=* .
    • *:frequency=* is somewhat used for waveforms following frequency=* , eg railway:signal:radio:frequency=* , and beacon:frequency=* (although I don't know why airmark=beacon + frequency=* isn't acceptable). Technically, "frequency" is number of occurrence within a time period.
    • max_use=* : Used on amenity=locker and amenity=luggage_locker , akin to a maxstay=*
    • water_point:max_use=* : Exact quantity you can use each time, not how many times you can use it in a time period
• eligibility=* → social_facility:for:*=* : Separating eligibility=* from max_income=* and location_restriction=* already seems unorganized. They refer to the same aspect.
  • eligibility:website=* → social_facility:for:url=* : As this has content inside, *:url=* seems more suitable.
    • *:website=* is mainly used for the website of an identified entity, eg brand=* , operator=* , network=* , and heritage=*
    • *:url=* has been used in opening_hours:url=* to show how you can lookup the attribute from the link
• supershelf=yes → network=SuperShelf / brand=SuperShelf (need to consider they are organized first): Don't do it for every certification, programme, project , etc possible. This can have *:wikidata=* etc added, allowing every initiative anywhere can be handled.

Therefore for Proposal:Additional_Food_Shelf_Tags#Examples :

• social_facility:for:income=unlimited / social_facility:criteria:income=unlimited / max_income=unlimited (again, I personally don't favor extend social_facility:for=* too much without a review, as it has its limit)
• service_area=no (The val is to be clarified)
• maxvisit=unlimited
• self_service=only

Yes, this is very long. But you can expect the number of comments to be proportional to how many you are proposing. It's a reason why you should start small.
—— Kovposch (talk) 08:31, 13 June 2024 (UTC)