Proposal talk:Customers

When is access=destination + operator=name-of-the-store not sufficiently correct? That's what I've mostly seen used. Alv 23:58, 15 January 2011 (UTC)

actually most shopping parking facilities are tagged access=permissive. the problem is, that this access type describes a role a person can hold, not a way of transportation and therefore is not exclusive. so a customer can also be a disabled person or a parent. i've posted my thoughts on this in the comments for the access page: http://wiki.openstreetmap.org/wiki/Talk:Key:access#access_structure_is_confusing_and_often_limited -- Flaimo 21:11, 15 March 2011 (UTC)

access=destination means by definition, that access is allowed if "this is the only road to your destination". This is meant for roads where transit is forbidden (usually in order to reduce noise in residential areas). This is obviously not what we are looking for (although some parking places can be used as shortcuts indeed). BTW: Most amenity=parking objects need retagging anyway because access=* is used where it should be vehicle=*. --Fkv 04:43, 15 May 2011 (BST)

Nitpicking on some words on the wiki doesn't change the real life: there are lots of roads tagged with =destination, where one can choose from several roads - i.e. none of them is the only road to destination, hence they couldn't be used for traffic if one takes a wiki sentence literally. The effect of destination is, that entering is allowed only when one doesn't need to use anything not tagged with destination afterwards, before reaching their destination. The intention is the same: only enter if your destination is within. Sure, in some countries permissive access makes sense, but in others the whole concept is absurd for anything located outside. Alv 16:23, 15 May 2011 (BST)

I don't think it's nitpicking. We need to tease apart these issues into conceptually coherent units. I think access=destination meaning "you may not access this in general, but you may do so in order to reach a destination" is different from access=customer meaning "you may not access this in general, but you may if you're a customer of the operator". They're both quite narrow categories, but they're quite common in actual use (I mean in life, not in OSM). --Danstowell 10:30, 14 July 2012 (BST)

i would vote no for this proposal because, i think that the access tag in general needs to be corrected. and then, "customer" could be integrated by default. -- Flaimo 21:11, 15 March 2011 (UTC)

Does a new value access=customer hinder your access refacturing proposal in any way? --Fkv 04:43, 15 May 2011 (BST)

Checkout that access=customers is more used. http://taginfo.openstreetmap.org/tags/access=customers

I'd vote yes to the proposal. I tag plenty of urban stuff where access is "customers only" and this is an important category that people will need to know in routing etc. If the crowd decision is to stick with access=destination then fine but I think that's a muddling of two distinct concepts. --Danstowell 10:30, 14 July 2012 (BST)

This seems to be a good idea. But to use this right, there must be some way to tell, what shop's customers are ment by access=customer. The site relation was proposed, but I'm not sure, this would be appropriate since it would group for example shops together, that are not really associated, even if they are sharing parking space. Something like associated_parking might be better.

Discussion originally from Talk:Key:access

The access=customers was added only recently in April 2011, as a copy from the Parking page. Its propagation needs to be stopped. For a parking lot the value for customer access has been permissive or destination from the start; the meaning of access=customers would be a more specific case of access=permissive - the owner generally gives access, but can choose to remove access at any time, for any reason. The access=customers is not yet used too much, only 1600 times, to have users convert them to permissive or destination. With those 1600 uses it can be documented somewhere, but the list of accepted main values on this access=* page should list only the established core values. Alv 13:12, 23 May 2011 (BST)

for this current scheme, i agree, that user roles shouldn't be added left and right. permissive for customer parking is enough. --Flaimo 16:22, 23 May 2011 (BST)

access=permissive isn't really accurate, though, in the case where a sign says "customers only". In that case, barring a new tag, I'd use access=private rather than access=permissive. In my opinion the "general permission" in access=permissive means anyone can use the [whatever] unless the owner specifically says they can't, whereas access=private means no one can use the [whatever] unless the owner specifically says they can. "Customers only" would be an instance of the latter. Anthony 02:21, 4 June 2011 (BST)

