Modify

Opened 5 days ago

Closed 40 hours ago

#19805 closed defect (fixed)

MapCSS meaning of 'none'

Reported by: frodrigo Owned by: team
Priority: normal Milestone: 20.09
Component: Core validator Version:
Keywords: mapcss, osmose Cc: taylor.smock

Description

combinations.mapcss now provide this rule

789	*[fixme][count(split(" ", tag("fixme"))) == 1][tag(tag("fixme")) != "none"],
790	*[FIXME][count(split(" ", tag("FIXME"))) == 1][tag(tag("FIXME")) != "none"] {
791	  throwWarning: tr("{0} together with {1}. Is the fixme fixed?", "{0.tag}", "{0.value}");
792	  group: tr("suspicious tag combination");
793	  assertMatch: "way name=\"Florist Gump\" fixme=name";
794	  assertMatch: "way name=\"Florist Gump\" FIXME=name";
795	  assertNoMatch: "way fixme=name";
796	  assertNoMatch: "way name=\"Florist Gump\"";
797	  assertNoMatch: "way name=\"Florist Gump\" fixme=\"the name might have changed\"";
798	}

I concerned about this part

[tag(tag("fixme")) != "none"]

It checks if there is no key like the value of fixme key. But comparing to the "none" string.

It asserted with

795	  assertNoMatch: "way fixme=name";

It strange to me to check "none" string as not existing tags.

This assert fails on Osmose-QA MapsCSS implementation.

Attachments (0)

Change History (7)

comment:1 Changed 5 days ago by Klumbumbus

Cc: taylor.smock added

from #17296
Yes, to be safe we could replace "none" by something like "a_value_that_hopefully_never_appears_in_the_osm_database_:o"
But it would still fail in the osmose interpreter, would it?.

Last edited 5 days ago by Klumbumbus (previous) (diff)

comment:2 Changed 5 days ago by taylor.smock

It looks like I used none because println was returning none instead of null (System.out.println(o == null ? "none" : o.toString());). I think, at the time I wrote the test, I was using println to see what values were output, and using that to check against.

Should we change the println function to print null when the object is null? Or is none a mapcss special value?

Last edited 5 days ago by taylor.smock (previous) (diff)

comment:3 Changed 4 days ago by Klumbumbus

So we have basically 3 different problems here:

  1. "none" in the rules is not a good choice as currently a way with fixme=sidewalk + sidewalk=none is not catched by the rules. This can easily be fixed, see comment:1
  1. A simple a!=b selector does not require the presence of the key a to match. But in our case [tag(tag("fixme")) != "none"] requires the presence of tag("fixme") e.g. name=*. I don't know if this is a bug, feature or hack, but in this case it makes the rule work in the first place by not matching solely fixme=name. A simpler implementation could be [(tag("fixme")] instead of [tag(tag("fixme")) != "none"], but that doesn't work in JOSM (it matches solely fixme=name).
  1. none vs. null as output of println.

comment:4 Changed 4 days ago by skyper

Does an additional count solve it?
[count(tag(tag("fixme"))) > 0]

comment:5 in reply to:  4 Changed 4 days ago by Klumbumbus

Replying to skyper:

Does an additional count solve it?
[count(tag(tag("fixme"))) > 0]

No, but I found another solution which seems to work fine:

[has_tag_key(tag("fixme"))]

comment:6 Changed 4 days ago by Klumbumbus

Milestone: 20.09

comment:7 Changed 40 hours ago by Klumbumbus

Resolution: fixed
Status: newclosed

In 17038/josm:

fix #19805, see #17296 - Improve "Is the fixme fixed?" validator warning

Modify Ticket

Change Properties
Set your email in Preferences
Action
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.