Change allotments color and add outline

[jeisenbe]

Fixes #3411

Changes proposed in this pull request:

• Change allotments color to #c9e1bf
• Revert allotments pattern to small light dots
• Add outline for allotments

Explanation:

• The new allotments color is the same as grass and gardens, which was not ideal. @imagico recently showed an example of a color that would work with the other shades of green: #c9e1bf
• The new color is close to scrub but not too close to any of the areas of vegetation, and it is more similar to areas of developed land like landuse=residential.
• The pattern is changed because with this new color it is difficult to see the geometry of buildings on areas of allotments, especially at z14 and z15. By changing back to the previous pattern of light dots, it is easier to see buildings, tracks and paths. The new color is sufficiently distinct that the pattern no longer needs to be so strong.
• A border is added to show the limits of allotments, particularly where two named allotments are adjacent. line-offset is used so that the borders between allotments will be more visible, and the border is less likely to be covered by other features along the edge.

Test renderings with links to the example places:

Before - #cdebb0 with squares
z13 Harburg https://www.openstreetmap.org/#map=13/53.4628/9.9847

Bremen, Germany: https://www.openstreetmap.org/#map=16/53.1070/8.8134
z14

z15

z16

z17

After #c9e1bf with dots
z13 Harburg #c9e1bf
https://www.openstreetmap.org/#map=13/53.4628/9.9847

z14 Tatenburg #c9e1bf
https://www.openstreetmap.org/#map=14/53.4933/10.0788

z17 Bremen
https://www.openstreetmap.org/#map=16/53.1070/8.8134
[EDITED: fixed outline offset]

z16

z15

z14

[Adamant36]

Kind of off topic, but it would be good to change the color of gardens to this color sometime in the future also. As it is, I massively dislike how you can't tell the difference between a grassy area and garden outside of the pattern when they are next to each other. People wouldn't confuse a garden for an allotment if the colors where the same either. Since they have different patterns. So I think its worth doing.

[kocio-pl]

I was researching the garden problem after failure to render it like park, which was my first idea, and found that it's better to keep it low. Looking at usage, garden can be almost anything, ranging from lawn on the backyard to the botanical garden or private palace park. There are different garden types defined, but I'm not sure if this would be good to render them in a different way.

This color and pattern is OK for me, even if it's quite dark and we loose more meaningful pattern - it's distinguishable from the other greens on z13, does not clutter the space when there are a lot of buildings and named ways.

[polarbearing]

        line-width: .5;
        line-offset: -0.5;

IIRC, shouldn't the line offset be half of the line width?

[jeisenbe]

shouldn't the line offset be half of the line width?

Yes, you are right! Thank you for catching that. I've pushed a new commit.

The lines between allotments look much better now:

[kocio-pl]

Looking briefly at the code - why there are no SVG version nor documentation? How did you create this pattern? And why change the name of the file?

[imagico]

A few observations from me as well:

• the outline with offset is so far unique among simple thin outlines for landcover areas (see farmyard, farmland and urban landcovers for example). It is not clear to me why you depart from established standards here.
• the inner outlines on touching areas look prone to be mistaken for distinct mapped geometries.

[jeisenbe]

the outline with offset is so far unique among simple thin outlines for landcover areas (see farmyard, farmland and urban landcovers for example)

This was discussed in #3045 and again in #3392, where @polarbearing suggested "we fixed a similar issue when changing the military colour and outline. In military we shift the line 50% of its width inwards" - this is where I got the idea.

If it works for allotments I would like to extend it to farmland, farmyards, residential and so on.

The idea is that the outline should only be on the area of the landuse. Without the offset, half of the outline spills over into the adjacent pixels. Then when there are two mapped areas, half or all of the outline is blocked by the adjacent area, depending on way_pixels since this is used to determine the order that area fills are rendered.

By offsetting the outline into the polygon, it should render consistently. Also, the line width is doubled when there are two adjacent landuse=allotments areas, which makes it easier to see where one named allotment area ends and another begins, without resorting to a wider or darker line.

the inner outlines on touching areas look prone to be mistaken for distinct mapped geometries.

I'm not sure if I understand this. Do you mean it could look like they are mapped with a small gap in between rather than reusing the same nodes along the border?

The examples at top were wrong, because I mistakenly set the offset the same as the line width instead of 1/2. But this new example is correct: #3625 (comment)

