Visually differentiate deprecated tags

[naoliv]

When some tags are deprecated in JOSM they get represented only as a grey line and without a description in the Tags/Memberships window.

For example, the recent land=farm:

The same for power=sub_station and others.

I already saw people deleting objects from OSM just because they were strange or not properly represented. For example, some users thought that a "grey line" wasn't actually a valid object and just deleted. Or they just thought it was an empty (0 tags) object.

I guess it's even worse for relation members, where they have only a grey color and no properties.

Could the objects with a deprecated tag be represented with a different color, please?
Some color that means "this object is not wrong" + "this object is not empty" + "this object needs to be updated".

Also note that it's not everybody who validates the data in JOSM and thus they won't note/know why the object is only grey.

JOSM:

URL:http://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2016-01-05 00:10:30 +0100 (Tue, 05 Jan 2016)
Build-Date:2016-01-05 02:32:35
Revision:9316
Relative:URL: ^/trunk

Identification: JOSM/1.5 (9316 en) Linux Debian GNU/Linux testing (stretch)
Memory Usage: 887 MB / 9102 MB (588 MB allocated, but free)
Java version: 1.8.0_72-internal, Oracle Corporation, OpenJDK 64-Bit Server VM
VM arguments: [-Dawt.useSystemAAFontSettings=on]
Dataset consistency test: No problems found

[Don-vip]

How could we do this? deprecated.mapcss should become at the same time a map style and a set of validator rules. Do you see a possibility to have something like that:

*[landuse=farm] {
  throwWarning: tr("{0} is deprecated", "{0.tag}");
  suggestAlternative: "landuse=farmland";
  suggestAlternative: "landuse=farmyard";
  fill-color: deprecated#ff0000;
}

[bastiK]

Yes, should work, but the perfectionist in me doesn't like that useless properties are evaluated during style and validator run. It would indeed be convenient to maintain both rules in one place. Maybe like this?:

@media (validator) {
  *[landuse=farm] {
    throwWarning: tr("{0} is deprecated", "{0.tag}");
    suggestAlternative: "landuse=farmland";
    suggestAlternative: "landuse=farmyard";
  }
}
@media (mapstyle) {
  *[landuse=farm] {
    fill-color: deprecated#ff0000;
  }
}

Not sure if @media fits here, but the good thing is that it's evaluated at "compile-time".

[Don-vip]

@media or @supports? I though @media was deprecated and we could drop its support.

[bastiK]

Replying to Don-vip:

@media or @supports? I though @media was deprecated and we could drop its support.

@media for the purpose of checking supported features is deprecated. It would be good for the intended use case, i.e. to check output device (screen/printer, high-resolution/standard-resolution, ...). As long as this is not relevant in JOSM, we can drop @media.

For switching between validator and mapstyle, @supports doesn't seem like a perfect fit. But to keep things simple, I think it is better than inventing something new again.

[Don-vip]

Replying to bastiK:

@media for the purpose of checking supported features is deprecated. It would be good for the intended use case, i.e. to check output device (screen/printer, high-resolution/standard-resolution, ...). As long as this is not relevant in JOSM, we can drop @media.

ok then maybe it could be useful in the future with hidpi screens? (#8764 / #9995 / #11806)

[bastiK]

My first idea to fix mapview for hidpi would be an option for a global scale factor of 2. I.e. all lines twice as wide and icons scaled up times 2. This would not require a change to the mapcss code. But for manual fixes in the style, @media would be appropriate.

[Klumbumbus]

see also #10529