Check for trees that are too big

[anonymous]

According to the Guinness World Records, the greatest circumference for a tree is 43m. I suggest implementing a check for trees with circumferences exceeding this value, as they are likely to be errors.

For instance, we currently have 2001 nodes in the database with a circumference of 45: ​https://overpass-turbo.eu/s/1JUU. Osmose could suggest to check them and:

1. delete the value if plainly wrong or
2. fix 'circumference=45' to 'circumference=0.45' or 'circumference=45 cm'

Another check could be on height. Trees taller than Hyperion (tallest tree in the world with 116m) are likely to be errors.

​I suggested this check in Osmose and they redirect me here:

​https://overpass-turbo.eu/s/1JWd
At least 62638 trees worldwide affected by the circumference limit of 43m (excluding those with units or decimals).

I suspect this might be interesting for JOSM, for their numerical validation rules (which we synchronize with Osmose). That way it benefits more people and people who add those trees get a warning prior to uploading it in the first place.

[Famlam]

If interesting for JOSM, I would propose the following rule:

node[circumference >= 50][natural=tree] {
  throwWarning: tr("Unusually large value of {0} in meters, possibly centimeter units are meant?", "{0.key}");
  assertMatch: "node natural=tree circumference=200";
  assertMatch: "node natural=tree circumference=82.4";
  assertNoMatch: "node natural=tree circumference=18.4";
  assertNoMatch: "node natural=tree circumference=\"100 cm\"";
  assertNoMatch: "node natural=tree circumference=43"; /* Current world record */
}

This gives about 72k results worldwide.
Or, if you also want to also include the 2 trees worldwide with m-units explicitly specified:

node[circumference=~/^([1-9][0-9]{2,}|[5-9][0-9])(\.[0-9]+)?( ?m)?$/][natural=tree] {
  throwWarning: tr("Unusually large value of {0} in meters, possibly centimeter units are meant?", "{0.key}");
  assertMatch: "node natural=tree circumference=200";
  assertMatch: "node natural=tree circumference=\"82.4 m\"";
  assertNoMatch: "node natural=tree circumference=18.4";
  assertNoMatch: "node natural=tree circumference=\"100 cm\"";
  assertNoMatch: "node natural=tree circumference=43"; /* Current world record */
}

[gaben]

I would opt for the first version, easier to understand and maintain.

Also the circumference and diameter_crown should be added to the numeric validator to warn cases such as circumference=10m -> circumference=10 m.

[GerdP]

Is there really no method to ask for the - possibly converted - value in m using mapcss?
We have a similar test for towers also using a very complex regex:

*[man_made=communications_tower][height][height =~ /^((7[0-4]|[1-6]?[0-9])(\.[0-9]*)?( m)?|(2(4[0-5]|[0-3][0-9])|1?[0-9]?[0-9])((\.[0-9]*)?( ft|\')|\'(11|10|[0-9])(\.[0-9]*)?\"))$/] { /* 75m ~ 246ft ~ 246' */
  throwWarning: tr("{0} together with {1}", "{0.tag}", "{1.tag}");
  suggestAlternative: "man_made=tower + tower:type=communication + height";
  group: tr("suspicious tag combination");
  assertMatch: "node man_made=communications_tower height=58";
  assertMatch: "node man_made=communications_tower height=\"74 m\"";
  assertMatch: "node man_made=communications_tower height=0.8";
  assertMatch: "node man_made=communications_tower height=245'";
  assertMatch: "node man_made=communications_tower height=\"224.22 ft\"";
  assertMatch: "node man_made=communications_tower height=231'10.22\"";
  assertNoMatch: "node man_made=communications_tower height=\"75 m\"";
  assertNoMatch: "node man_made=communications_tower height=75.72";
  assertNoMatch: "node man_made=communications_tower height=\"328.22 ft\"";
  assertNoMatch: "node man_made=communications_tower height=4358'8\"";
  assertNoMatch: "node height=4358'";
}

[gaben]

In Rules/Runways I've used some MapCSS hack (to_int()) to get the value, but it does not look better.

[skyper]

There is a ticket about supporting unit conversion with a library but I cannot find it right now. Maybe it was closed as wontfix as the size of the library was to big.

[gaben]

Is it a call for a conversion plugin? :)

[Famlam]

I think it would be a 'nice to have' to support all units (either as a plugin or via a complicated mapcss regex or ...), but I don't think it should be a blocker for this issue, not?
I mean, if I quickly search for any circumference tag value containing a ', ", "in" or "ft", there's just 317 worldwide.

I suspect the majority of the cases with 'too large' circumferences will be due to people who assume the wrong default unit, thus for instance entering a value in mm without adding mm to the value. (For such cases the simple numerical rule in comment:2 would be enough)

[gaben]

FYI: Yesterday I created a unit conversion plugin. So far it's capable converting metric lenght values, the imperial ones not yet.

The biggest work would be to collect and categorize all the tags which contains units.

Regarding the ticket, I'm fine with the proposed rule from comment:2.

[GerdP]

A plugin seems wrong to me if we distribute the rules with core.

[gaben]

Yeah, but is there a better option? It wouldn't make into core because it's using a ​lib.

[stoecker]

Writing a function to convert about 10 different units shouldn't be so complicated that it needs a lib. Supporting strange units is anyway a bad idea. There is reason why SI units exist.