Curb Zone relationship to Curb Area(s)

[zanebclark]

According to the Curb Area definition:

Curb Areas MAY overlap with other Curb Areas

This suggests a one-to-many relationship between a Curb Zone and Curb Areas

On the Curb Zone spec, the curb_area_id field only makes room for a one-to-one relationship between a Curb Zone and a Curb Area.

We either need to:

1. Clarify how two Curb Areas could overlap but a Curb Zone contained within both areas could only belong to one of them or
2. Change curb_area_id to curb_area_ids and make the type an array of UUIDs

[zanebclark]

@lummish + @schnuerle

[BigIdeas]

Good catch - seems like we should go with option 2.

[schnuerle]

I think the original intention was that there would really be only one Area surrounding a Zone. Though Areas can overlap other Areas. So that's option 1. But I can see that there could be more than one Area that overlaps a Zone and if so then an array would work, so that's option 2.

Might need to do some diagraming to see how this could play out on a curb/street/neighborhood. I'm actually inclined to keep it as option 1 since it is simpler unless there is a use case for option 2.

[zanebclark]

In this example:

I think it would be very hard to communicate that Zone 3 belongs to Area A and not Area B and C. If we instead supported a one-to-many relationship between zone and area, the relationships become intuitive. Cities can now define any number of overlapping groupings for reporting. In this example, we could analyze Area A (1, 2, 3), Area B (2,3), or Area C (1, 3).

[schnuerle]

More to back up your example, here is a scenario I thought of where you might want overlapping areas around 2 separate zones. Along Main Street, the blue zone with the purple area may overlap with the orange zone with the yellow area -- you may want to know what's happening along Main St for both zones.

Of course you could use one single larger area to capture activity around both zones, like so:

The original intention was to be thoughtful about how you design your zones and areas to make sure they was not more than one area around a zone. But there might be a reason to allow the one to many relationship instead.

[zanebclark]

The original intention was to be thoughtful about how you design your zones and areas to make sure they was not more than one area around a zone.

You're far more familiar than I am with the landscape with here, but there may be many cases where the luxury of defining zones this way isn't afforded. The neighborhoods, council districts, traffic corridors, etc. could already be defined in ways that intersect .

[schnuerle]

I think now that we have identified some scenarios, we are in agreement here. I made curb_area_ids an array of UUIDs and added "Multiple Curb Areas MAY include the same Curb Zones" in the Curb Area definition.

https://github.com/openmobilityfoundation/curb-data-specification/blob/release-1.0.0/curbs/README.md#curb-zone