Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"

[Eckhart Wörner]

Hi,

just seen that there is more FUD that needs to be adressed:

Am Dienstag, 18. September 2012, 23:15:57 schrieb Rob Nickerson:
> * No variable parts in the key. This is essential as keys are used to
> search for data in the OSM database. If a key comprises a variable part it
> can no longer be retrieved during search unless you know the exact
> condition you are looking for (database searches do not allow wildcards in
> search keys).

This is completely wrong. There is *one* key/value storage called hstore in 
*one* database called PostgreSQL that doesn't support this inside the data 
structure, due to the nature of the data structure.
Even then, it is trivially possible to do exactly what has been described: 
SELECT * FROM each('highway=>primary,maxspeed=>80,maxspeed:wet=>60'::hstore) 
WHERE key LIKE 'maxspeed%';
Note that this argument is moot anyway; when preprocessing data for routing, 
you normally deal with the full set of tags outside the database anyway.
If that is still not enough, please do write down the query to pick every 
aspect of access you need for hgv routing in the Conditional Restrictions 
proposal (see below).

> Variable parts in keys will also lead to an undesired
> proliferation of unique keys.

This is the only argument that is not completely broken, and it has two sides: 
the Extended Conditions proposal has a moderate amount of keys and a moderate 
amount of values. The Conditional Restrictions proposal has a tiny set of keys 
and an insane amount of values. Do the math.

> * Avoids the requirement for problematic characters in the key such as "<"
> or ">"

Which is a huge problem for data consumers that process XML using regular 
expressions, and nobody else.

> * Clear distinction between scope (transportation mode, vehicle class) and
> condition.

That distinction is so clear that things already moved between those two sides. 
(Is "electric" a vehicle class or a condition?)

> * Possibility to combine conditions using operators.

…or more specifically, the AND operator, which has already been a key element 
in the Extended Conditions proposal.

> * The conditional restriction can be defined as a single tag. Some prior
> proposals required multiple tags such as hour_on and hour_off tags. For
> objects having multiple restrictions this could lead to problems (which
> tags belong to which restriction?)

"single tag" is a slight understatement. Just to get the access for an hgv 
vehicle in Germany right, you have to consider:
access
access:conditional
access:vehicle
access:vehicle:conditional
access:motor_vehicle
access:motor_vehicle:conditional
access:hgv
access:hgv:conditional

> * Backward compatible. Doesn't break any established tagging schemes.
> //end quote//

I have already shown that this is completely wrong, but just for the record: 
maxspeed:wet, access:disabled, …

Eckhart

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"

[David ``Smith'']

On Sep 19, 2012 5:09 AM, "Eckhart Wörner"  wrote:
> "single tag" is a slight understatement. Just to get the access for an
hgv vehicle in Germany right, you have to consider:
> access
> access:conditional
> access:vehicle
> access:vehicle:conditional
> access:motor_vehicle
> access:motor_vehicle:conditional
> access:hgv
> access:hgv:conditional

Wouldn't that be...
access
access:conditional
vehicle
vehicle:conditional
motor_vehicle
motor_vehicle:conditional
hgv
hgv:conditional
...?
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"

[Eckhart Wörner]

Hi David,

Am Mittwoch, 19. September 2012, 08:26:07 schrieb David ``Smith'':
> Wouldn't that be...
> access
> access:conditional
> vehicle
> vehicle:conditional
> motor_vehicle
> motor_vehicle:conditional
> hgv
> hgv:conditional
> ...?

Actually, no. To quote: "For access restrictions it is *allowed* to use the 
abbreviated form by omitting access: in front of the category."
The list would therefore look like:
access
access:conditional
access:vehicle
access:vehicle:conditional
vehicle
vehicle:conditional
access:motor_vehicle
access:motor_vehicle:conditional
motor_vehicle
motor_vehicle:conditional
access:hgv
access:hgv:conditional
hgv
hgv:conditional

However, since *both* the Conditional Restrictions and the Extended Conditions 
proposal have this kind of shortening for backward compatibility, I 
deliberately omitted these tags.

Eckhart

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"

[SomeoneElse]

To echo Sir Humphrey*, my first reaction was "beautifully typed". My 
second reaction was as follows:


What attempt has been made to get editor support for this "proposal"?  
Without it no-one, apart from the dwindling proportion voting on the 
wiki, will ever even have heard of it.


Without editor support even people looking at the wiki page won't be 
able to understand what they're supposed to do (for example, the 
"Tagging" section appears to contradict the "Examples" section).


Presumably the submitter of this proposal is already working on a patch 
for Potlatch and a JOSM plugin?


Cheers,
Andy

* 
http://books.google.co.uk/books?id=qPxeFwAk9T8C&pg=PA382&lpg=PA382&dq=%22beautifully+typed%22+%22sir+humphrey%22&source=bl&ots=HB0DwsugrB&sig=TZUnIzVTIfG0G7TwxGsxjdkl4qU&hl=en



___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"

[Ilpo Järvinen]

On Wed, 19 Sep 2012, Eckhart Wörner wrote:
> Am Dienstag, 18. September 2012, 23:15:57 schrieb Rob Nickerson:

> > Variable parts in keys will also lead to an undesired
> > proliferation of unique keys.
>
> This is the only argument that is not completely broken, and it has two
> sides: the Extended Conditions proposal has a moderate amount of keys
> and a moderate amount of values. The Conditional Restrictions proposal
> has a tiny set of keys and an insane amount of values. Do the math.

With this proposal I can still pick the key I'm interested in from
rather small set of keys. And I know what I'm talking here... Somebody
around here has been doing some traffic volume counting and now all those
different times put into the keys basically occupy most of the key space
already (in fact e.g. ITO won't even show all keys anymore because they're
so many which would obviously be fixable in that particular case as long
as the browsers can handle such insanely long lists but still highlights
my point about key space explosion beyond what was considered "sensible"
upper limit by somebody). I don't find it useful to have a semi-large key
and semi-large value space instead of sensibly small key space and
insanely diverse value space per key. I can only image what your proposal
would cause when all those different times would be put to all keys
instead of just one.

> > * Avoids the requirement for problematic characters in the key such as "<"
> > or ">"
>
> Which is a huge problem for data consumers that process XML using
> regular expressions, and nobody else.

This is a false claim. I've seen e.g. misdecoded ampersand just too many
times here and there. And I doubt that such services had anything to
do with regexp.

> > * Possibility to combine conditions using operators.
>
>  or more specifically, the AND operator, which has already been a key
> element in the Extended Conditions proposal.

Now you're arguing bothways. Extented conditions wanted to get rid of
such operator and use multiple keys instead of an operator. The use of a
_real_ operator prevents the key space explosion which you hold so dear,
so no, extented conditions does not have operators in the same sense this
proposal has.

--
 i.___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"

[Eckhart Wörner]

Hi Ilpo,

Am Mittwoch, 19. September 2012, 15:45:44 schrieb Ilpo Järvinen:
> > > * Avoids the requirement for problematic characters in the key such as "<"
> > > or ">"
> > 
> > Which is a huge problem for data consumers that process XML using 
> > regular expressions, and nobody else. 
> 
> This is a false claim. I've seen e.g. misdecoded ampersand just too many 
> times here and there. 

Example? I have yet to encounter a single OSM tool that does not handle XML 
correctly.

> And I doubt that such services had anything to 
> do with regexp.

XML is a format explicitly designed for exchange of *arbitrary* data, and 
libraries that manipulate XML documents go to great effort to ensure stuff like 
character entities are handled correctly.
The only reason why such errors happen is because some idiots believe that they 
can handle XML in five lines of code, which normally involves some "clever" 
regexp'ing.

Apart from that, the argument is flawed anyway because both key and value end 
up as attributes in the XML, and the Conditional Restrictions proposal has "<" 
in its values.

> > > * Possibility to combine conditions using operators.
> > 
> >  or more specifically, the AND operator, which has already been a key 
> > element in the Extended Conditions proposal.
> 
> Now you're arguing bothways. Extented conditions wanted to get rid of 
> such operator and use multiple keys instead of an operator. The use of a 
> _real_ operator prevents the key space explosion which you hold so dear, 
> so no, extented conditions does not have operators in the same sense this 
> proposal has.

Extended Conditions does not have an *explicit* AND operator, however, there is 
an *implicit* AND written as ":".
maxspeed:hgv:(22:00-06:00):forward is the maxspeed that applies if you are in 
an hgv *and* the time is between 22:00 and 06:00 *and* the relative direction 
is forward.

Eckhart

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"

[Eckhart Wörner]

Hi Ilpo,


Am Mittwoch, 19. September 2012, 15:45:44 schrieb Ilpo Järvinen:
> > > Variable parts in keys will also lead to an undesired
> > > proliferation of unique keys.
> > 
> > This is the only argument that is not completely broken, and it has two 
> > sides: the Extended Conditions proposal has a moderate amount of keys 
> > and a moderate amount of values. The Conditional Restrictions proposal 
> > has a tiny set of keys and an insane amount of values. Do the math. 
> 
> With this proposal I can still pick the key I'm interested in from 
> rather small set of keys.

Ignoring compatibility keys, we are already talking about ~150 keys for any 
base key. That's not something you want to pick from a list.

> And I know what I'm talking here... Somebody 
> around here has been doing some traffic volume counting and now all those 
> different times put into the keys basically occupy most of the key space 
> already (in fact e.g. ITO won't even show all keys anymore because they're 
> so many which would obviously be fixable in that particular case as long 
> as the browsers can handle such insanely long lists but still highlights 
> my point about key space explosion beyond what was considered "sensible" 
> upper limit by somebody).

Which "ITO" tool is that?

> I don't find it useful to have a semi-large key 
> and semi-large value space instead of sensibly small key space and 
> insanely diverse value space per key. I can only image what your proposal 
> would cause when all those different times would be put to all keys 
> instead of just one.

And what *can* you imagine? The only negative effect you have brought up so far 
is that it is not possible to list all keys on one page anymore (which has been 
impossible for quite some time).
Also, existing tagging practise tells us that with the Extended Conditions 
proposal, keys tend to cluster (e.g. maxspeed:(22:00-06:00) has been used 416 
times all over Germany), while with the Conditional Restrictions proposal, 
clustering in values rarely happens.

Eckhart

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"

[Tobias Knerr]

On 19.09.2012 14:44, SomeoneElse wrote:
> What attempt has been made to get editor support for this "proposal"? 

Tagging ideas are often documented (as a proposal or elsewhere) first,
then actually used in the database, and only then added to editors.

At this point, a JOSM/Potlatch patch would probably be rejected because
this tagging style has yet to prove itself in the database.

Tobias

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"

[Ronnie Soak]

Eckhart,

Ich habe gerade eine Spalte für das Extended Conditions Schema zur
Beispieltabelle auf der Diskussionsseite des Conditional Restriction
Schemas hinzugefügt. [1]

(Warum hat das  Extended Conditions Schema eigentlich keine Beispiele?)

Würdest du mir helfen die Lücken zu füllen? Du scheinst mehr Erfahrung
damit zu haben als ich.
(Obwohl mich das zum besseren Versuchskaninchen macht ..)

Andere dürfen natürlich auch ...

Gruß,

Chaos


[1] 
http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Conditional_restrictions#Pictorial_examples

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"

[Ronnie Soak]

I'm sorry. Here it is again in English:

Eckhart,

I've added a column for the Extended Conditions scheme to the examples
table on the discussion page of the Conditional Restriction
scheme. [1]

(Why doesn't have the Extended Conditions scheme it's own examples?)

Would you please help me fill in the blanks? You seem more experienced
in this scheme than me.
(Although that would make me more suited as a test candidate.)

All others are invited too, of course.

Regards,
>
> Chaos
>
>
> [1] 
> http://wiki.openstreetmap.org/wiki/Talk:Proposed_features/Conditional_restrictions#Pictorial_examples

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"

[Eckhart Wörner]

Hi Ronnie,

Am Mittwoch, 19. September 2012, 16:17:07 schrieb Ronnie Soak:
> I've added a column for the Extended Conditions scheme to the examples
> table on the discussion page of the Conditional Restriction
> scheme. [1]
> 
> (Why doesn't have the Extended Conditions scheme it's own examples?)

It does:
http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags#Examples
(without pictures, though)

> Would you please help me fill in the blanks? You seem more experienced
> in this scheme than me.
> (Although that would make me more suited as a test candidate.)

Will have a look at it later.

Eckhart

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"

[Rob Nickerson]

Hi All,

Despite some of the perceived benefits of this proposal being challenged
(mainly in regards to their relevance), the overwhelming thing that was
clear was that this proposal was well thought out. Ole looked carefully at
the feedback that was given during previous proposals and worked to find
solutions for many of them.

