add building=hospital,warehouse,retail

[aceman]

The Man Made/Building preset currently does not contain hospital,warehouse,retail:
<group name="Man Made" icon="presets/works.png">
4650 <group name="Man Made" icon="presets/works.png">
4651 <item name="Building" icon="styles/standard/misc/landmark/building.png" type="node,closedway,relation">
4664 <label text="Edit Building" />
4665 <combo key="building" text="Building" values="yes,roof,garage,garages,industrial,church,school,hangar,commercial,farm,transportation,greenhouse,office,university"

1. Each of hospital, warehouse, retail has thousands of uses so I propose to add them.

2. Actually could we split out "commercial", "retail", "office" into a separate preset, like Man Made/Building/Commercial that would also have an optional "shop" and "office" keys in addition to name? Yes, once "shop" gets a value it could also be matched by some of the other existing presets for the specific shop type.

3. Can we make Man Made/Building match any "building" value (except "no")? Is there any reason we don't do it yet?

[AlfonZ]

Replying to aceman:

3. Can we make Man Made/Building match any "building" value (except "no")? Is there any reason we don't do it yet?

From reading #5933 and #7576 I got the impression that matching only specified values is the intended behaviour.

[aceman]

Yes, I do not want to change the internal logic of the matching algorithm. I meant to tweak only this rule like: <combo key="building" text="Building" values="yes,roof,garage,garages,industrial,church,school,hangar,commercial,farm,transportation,greenhouse,office,university,*" remove_if_star=true

So that any value in building matches offers this preset. However, the "*" would not be selectable in the dropdown list or if it is selected then remove it automatically (or convert to yes).

Maybe the matching algorithm does not yet have this feature, but if one was added, it would only apply in specifically marked rules (like this with the *)

[AlfonZ]

Replying to aceman:

Yes, I do not want to change the internal logic of the matching algorithm. I meant to tweak only this rule like: <combo key="building" text="Building" values="yes,roof,garage,garages,industrial,church,school,hangar,commercial,farm,transportation,greenhouse,office,university,*" remove_if_star=true

So that any value in building matches offers this preset. However, the "*" would not be selectable in the dropdown list or if it is selected then remove it automatically (or convert to yes).

Maybe the matching algorithm does not yet have this feature, but if one was added, it would only apply in specifically marked rules (like this with the *)

It is indeed possible to do it - changing match="keyvalue" to match="key" would do the job. It's the exact opposite of #8995 - widening the matching of the preset.

There is also Residential Building that matches other values of building.
Letting it match all values would lead to displaying Building and Residential Building in the properties (for some values). It seems to me that they were split for a reason.

What would solve it is new matching logic - match key unless value is one of specified ones. This would mean something like

<combo key="building" text="Building" values="yes,roof,garage,garages,industrial,church,school,hangar,commercial,farm,transportation,greenhouse,office,university" default="yes" 
    match="key!value" match_values="residential,apartments,house,hut,terrace,detached" />

which seems too contrived for me.

[aceman]

That could be interesting idea:
Have the Building preset match all buildings (match="key") and having only common optional keys, like name, height, building:levels.
Then have the Residential preset and my proposed Commercial and maybe some others, that would match by keyvalue on some specific values and had their own specific fields (for commercial I proposed some, for residential we could have some others, and Industrial preset could have some others (like type of production)).

On the other hand, not matching the building preset is cool for incitating the user he is using an uncommon value and maybe he just made a typo...

[aceman]

incitating => indicating to the user

[aceman]

And actually after I have found out what junk values the database already contains (and the policy forbidding to fix typos), I am leaning towards the latter variant. Let the user clearly know he is using an uncommon value and is on an unsupported territory. So scratch point 3 from the bug description. Can you please implement points 1. and 2.? Thanks.

[Don-vip]

In 6193/josm:

see #8999 - add building=hospital/warehouse/retail to presets

[aceman]

OK, point 1. implemented by the patch looks fine.

[Don-vip]

it's hard to follow tickets containing different subjects. Point 1 is fixed so I close this ticket. Please create new ones (or find existing ones) for the other points, if still wanted (I think the building question is already addressed by at least another ticket)