Opened 6 years ago

Closed 6 years ago

Last modified 2 weeks ago

#10913 closed defect (fixed)

Sequential execution of fix* commands in validator rules

Reported by: mkoniecz Owned by: team
Priority: normal Milestone: 15.04
Component: Core validator Version:
Keywords: template_report Cc: Klumbumbus


What steps will reproduce the problem?

  1. Make validator rule with multiple fix* commands

For example:

fixChangeKey: "highway => construction";
fixAdd: "highway=construction";

executed on

highway=tertiary, construction=yes

What is the expected result?

fix* commands operate on state modified by previous fix* operations:

highway=tertiary; construction=yes

<after fixChangeKey: "highway => construction";>

highway=construction; construction=tertiary
<after fixAdd: "highway => construction";>

What happens instead?

Output is


It is equivalent of executing fixAdd before fixChangeKey. Order of fix* commands is ignored (it is neither going first to last nor from last to first). Adding fixRemove "construction"; failed to improve situation (I hoped that fixChangeKey refuses to overwrite existing key).

Please provide any additional information below. Attach a screenshot if possible.

Repository Root:
Build-Date: 2015-01-01 02:35:00
Last Changed Author: Don-vip
Revision: 7919
Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Relative URL: ^/trunk
Last Changed Date: 2015-01-01 02:55:34 +0100 (Thu, 01 Jan 2015)
Last Changed Rev: 7919

Identification: JOSM/1.5 (7919 en) Linux Ubuntu 14.04.1 LTS
Memory Usage: 326 MB / 889 MB (164 MB allocated, but free)
Java version: 1.7.0_72, Oracle Corporation, Java HotSpot(TM) Server VM
Dataset consistency test: No problems found

- OpeningHoursEditor (30892)
- buildings_tools (30892)
- continuosDownload (1413902943)
- ext_tools (30892)
- measurement (30892)

I was attempting to run custom validation rule

*[construction=yes][highway =~ /motorway|trunk|primary|secondary|tertiary|unclassified|residential|service|living_street|pedestrian|cycleway|footway|steps|path|bridleway|track|bus_guideway|raceway|road|/][highway!=construction] {
  throwWarning: tr("{0} with {1}=* (highway=construction, construction=* is a superior tagging scheme)", "{0.tag}", "{1.key}", "{1.value}");
  fixRemove: "construction";
  fixChangeKey: "highway => construction";
  fixAdd: "highway=construction";


Making separate rule for every highway value would be feasible but awful hack.

Attachments (0)

Change History (9)

comment:1 Changed 6 years ago by Klumbumbus

Cc: Klumbumbus added

comment:2 Changed 6 years ago by Don-vip

Component: CoreCore validator
Milestone: 15.01

comment:3 Changed 6 years ago by Don-vip

Milestone: 15.0115.02

comment:4 Changed 6 years ago by Don-vip

Milestone: 15.02

comment:5 Changed 6 years ago by mkoniecz

So I should rather use workaround rather than waiting for fix?

comment:6 Changed 6 years ago by Don-vip

I plan to fix it but I have no time right now and I can't promise any date. It won't be for this release at least.

comment:7 Changed 6 years ago by simon04

Resolution: fixed
Status: newclosed

In 8265/josm:

fix #10913 - MapCSS validator: retain sequence of fixing commands

comment:8 Changed 6 years ago by simon04

Milestone: 15.04

comment:9 Changed 2 weeks ago by Don-vip

In 17499/josm:

see #20498 - see #10913 - partial revert of r17497, breaks other use cases

Modify Ticket

Change Properties
Set your email in Preferences
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment

E-mail address and name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.