There will never be a 100% perfect solution due to the fact that, in the
absence of a tag scheme, many alternate tags have crept into use. Despite
this I feel it is important to push ahead with a conditional restrictions
tagging scheme as it provides some form of standardisation and therefore
simplifies the task of downstream users (which ultimately will lead to more
use of OSM's fantastic data). To put this into some context, recall that
there was a discussion recently (on talk list I think), where it was made
clear that the German auto industry had asked OSM how we intend to "close
the gap" between us and commercial navigation.

As noted by Andy, I do however agree that this proposal (like many others)
could slip under the radar of many people. Due to it's potential reach, I
would have liked to have seen something posted to the Developer mailing
list during the Draft & RFC stages.

Kind Regards,
Rob

p.s. I know voting isn't popular, but it is one part of communications
(i.e. giving feedback) and I encourage you to reconsider it if you have so
far opted not to vote.

http://wiki.openstreetmap.org/wiki/Proposed_features/Conditional_restrictions
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

[Tagging] Monasteries - RFC

[Martin Koppenhoefer]

I'd like to ask all of you for comments and for missing communities:

http://wiki.openstreetmap.org/wiki/Tag:amenity=monastery

cheers,
Martin

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

[Tagging] Conditional Restrictions vs. Extended Conditions

[Eckhart Wörner]

Hi everybody,

it probably comes as no surprise that I am against the Conditional Restrictions 
proposal and in favor of the Extended Conditions proposal.
My main reason is that I believe the Conditional Restrictions proposal is so 
complicated it will kill mapping of those conditions almost completely, while 
its benefits are only dubious.
However, since the majority of participants in the whole discussion has 
apparently never tried to do anything with either of the two tagging schemes, 
here is a simple challenge. Maybe you should complete the challenge *before* 
voting.

== The situation ==

A short section of a motorway. There is a bridge which is prone to accidents 
when wet, therefore the speed is reduced to 80 kmph on the bridge when wet, 
with a gradual reduction of speed before the bridge.
There are also people living nearby complaining about the noise, so the 
administration decides to limit the speed of the whole motorway section to 100 
kmph between 10 pm and 6 am.

== The task ==

1) Map the night-time speed limit using the Conditional Restrictions proposal.
Here is the starting position: 
http://eckhart-woerner.de/~eckhart/conditional-restrictions.osm

2) Map the night-time speed limit using the Extended Conditions proposal.
Here is the starting position: 
http://eckhart-woerner.de/~eckhart/extended-conditions.osm

Eckhart

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"

[Eckhart Wörner]

Hi Rob,

Am Mittwoch, 19. September 2012, 18:08:30 schrieb Rob Nickerson:
> Despite some of the perceived benefits of this proposal being challenged
> (mainly in regards to their relevance),

Except for one claimed benefit, I did not question the relevance of the claims, 
but their validity. Maybe you should read mails before summarizing them?

> There will never be a 100% perfect solution

(which is no argument for adopting inferior solutions)

> due to the fact that, in the
> absence of a tag scheme, many alternate tags have crept into use.

However, some proposals actually manage to embrace and extend existing tagging.

Eckhart

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] access restrictions on ways

[André Pirard]

Update.

First, If I were asked, is there a map showing access restrictions? ;-)
I've seen many showing speed limits, this and that, but I didn't spot 
any global one.


I have been called by a Council secretary and I finally received an 
e-mail reply too.

They asked what is that osm.org map? (I typed osm.org and I read :-))
They don't know much about the signal, it was placed by State staff they 
say.

But they got aware and they will investigate.

Who would say that OSM isn't useful? Cop bugs buster ;-)
According to GooM lately, there was no way to get out of that town at 
the other end.

And when I say no way I mean no way :-)
Fortunately, Google noticed before the town burst and shattered :-)

On 2012-09-17 17:58,  Martin Vonwald wrote :

I would use a pragmatic approach here: from the position where the signs is up 
to the next junction or end of this osm-way (one, single way; no connected, 
following osm-ways) - whichever comes first - a simple maxweight:forward=7.5 . 
As soon as (if ever) the conditional-tagging
I did that, but not over 50m, down to where the way ends. That isn't 
worth a split.


BTW, I'm wondering about that "forward".
Why have a direction depend on an arbitrary one that could be inverted 
carelessly.
Not all programs are as smart as JOSM to detect that a tag bust be 
changed accordingly!


Why not North, East, South and West?
Clockwise and Anticlockwise or such if we don't want to split Circle Line?

Should I answer the other questions?

Thanks to all who replied.

Cordialement,
André.



___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"

[Rob Nickerson]

-- Eckhart wrote --

Hi Rob,

Am Mittwoch, 19. September 2012, 18:08:30 schrieb Rob Nickerson:
>* Despite some of the perceived benefits of this proposal being challenged*>* 
>(mainly in regards to their relevance),*
Except for one claimed benefit, I did not question the relevance of
the claims, but their validity. Maybe you should read mails before
summarizing them?
-- End --

Hi Eckhart,

Please accept my apologies that my English was not clear. I did read
your mails and my wording should be seen as it was intended - that is,
the perceived benefits may not be "relevant" due to the "invalidity"
of the thing they are trying to fix. I will try to be more exact next
time.

Kindest regards,
Rob
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Conditional Restrictions vs. Extended Conditions

[Rob Nickerson]

>Hi everybody,
>
>it probably comes as no surprise that I am against the Conditional 
>Restrictions proposal and in favor of the Extended Conditions proposal.
>My main reason is that I believe the Conditional Restrictions proposal is so 
>complicated it will kill mapping of those conditions almost completely, while 
>its benefits are only dubious.

== The following responses are not specific to this proposal only ==
I disagree that it will kill mapping of these features. I expect some
people are holding off mapping these until there is an accepted tag
schema (otherwise they may have to go back and waste time correcting
anything they do add once a schema is decided upon). As for the
complexity, I feel that the wiki page can be improved to help explain
the proposal better (for example by using colours like seen on an
alternate proposal [1], and adding some image examples).

Regards,
Rob

[1] http://wiki.openstreetmap.org/wiki/Proposed_features/Conditional_values
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] access restrictions on ways

[Martin Vonwald]

Am 19.09.2012 um 20:36 schrieb André Pirard :

> BTW, I'm wondering about that "forward".

If I understood you correct(!) this restriction should block traffic going in. 
If anyone manages to get into the town without passing that signpost (don't ask 
me how) he is allowed to leave town on that road.
Usually this kind of restrictions are bidirectional. I guess that it won't 
matter too much if you skip the ":forward" but I know the place only from your 
description.

> Why have a direction depend on an arbitrary one that could be inverted 
> carelessly.
> Not all programs are as smart as JOSM to detect that a tag must be changed 
> accordingly!

We have to rely on our mappers. When I look at our map(s) I think that the are 
quite ok ;-)

> Why not North, East, South and West?
> Clockwise and Anticlockwise or such if we don't want to split Circle Line?

Because this might be ambiguous and is much harder to process by data consumers.

Regards,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Announcement: Voting ongoing for proposed access tagging "Conditional restrictions"

[Eckhart Wörner]

Hi Rob,

Am Mittwoch, 19. September 2012, 20:10:45 schrieb Rob Nickerson:
> Am Mittwoch, 19. September 2012, 18:08:30 schrieb Rob Nickerson:
> >* Despite some of the perceived benefits of this proposal being 
> >challenged*>* (mainly in regards to their relevance),*
> Except for one claimed benefit, I did not question the relevance of
> the claims, but their validity. Maybe you should read mails before
> summarizing them?
> -- End --
> 
> Please accept my apologies that my English was not clear. I did read
> your mails and my wording should be seen as it was intended - that is,
> the perceived benefits may not be "relevant" due to the "invalidity"
> of the thing they are trying to fix. I will try to be more exact next
> time.

I apologize for being a bit harsh on my response. My intention was not to be 
picky about the language, just to note that there is an important distinction. 
"Invalidity" is something that can normally verified/falsified, "relevance" 
lies in the eye of the viewer.

Eckhart

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

[Tagging] Animal_shelter, multiple semicolon separated values?

[Alberto]

Hi everybody, what do you think about using multiple comma separated values
in a key (see

http://wiki.openstreetmap.org/wiki/Semi-colon_value_separator)?

In particular about the new proposal "amenity=animal_shelter".

Suppose we need to set a subkey that specifies adoption and boarding for
dogs, cats and rabbits: for simplicity and applications compatibility would
it be better something like:

"animal_shelter:dog:adoption=yes" + "animal_shelter:dog:boarding=yes" +
"animal_shelter:cat:adoption=yes" + "animal_shelter:cat:boarding=yes +
"animal_shelter:rabbit:adoption=yes" + "animal_shelter:rabbit:boarding=yes

OR

"animal_shelter:adoption=dog;cat;rabbit" +
"animal_shelter:boarding=dog;cat;rabbit"?

Please post your comments in the discussion page:

http://wiki.openstreetmap.org/wiki/Talk:Animal_shelter

___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging