Should every curb polygon require a unique ID?

[jacobbaskin]

Hi all,

Since yesterday's meeting, another implementation question I've been thinking about has been unique IDs for curb space. It's pretty clear to me that any curb space that has event information needs a unique identifier, but we will have lots of curb space without events. So the question there is, should we require in the spec that every polygon of curb space with its own regs info gets its own ID.

The benefits of having IDs is obvious, but there are some challenges that are worth considering:

• IDs may encourage people to think of them as stable when they really aren't. For instance, if I auto-generate IDs based on a linear reference, those IDs can change due to very slight updates to the underlying data (base map changes, segment splits/joins, etc)
• Conversely, stable IDs can encourage people to apply regulations anachronistically -- e.g. I look at the current regs and I see that space 12345 is 40 feet long and allows loading only, but a month ago that space was 50 feet long and also allowed parking, so if I have an event stream from a month ago I will misinterpret it.
• Requiring IDs Imposes additional requirements on data producers
• A single conceptual stretch of curb can be broken up into multiple regulations if there are e.g. driveways or buffers separating spaces, so the space you want to give an ID to may not match the space you want to regulate
• If we use CurbLR-style regulation priorities, different polygons can overlap each other in space, so assigning each one a unique ID means that a point in space could correspond to multiple IDs.

Would appreciate thoughts on this!

[schnuerle]

I think it makes sense and is pretty easy to create a unique ID for each curb space polygon. Whether it gets used or not, it's worth doing it for when it will be used. And I can see the ID being used in MDS to reference CDS curb areas.

For the format, I recommend using UUID (Universally Unique Identifiers), which is an easily generated unique and random identifier. We use UUIDs extensively in MDS and they work well.

[jacobbaskin]

We will need to write up some stuff about when you can expect IDs to be stable. For pure regulation data, to a first approximation I would say "never". But if you define space as being monitored, bookable, etc. then probably we will say something like the ID will remain stable as long as the use of the space stays substantially the same.

[schnuerle]

Since the ID is then not strictly dependent on the underlying data, then I think UUID is good mostly because of consistency with MDS. SHA256 (eg, e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855) is a string not much different that a UUID (eg, 123e4567-e89b-12d3-a456-426655440000).

[jacobbaskin]

Yeah I had an idea in my head that UUIDs had some internal structure that made them hard to just stick hashes into but it looks like generating UUIDv5s from hashes is in fact encouraged, so let's use 'em

[schnuerle]

Great. Yeah the hashes are there to simply provide some structure to the string, and v5 could work well if seed data is needed. In other cases I imagine no seed data is needed, so could use the random UUID v4.

[jacobmalleau]

To follow up James' point, I like the idea of having unique IDs for segment blocks (segIDs) while regulations have their own unique IDs (regIDs) like how you have described above. I know this brings in the question of how you label the segment blocks - but many cities working at the curbside have some type of identification for this.

As for the two cases you provided, I agree with the approach to Case 1, however I don't love the idea of leaving gaps in the curb to be dealt with later. At CurbIQ we have tried to emphasize mapping the entire curb and found that cities don't just want to know where the 'commercial loading zones' are, but what all curbside space is designated as (curb bulbs, no parking, etc.). By leaving those gaps, it then becomes complicated when updating and changing designations. Say that whole street becomes No Parking - you would then have No Parking segments with gaps in between with the proposed approach, opposed to having the whole curbside be No Parking (including the small 2' gaps segments) if you were to have all segments with unique IDs.

[jiffyclub]

I think every entity should have a unique ID, so the question for me is what are the atomic entities in CDS? In CurbLR the atomic entity seems to be a stretch of curb and its associated regulations (if any). I think that should also include dates of validity.

[schnuerle]

I think in CDS the atomic entity is Curb Zone (a polygonal area of curb that is used for some specific activities), which aligns to CurbLR in purpose I believe. There is also optionally a level lower in CDS, which is Curb Space (a designated place for a vehicle).

[jacobbaskin]

I think this has been pretty resolved in favor; locking.