Made some line-colors dependent on their polygon-fill

[floscher]

I worked on resolving issue #57.

Objects with the following tags have now a border-color, that depends on the polygons fill-color:

• leisure
  • swimming_pool
  • playground
  • track
  • pitch
• tourism
  • camp_site
  • caravan_site
  • picnic_site
• landuse
  • field
  • retail
• natural
  • field
• power
  • station
  • generator
  • sub_station
  • substation
• amenity
  • parking
  • place_of_worship
• aeroway
  • aerodrome
  • terminal
• building=*
• railway
  • station

The dependency of both colors was expressed by adding:

line-color: saturate(darken(@color, x%), y%)

with 40 <= x <= 60
and 0 <= y <= 30

In my opinion this improves both the appearance and maintainability, because there is one variable per selector to define the colors of polygon-fill and line-color.

What do you think: Is this approach desirable for this mapstyle, or should the line-color rather be left hardcoded?

[dieterdreist]

Am 24/mag/2014 um 21:18 schrieb Florian Schäfer [email protected]:

What do you think: Is this approach desirable for this mapstyle, or should the line-color rather be left hardcoded?

I think it is generally a good idea to have a default like this to calculate the outline color for filled areas. In special cases this could still be overwritten with a hard coded outline color

[daganzdaanda]

Sounds great to me!

[floscher]

Good to hear that you support this change.
I've now continued to work on these changes by updating buildings.mss.

One point I wanted to note is: There are some borders which would change colors with this PR (mostly from some sort of grey to a more saturated color). But I tried to reach a compromise between leaving the colors as they are and unifying the relation between polygon-fill and line-color.

@dieterdreist wrote:
In special cases this could still be overwritten with a hard coded outline color

Sure, one example is amenity=university/school, which I excluded from 611f4fe, because the current line-color (brown) is too different from the polygon-fill (#f0f0d8).

[matthijsmelissen]

i tested this and looked at the code. I recommend this to be merged.

[pnorman]

👍 in principle to this idea, haven't reviewed the code. I was going this direction in the buildings code, as it makes it a lot easier than copying hex values to/from gimp/photoshop as I adjust everything, and it makes it clear what is happening than the different hex values.

[pnorman]

line-color: saturate(darken(@color, x%), y%)

It is worth noting that transformations like this should generally be carried out in Lab or Luv/Lch colour-space, not HSL, which is what darken works in.

Computer science offers a few poorer cousins to these perceptual spaces that may also turn up in your software interface, such as HSV and HLS. They are easy mathematical transformations of RGB, and they seem to be perceptual systems because they make use of the hue-lightness/value-saturation terminology. But take a close look; don’t be fooled. Perceptual color dimensions are poorly scaled by the color specifications that are provided in these and some other systems. For example, saturation and lightness are confounded, so a saturation scale may also contain a wide range of lightnesses (for example, it may progress from white to green which is a combination of both lightness and saturation). Likewise, hue and lightness are confounded so, for example, a saturated yellow and saturated blue may be designated as the same ‘lightness’ but have wide differences in perceived lightness. These flaws make the systems difficult to use to control the look of a color scheme in a systematic manner. If much tweaking is required to achieve the desired effect, the system offers little benefit over grappling with raw specifications in RGB or CMY.

Wikipedia has more background and links to papers.

I'm still not opposed to this, but we do need to be aware that it's not actually making it any easier for someone else to change the colours properly. In my work to make landuse more consistent so #565 becomes easier, I'm ending up copying/pasting from a colour picker that works in Lch, because that's the easiest way to get the two colours to match in apparent lightness but differ in hue/chroma.

On the other hand, it makes a quick change where you aren't as concerned about the particulars much easier.

[floscher]

line-color: saturate(darken(@color, x%), y%)

It is worth noting that transformations like this should generally be carried out in Lab or Luv/Lch colour-space, not HSL, which is what darken works in.

Thanks for this hint, I wasn't aware of that before.

Using Lab/Luv/Lch would surely be the best solution in terms of the appearance of the result, but as you said it has to be done manually in an external program and copied back as for instance a hex-value. If you do that, maybe it would be a good idea to share instructions on how this color was determined, e.g. @buildingBorder: #123456; // decreased lightness of @building by 10% in Lch-colorspace, so subsequent editors know about the dependencies.

But I think for now darken and saturate are sufficient. They will produce an acceptable result in most cases and document the dependencies between colors in the code. Additionally by looking at the code it seems to me that in the past very few people (if any) used a "better" color space than HSL to select border-colors. Mostly some sort of grey (e.g. #555, #666 or #888) was chosen or even named colors (blue for swimming pools, red for landuse=retail, brown for universities and schools) were used.

In conclusion, I really like your idea of using better color spaces than HSL, as it would produce the best results. But for the moment I think it is a step in the right direction to use the color operation functions.

[pnorman]

Additionally by looking at the code it seems to me that in the past very few people (if any) used a "better" color space than HSL to select border-colors.

Yes - it is very clear. I should note that my comment above was made in the middle of 2-3 hours of adjusting colours in Lch/Luv colour space, converting them to/from RGB (in decimal and hex) and computing perceptual differences between colours to make sure there was sufficient difference.

In conclusion, I really like your idea of using better color spaces than HSL, as it would produce the best results.

What I'm wondering is, having done the above, should I compute the saturate(darken(@color, x%), y%) that produces the result I want, or just indicate the Lch value in a comment?

[matthijsmelissen]

@pnorman @floscher This change conflicts with one of the merged changes, so it needs to be rebased. Is either of you planning to take care of this?

[gravitystorm]

@math1985 I'm working on it just now :-)

[gravitystorm]

I've kept @pnorman's changes to the retail landuse, but merged the rest of the changes in this request.