Re: [Tagging] new tagging scheme for detailed information.
Am 24/lug/2013 um 07:56 schrieb amrit karmacharya amrit...@gmail.com: Here, it is commonly called operation theater and even the hospital have board written operation theater For osm we agreed on using the British version of words, which is theatre in this case, even if on a global level the other variant (theater) might be more frequently used. cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] new tagging scheme for detailed information.
On 24/07/2013 06:56, amrit karmacharya wrote: Here, it is commonly called operation theater and even the hospital have board written operation theater. As for operating theater, even i am hearing it called so for the first time. I love the diversity of English as a world language! Anyway, here's a Google Ngram: http://books.google.com/ngrams/graph?content=operating+theatre%2C+operation+theatreyear_start=1800year_end=2013corpus=15smoothing=3share= Steve ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting Open - toilets, toilets:disposal, pitlatrine
Bryce Nesbitt wrote: Something could be both inquiry and customer. Is there a better way? FWIW, it'd be enquiry not inquiry in English (rather than in American). Cheers, Andy ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting Open - toilets, toilets:disposal, pitlatrine
2013/7/24 Andrew Chadwick (lists) a.t.chadwick+li...@gmail.com
As described in the proposal, inquiry is partly about practical
locking mechanisms so a better way which factors out those concerns is
access=private
locked={yes|mechanism}[1] (or some other tag)
While I can see your intention here, that is the most counter-intuitive way
to tag this I've ever seen.
You would tag a PUBLIC toilet with access=PRIVATE just because you have to
ask for a key first?
This is better because access=private already carries the you must
inquire meaning. As the Key:access page states, access=private means
only with permission of the owner on an individual basis. And how
does one acquire permission? One inquires.
There is a subtle difference between enquiring for permission to enter/use
and to inquire for the key/code/token.
We won't tag access=private at all, because we only want public toilets to
be in the database.
Access=permissive would be the most limited value I would tag at all.
A toilet at a gas station might be for anyone to use (access right)
(access=public? access=yes?), but you still
may have to inquire within for the key (access method).
For your example, one needn't inquire as to whether one may use the
toilets if one is a customer. Merely after a code, for example. So a
better way would be to use
access=customers
locked=code[1] (or some other tag)
So maybe we mean the same thing after all. The access restriction has
nothing to do with inquiring for a code.
I still think its more helpful to tell that you have to ask the staff
instead of just saying it is locked with a code.
I object to muddling the access=* key with yet more values having the
same meaning as existing ones, especially without discussion on the
access tagging page. access=* describes legal access, and should have
nothing to do with practical access (except for barriers, sigh). In
short: if you need to ask before each use, then it's an existing
restrictive access value, either customers, or more probably private.
I see your concerns about using the access key here. I'm fine with access=*
having a different meaning depending on the main tag. We have that for
other tags as well (type=* is probably the best example). But if others
also see this problem, we better might move it to toilet::access to avoid
confusion. Not all the access=* values make sense anyway. (access=hgv
anyone?)
Regards,
Chaos
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting Open - toilets, toilets:disposal, pitlatrine
On 15/07/13 07:52, Bryce Nesbitt wrote:
Open for voting is
http://wiki.openstreetmap.org/wiki/Proposed_features/Tag:amenity%3Dtoilets
Which includes toilets:position and toilets:disposal, to allow tagging
of squat facilities
and pitlatrines.
Capacity tagging needs to be added. This might make toilets:position
redundant.
We should be able to express how many stalls and urinals there are, to
help solve the problem of finding a toilet which is likely to be vacant
right now.
Let's use a riff on the way the parking schemata do it, tailored for
toilets by 'position', or better by a sort of stall type/user or stall
plumbing type thing:
capacity={yes|count};; total capacity for all users
capacity:type={yes|no|count} ;; capacity for specific usage
where count is a cardinal number, {0, 1, 2, ...}, and type is a
stall type {disabled, seated, squat, urinal, ...}. Expressing it in an
open-ended way allows capacities for disabled users to be expressed
similarly to the parking schemata. It even helps hide a minor
ick-factor by making it not purely about how one excretes, and that
could help with uptake of the tag[1].
Speaking of cultural mores that make mapping trickier, we may wish to
add limited as a possible count, for when queues are known to form
at busy times for people of a different toilet-door-gender to one's own.
This would seem to fully replace the proposed toilets:position key, and
it's simpler and more versatile. What do you think?
[1] No, seriously. Simple resistance to talking about these things even
affects healthcare provision and research, just ask Mary Roach. Assume
a non-zero number of OSM volunteers will be shrinking violets...
--
Andrew Chadwick
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Are addresses ... objects vs attributes
2013/7/24 André Pirard a.pirard.pa...@gmail.com An object is the physical thing. It's unique. An attribute is the different forms, usage etc... of the object. It can be multiple. I don't think we should be so inflexible with the object vs attribute. It depends on the context. If you are a data consumer, and are making a list of all addresses in a town, then the addr:housenumber + addr:street is your object, and building=yes is your attribute that says there is a building at this address. If you are making a list of all buildings, then it's the other way around. If you are making a list of restaurants, then the amenity=restaurant is your object, with attributes building and address. You could consider this address is in a building an attribute, and that can be the same as tagging the address on the building way. Or an attribute this building has an address node in it. Then if a building has only one address node in it, it can be considered that the building has that address. But I am getting off topic. Janko ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Are addresses ... objects vs attributes
On 24 Jul 2013 16:44, Janko Mihelić jan...@gmail.com wrote I don't think we should be so inflexible with the object vs attribute. It depends on the context. If you are a data consumer, and are making a list of all addresses in a town, then the addr:housenumber + addr:street is your object, and building=yes is your attribute that says there is a building at this address. If you are making a list of all buildings, then it's the other way around. If you are making a list of restaurants, then the amenity=restaurant is your object, with attributes building and address. +1 Chaos ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting Open - toilets, toilets:disposal, pitlatrine
On 24/07/13 14:14, Ronnie Soak wrote:
While I can see your intention here, that is the most counter-intuitive
way to tag this I've ever seen.
You would tag a PUBLIC toilet with access=PRIVATE just because you have
to ask for a key first?
Let's agree that permissive is probably more useful. However it does
not carry any implicit you must inquire meaning, rather an unless the
owner says no.
Perhaps a third axis is needed for this particular nuance. For a value,
maybe indicate what to ask for:
access:request={permission|yes|key|code|...}
I'm not sure. It's more detail than my baked brain would be capable of
after a long summer day's mapping. Provided it doesn't mess with the
access tagging, it's probably OK. Hey,
access-key=request ; no, though they'll listen
request={key|code|permission} ; specifics of what to ask for
might be OK too, as a less restrictive private or no indicating what
to ask for.
Attempting to crowbar access=new-stuff in via a refinement of the
toilet tagging seems a bit of an abuse of the procedure some people seem
to love around here. It should be proposed directly, in its own right,
since it affects such an important key.
[Either that or faffing with voting doesn't matter in the first place
and you should just use what you see fit and document what works]
There is a subtle difference between enquiring for permission to
enter/use and to inquire for the key/code/token.
We won't tag access=private at all, because we only want public toilets
to be in the database.
We tag private parking, so why not private outhouses if they're a useful
landmark to the public?
So maybe we mean the same thing after all. The access restriction has
nothing to do with inquiring for a code.
I still think its more helpful to tell that you have to ask the staff
instead of just saying it is locked with a code.
Fair enough. I think it's best for this proposal to drop the additions
to the access scheme. Those could be done later, and in the right way.
I see your concerns about using the access key here. I'm fine with
access=* having a different meaning depending on the main tag. We have
that for other tags as well (type=* is probably the best example). But
if others also see this problem, we better might move it to
toilet::access to avoid confusion. Not all the access=* values make
sense anyway. (access=hgv anyone?)
There's no such tag, but I get your drift. horse=no would be fairly
silly too. I guess the correct access-key to use is foot then, not
access... (/old discussion)
type=* is horrendous garbage data that should be replaced on sight,
unless it's on a relation. service=* is pretty nasty as well, but an
acceptable refinement for service roads. We should do better than these
in new tagging for the sake of our data. Namespaces are one honking
great idea - let's do more of those.
According to the main tag - sure, but how does a machine know which
one is the main tag? I don't think it should be expected to. Tags
should mean the same thing in all contexts to be of maximal use, and we
ought to make efforts to avoid or correct erroneous situations where
they don't.
--
Andrew Chadwick (although practicality beats purity)
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Are addresses ... objects vs attributes
On 2013-07-24 16:54, Ronnie Soak wrote : On 24 Jul 2013 16:44, Janko Mihelić jan...@gmail.com mailto:jan...@gmail.com wrote I don't think we should be so inflexible with the object vs attribute. It depends on the context. If you are a data consumer, and are making a list of all addresses in a town, then the addr:housenumber + addr:street is your object, and building=yes is your attribute that says there is a building at this address. If you are making a list of all buildings, then it's the other way around. If you are making a list of restaurants, then the amenity=restaurant is your object, with attributes building and address. +1 Chaos The object vs attributes distinction I speak of is not related to processing the database. OSM is made of colorless tags and you consider them as primary or secondary as you see fit. The point is to avoid being told you can't say it's *for* leisure because you said it's *a* water. It is finding a characteristic that one can make exclusive and that always exists. Bing exclusive translates in facts the rule that a key must be unique. Having to exist is necessary so that the allowed associated attributes can be enumerated. I think that the best way to do that is to use the physical nature, or assimilated. A building, a water, a highway etc... are characteristics that are exclusive. The point is that a water can be used for leisure but that leisure cannot be uses as water. The point is that water can be used for leisure fishing and swimming or none. Hence water= is OK for a description but leisure= is not. swimming= is an attribute of the water and is compatible with fishing=. If we want to speak of addresses again, their problem being used as objects defined that way starts with countries or streets using no addresses. No problem using them either way you describe. Cheers, André. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Are addresses ... objects vs attributes
Hi André, I agree with you that this Keepright error message is not useful, but my solution is different from yours: I tend to think that KeepRight is wrong here. Something CAN be natural=water and leisure=whatever in common - and why not? Your example is perfectly valid, and others are as well. natural=water, leisure=fishing (I think that was your example) natural=water, leisure=swimming natural=water|heath|grassland|..., leisure=nature_reserve natural=water, leisure=wildlife_hide and many more. But it's not necessarily you who's wrong, it's KeepRight in this case. Of course the OSM tagging scheme in some places has it's drawbacks, but that's (technically) the case where more than one value would have to be applied to the same key, e.g. amenity=cafe + amenity=restaurant, or whatever else. In this case it's an IMHO wrong interpretation by KeepRight. regards Peter Am 24.07.2013 00:07, schrieb André Pirard: On 2013-07-21 14:06, Pieren wrote : On Sat, Jul 20, 2013 at 11:04 PM, Friedrich Volkmann b...@volki.at wrote: Adresses are attributes of physical objects, e.g. a parcel, a house, or a part of a house. Parcels can be merged and deleted, houses can be replaced, shops/restaurants/POI's may change at any time but the addresses remain. It is more permanent as a simple 'attribute' than all the 'features' you mention. Anecdote and fundamental discussion... When I built my house, I went to the town hall to get a number assigned. I expected a problem because the houses on each side were nr 1 3. - No problem, sir, everything was planned, you get nr 2 [normally on the other side] - ahem, there are 2 parcels between 1 and 3 - No problem, sir, everything was planned, see (pulling plates), you get nr 2a - ahem, I built my house on the second parcel - No problem, sir, then (swapping plates) it's nr 2b for you So did 1I live at mystreet 2b. But only for a few years. The communes merged, street homonyms were renamed and... all houses renumbered thoughtfully. I've lived at nr 5 since then. Only thing is, I almost lost a friend. The guy living at nr 26 :-) I hope you won't mind my feeling that my house is the object and the numbers the attributes. Your speaking of objects and attributes delights me. That's exactly the way I think of the different features in OSM. Unfortunately, in the OSM tag definitions, there is no mention of being an object or an attribute. And in practice there can be much confusion. An object is the physical thing. It's unique. An attribute is the different forms, usage etc... of the object. It can be multiple. We've already talked of how to tag a château historical=castle It is strange to seem to say that a castle is /*a historica*/l, especially if it's not historical. In my mind, it should be: building=yes castle=yes (or =type IF AND ONLY IF any type is exclusive, e.g. =château instead of...) château=yes hotel=yes (because château can be used as hotels in addition to being château) historical=no (or yes or 1200?) Same kind of problem here http://www.openstreetmap.org/browse/way/180545448 with a sort of concrete basin, like a swimming pool, where fishes to be fished are thrown This object is undoubtedly a piece of water: water=? But OSM seems to require that object to be called /*a natural*/, although it's not natural at all. Furthermore, I want to state that this water is made for leisure with a an attribute leisure=. And once again, Osmose clashes with saying that /*a leisure*/ is a conflicting /*object*/ once again. Tag en conflit Conflit entre les tags natural, leisure way 180545448 rawedit josm water = pond natural = water name = Pêcherie du Tultay leisure = fishing Erreur reportée le : 2013-07-23 In my mind, that tagging should resemble this: water=basin natural=no phishing=yes leisure=yes (industrial=no) pay=yes drinks=yes (to spare a separate amenity object) talking=no bicycle=carefully ;-) Cheers, André. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Are addresses ... objects vs attributes
Am 24/lug/2013 um 20:42 schrieb Peter Wendorff wendo...@uni-paderborn.de: natural=water, leisure=fishing (I think that was your example) natural=water, leisure=swimming natural=water|heath|grassland|..., leisure=nature_reserve natural=water, leisure=wildlife_hide on a side note some of the values above like swimming are currently under the sport key, not leisure. Typical values for leisure are pitch, track, stadium, marina, playground, park, garden... cheers, Martin ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
Re: [Tagging] Feature Proposal - Voting Open - toilets, toilets:disposal, pitlatrine
On Wed, Jul 24, 2013 at 5:43 AM, Andrew Chadwick (lists) a.t.chadwick+li...@gmail.com wrote: This is better because access=private already carries the you must inquire meaning. As the Key:access page states, access=private means only with permission of the owner on an individual basis. And how does one acquire permission? One inquires. On the contrary, I interpret *access=private* as *don't ask*. Do you want people knocking at your door asking to use your private toilet? - The customer case one can purchase access: anyone with money (meeting other requirements like shoes or a shirt) can gain access. The permissive case is the lazy one. It might be private or customer, but nobody's enforcing it and casual use is tolerated. In the private case it is understood an invited guest has access to the facilities: but not everyone will be invited. - The only thing new to toilets is the type of shop or establishment which semi-controls access to the loo by keeping the key out of reach. They'll then follow a policy as to who gets it: customers, anyone, or perhaps anyone they don't dislike. So perhaps the bit about asking has nothing to do with *who can ask*. But really my goal is to establish *pitlatrine*. Access for toilets is already widely mapped for better or worse. That's really what I've put up for vote. ___ Tagging mailing list Tagging@openstreetmap.org http://lists.openstreetmap.org/listinfo/tagging
