Complain about ele values with decimals

[GerdP]

See ​https://www.openstreetmap.org/changeset/61665082 and ​https://www.openstreetmap.org/node/5832707336

I think JOSM should complain when someone adds ridiculous number of decimals. Autofix could be to round to full meter or feet (depending on the given unit).

[GerdP]

@Klumbumbus: Do you see a simple way to code that test as a MapCss rule? I see no existing test in Java where this would fit, so I'd create a new one.

[Klumbumbus]

​Values of ele with units ("m", "ft" or "feet") are extremely rare and we already have a warning for these in numerical.mapcss, so I think we can just ignore these.

This seems to work fine:

*[ele][ele =~ /^-?[0-9]+\.[0-9][0-9]+$/] {
  throwWarning: tr("Unnecessary amount of decimal places: {0}", "{0.tag}");
  fixAdd: concat("ele=", round(tag("ele")*10)/10);
  assertNoMatch: "node ele=12";
  assertNoMatch: "node ele=1.1";
  assertMatch: "node ele=12.12";
  assertMatch: "node ele=12.123";
  assertMatch: "node ele=-12.789";
  assertNoMatch: "node ele=12.123 m";
  assertNoMatch: "node ele=high";
}

It warns for more than one decimal place and rounds to 1 decimal place. According taginfo 204104 out of 216030 (94%) of different ele values include a . in the value (not sure how to quickly get the total number of objects).

[GerdP]

The wiki ​https://wiki.openstreetmap.org/wiki/Key:ele says "In general elevation information with sub-metre accuracy is rarely verifiable so elevations should usually be specified in integer metres."
Why would you want to keep one decimal?

[GerdP]

I see we already have some rules in numeric.mapcss, don't know why I didn't find them before. So quiestion is why none of them is triggered.

[Klumbumbus]

Replying to GerdP:

Why would you want to keep one decimal?

To not loose too much possible valid information with a autofix. "...elevations should usually be specified in integer metres." Sometimes a more precise ele is known, e.g. at ​osmwiki:Tag:man_made=survey_point

[GerdP]

OK, so one decimal sounds like a good compromise ;)

[Hb---]

Every geodetic elevation point in Germany has a Centimeter grade value, most points are better. Centimeter grade values are used in water management. So JOSM should be able to handle elevation values with such a precision. At least two decimals are needed.

[GerdP]

I've tested the patch, it works but produces one error entry for each different ele value:

Unnecessary amount of decimal places: ele=66.7372980286 (1)
Unnecessary amount of decimal places: ele=84.5246949189 (1)
Unnecessary amount of decimal places: ele=95.4709986092 (1)
Unnecessary amount of decimal places: ele=100.143864165 (1)
Unnecessary amount of decimal places: ele=120.75441489 (1)

I'd prefer to have a single group.

[GerdP]

Maybe like this:

*[ele][ele =~ /^-?[0-9]+\.[0-9][0-9][0-9]+$/] {
  throwWarning: tr("{0}", "{0.tag}");
  group: tr("Unnecessary amount of decimal places");
  fixAdd: concat("ele=", round(tag("ele")*100)/100);
  assertNoMatch: "node ele=12";
  assertNoMatch: "node ele=1.1";
  assertNoMatch: "node ele=12.12";
  assertMatch: "node ele=12.123";
  assertMatch: "node ele=-12.6789";
  assertNoMatch: "node ele=12.123 m";
  assertNoMatch: "node ele=high";

rounds to two digits and creates

Warnings (162)
Unnecessary amount of decimal places (162)
ele=64.6337576174 (1)
ele=66.7372980286 (1)
ele=84.5246949189 (1)
ele=95.4709986092 (1)

[Klumbumbus]

In 14940/josm:

• fix #17530 - warn about ele values with more than 2 decimal places
• ignore healthcare=dentist for now