Regulations external to or within curb Zones

[schnuerle]

Should regulations details be separated from curb Zones and referenced by a regulation ID (allows defining a regulation and applying that to multiple Zones), or should they just be embedded in the Zone object (reduces complexity and improves readability, but could have more repetitive data with larger file sizes).

Example could be a city that has 30 blocks of Zones that all have the same regulations: it would be easier to specify the regulations once and apply that regulation ID to each zone, making updates easier too. But is this an edge case and worth splitting this out?

[schnuerle]

Comments from the document:

Tomas Carranza

LADOT Comment: Curb zones are defined as GeoJSON polygons with “regulations” and other metadata embedded into the GeoJSON properties object, including optional LinearReferencing attributes. Keeping curb zones and regulations separated into different objects and endpoints would be better for many reasons - one being the very different life cycles of those objects (i.e., curb zones change rarely, regulations change frequently).

Jascha Franklin-Hodge

At scale, separating regulations and areas (and referring to regulations by ID in a CurbZone) offers a much cleaner data model. For example, the regulation for a taxi zone may be the same citywide, but embedding the regulation in the CurbZone object requires repeating the same regulation definition over and over again.

Jacob Baskin

oh that's a very different approach! Where would the time-based config live (i.e., is a regulation ID "this is a taxi zone 9am-5pm and parking otherwise", or is a regulation ID "this is a taxi zone" and then the area is a map from time periods to regulation IDs?

I would rather have things go the other way, and have a regulations API that refers to areas by ID...

Michael Schnuerle

I was thinking regulations API could reference curb API by (one or more) curb IDs, and curb API could reference regulations API by (one or more) regulations IDs.

Jacob Baskin

We should have the references go one way but not both

Jascha Franklin-Hodge

Agree that we shouldn't do it both ways. In the MDS Policy API, a rule can reference one or more geographies where it is applicable (essentially the direction you're suggesting, @jacob@coord.co). Would probably argue for consistency in design with Policy, though I'm open to the idea that it's totally overkill for curb zones and we should just implement as originally suggested for now.

Jacob Baskin

OK that sounds like a plan.

Jacob Baskin

One wrinkle: if people want to query by location x regulation ("show me all the loading zones in the given bounding box") separating areas from regulations could be problematic

Jascha Franklin-Hodge

Couldn't we just develop the appropriate query endpoint that returns the matching array of CurbZones? It doesn't seem like there is any data model that will make it easy to implement the full potential set of queries. But backend systems can re-factor the data to support various query schemes.

Jacob Baskin

Yeah but this breaks separations of concerns between APIs, since it means a single API knows both the regulations and the geometries. So if it knows both, it might as well return both?

Neil Goldader

I've had similar thoughts in the past regarding endpoint-separation purity, but I think the complexity needs to land somewhere, and it should not be on the backs of the API consumers. Oftentimes, within the backend is the best place to reconstruct the graph of the data model when you have referential entities, because you can do efficient query tricks within the db. Separation of concerns doesn't mean they can't eventually come back together, I think it's reasonably common practice to have high-level endpoints which allow querying across & combination of multiple entities a-la GraphQL.

As long as we maintain a pointer in one way (like how MDS Policy refers to geographies), it should be reasonably trivial to derive the relationship in the other direction if needed at query-time!

Jacob Baskin

Yes I tend to agree with you -- I think the Curb Zone object we have in the doc right now is a decent balance of this, we include regulations but not like every possible event and metric that you might want. Definitely on the side of putting complexity "behind" the API rather than "in front" of it.

Neil Goldader

I think the things that's tricky is that the Curb Zone object we have now is defining these entities inside of itself, as opposed to being built by them. I suggest that we should define these as fully qualified separate logical entities, that can be joined together by a higher level abstraction.

[HenryEspinosa]

If zones are going to be limited to a single block face, I'd support having the regulation separate and referenced since we have so many blocks with the same regulations. If, on the other hand, a zone can encompass multiple blocks, embedding the policy would be simpler.

[schnuerle]

I think the scenario you brought up in the meeting was 30 blocks in a row with the same regulations at the curb. In CDS, each cub zone would have to be defined, one (or more if not contiguous on the block) for each block. The way it's designed now, you would (a) include the same regulation in each zone. Optionally (b), this same regulation could be defined elsewhere in CDS, and given an ID, and only that ID would be used in each of the 30 zones.

