Complain about natural=rock used for large areas and suggest natural=bare_rock instead

[mkoniecz]

What steps will reproduce the problem? ¶

1. Create large closed way to represent rock surface (like ​https://www.openstreetmap.org/way/32639987 or ​https://www.openstreetmap.org/way/375390567 ) and tag it with natural=rock
2. Run validator

What is the expected result? ¶

Validator suggest using natural=bare_rock instead

What happens instead? ¶

Nothing

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

I am not sure what would the largest rock that is "notable rock feature or small group of rocks, attached to the underlying bedrock" but if this idea is in principle accepted I may research it.

OSM Wiki claims that

natural=rock describes a notable rock feature or small group of rocks, attached to the underlying bedrock, mainly as a single node element.

On the contrary, single boulders not attached to the bedrock are better tagged as natural=stone.

For larger bedrock areas you may use natural=bare_rock.

​https://wiki.openstreetmap.org/wiki/Tag:natural%3Drock

Triggered by ​https://github.com/gravitystorm/openstreetmap-carto/pull/3832

URL:https://josm.openstreetmap.de/svn/trunk
Repository:UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b
Last:Changed Date: 2019-08-11 22:00:20 +0200 (Sun, 11 Aug 2019)
Build-Date:2019-08-12 01:30:56
Revision:15296
Relative:URL: ^/trunk

Identification: JOSM/1.5 (15296 en) Linux Ubuntu 16.04.6 LTS
Memory Usage: 442 MB / 869 MB (105 MB allocated, but free)
Java version: 1.8.0_201-b09, Oracle Corporation, Java HotSpot(TM) 64-Bit Server VM
Screen: :0.0 1920x1080
Maximum Screen Size: 1920x1080
libcommons-logging-java: libcommons-logging-java:all-1.2-1+build1
fonts-noto: fonts-noto:-
Dataset consistency test: No problems found

Plugins:
+ OpeningHoursEditor (34977)
+ PicLayer (35030)
+ buildings_tools (34982)
+ continuosDownload (82)
+ ejml (35049)
+ geotools (34908)
+ imagery_offset_db (34908)
+ jts (35064)
+ log4j (34908)
+ measurement (35051)
+ reverter (35084)
+ todo (30306)

Validator rules:
+ ${HOME}/Documents/install_moje/OSM software/josm/data/validator/deprecated.mapcss
+ ${HOME}/Documents/install_moje/OSM software/josm/data/validator/unnecessary.mapcss
+ ${HOME}/Documents/install_moje/OSM software/josm/data/validator/combinations.mapcss

Last errors/warnings:
- W: No configuration settings found.  Using hardcoded default values for all pools.

[Klumbumbus]

I guess it could be hard to argee on a value of the area size here even if we use a range between without warning similar to what we do with island/islet (wiki value is 1km² and we warn if <0,5m² or >1,5m² with wrong tag)

/* #12496 */
area:closed[place=islet][eval(areasize()) > 1500000] {
  throwWarning: tr("{0} on a large area", "{1.tag}");
  suggestAlternative: "place=island";
  fixAdd: "place=island";
}

area:closed[place=island][eval(areasize()) < 500000] {
  throwWarning: tr("{0} on a small area", "{1.tag}");
  suggestAlternative: "place=islet";
  fixAdd: "place=islet";
}

[mkoniecz]

Note that natural=bare_rock can be correctly used for very small areas, so only warning for overly large areas with natural=rock makes sense.

I guess it could be hard to argee on a value of the area size here

Yes, that would require some research, but I would expect single rock or "small group of rocks" to be smaller than 0.5 km2. So warning from something like 0,5 km2 or 0,75 km2 or 1 km2 would IMHO make sense.

[Klumbumbus]

Replying to mkoniecz:

Note that natural=bare_rock can be correctly used for very small areas, so only warning for overly large areas with natural=rock makes sense.

OK.

I guess it could be hard to argee on a value of the area size here

Yes, that would require some research, but I would expect single rock or "small group of rocks" to be smaller than 0.5 km2. So warning from something like 0,5 km2 or 0,75 km2 or 1 km2 would IMHO make sense.

Is it possible to count with overpass how much objects that would be each?