[jeisenbe]

why there are no SVG version nor documentation?

This is a revert to the previous state before the last allotments PR. I just reused the old .png file, which was probably made by hand. It is just 1 dot on a 8 by 8 pixel canvas, which repeats regularly.

And why change the name of the file?

I did that while testing so that I could switch between branches. If the .png files have the same name, then Kosmtik doesn’t realize they have changed. But I’ve changed the name back now, and pushed the change.

…

[imagico]

I know what line-offset does but your arguments do not convince me considering the confusion this will cause for the map user who does not expect this. And i can't really recommend testing this in the live map. Maybe the starting point would be explaining why you want to use an outline in the first place. If allotments so far were drawn without outline why now?

I'm not sure if I understand this. Do you mean it could look like they are mapped with a small gap in between rather than reusing the same nodes along the border?

I mean the map reader seeing such a line will likely assume it being some 1d geometry or a narrow strip of forest along this line. In contrast to the standard landcover and building outline design due to the offset and the resulting stronger line weight at inner edges it is not intuitively understandable as an outline.

[jeisenbe]

@kocio-pl was interested in adding an outline. I believe the main reason is to show where one named area of allotments ends, and another begins. This is similar to the reason why we render outlines for farmland and residential.

the map reader seeing such a line will likely assume it being some 1d geometry or a narrow strip of forest along this line.

That's a good point. The other outlines are not similar to barriers, except for the residential area outline, but this new allotments color is gray-green so it could be confused with a fence or hedge.

I did some further test renderings next to hedges, tree lines, power lines, fences and walls. The closest linear features are hedges and power lines. The hedges are 2.5 pixels wide, but the color is rather similar to the outline color that I was using above. The power lines are thin and gray, but this limits the option to desaturate the allotments outline. However, adding some desaturation helps to make the outline color less similar to hedges while still being far enough from fences and power lines.

I also found out that the offset is not working as I expected. Rather than two 0.5 pixel lines combining into a single 1.0 pixel line, we actually get a gap in the middle. This is visible when exporting at 4x resolution, and at standard resolution it causes the line to be lighter than expected and somewhat fuzzy. Reducing the offset to 0.2 is not enough to fix the problem. This can also be seen in the current zoo and amusement park outline, when two are adjacent. I believe this is a Mapnik bug?

Adjacent zoos (the two closed ways share the same nodes):

This outline is 0.7 pixels wide, darkened 15%, with no offset.

This is 0.5 pixels wide, offset 0.25 pixels, darkened 15%, so one would expect it to be wider and darker than the above, yet it is much lighter.

At 4x resolution, it's clear that there is a gap between the two outlines which is causing this problem:

So instead I've tried desaturating the line and using 0.5 to 0.7 pixel width (depending on the presence of a name) without any offset, as used for farmland, farmyard, residential etc:

New option 1: 10/10
Desaturate 10, Darken 10, width 0.7 (named):

• power lines, hedges, tree rows, fences and walls are shown along some of the borders

Option 2: 15/15
Desaturate 15, Darken 15, width 0.7 (named):

[kocio-pl]

@kocio-pl was interested in adding an outline. I believe the main reason is to show where one named area of allotments ends, and another begins. This is similar to the reason why we render outlines for farmland and residential.

Yep. They can be fenced (usually, but that's not required) and this is discrete, human-created object, so the outline makes sense.

[imagico]

Rendering a line implying a barrier when no barrier is mapped would go against everything this style tries to do. This is why in the past we have weakened outlines on multiple occasions - specifically to avoid them being interpreted as barriers (or paths/tracks).

And note a map user does not necessarily know hedges and similar things are rendered with a wider line.

For allotments you will also need to keep in mind that mapping of subdivisions (plots) within an allotments site is currently under discussion and splitting the allotments mapping itself is AFAIK not a method that is considered by mappers for this purpose. That is different for farmland where many consider mapping individual fields with individual polygons to be the best approach for high quality mapping. So some looking ahead for showing things like that in the future and not giving mappers counterproductive incentives might not be a bad idea. As said we have so far not shown outlines so the question what has changed still stands in the room.

I think your weakest new example would be reasonable if you want to go with an outline but so far for me this is still not quite convincing.

As far as the relative weight of lines with different widths and offsets is concerned - you have to understand how mapnik/AGG renders things. The basics are explained on http://www.imagico.de/map/polygon_rendering.php

[polarbearing]

confusion this will cause for the map user who does not expect this

Adjacent polygons of the same kind very often carry the names, thus the user indeed expects to see where the boundary is between them. They serve also as feedback for the mapper who splits anonymous larger landuse in smaller units.

This goes for residential, allotments, commercial etc, schools, kindergartens...

[polarbearing]

Rather than two 0.5 pixel lines combining into a single 1.0 pixel line, we actually get a gap in the middle.

I would not call it a gap at normal resolution. It appears to me an anti-aliasing effort of mapnik. Is it really bothering? It might help when adjacent landuses are different.

An alternative would be to define a single, neutral colour for non-barrier landfill boundaries, that would be used independent of the landfill colour. Thus we could leave them on the edge without offset, as they would be identical for the different landuses and not cause merging effects.

[kocio-pl]

I've found the example where the outline is missing to show the shape of both adjacent allotments:

https://www.openstreetmap.org/#map=17/52.55110/13.48115

[polarbearing]

Welcome to Berlin. That's just two associations operating. Have a look here, you have plenty, and the user would not have a clue why the names are of different size, until she sees the size of the polygons ;-)

https://www.openstreetmap.org/?mlat=52.4781&mlon=13.4681#map=16/52.4781/13.4681

[jeisenbe]

mapping of subdivisions (plots) within an allotments site is currently under discussion

I had planned to do a PR for allotments=plot, until I realized that the database import does not currently recognize "allotments" as a polygon.

My thought was that we should add the outline to landuse=allotments first, and then use the same color (but a tiny bit thinner?) for allotments=plot outlines, to close issue #432 (rendering the ref numbers for allotments).

But it sounds like you are concerned that mappers might start drawing each plot as landuse=allotments to get the outline to render. That seems unlikely, but certainly my intention is that we should render the plot outlines and ref numbers as soon as feasible.

your weakest new example would be reasonable

I also think that is the best option (darken 10%, desaturate 10%), so I've pushed a new commit.

[jeisenbe]

Examples with latest commit. The outline is 0.5 pixels with name=null, and 0.7 pixels with a name (same as farmyard, farmland, residential etc), and the color is allotments darkened 10% and desaturated 10%:

z16, unnamed allotments in Bremenhaven:

z16, unnamed:

z17, named allotments in Bremen (the names are visible at z18):

z17, fence visible on the left for comparison (border is horizontal, in the middle. Part parallels a ditch)
I have no idea what those dotted lines are? Something about addresses?

z16, hedges visible on the right, power=line visible on upper right
allotments borders visible in the middle, and upper left

Test area with lots of barrier types (wall, hedge, fence, tree_row, and hedge drawn as an area)

[imagico]

But it sounds like you are concerned that mappers might start drawing each plot as landuse=allotments to get the outline to render. That seems unlikely, but certainly my intention is that we should render the plot outlines and ref numbers as soon as feasible.

It is good to be aware of what future needs and design options for those might be but i would generally advise against making firm assumptions on the future and making changes with the assumption they will only be provisional but operate under the assumption that your change is how it is going to be rendered for the foreseeable future.

We have discussed the different points of consideration - from my side it is your choice.

Regarding the change otherwise i would like to see someone else do the overall review - given that i had chosen this color and a very similar pattern in a different color environment i don't really feel like i can provide a solid opinion on how it fits here.

[kocio-pl]

I have no idea what those dotted lines are? Something about addresses?

Most probably it's the address range.

[kocio-pl]

Regarding the change otherwise i would like to see someone else do the overall review

It depends on what you expect. I'm happy with this solution, but if you have someone particular on your mind, just ask him directly or use "request for review" button.

[imagico]

Probably need to explain a bit better. I obviously have no issues with this design idea for allotments in isolation but i like it less in the context of the colors here than in the ac-style. And i do not feel like i am the right person to decide if this is purely a problem of the other colors or if the design of allotments can be improved to better fit into the color design here.

This is why i think someone else should make this assessment - have another set of eyes consider this. I have no preferences as to who, if you feel like doing this go ahead. Obviously if we change the design of allotments a second time within a short period of time it is important to get it right and find a solution that is satisfying for everyone.

[polarbearing]

Good to see the outline now.
I'm still not convinced that we have to give up the square pattern recently introduced.

[kocio-pl]

@imagico Thanks, that's clear answer for me.

@jeisenbe I would get back to the SVG pattern as an intermediate file. It's not a blocker for me, but sooner or later I hope Mapnik will be fixed (#2750) and we will be able to use vector patterns instead of the raster ones (#2045), so it's good to have it done by then. It's needed for hi-res rendering consistency:

https://osm.rrze.fau.de/testhd.html layers (with old allotments color and pattern - compare with the forest)

Normal scale

Hi-res rescaled

@polarbearing I agree with explanation ("By changing back to the previous pattern of light dots, it is easier to see buildings, tracks and paths."), especially when we have the outlines and it's ready for future real plots rendering, which current pattern tries to symbolize:

[imagico]

@polarbearing - another comment on the pattern. So far i have not seen any specific idea for the 25% square pattern that seemed to work well in my eyes but that does not mean it is not possible to make this work. When you have a fine grained pattern - no matter if regular or irregular, and this square pattern borders to that, map readers do not perceive this as a pattern of two distinct colors but as a single color plus a structure element. Both perception of the color and the structure element are influenced if you change the colors used. Being only borderline fine-grained, depending on the specific viewing situation, makes this particularly difficult.

@kocio-pl / @jeisenbe - the ac-style contains an SVG version of the allotments pattern:

https://github.com/imagico/osm-carto-alternative-colors/blob/master/symbols/patterns/allotments.svg

but keep in mind #2727/#2750 - SVG patterns can currently not be used with reliable results.

[polarbearing]

Thanks for the additional explanations and tests, you're probably right.

[kocio-pl]

Real life example how changing the color with pattern and adding outlines improves rendering:

https://www.openstreetmap.org/#map=16/52.2919/21.0868

Before

After

[jeisenbe]

Can we use the .svg file in this case, because it is a regularly repeating pattern which just uses one symbol? The quarry pattern and the graveyard/cemetery patterns use svgs, currently.

I've tested with the allotments.svg from @imagico's fork, and it seems to work as expected at different zoom levels and resolutions:

Regular resolution

4x resolution (export from kosmtik)

[imagico]

All SVG rendering with partial pixel coverage is broken - either consistently too dark (quarry, graveyard, case 3 in #2727 (comment)) or inconsistently (when in landcover-area-symbols, i.e. forest).

[kocio-pl]

I have not spotted such problem myself ever (of course maybe it was here, but not noticeable for me), so it does not have high priority and I did not have enough motivation to revert all the patterns to raster, but I don't like to introduce new vector patterns for rendering until the problem is fixed. I just like to have SVG as intermediate format to be used in the future.

[jeisenbe]

Ok. I’ve added the svg file but the png is still used for the pattern.

…

On Fri, Jan 11, 2019 at 5:00 AM kocio-pl ***@***.***> wrote: I have not spotted such problem myself ever (of course maybe it was here, but not noticeable for me), so it does not have high priority and I did not have enough motivation to revert all the patterns to raster, but I don't like to introduce new vector patterns for rendering until the problem is fixed. I just like to have SVG as intermediate format to be used in the future. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3625 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AoxshLL1PC0pfE98mG7fL_z6YXQz3u72ks5vB5vKgaJpZM4Z0wj7> .

[kocio-pl]

I guess it's better to move it into symbols/generating_patterns directory and add simple documentation (generating_patterns/allotments.md) clarifying where does it come from and how it's supposed to be used.

The best would be to create the pattern from the pattern generator and really transform it into raster file with full documentation, but that is not a blocker for me.

[jeisenbe]

I've moved allotments.svg to the generating_patterns folder.

[kocio-pl]

Please add also short documentation explaining current state of this file. Even plain scripts have same basic information so we don't have to recall what is it doing here.

[jeisenbe]

OK, I’ve added allotments.md

…

On Fri, Jan 11, 2019 at 7:39 PM kocio-pl ***@***.***> wrote: Please add also short documentation explaining current state of this file. Even plain scripts have same basic information so we don't have to recall what is it doing here. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3625 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AoxshD6Mv_XkjbJgnjdw8x_NMIGHRnGZks5vCGnxgaJpZM4Z0wj7> .

[kocio-pl]

Thanks, guys! Next interesting thing here is rendering individual plots, but it should be easier now.