Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Made military area rendering less prominent. #3057

Merged
merged 7 commits into from
Feb 15, 2018

Conversation

andrzej-r
Copy link
Contributor

Re #3045

This version does the following:

  • Military areas are displayed at zoom >= 9 with more aggressive (way pixels >= 900)
  • No filtering at zoom >= 13
  • More transparent fill pattern (0.08 opaque)
  • More transparent and finer hatching pattern (0.16 opaque)
  • More transparent (0.24 opaque), thinner (1-2px) and offset (0.5-1px) border lines
  • Border lines switch to 2px wide at zoom >= 15

Examples (the reddish area in the middle is military area + danger_area, the latter was not modified):
ver3_l10
ver2_l14

@kocio-pl
Copy link
Collaborator

kocio-pl commented Feb 6, 2018

In fact danger area rendering was changed, because it uses the same overlay file as standard military area (military_red_hatch.png) and you made it lighter. My idea was to leave it for danger area to stand out, because there are not so many of them probably (for example it doesn't bite me with landfills, which are quite strong, but not too common). What do you think about having both versions of a raster layer?

@andrzej-r
Copy link
Contributor Author

Danger area uses symbols/danger.svg:

  [feature = 'military_danger_area'] {
    [zoom >= 9][zoom < 11] {
      polygon-fill: @danger_area;
      polygon-opacity: 0.3;
      [way_pixels >= 4]  { polygon-gamma: 0.75; }
      [way_pixels >= 64] { polygon-gamma: 0.3;  }
    }
    [zoom >= 11] {
      polygon-fill: @danger_background;
      polygon-pattern-file: url('symbols/danger.svg');
      [way_pixels >= 4]  { polygon-pattern-gamma: 0.75; }
      [way_pixels >= 64] { polygon-pattern-gamma: 0.3;  }
    }
  }

It contains a fine 'X' pattern you can just about see in one of examples.

I agree it should be improved, but it wasn't the goal of that fix.

As for the pattern for the danger_area, I'm not quite equipped for svg editing - this may be job for someone else. I you are OK with a raster pattern in png I can prepare one for a discussion in #3045. For example, we could use a bit more opaque version of military_red_hatch.png with -45Deg lines.

@kocio-pl
Copy link
Collaborator

kocio-pl commented Feb 6, 2018

I know, I did the SVG version of this x, but I think this is barely noticable even on your "after" rendering and not as clear symbol, so I'd like to get rid of this, making a difference only in hatching. When the standard area will be lighter, it will be easy to see the strong hatching, which has clear connotation ("don't go there").

@andrzej-r
Copy link
Contributor Author

Hi kocio-pl, anything you want me to do with regard to this pr? I assumed danger_area will be improved later/separately. Or do you want to bundle both changes together?

@kocio-pl
Copy link
Collaborator

kocio-pl commented Feb 9, 2018

If there are no objections, I suggest to make it at once. But if there are any or you think this would be too broad, we can deal with it in another PR.

@andrzej-r
Copy link
Contributor Author

Any suggestions for the pattern of danger_area? If it is hard to decide I would recommend moving this discussion to #3045.

There is also a possibility of further reducing opacity of the military area or removing hatching from it, which would make the existing danger area more noticeable.

@kocio-pl
Copy link
Collaborator

My idea is simple - just continue to show it like currently (so current PNG file shouldn't be removed), but without x and with the same line offset as new military area.

@andrzej-r
Copy link
Contributor Author

Sorry, I don't quite get it. Do you mean the following changes to the danger_area:

  • Use the original military_red_hatch.png (before my modifications) instead of danger.svg for danger_area fill
  • Use a border line with offset (width 2, offset 1)? Currently there is none.
  • Remove fill colour/opacity/gamma (it will be set by the png)

If you want to keep old and new png's, I will rename them to military_red_hatch.png and danger_red_hatch.png. Just want to make sure that's indeed what is needed.

@kocio-pl
Copy link
Collaborator

Yes, this is a the shopping list I would propose. 😄

@andrzej-r
Copy link
Contributor Author

I've modified the military danger area. Just using the original military_red_hatch.png pattern resulted in very contrasting rendering, which IMHO defeats the main purpose of this PR (making the rendering of military areas less obnoxious). I've modified the pattern a bit to turn down the opacity and line thickness (4->3px) of hatching lines and, at least to me, the result looks like a good trade-off.

Note that the danger_area is also used in amenity-points.mss. I haven't touch this part except for matching the text colour to the updated fill pattern.

Before and after (combined both military and danger area changes) comparison:
military_and_danger_area_l14

@kocio-pl
Copy link
Collaborator

Thanks, it looks sane for me - we can apply some more tuning and test rendering more, but I guess this code is mergable in general and fixes most of the problems. I'm not sure if the outline offset is big enough (especially with city walls), but more aggressive filtering of military areas is nice.

My rendering tests (see also #3045 (comment) ):

Military area (with and without the barrier) compared to commercial, retail, industrial and power areas around:
zilpz8yd
4jslryg4
df4_sle_

City area:
z12
Before
rs8ytu7e
After
v4grh6bi

Country level:
z9
Before
cyv2foko
After
auo5isfh

z11
Before
cwu7e4nv
After
00bizamj

@matthijsmelissen
Copy link
Collaborator

That's a big improvement, thanks!

@kocio-pl
Copy link
Collaborator

Name rendering and area rendering need to be synchronized. We can have the area with no name label, but not the other way around.

I guess since we don't have use case for military areas on z7, we can start on z8, just like with the other areas, for example nature reserves, which have similar rendering.

New Mexico example:
z8
yijt3fyp
z9
ouftx64v

Treating them the same way as military_danger_area labes.
Both were already using the same font size, colour etc.
Now they also use the same filtering options.
@andrzej-r
Copy link
Contributor Author

I've adjusted text filtering options for military areas (z8->z9). In fact, I've combined military_area and military_danger_area label rendering code, as they were already using the same rendering settings. (Previously military_area was sharing code with natural_wood, landuse_forest, boundary_national_park, leisure_nature_reserve areas which all start at z8).

@kocio-pl
Copy link
Collaborator

Did you test this change? Looks like something got broken and the names are not shown even when they were visible before:

Example
6mhbvi60

@andrzej-r
Copy link
Contributor Author

andrzej-r commented Feb 11, 2018

Sorry. Working on it.
[...]
Should be fixed now. Two errors: wrong layer name and an incorrect font face.

@kocio-pl
Copy link
Collaborator

Now it works as expected, also in New Mexico. I would however start with z8, like we do with nature reserves - we can set filter to avoid too small areas being shown (for nature reserves we filter out the areas that are too small to show their name).

@andrzej-r
Copy link
Contributor Author

But before the last two commits it was starting from z8. Do you mean I should revert them and change the stating zoom level for landuse_military to z8?

@kocio-pl
Copy link
Collaborator

kocio-pl commented Feb 11, 2018

Sorry, I try to follow more issues and I loose the sight of details, so I'm not 100% sure what was the state before last two commits. IIRC you've made small code fix which makes sense for me ("I've combined military_area and military_danger_area label rendering code"), so maybe it's better to not revert it, for the sake of clarity, but instead add zoom-entry-level fix on top of it.

@andrzej-r
Copy link
Contributor Author

Before my modifications, handling labels of military areas was combined with other land-use labels as they were all rendered from z8. Military danger areas are rendered from z9, so when you asked me to switch the military area from z8 to z9 it was logical to detach it from the existing code and combine it with the code handling labels for military danger areas.

But, if the plan is now to switch back to z8, I'd just revert to the original code, as there was nothing wrong with it. Then, of course, there will be cases of lone labels you've noticed. To fix that we would have to push back rendering the military areas themselves from z9 to z8.

So, I'd suggest (in order of my preference) :-)

  1. Use the current implementation (both military and danger areas rendered from z9),
  2. Revert last two commits and modify the military area to be rendered from z8 like other land uses (except the danger area that is rendered from z9).

@kocio-pl
Copy link
Collaborator

You know my reasons to stay with z8 (analogy with nature reserves and some other landuses), so I would choose 2 (however I don't know why danger area is rendered later). What are your reasons to omit z8 completely?

@andrzej-r
Copy link
Contributor Author

I chose z9 specifically to match it to military_danger_area and to suppress visibility of military areas in general (initially they were way overexposed because of limits and the rendering style).

Z8 is still fairly low ("a map of a small country/large region"), at this level users are still interested in basics (large cities, topography, large land uses and waterways, main communication routes) rather than features, and military areas are IMHO a feature.

For comparison:

  • Heathrow doesn't show up until z10.
  • Military danger area (which arguably are more important features than regular military areas) show up at z9.

The above is my opinion. If you disagree let's just switch back to z8. Both solutions are an improvement over the current rendering.

@kocio-pl
Copy link
Collaborator

OK, so let's get back to z8 - rendering will be weaker, so it will be less visible than currently at least.

@andrzej-r
Copy link
Contributor Author

Done

@kocio-pl
Copy link
Collaborator

Thanks! I plan to check it again soon and this time I will also take a look at military danger areas (I haven't found them yet with my random testing).

@kocio-pl
Copy link
Collaborator

Military danger area on the water example (click to see the full image):

z10
Before
cpy9fvjs
After
v7y_q3sg

z11
Before
aez5ysl

After
kkj6e 6

@kocio-pl
Copy link
Collaborator

kocio-pl commented Feb 12, 2018

Land example of military danger area with some plain military areas around:

z14
Before
w dzm1p3

After
qkakrhtj

My suggestion: this is an improvement also in danger areas (especially on the water, but lack of a pink background helps to notice the forest area too), so I'd like to have it merged, but I think I would keep the bright red font color for all such areas, because the difference between plain military area is not that visible now.

@andrzej-r
Copy link
Contributor Author

Just in case you haven't noticed: in the last example all labels come from regular military areas, so no difference is expected there. Military danger area labels (first example) are bold and not slanted.

I did change the text colour to match the new background pattern. And since we reused the military area pattern that also meant using the military area text colour. I think the difference in the text rendering is very noticeable but if you prefer the old colour that's fine too.

@kocio-pl
Copy link
Collaborator

Yes, I have noticed, but haven't investigate it. I prefer the old font color for danger areas, but slanted (as we do with most, if not all the areas without icon).

@andrzej-r
Copy link
Contributor Author

Can you share a snipped of code for the design you like? Frankly speaking, this is not a part I care about, so I'm OK with pretty much any sensible design.

BTW, I've only changed the colour, the font face, sizes, filtering etc are are all original.

@kocio-pl
Copy link
Collaborator

kocio-pl commented Feb 13, 2018

OK, I made the change and it's available in my branch. Looks like nobody noticed the rule that area labels should be slanted.

This color works only without landuse=military:
iqdw2do_

otherwise it's rendered just like any other military area:
qkakrhtj

but that's enough for now - tagging problems might need separate discussion.

@andrzej-r
Copy link
Contributor Author

Looks suitable for a danger area. BTW, If we were to change the starting level to z8, we could combine it with other landcover areas.

@kocio-pl
Copy link
Collaborator

I feel that it's not worth trying to put more things into this PR, let's finish it now and we may discuss next things in separate issues/PRs.

@andrzej-r
Copy link
Contributor Author

Agreed

@kocio-pl
Copy link
Collaborator

Let me ask you - If I understand the plan, you want to add this patch? I would merge this PR right after that.

@andrzej-r
Copy link
Contributor Author

I am OK with merging this PR in its current state. The last suggestion brings very little value IMHO (minor refactoring) so let's not bother with it.

@kocio-pl kocio-pl merged commit c229b5f into gravitystorm:master Feb 15, 2018
@kocio-pl
Copy link
Collaborator

Thanks for both the code and constructive discussion! I hope some more tuning will follow it.

@matthijsmelissen
Copy link
Collaborator

matthijsmelissen commented Feb 15, 2018

Thanks a lot both!

@andrzej-r
Copy link
Contributor Author

Nice. Thank you for support and testing.

I think rendering is fine now but it may be worth adjusting filtering options someday depending on the prevailing feedback (feature not prominent enough / too prominent).

@andrzej-r andrzej-r deleted the military_area3 branch February 15, 2018 21:49
@kocio-pl
Copy link
Collaborator

BTW - did you understand this hint: #3045 (comment)? I don't, it's too specific for me, but I wonder if we could use it and what would it look like?

@andrzej-r
Copy link
Contributor Author

Not sure, I think that could have been about making the whole layer ("landuse_overlay") transparent while keeping objects in it 100% opaque. That way, if there are multiple overlapping military areas they would be rendered like a single area. At the moment, opacity of 2 overlapping military areas is higher than that of a single one.

I don't necessarily mind the current implementation, I'd even consider it a feature (you can see it in action in #3045 (comment), second screenshot). But I don't know if I understand this issue correctly of if @gravitystorm meant something else.

@gravitystorm
Copy link
Owner

@andrzej-r Your description is exactly what I meant - that way, if there are two (or more) overlapping areas they would be rendered like a single area.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants