Usage of access=private tag in Conjunction With Private=

Adamant1 · 2017-11-19T09:07:39.000Z

Hi. So I have been taging residential swimming pools for a while now with access=private and than adding private=residents. I was just looking through the wiki though I could not find a page for the private tag. So I am wondering if I am labeling swimming pools wrong or if there is no wiki for the private tag because one just has not been created yet. There seems to be multiple options that on ID that can be added to the private tag, like residents, costumers, or drive. So it does seem like people are using it. But from reading the wiki page definition for access=private it seems like that would be sufficient on its own without adding the extra private=resident tag on to it. So I appreciate any advice. Also, if private= is a valid tag, can someone point me to a guide on how I can create a wiki page for it and where I can find the statistics for its sub tags? If I go that route, id like also like to add the sub tag “employees” for employee parking areas, or if not, maybe it could be added to the access tag. Any ideas on what to do on that situtation would be appreciated also. Thanks.

Brian_de_Ford · 2017-11-19T11:59:25.000Z

Adamant1:

Hi. So I have been taging residential swimming pools for a while now with access=private and than adding private=residents. I was just looking through the wiki though I could not find a page for the private tag. So I am wondering if I am labeling swimming pools wrong or if there is no wiki for the private tag because one just has not been created yet.

I can’t find anything for a private tag in the wiki. Which implies it’s not valid usage.

There seems to be multiple options that on ID that can be added to the private tag, like residents, costumers, or drive.

I believe iD interrogates the database to find keys and values that have been used by others in order to guess what you might be trying to do. In that respect the database (and hence iD) is like English dictionaries and not French ones. English dictionaries reflect how people use (and misuse) language; French dictionaries tell you what is permissible. So anything that has been used/misused/abused in the past will be available as a suggestion in iD. Even typos.

I’d check with iD but it’s not been loading properly for me for the past three days. Despite begging people in this and the editors fora to tell me if iD is working for them (so I can figure out if it’s me, my ISP, or iD’s servers) nobody has responded. If you could do me a simple favour…

So it does seem like people are using it.

Not many. Not many at all.

But from reading the wiki page definition for access=private it seems like that would be sufficient on its own without adding the extra private=resident tag on to it.

Or you could use access=residents. Around 950 people have used access=residents; around 80 people have used private=residents.

If I go that route, id like also like to add the sub tag “employees” for employee parking areas,

private=employee or employees has not been used. private=staff has been used 6 times. access=employees has been used 315 times. access=staff has been used 138 times.

where I can find the statistics for its sub tags?

https://taginfo.openstreetmap.org/

Adamant1 · 2017-11-19T13:29:10.000Z

Thank you for the thorough answer. I was not aware that iD worked that way. I will have to be more careful next time and check the wiki to make sure a key it recommends is valid before I use it. I think access=residents is a much better option than what I have been doing. Its to bad it has been in proposal stage since 2011. It seems like the access tag was originally intended for roads and not things like swimming pools, but I guess that is another issue. Access=employees seems like a good alternative also. It also insinuates that the thing being tagged has private access, which is helpful.

As far as the iD editor goes, it seems to be working fine for me. I’ve been using it all day without any connection problems.

hadw · 2017-11-19T14:58:29.000Z

Whilst it is best practice to add new tags to the wiki, I don’t think not having a wiki entry makes them invalid.

On the other hand, access does seem to be a better choice here.

I guess the reason some people didn’t like access is that there are only about four access categories recognized by renders: public, permissive, limited public (e.g. destination or customers), and private. People may see that coding as private and then subdividing that ensures that the essentially private nature is recognized. I think I would argue that that has elements of tagging for the renderer.

Using “employees” on a residential swimming pool would be wrong, although “residents” is probably an oversimplification, as they can probably permit friends to use it. Real life access rules tend not to fit into neat categories.

(Common renderings for the four major classes are: public - no modifier; permissive: - green; limited: blue; private red.

Brian_de_Ford · 2017-11-19T15:24:26.000Z

Adamant1:

I was not aware that iD worked that way.

Try adding a tag with the letters “fix” and iD suggests both “fixme” and “FIXME”. If this were hand-coded in iD, you’d get only “fixme”. So it’s pulling both variants from the database.

As an aside, I think db insertion of keys ought to be case-insensitive and it is justifiable running a conversion operation on existing keys. Or at least on fixme.

I will have to be more careful next time and check the wiki to make sure a key it recommends is valid before I use it.

That’s a good idea. But there are times when it is sensible to use an undocumented value with a key. Which is where taginfo comes in useful. But you have to use it with care. A value might be rarely used but is perfectly valid and sensible, it just happens that there’s not much of it in the world. OTOH, a value might be rare because it’s not a sensible thing to use.

I think access=residents is a much better option than what I have been doing. Its to bad it has been in proposal stage since 2011. It seems like the access tag was originally intended for roads and not things like swimming pools, but I guess that is another issue.

The usage of a tag can get extended, sometimes sensibly, sometimes not. Access may have started as access on roads, but it’s a small step to use it for parking, and not a vast step from using it for other things like swimming pools. Opening_hours originally applied to shops but now also applies to other things like buses (where “operating hours” makes more sense but we already have “opening hours”).

Access=employees seems like a good alternative also. It also insinuates that the thing being tagged has private access, which is helpful.

Access=employees is not particularly helpful, though. If I look at a pool on a map and it’s private, I know I can’t use it. If it’s public I know I can. If the pool is part of a member’s club then access=customers is meaningful. For somebody who has never been there before, there is no real distinction between access=private and access=employees. So access=employees is nice for those of us (like me) who obsess over detail, but private is adequate if you’re not obssessive. Employees don’t need it marked on the map because they’ll be told they can use it when they get the job.

Note that if the situation demands it, you could have “access=employees; customers” but most renderers may not handle it correctly and it’s not really necessary to have those in combination except in bizarre circumstances. The least restrictive access generally implies access is also allowed to more restrictive cases.

Note also that access=public does not preclude fee=yes. There’s a pool near me which is public and charges a fee.

As far as the iD editor goes, it seems to be working fine for me. I’ve been using it all day without any connection problems.

Thanks for checking. Such a simple thing to do, but you’re the only one (of over 100 people who have seen my posts mentioning the problem) that has done so. Since I’ve checked with two computers using different operating systems and browsers, either I’m doing something very stupid or there’s something blocking the routeing between me and a particular server that pushes out a critical chunk of iD functionality. Getting the monkeys on my ISP’s helldesk to accept that there is a problem and report it upwards is a painful, endless task of the type described in Dante’s Inferno. It could be a long time before I can use iD again.

escada · 2017-11-21T12:24:59.000Z

Brian de Ford:

Access=employees is not particularly helpful, though. If I look at a pool on a map and it’s private, I know I can’t use it. If it’s public I know I can. If the pool is part of a member’s club then access=customers is meaningful. For somebody who has never been there before, there is no real distinction between access=private and access=employees. So access=employees is nice for those of us (like me) who obsess over detail, but private is adequate if you’re not obssessive. Employees don’t need it marked on the map because they’ll be told they can use it when they get the job.

This makes it hard for any data consumer to know what the access is, without full understanding of the English language.
IMHO, it would be better to have access=private;private=xxx. so any data consumer knows that access can only be granted on a personal basis. The private=xxx could also be “access_details” or whatever. I just would restrict the values in access to a know list.

Brian_de_Ford · 2017-11-21T12:46:57.000Z

escada:

This makes it hard for any data consumer to know what the access is, without full understanding of the English language.
IMHO, it would be better to have access=private;private=xxx. so any data consumer knows that access can only be granted on a personal basis. The private=xxx could also be “access_details” or whatever. I just would restrict the values in access to a know list.

I don’t see how your proposal improves understanding. Your scheme still requires English language to be parsed and comprehended.

Nor do I see how your proposal improves upon what is already avaliable with access=* (see https://wiki.openstreetmap.org/wiki/Key:access). It has: yes (public access), no (no public access), private (you need the permission of the owner with no guarantee that you will get it), and permissive (open to public but the permission can be revoked at any time). There are other values and key combinations listed on that page for finer control. If you then take into account values for access=* found in the wild, such as access=customers, access=employees, that seems to cover everything.

Let’s face it, for a typical map consumer the only values of access that really matter boil down to yes, no, permissive and customers. Access=yes: I can park there (but I may have to pay a fee). Access=permissive: I can probably park there, but the owner may have changed his mind by the time I get there. Access=no: I’m not allowed to park there (maybe if I ask the owner very nicely he/she will let me, but probably not). Access=customers: I can park there if I’m a customer. Anything more is detail=obsessive. But I’m an obsessive:)

The wiki documents access=delivery. But if I’m a delivery driver I probably already know that before I go there and without having to look at a map. Similarly, access=employees is in the wild, but if you’re an employee you’d have been told where you can park when you were hired.

Maybe I’m missing something about your proposal, but I don’t see it doing anything that isn’t already covered.

TZorn · 2017-11-21T15:06:53.000Z

What Escada’s suggestion implies is that adding a new value (e.g. employees) to the common ones listed for such an important tag is a bad idea. If a data consumer finds such value they will hardly know what to do and will likely fall back to a default “no”. If you really want to make the distinction then use access=private and private=employees. The odd data consumer will know that access is restricted and the more clever one or the human user can additionally evaluate the employee information.

hadw · 2017-11-21T15:31:57.000Z

That seems to go against the general free tagging principle, which is that new values can be added and it is the responsibility of data consumers to survey what values are actually in use, and account for those which are important for them.

escada · 2017-11-22T06:32:50.000Z

hadw:

That seems to go against the general free tagging principle, which is that new values can be added and it is the responsibility of data consumers to survey what values are actually in use, and account for those which are important for them.

And what is the default fallback for those values that they do not account for ? Access=no or yes ?
Adding subtags is quite common (e.g. tourism=information, information=board; board_type =xxx, we do not tag that as tourism=information_board_xxx)

Here, the basic message we try to convey with the access tag is that you need permission in some form to access the premisses. So access=private (as opposed to access=public). If you want to specify the private group further, that can go in a subtag without breaking any data consumer, and making it easy to add new groups (management, car-poolers, employees, visitors, etc…).
This is the same as with the information board.

Similar amenity=shelter + shelter_type, historic=memorial + memorial:type/memorial ,etc. etc.