I wholeheartedly agree. "Customers only" is not permissive, one glance at its definition makes this unambiguously clear. destination appears to be the best choice if we want to stick with the existing tags. Though I could certainly see the point be made that semantically customers is the sounder option, but that distinction is of lesser importance. What is much more important is the matter of how to tag the associated business or, even more complicated, businesses! Tagging such a restriction is pretty much useless if we do not at the same time give the permitted uses. Is there an established schema? --Silanea 12:19, 22 July 2011 (BST)

for associating a parking lot with a business, you can use the operator tag on the parking lot which could be the name of the business. while "permissive" might not be ideal, it still the best match under this access scheme. for a new scheme you could take a look at this proposal i wrote: http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/access_restrictions_1.5

operator is not always appropriate. A parking lot may be run by one company on behalf of the shop owners in the vicinity (think: big shopping centre). So we have an operator, company X, and a slew of businesses for whose customers the parking lot is a valid destination. This case is not hypothetical: Many bigger shopping centres require parking tickets but will refund some or all of the ticket cost to people who actually shop at one of the associated businesses. How do we tag this? --Silanea 22:42, 16 August 2011 (BST)

that is why i wrote the proposal mentioned above. together with the already approved parking proposal from may 2011 this would solve most user role problems including "customer". --Flaimo 11:43, 17 August 2011 (BST)

Still figuring out whether all the restrictions I have come across so far map onto this scheme. :-) This may indeed be the Big Thing. --Silanea 14:24, 18 August 2011 (BST)

If the shop is inside a shopping center, that is evident from the data, and the operator for parking can then be the shopping center. Alv 16:53, 18 August 2011 (BST)

Firstly in many cases the shopping centre is not the operator. Someone else is, on their behalf. Secondly I can think of two major cases along my daily commute where the related shops that share one parking area are not organised in a unified shopping centre. Thirdly forget shopping centres and look at the general case of one parking facility being shared amongst a group of entities, be that in a residential area, a business park with offices or a bunch of shops. I hope I do not come across as rude, that is not my intention. I am banging my head against the wall trying to understand the implications of tagging such properties and I am currently looking at some examples of Flaimo's proposal applied to parking facilities in my mapping "home zone" to see if it works. In my mapping work so far access has been the second most problematic tag, topped only by the subtypes of building. I really hope for a tagging scheme that enables us to answer the question "Can and may I go there?" for anyone and for anything that is on the map. Call me a dreamer, heh? :-) --Silanea 23:03, 21 August 2011 (BST)

In the end it's irrelevant if it's tagged operator= or destination= or for_customers_of= - it's a parking lot that just happens to be nearby, and any of the nearby lots with =yes, or =permissive, or =destination with a suitable additional criteria, is as good as the others if the trip destination is known to the software at that time. Alv 14:03, 22 August 2011 (BST)

I'd rather see access=restricted (access is given by the owner under certain conditions), as something in between access=permissive and access=private. Then access:restriction=customers_only could specify the restriction. I think this would be easier on the routers when people decide to add new types of conditional access, rather than having lots and lots of things all under different access=* tags. Anthony 02:17, 4 June 2011 (BST)

On the parking page, the access tag's possible values are listed as "yes/customers/private". Perhaps "permissive" or whatever tags are preferred should be added there? This will prevent users from assuming that one of the three above values is best. --Douglas P Perkins 01:15, 14 June 2011 (BST)

I think the customer tag is really needed, because "access=permissive" is a parking lot that is "Open to general traffic" as stated in the wiki, while "access=customers" says that the parking lot is open for a special group of people, the ones who are customers of a shop, etc. Its also a matter of usage. When I want to go to a restaurant and look at the map where to find a parking lot and I find a parking lot directly beside the restaurant I need all three tags to know if I can use it. If "access=Private" I have to search for another. If "access=permissive" I'm generally allowed to use it. With "access=customers" I know that I may use it, BUT ... Now what is missing in my opinion. There is no relation to what that says whose customers are allowed. Are the customers of the restaurant I want to got to are allowed to park there or the customers of the shopping centre on the other side of the parking lot. So I would suggest to keep the "access=customers" tag and add a relation what it belongs to. --Maptin 11:05, 7 August 2011 (BST)

Permissive inherently implies that the lot owner has the right to disallow access, even if it's generally open to traffic. You'll never now for certain if anything tagged as permissive is open at any given time, not until you reach said object. "Customers" is still a role and roles don't make good values - you'll soon have a slew of different values (say, access=jury, as was mentioned on the talk mailing list) and cases with concatenated values, i.e. access=customers;employees Alv 16:53, 18 August 2011 (BST)

It depends on what you want to do. If I ask a navi for the nearest parking lots, I assume that it just shows me those available for general use. A public Parking lot is a parking lot with no or few restrictions, but a parking lot of a shop center is a parking lot where Parking is not allowed, except for customers. "access=customers" might not be the best way to specify the restrictions, but it's better than "access=permissive", because such parking lots are not for general use. --Ancpru 15:06, 19 March 2012 (UTC)

I agree, access=destination is the right way to tag that. Lulu-Ann

I wonder why a discussion was started here when there was already a proposal on this. Please note that the proposed tag value is in singular case (access=customer) because singular is generally preferred for tag values (eg. shop=car instead of shop=cars), and key names in the access scheme are singular too (eg. horse=*, bicycle=*). --Fkv 19:32, 28 September 2011 (BST)

Thanks, I've taken the liberty of moving the discussion here.--Danstowell 10:31, 14 July 2012 (BST)

customer vs. customers

As of now there are far more access=customers than there are access=customer. I propose acknowledge this in the proposal. --Dieterdreist 18:15, 11 September 2012 (BST)

At the beginning, I preferred the singular case, but the plural is obviously more intuitive and more tempting to use.

Whatever we decide for, we should unify the existing tags in the database as soon as the proposal is approved. --Fkv 19:18, 11 September 2012 (BST)

I think, most keys and tags are explicitly singular, so we probably should stay with that. Also, I don't see how plural would be more intuitive. It isn't to me, but this might be different for everbody. --DLichti 10:45, 14 September 2012 (BST)

I agree that plural might be more intuitive (a shop normally expects more than one customer), but apart from that, JOSM seems to propose the plural form to me, and not the singular form. So that might be the reason why there are so many plural tags in the DB. --Sanderd17 19:19, 29 September 2012 (BST)

+1 for plural --Bigfatfrog67 (talk) 10:18, 17 October 2013 (UTC)

I am moving this page to plural form to reduce confusion Bulwersator (talk) 07:00, 11 May 2014 (UTC)

Which business?

Okay, how shall we tag a parking lot surrounded by a number of businesses but designated for the customers of only one of the businesses? A case in point: the parking lot for North Lake Tahoe Visitor Information Center. T99 (talk) 08:35, 12 August 2013 (UTC)

I would say that you put access=customers and the operator=[name of business] on the car park, in fact I do that in most car parks, whether there is ambiguity or not, it is good practice to put the operator tag on every car park. --Bigfatfrog67 (talk) 10:18, 17 October 2013 (UTC)

Agreed that operator=* should be marked as a useful combination --achadwick (talk) 10:53, 23 June 2014 (UTC)

Hospital parking for patients or visitors only

Is this the preferred tagging for hospital parking which is marked for patients or visitors only? It's not private since it's an open agreement, but it's not permissive either since it's not open to general traffic. --achadwick (talk) 11:11, 23 June 2014 (UTC)

Dutch Railway Stations only accessible for customers

In the Netherlands more and more we'll see the situation where you can only enter the Railway station using a chipcard (OV-chipcard) to open the gate to the platforms.
Can travellers be considered as customers? --Marczoutendijk (talk) 19:53, 26 February 2015 (UTC)