Since CDS is not meant to align to internal data storage systems, and is instead a common way to translate those and communicate them out, it's not really much more work in either scenario. Option (a) would create a larger CDS file, though maybe it more human readable if you are interested in just one zone. Option (b) would have a smaller CDS file, but you'd have to cross reference the ID in the zone with the regulation ID.

[jean-populus]

+1 to @HenryEspinosa's comments.

Just to reiterate that human-readability is important even if it's not the driving factor - we should try to do this when possible.

It also seems like less work - both for cities and third parties - if regulations + locations were treated the same way consistently across data standards. Is there a meaningful reason that CDS and MDS should differ in this?

[schnuerle]

I think you could argue that human readability could apply to both scenarios. If the regulations are spelled out in a zone, then you don't have to cross reference for an ID in the same or another file. If regulations are referenced by ID in a zone, and you have 30 zones with the same ID, then it might be easier to know they are the same rather than hunt for differences.

Minimizing redundancy and architectural consistency might be the bigger concerns.

For MDS alignment, are you thinking that Policy is to Regulations as Zones are to Geography? Policy would have to change a lot to accommodate the concepts in Curb regulations, and Geography would need a lot added to it to have Area/Zone/Space info included (unless these three endpoints stand on their own and reference both Geography and Policy externally).

But there's so much that's not clear yet with the final design of CDS and the use cases it needs to support, that until we get real world results from pilot projects, I don't think direct data crossover between CDS and MDS should happen yet. Plus we are looking at reworking Policy in the next major MDS 2.0 release.

[avatarneil]

I think that we should strive to keep MDS & CDS aligned as much as possible, and one key decision that was made in MDS was to split Policy & Geography. While for some views it may be beneficial to see both things in one payload, I think that shouldn't mean that we have CDS only present the 'joined' view. Managing geospatial definitions separate from policy definitions is hugely beneficial in a lot of cases, it enables things such as:

• Minimizing unnecessary data sync. If a regulation is updated but the geospatial definition hasn't changed at all, then instead of re-pulling both entities, you could only pull the updated regulation.
• Composability. I could imagine a universe where MDS & CDS are very closely aligned, and perhaps MDS Geographies could be used in conjunction with CDS Regulations (or MDS Policies could reference CDS Geographies). Or perhaps MDS Geographies & CDS Geographies could be the same thing, and live outside the immediate purview of either spec.
• Human readability. Funnily enough, I think that having these as discrete entities would make the regulations more human readable, most folks can't parse GeoJSON blobs in their heads, I think!

If we go with the approach of having them as separate entities, we can also design an endpoint which serves both simultaneously (because there are obviously some benefits to API consumers in some cases). It's easy to join the two entities together through an additional endpoint, but it's very hard to separate them if they aren't defined as separate entities within the spec.

[jamesianbarr]

+1 to all of this. Creating a rigid hierarchy (wherein regulations are embedded in Geographies) will force a ton of duplicated data (rewriting similar regulations for varying geographies unnecessarily), and ultimately make things harder for everyone. @avatarneil nailed it so I won't belabor the point 😄

[schnuerle]

Neil are you thinking then that there would be 3 main endpoints for Area/Zone/Space, and then each of these could reference by ID external endpoints for Regulations and Geography in CDS? That would allow future alignment between Policy and Geography in MDS.

One thing that may affect this is it's not clear how many geographic areas are going to be needed, especially in Zones. One block may have 20 different regulations across its curb. Do each of these get their own geography? Should we reduce the complexity here and only define general curb areas with a larger polygon, and the use Space to define smaller useable areas of curb (and not define gap areas between usable curb space)?

[BigIdeas]

My $0.02 - curb zone geometries and regulations have relatively different lifecycles (regulations change more frequently than curb zone geometries), therefore it makes sense to allow curb zones and regulations to be fetched separately. If curb zones and regulations can only be fetched together, CDS may not scale as well with increasing numbers of curb zones, increasing complexity of curb zone geometries, and/or increasing frequency of regulation changes.

[jiffyclub]

One thing I like about having separate regulation and geometry entities is that it's easy to have a "default" policy that applies in many places. I imagine that in many cities the number of curb policies is an order of magnitude or more less than the number of curb zones, so being able to reference out to them will save tons of space. I'm fine with the idea of putting zones and regulations in the same API response as separate arrays or objects, but do think it's better to have them separate.

[jacobbaskin]

Lacuna feedback doc attached:
CDS Spec - Lacuna Feedback.pdf