On Thu, May 20, 2010 at 7:36 AM, Tyler Gunn <ty...@egunn.com> wrote: > > > Access=private works fine, then (along with access=public > > andaccess=permissive). Preferably with an additional tag (or relation) > > withsome indication of who is allowed to park there. > > Maybe access=customer isn't needed after all. > > How about something like: > access=private > permitted=patron/permit_holder/staff > > There's probably other valid permitted types, but this organization would > handle the following types of situations quite well: > - Public parking lot (ie you come here and pay to park, regardless of > where you're going): access=permissive > - Store parking lot for customer: access=private, permitted=patron > - Store parking lot for staff only: access=private, permitted=staff > - Parking lot for monthly parkers: access=private, permitted=permit_holder > > A relation to define what businesses are served by the lot could be > something like: > type=parking_use > Where you'd have member roles: > lot: a parking lot(s) > for_use_by: the business(es) that the parking is intended for. > I think in most circumstances it is probably pretty clear which business a > parking lot is intended for though.
Rather than permitted=*, why not use parking_use=*? That would then be consistent with your proposed relation. Though "permitted" is more general and might be able to be generalised to other features... I suggested a similar solution a couple of days ago: "Alternatively, for parking, use the key "use" (as a noun) instead of [or in addition to] access, as in use=public/customer/private." There are then a few options for defining the values of parking_use, e.g. my public/customer/private or your patron/staff/permit_holder, or some combination thereof... _______________________________________________ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
