Alignment with OMF's Curb Data Specification

[jlarsonOmahaNE]

OMF recently released the 1.0.0-rc Curb Data Spec. Cities would be interested in identifying the overlap of a work zones and curb zones for better management in a local aspect.

Local municipalities would like to identify when a work zone would interfere with vehicles being able to access a curb zone. This would help with vehicle congestion and safety in local downtowns/BIDs where delivery vehicles park in a travel lane when a work zone is present instead of going to the nearest open curb zone. It would be up to the data producer/consumer to update the necessary fields in their feeds depending on the overlap.

I think a best path would be to expand on the Lane Types to account for curbs.

A producer/consumer could identify the work zone and then update the Curb Space availability based on the work zone start_date and end_date or other fields.

[natedeshmukhtowery]

This makes sense to me. In the current v4.0 of WZDx, the lane types that I think might overlap with curbs include sidewalk, parking, bike-lane, and general. What would be a logical addition for lane type - loading? Would something like "bus-stop" also be a relevant addition?

[jlarsonOmahaNE]

I think that some key LaneType additions would be the loading and bus-lane as mentioned along with a street-car.

[jlarsonOmahaNE]

@natedeshmukhtowery To simplify this in the lane types, would it make sense to change parking to curb : A lane used for curbside loading/unloading or time delineated parking. Or would you want to keep all lane types separate?

[natedeshmukhtowery]

@jlarsonOmahaNE to me it makes sense to use the more generic "curb" you describe rather than the "parking" enumeration we use now for the curbside lane when appropriate.

Thoughts from others?