#19012 closed enhancement (fixed)
Tagging presets: Possibility to set "match" negative
Reported by: | skyper | Owned by: | simon04 |
---|---|---|---|
Priority: | normal | Milestone: | 21.03 |
Component: | Core | Version: | |
Keywords: | template_report tagging preset match false | Cc: | Klumbumbus |
Description (last modified by )
I need an option to exclude generic presets from Tags/Memberships panel and only show specific ones if objects contain certain tags. See wiki:Presets/MastAndTower for a real life example and ticket:6157:josm_6157_Preset_Debug.zip for a condensed one.
What steps will reproduce the problem?
- Have a general preset and a specific preset for the same main tag with both including same secondary tags
- Add main tag to object
- Add secondary tag to object
What is the expected result?
- After 2. the general preset is linked to from Tags/Memberships panel
- After 3. only the specific preset is linked
What happens instead?
After 3. generic and specific presets both are linked
Please provide any additional information below. Attach a screenshot if possible.
I could live with match="false"
for now but I wonder how I could add a tag not present in the preset to match negative.
Relative:URL: ^/trunk Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b Last:Changed Date: 2020-03-30 07:18:28 +0200 (Mon, 30 Mar 2020) Revision:16220 Build-Date:2020-03-30 23:25:33 URL:https://josm.openstreetmap.de/svn/trunk
Attachments (0)
Change History (11)
comment:1 by , 5 years ago
Description: | modified (diff) |
---|
follow-up: 6 comment:2 by , 5 years ago
comment:3 by , 5 years ago
Well for keys within the preset match="negKey/negKeyValue"
or similar should work and looks much easier.
Overall a complete search expression is much more flexible and would cover the case that the key is not present in the preset.
follow-up: 5 comment:4 by , 5 years ago
I guess the crucial part of the example is the following:
<item name="General preset Tower"> <key key="man_made" value="tower"/> </item> <item name="Small communication tower"> <key key="man_made" value="tower"/> <key key="tower:type" value="communication"/> </item>
For a node man_made=tower tower:type=communication
only the second preset should match?
Where/how would you specify match="negKey/negKeyValue"
?
comment:5 by , 5 years ago
Replying to simon04:
I guess the crucial part of the example is the following:
<item name="General preset Tower"> <key key="man_made" value="tower"/> </item> <item name="Small communication tower"> <key key="man_made" value="tower"/> <key key="tower:type" value="communication"/> </item>For a
node man_made=tower tower:type=communication
only the second preset should match?
Yes, this is without the key in the first item and the general approach.
Where/how would you specify
match="negKey/negKeyValue"
?
My preset looks like this:
<item name="General preset Tower"> <key key="man_made" value="tower"/> <multiselect key="tower:type" text="Type of tower" match="negKey"> <list_entry value="bell_tower" display_value="Bell tower" icon="Tower_bell_tower.svg" /> <list_entry value="communication" display_value="Small communication tower" icon="Tower_cantilever_communication.svg" /> <list_entry value="cooling" display_value="Cooling" icon="Tower_cooling.svg" /> </multiselect> </item> <item name="Small communication tower"> <key key="man_made" value="tower"/> <key key="tower:type" value="communication"/> </item>
comment:6 by , 4 years ago
Cc: | added |
---|
Replying to simon04:
For relation
<role>
s, we usemember_expression
to test for matches. Would a similar attribute be helpful for a preset<item>
as well?
Definitely! Never used it, but it looks like the need extension also for preset links
I just noticed the problem is already present in defaultspresets, meanwhile. Have a look at a bus stop with bus=yes
. The "Access Restriction" preset is linked.
comment:7 by , 4 years ago
Milestone: | → 21.03 |
---|---|
Owner: | changed from | to
Status: | new → assigned |
comment:9 by , 4 years ago
Thanks, so defaultpresets can profit from this for now, as my presets have to wait at least a few months, see #20667.
For relation
<role>
s, we usemember_expression
to test for matches. Would a similar attribute be helpful for a preset<item>
as well?