Add ISSprOM 2019 symbol set

[dg0yt]

Task: GH-1037

[dg0yt]

Let's move on with ISSprOM.

TODO: Scaling/deployment.

Request for comment: Color levels. Most significant deviations:

• Grey for bare rock is above green for area features, as in
  our ISOM 2017-2 symbol set.
• Blue 100% for area features and blue screens are below light
  browns.

[dg0yt]

@yevhenmazur @krticka @Zerbembasqwibo @ollesmaps I'm going to merge this soon, for the next master build.
ISSprOM.zip

[ollesmaps]

I would rather put grey for bare rock bellow greens. Bare rock is in character similar to other open areas (yellows). And bushes (green) grow on top of it.
This discussion somehow relates:
https://www.facebook.com/groups/485564718218028/permalink/2432700646837749/

Blue area x light browns. Order really does not matter IMHO.

[ollesmaps]

Offtopic?
"In laser printing overprinting effect must be simulated. The easiest way to do this is to place the purple track colour in the colour order below black, brown and blue 100% colours."
How is this going to be achived in stand alone apps (Purple Pen with Mapper as template)?

[ollesmaps]

I do not like contours above edges of pavement. I think thin linear pavements almost disappear bellow contours.

I know it is either/ or situation. Either seamless connection of linear pavements or contours bellow edges of pavement. It is a pity we can not have both at the same time.

[krticka]

We have already discussed such issues in MC. The problem is biggest when the path follows the index contour. It is possible to define black edges above contours, but than you can't use predefined double line with brown infill for fast drawing of the junctions of pavements. The junctions must be drawn by hand. Some mappers are already drawing edges separately with hand made area infill, but majority not. I would like to see black for the edges over brown, but not sure about impacts on the less experienced mappers. LK

…

---------- Původní e-mail ---------- Od: Aleš Hejna <notifications@github.com> Komu: OpenOrienteering/mapper <mapper@noreply.github.com> Datum: 9. 12. 2019 11:30:06 Předmět: Re: [OpenOrienteering/mapper] Add ISSprOM 2019 symbol set (#1348) " I do not like contours above edges of pavement. I think thin linear pavements almost disappear bellow contours. I know it is either/ or situation. Either seamless connection of linear pavements or contours bellow edges of pavement. It is a pity we can not have both at the same time. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub (#1348?email_source=notifications&email_token=ADZ2ZGUCB7MWXM5ZNQO3JGTQXYM2TA5CNFSM4IVDXXP2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGIUEAQ#issuecomment-563167746) , or unsubscribe (https://github.com/notifications/unsubscribe-auth/ADZ2ZGWWC6YB76TIBY2SRZDQXYM2TANCNFSM4IVDXXPQ) . "

[dg0yt]

I would rather put grey for bare rock bellow greens. Bare rock is in character similar to other open areas (yellows).

This is a fair point from a consistency point of view: yellow and grey meaning open area.

But there is another view on consistency: Other than yellow and green, grey means no vegetation.
Now, yellow and green are used together for some kind of vegetation (open land with scattered bushes, orchard, vineyard). Grey must not mix in. Thus if we want to make it easy to use the symbols right, and hard to use these symbols wrongly, grey can be either above green or below yellow, but not in the middle.
(Side note: I also added a level of black between yellow and green, for open sandy ground and for cultivated land: either both yellow and black are covered by green, or both are visible.)

Now assuming that bare rock is less common than yellow and green, I think it is easier to add accurate patches of grey on top of yellow and green, than anything else.

And bushes (green) grow on top of it.

There is no problem with bushes etc. anyway: This green is on a much higher level, even above paved areas, bodies of water, (lower purple) track symbols.

[dg0yt]

Offtopic?
"In laser printing overprinting effect must be simulated. The easiest way to do this is to place the purple track colour in the colour order below black, brown and blue 100% colours."
How is this going to be achived in stand alone apps (Purple Pen with Mapper as template)?

Haha! I was wondering how long it takes for someone to come up with this question...
Probably not so much an issue for international events. However, that's just a minor share of all orienteering activites, and I think it is reasonable to ask for a way to do proper course setting on top of fixed map content (PNG, JPG, whatever).

[dg0yt]

I do not like contours above edges of pavement. I think thin linear pavements almost disappear bellow contours.

Same for me. However, I feel that is unclear what is actually desired by the specification. There is no example or instruction given in ISSprOM, and also the color specs aren't a complete and consistent guide. (What about contour lines, or track symbols, and black edges of buildings and uncrossable bodies of water?)

When a paved path follows a contour, you can still move the contour away from the edge of the paved area.

[ollesmaps]

Wouldn't be there a software solution to this conondrum possible? A local overprint effect? I assume it might come in hand also in other stances.

Note: In spot colors printing this is solved.

[dg0yt]

Wouldn't be there a software solution to this conondrum possible? A local overprint effect? I assume it might come in hand also in other stances.

Note: In spot colors printing this is solved.

One software solution was overprinting simulation.

• Pros: Mitigates some other issues. Output only, not affecting file format
• Cons: Rasterization / file size. Mixed colors possibly not accurate.

Another solution would be to use the brown infill to for clipping the black edge lines when they are printed above the brown contour lines.

• Pros: Desired output.
• Cons: Not possible with current file formats, thus likely to lead to incompatibilities. Possibly computationally expensive a) when computing clipping masks (map software) and b) when using the clipping mask (printer driver, printer).

CMYK+B will solve this by... overprinting. However, this means to actually produce a suitable PDF file to give to the print shop. Not sure which map software can do this at the moment, without tricks.

[dg0yt]

I guess I can proceed with merging, to offer the symbol set with the next master snapshot, for broader review?

There is no short-term solution to the cyclic problem of 'edge covers contour covers infill covers edge' problem.

• Current implementation: brown contours above the others. No direct contradiction to ISSprOM.
• Alternative: black edges above the others. For now, this means forcing map makers to draw crossing explicitly in order to conform to ISSprOM.

If we would implement the missing 'line gap' feature for border lines (GH-150) it would be possible to interrupt edges at crossings. However, I think it may be tricky to hit the exact points exactly. With the current implementation, it should be possible to upgrade maps safely. With the mentioned alternative, the map data would already be different, so an upgrade would be less beneficial.