Proposal:Generic service object model

generic_service_object_model
Proposal status:	Draft (under way)
Proposed by:	nounours77
Tagging:	service=* Data item
Applies to:
Definition:	generic model to tag service and object combinations, like boat, sharing and book, selling
Statistics:
Draft started:	2014-04-10

From amenity=boat_sharing proposal:

Possible Solutions

I see three possible solutions:

1. Follow the same path as used for cars: having different tags: amenity=car_rental, amenity=car_sharing. The main argument for this is that normally, the interest group is different. Either I'm part of a car sharing community, and thus would normally not rent a car at a car_sharing.

2. Group features together according to subject, e.g. amenity=boat_to_use, type=rental;sharing;pooling" (this was suggest on the "Boat_Rental" page. (amenity=boat_rental exists 429 times)

3. Group features together according action, e.g. rental=*, sharing=*, ... this was suggest on the rental page.

=> From current usage, I conclude that option 1 would be most accepted.

But 2. or 3. would be more interesting. => we try to model 3. here.

Input André

more structured approach might me more rewarding.

A map feature must be made of an object having attributes. An object is the more generally a building=yes or a shack=yes, an open place or whatever "physical" (meadow, forest, landuse, tower, ...): it is what is represented by the node, way or relation and that needs to be rendered on the map.
amenity, shop, rental, hairdresser etc... are not objects but the activity or other attribute taking place at the object. There can be several attributes (e.g. shop and rental activities) for the same object, not two objects for the same map feature. As discussed before, a building may be both a castle (château) and a hotel. I have recommended that the wiki should clearly classify objects and attributes. People have advocated that the street number can be the object and that the house (and roof) would be the attributes of the number. This is of course nonsense. The object is what is represented by the map node, way or relation and that is a house or land ... One may be interested in building a "view" (in SQL sense) by street number key, but that does not make a closed way a number. Or several numbers being represented by the same closed way. Well known objects have a well known rendering, which solves the problem of those complaining that amenity=their_invention is not rendered. building=yes must always be rendered and it may be rendered differently according to its attributes, e.g. amenity.

In practice, amenity, for example, is all-right, but it should not be considered a mistake but rather a requirement to add building or meadow or landuse, an object to it.

Semi-colon value separator explains that what;some;taggers;are;doing and that talking about it here are sins. I'm nut sure I agree, but it suggests namespaces: a good idea because it's more general and because it's already used. So, we can have:

building=yes and shop=goods1;goods2 or shop:goods1=yes shop:goods2=yes

So, for your boat business, we would have things like:

building=yes | wharf=yes | whatever
rental:kayak=yes
rental:life-jacket=yes
shop:life-jacket=yes   (rent or buy)
rental:boat=yes
rental:boat:capacity=10
sharing:boat=yes
sharing:boat:capacity=2
or
sharing:boat:1:capacity=2
sharing:boat:2:capacity=4
shop=yes       (used alone for surprise selling)
and, of course, not excluding
sharing:car=yes
and the beat goes on...
rental:opening-hours=*
shop:opening-hours=*
shop:русский:матрёшки=many

So, regarding your 1-2-3 choice, I think that # 3 is the good direction. Please note that, regarding searches, shop, rental, boat, car, ... are different words. One may search for "rental" = anything to rent or "car" = any way to use a car or "car rental" or "car sharing" specifically. life-jacket, on contrast, is a single word.

Tags like car_rental, car_pooling, boat_rental etc... are annoying because they multiply the same kind of wiki pages and propositions. For example, I need tags to indicate places where subscribed pedestrians can stop a subscribed car). Do I really need to create a new "car_riding_on_subscription" page, nobody would discuss that and I understand, or would the following two riding:*, very agreeable additions to that general framework suffice:

Logically, following that and one's reasoning: post=yes (or stop-sign=yes, or whatever (to be discussed), that's the map feature where the service takes place) get-a-vehicle=yes (if felt needed, generic term for all those kinds of activities, term off my improvable invention) riding:car=yes riding:car:subscription=yes ....

I would love to see you propose this general framework allowing your boats as well as my kayaks and car riding. As well as "Trains and boats and planes to Paris or Rome" with Billy and Dionne :-) I think you would be heard.

• -------------------------

But I think that general principles must be respected. A more structured approach might me more rewarding.

A map feature must be made of an object having attributes.
An object is the more generally a building=yes or a shack=yes, an open place or whatever "physical" (meadow, forest, landuse, tower, ...): it is what is represented by the node, way or relation and that needs to be rendered on the map.
amenity, shop, rental, hairdresser etc... are not objects but the activity or other attribute taking place at the object.
There can be several attributes (e.g. shop and rental activities) for the same object, not no two objects for the same map feature.
As discussed before, a building may be both a castle (château) and a hotel.
I have recommended that the wiki should clearly classify objects and attributes.
People have advocated that the street number is the object and that the house (and roof) are the attributes of the number.
This is of course nonsense. The object is what is represented by the map node, way or relation and that is a house or land ...
One may be interested in building a "view" (in SQL sense) by street number key, but that does not make a closed way a number.
Or several numbers being represented by the same closed way.
Well known objects have a well known rendering, which solves the problem of those complaining that amenity=their_invention is not rendered. building=yes must always be rendered and it may be rendered differently according to its attributes, e.g. amenity.

In practice, amenity, for example, is all-right, but it should not be considered a mistake but rather a requirement to add building or meadow or landuse, an object to it.

<a href="http://wiki.openstreetmap.org/wiki/Semicolon">Semi-colon

 value separator </a>

explains that what;some;taggers;are;doing and that talking about it here are sins.
I'm nut sure I agree, but it suggests namespaces: a good idea because it's more general and because it's already used.
So, we can have:

building=yes
and
shop=goods1;goods2
or
shop:goods1=yes
shop:goods2=yes

So, for your boat business, we would have things like:

building=yes | wharf=yes | whatever
rental:kayak=yes
rental:life-jacket=yes
shop:life-jacket=yes (rent or buy)
rental:boat=yes
rental:boat:capacity=10
sharing:boat=yes
sharing:boat:capacity=2
or
sharing:boat:1:capacity=2
sharing:boat:2:capacity=4
shop=yes (used alone for surprise selling)
and, of course, not excluding
sharing:car=yes
and the beat goes on...
rental:opening-hours=*
shop:opening-hours=*
shop:русский:матрёшки=many

So, regarding your 1-2-3 choice, I think that # 3 is the good direction.
Please note that, regarding searches, shop, rental, boat, car, ... are different words.
One may search for "rental" = anything to rent or "car" = any way to use a car or "car rental" or "car sharing" specifically.
life-jacket, on contrast, is a single word.

Tags like car_rental, car_pooling, boat_rental etc... are annoying because they multiply the same kind of wiki pages and propositions.
For example, I need tags to indicate places where subscribed pedestrians can stop a subscribed car).
Do I really need to create a new "car_riding_on_subscription" page, nobody would discuss that and I understand,
or would the following two riding:*, very agreeable additions to that general framework suffice:

Logically, following that and one's reasoning:
post=yes (or stop-sign=yes, or whatever (to be discussed), that's the map feature where the service takes place)
get-a-vehicle=yes (if felt needed, generic term for all those kinds of activities, term off my improvable invention)
riding:car=yes
riding:car:subscription=yes
....

I would love to see you propose this general framework allowing your boats as well as my kayaks and car riding.
As well as "Trains and boats and planes to Paris or Rome" with Billy and Dionne :-)
I think you would be heard.