Add Zone Color to Zones in the Curbs API

[rneubauer]

We have been working with another CDS Partner and exchanging Curbs and Events in CDS. In our first sync of the curbs API, we noticed that zone color is not included in the Curbs API. This makes it very hard to differentiate between the various zones. Upon talking with the city, they have also asked to add ability to have a dashed border on the zone.

Proposed Solution:

We propose to add an additional element:

Name Type Required/Optional Description curb_zone_color HEX Required The color of this Curb Zone. curb_zone_dashed Boolean Optional The zone border is dashed

I am proposing to use HEX Color values, but completely open to other ideas.

Is this a breaking change? - No, not breaking

Impacted Spec - Curbs API

[rneubauer]

This needs some more vetting. This sample includes types and user classes which makes things a bit more complicated...

We will work on some ideas and post them here soon.

[schnuerle]

I think if a new field is added, like curb_color, then it should be in CMYK color - that's what's used in the real world (vs RGB for screens or Hex for web), has a wider color gamut, and is what MUTCD uses for color. Different color spaces have different gamuts, as seen here. It might depend if the colors are to be used for online maps only, or also connecting to real painted street curb colors.

Give your ideas on this soon so it could make it into the CDS 1.1 release.

[mplsmitch]

I think we're mixing multiple ideas here. One being the colors displayed on a web map or other interface, and the other being the colors of physical curbs out in the world. Any new fields need to be defined in a way that makes it clear where these colors are used.

There are lots of examples of how curb paint colors are used ( 1, 2, 3), none of them align with what's in this proposal.

As I understand it @rneubauer wants to designate colors used to indicate and display different regulations in an online platform. For this, CMYK makes no sense because it's not HTML supported. Web colors are typically expressed in HEX. I don't see why the specification would dictate these. It seems like a question of user interface design that should be left to the software vendor.

MUTCD uses spot color but it's intended for sign printing only, not curb paint. When is comes to curb paint, they recommend you mix your own

Guidance. For disabled parking, depending upon the number of linear feet of curb requiring blue paint, 1 or 2 gallons of our standard white traffic paint should be taken to a local paint store to have blue paint pigment added.

I can see a need for curb_color field for documenting the color (red, yellow, white etc.) of a physical curb but there are regional and international differences in how curb colors are used so I think it would be a mistake to define them in terms of specific regulations.

[schnuerle]

We will be talking about this at tomorrow's Curb Working Group meeting. We will determine if we just need a generic, text description for a color, or something more specific is needed. And are we using this color for engineers who are painting the curb, or just a more simple approximation of color for things like web maps.

[schnuerle]

This Seattle web map has various colors, dash types colored borders, etc, all in an ESRI product.

[rneubauer]

I'm still working on a standard for the pattern, but I definitely think it is a field we include. I do have a few other things that I also would like to introduce as part of this that support customizations that cities have as well with their zone abbreviation convention that coincides with the color selection.

The idea here is to allow cities to define the colors and abbreviations they use as part their CDs definition. Below is how we are using it in our environment with existing cities:

[schnuerle]

From our Curb Working Group meeting today:

• Create a PR to add an array of policy_color key value string pairs that contain needed color info, possibly based on ESRI options:
  • primary_color (hex value), required
  • pattern_type (solid, long_dash, short_dash, dot, etc),
  • secondary_color (hex value),
  • primary_border_color (hex value),
  • secondary_border_color (hex value),
  • zone_type_acronym (is this in color or another field in the object outside of color in Policy?)
• Does this array go in Curbs or in Policy (Policy is what was discussed)
• Description will say that the colors reflect the physical paint color at the curb zone. Displaying visually on a map or other location may or may not align with the physical colors, per the needs of the agency.

[schnuerle]

Drafted a solution with PR #195.

[schnuerle]

We will be reviewing this at tomorrow's public Curb Working Group meeting. However we won't have much time to discuss, so leave your comments and suggestions here as general or inline comments to spark changes before the CDS 1.1 release is made.

[bhamlinSDOT]

I'm supportive of this change. SDOT ran into challenges trying to communicate standard mapping symbology between tech vendors using CDS during our Stage 1 SMART grant project. A goal of our project was to show other SDOT staff the benefits of using CDS and more modern web mapping tools but we noticed it was a difficult for some staff to quickly pick up a vendors unique mapping schema when SDOT staff were used to seeing curb space web maps look a particular way for many years. This change would allow for easier symbology changes in the future.

[schnuerle]

Closed with #195