add fields to set services in Bicycle shops

[willemarcel]

Add fields to set retail, repair and rental services in Bicycle shops

[bhousel]

Would it be ok to make this a multicombo field (e.g. #3080)? Then it's not limited to retail/repair/rental - the available options could be everything under the service:bicycle namespace

I wonder if shop=car_repair could use something similar?

[willemarcel]

I haven't seen the multicombo field... It seems cool! One negative point is that it wouldn't be possible to explicitly set a no value for the tag. For example, a place that repair but doesn't sell bicycles.

I think it's good to have the service fields on shop=car_repair, but it tags are in this format: service=dealer;repair;parts;tyres;electrical;glass, so it requires another logic.

[bhousel]

I haven't seen the multicombo field... It seems cool! One negative point is that it wouldn't be possible to explicitly set a no value for the tag. For example, a place that repair but doesn't sell bicycles.

Yes, that's true. Maybe we can push osm away from tagging these explicit no's for multivalues? Data consumers already need to assume that a value without a tag is a no.

I think it's good to have the service fields on shop=car_repair, but it tags are in this format: service=dealer;repair;parts;tyres;electrical;glass, so it requires another logic.

ugh, maybe we can get that changed while the usage is low? Not only is service an overloaded tag, but the semicolon separated multivalue is painful to deal with. (sport= is the only one I know of in super widespread use.)

How bad would it be if iD just starts using multiselect for all of these? I'll open a separate issue to discuss.

[bhousel]

I ended up using a multiselect field here:
a6cf49d Use multiselect field for bike shop services

This is simpler than making a whole new field type just for bike repair services:

[slhh]

Maybe we can push osm away from tagging these explicit no's for multivalues?

Being able to tag "no" values is the only benefit of the namespace solution compared to a semicolon separated value in view of information content.
The semicolon separated list would be easier to handle for manual tagging and automatic data consumers can preprocess semicolon separated value into multiple tags if they like.

Data consumers already need to assume that a value without a tag is a no.

That's not true. What to assume depends on the application, the specific key, and also other tags and maybe even the region.
For example service:bycycle:retail would likely be assumed to be yes, at least if no other service:bicycle:* tags are set. A human data consumer, who wants to buy a bicycle might take 3 different actions depending on the service:bycycle:retail tag value:

• If yes, go to the shop.
• If no, discard the shop.
• If unset, call the shop to ask if they sell bicycles.

[bhousel]

Maybe we can push osm away from tagging these explicit no's for multivalues?

Being able to tag "no" values is the only benefit of the namespace solution compared to a semicolon separated value in view of information content.

Well I think there are other benefits, but anyway people who really want to do so can still tag their nos in the raw tag editor. These values just wont show up in the multiselect field.

I think this is fine because when tagging a recycling bin, we're more interested in the few things it accepts and not the 175 things that it doesn't accept. When tagging a currency exchanger or atm, we tag the few currencies that it accepts, and not the 175 currencies it doesn't accept.

The goal of the field (as for everything in iD) is to gather the most useful data quickly from untrained volunteers.

[slhh]

Well I think there are other benefits

In view of information content not, because when limiting to yes values, both data representations can be converted into each other without loss. In view of easier handling by some software applications without requiring such conversions I would agree.

when tagging a recycling bin, we're more interested in the few things it accepts and not the 175 things that it doesn't accept.

In this example I would agree. Because the probability for a single bin to accept a specific thing is quite low, a "no" would nearly have zero information content.
In case of a large recycling center consting of a large number of bins not accepting one of the most common things seems to be very unlikely, therefor a "no" would really have information content.

The goal of the field (as for everything in iD) is to gather the most useful data quickly from untrained volunteers.

Not showing the volunteers that someone has already checked that some services are not available is wasting their time, therefore, it does't seem to support the goal. In addition a "no" can be more useful data than a "yes" sometimes.

First of all the multicombo field should support existing "no" values. It can just show the string with a red bar drawn across. Below the "X" icon there could be a checkmark icon to change to "yes" value.

In case the current value is "yes", there could be an icon below the "X" to change to "no". This should be limited to keys where "no" values are useful like the service:bicycle:* keys.