Color handling

[pantierra]

Transit lines in GTFS have a route_color and a route_text_color, whereas the text color "should provide sufficient contrast when viewed on a black and white screen".

osm2gtfs tries to get this information from OpenStreetMap's colour tag. This can be information in RB hex code or a W3C color name.

In a first step, in #99, it is introduced to map the information from colour to the Line object to be used in the creators. The standard creator assume RGB hex colors, as also desired by GTFS. However for Estelí two good and additional functionalities are used, that could be considered to be moved also into the core of osm2gtfs:

• Transform W3C color code into RGB hex code.
• Calculate a suitable route_text_color based on route_color.

[pantierra]

In the current Estelí implementation the two things are addressed the following:

• Transform W3C color code into RGB hex code: The python extension webcolors is used to provide the functionality. A proper test of there is a valid name of a valid RGB hex code or a non-valid string would need to be included, I guess, in order to make it attractive to the core.
• Calculate a suitable route_text_color based on route_color: Currently it uses this code snippet which calculates the complementary or opposite color in the color spectrum. As far as I understand, this doesn't seem to fit the requirement GTFS is putting on this, to have a good contrast. I think we need more a function that checks the "brightness" of the given route_color and returns either #000000 (black) or #ffffff (white).

[pantierra]

I think those screenshots show pretty nicely why a white-black decision (right side) should be taken to generate the route_text_color rather than the complementary color (left side):

[ialokim]

I think those screenshots show pretty nicely why a white-black decision (right side) should be taken to generate the route_text_color rather than the complementary color (left side)

You're completely right 👍 Looks like ugly the left side 🤢😅

I think we need more a function that checks the "brightness" of the given route_color and returns either #000000 (black) or #ffffff (white).

I think I found a good approach, see this blog post.

[pantierra]

This looks convincing. Let's try it.

[nlehuby]

transitfeed lib already have some useful functions we should investigate:
https://github.com/google/transitfeed/blob/23e953749e4024130db102d30b2088e9bfae0e3b/transitfeed/route.py#L220

[ialokim]

transitfeed lib already have some useful functions we should investigate

I've checked it and they use the W3C formula to calculate the perceived brightness, but as stated on the blog post I've already posted above:

it tends to give wrong results for many colors, especially shades of yellow.

[pantierra]

Implemented the suggestion by @ialokim in the RoutesCreatorEsteli, see function _define_route_text_color. Seem to work very well for Estelí.

[pantierra]

I'm pretty happy with the current implementation, now. And I would suggest to move them to core but to two different places:

• name to hex: into the osm_connector so to normalize the data from OSM, where it can be either a web color name or the RGB hex value, to be consistent in our classes as hex value.
• move the function to get a corresponding color with high visible contrast into the Helper class and call it from the standard routes_creator, not before.

[ialokim]

I'm pretty happy with the current implementation, now. And I would suggest to move them to core

🎉

but to two different places

Why not having them both inside the Helper class to group colour functions together?

[pantierra]

Why not having them both inside the Helper class to group colour functions together?

Because there is only one function, for the other purpose we use the python extension webcolors (Probably it is easier to see it in code than talkng abstractly about it).

A proper test of there is a valid name of a valid RGB hex code or a non-valid string would need to be included

Is included now (see changes in the osm_connector)

[pantierra]

Created a PR for this: #114

[pantierra]

Done.