OpenOrienteering / mapper

OpenOrienteering Mapper is a software for creating maps for the orienteering sport.
https://www.openorienteering.org/apps/mapper/
GNU General Public License v3.0
400 stars 106 forks source link

Area symbol editor uses minimum size with just one decimal place #1684

Open dl3sdo opened 4 years ago

dl3sdo commented 4 years ago

Actual behaviour

The area symbol editor uses just one decimal place for the 'Minimum size' in the 'Area settings' tab. The forest sample as well as drawing with the provided ISOM 2017-2 show (when using the 'Measure' tool) that the minimum size values use two decimal places, i.e., 2,25mm2 for symbol 406, etc.

Configuration

Mapper Version: v20200613.1 Operating System: Win7x64

dg0yt commented 4 years ago

I wonder if we shall just add another digit, or opt for rounding the limit. Such tiny objects seem to need human review anyway, no matter if 2.2 mm^2 or 2.3 mm^3.

krticka commented 4 years ago

This has high importance for automatic map checks. For example in OCAD there is Check legibility tool which checks minimum distances between objects, minimum line lenghts and area sizes. Than matters if area is 2,24 or 2,25 mm^2. Some mappers can produce map in Mapper, but in their contract they can have clause that the map will pass this Legibility check in OCAD. For example in Map Commission it is standard tool for checking the maps for IOF major events.

dg0yt commented 4 years ago

I hope objects which do not fail the automated check still receive the attention they need.

lpechacek commented 4 years ago

While the code change is trivial, I'm afraid the reasoning in the initial comment is flawed. The value 2.25 mm² is a result of map scaling. 1 mm² @ 1:15000 becomes 1.51.51 mm² @ 1:10000. The additional decimal place is a pure technicality. If I, for whatever reason, scale a map from 1:15000 to 1:13000, the said square millimeter on the map will become 1.331360947 mm². So the addition of just one additional decimal place in the map sample is just a coincidence, and depending on the initial minimum area value, digits on additional decimal places could have been generated.

Regarding the automated checks, I believe that the map legibility rules are defined by the limits of human vision and not computational peculiarities. Therefore specifying the legibility rules with 1/10 mm² resolution looks reasonable to me. Talking about the OCAD Legibility Check tool, I guess that the limits are hardcoded in the tool. I cannot tell for sure, however, as I have never seen the software live. When Mapper gets the legibility checks one day, I suggest that it works with the proposed resolution.

dg0yt commented 4 years ago

The additional decimal place is a pure technicality.

That's my point of view, too.

Looking for mm² minimum area sizes in the IOF PDFs yields:

Oh, I'm asked to discover 0.25 mm² out-of-bounds patches at competition speed.

krticka commented 4 years ago

There is nothing wrong with 0.25 mm² (4 sq. meters in real world on sprint map). Here is example of 520 Area that shall not be entered comparing to some other map symbols. Such small areas are typical for flower beds. Of course bounding line must be used to ensure legibility of such small patch. Schránka 01

dg0yt commented 4 years ago

Of course bounding line must be used to ensure legibility of such small patch.

Is the bounding line meant to be added strictly around the 0,25 mm², i.e. add to the footprint, or to be part of the 0.25 mm², i.e. cut from the key color?

krticka commented 4 years ago

The ISSprOM for 520 only says: The area shall always be delineated by a boundary line (at least 0.1 mm in width). For practical reasons (drawing with fill/create edge) bounding line is not strictly added around, but typically centred on the edge of 520 patch.

dg0yt commented 4 years ago

For practical reasons (drawing with fill/create edge) bounding line is not strictly added around, but typically centred on the edge of 520 patch.

Hm. This seems like another argument for not caring about the second place after the decimal point.

For practical reasons (import from OSM), I recently had to deal with a combined symbol (area + boundary line) where the boundary line was moved completed to the inner side area. I expect this to be used more often, and the "fill/create edge" tool may need to follow.

krticka commented 4 years ago

Hm. This seems like another argument for not caring about the second place after the decimal point.

In MC when deciding about minimum dimensions we are always discussing the influence of mandatory boundary lines (which are usually making patch more prominent). Such areas are often not drawn as combined symbol (boundary from several sides can be created by building, bank line, fence, etc.), measuring the area of stand-alone patch (without bounding line) I see as most practical.

For practical reasons (import from OSM), I recently had to deal with a combined symbol (area + boundary line) where the boundary line was moved completed to the inner side area. I expect this to be used more often, and the "fill/create edge" tool may need to follow.

Can you give me some example (data, graphic) of such situation? Thanks.

lpechacek commented 4 years ago
For practical reasons (import from OSM), I recently had to deal with a combined symbol (area + boundary line) where the boundary line was moved completed to the inner side area. I expect this to be used more often, and the "fill/create edge" tool may need to follow.`

Can you give me some example (data, graphic) of such situation? Thanks.

I think the illustration would be https://www.facebook.com/ollesmaps/posts/10160037235909676 and the associated defect report appears to be https://github.com/OpenOrienteering/mapper/issues/1602.