Activity Definition Overlap: 'travel' vs 'no stopping'

[zanebclark]

What's the difference between these two Activities: no stopping and travel. Both activities prohibit stopping, loading, and parking. no stopping seems to imply that travel is allowed.

[jlarsonOmahaNE]

I think that parking and no parking should remain but loading should be broken out to freight loading and passenger loading or leave loading but add passengers into the description. no stopping I think could be removed and travel should remain.

[zanebclark]

@jlarsonOmahaNE, can we distinguish between commercial and passenger loading with the applicable user classes? For example:

{
  "activity": "loading",
  "user_classes": ["commercial"]
}

and

{
  "activity": "loading",
  "user_classes": ["tnc"]
}

[zanebclark]

no stopping I think could be removed and travel should remain.

👍

[jlarsonOmahaNE]

Yes, I agree with using the user classes. I think that no loading , no stopping and stopping could all be removed and the other descriptions updated accordingly. I think that no parking would take care of the 3 mentioned above.

[zanebclark]

I'm not sure I follow dropping the stopping activities. I'm a big fan of dropping negative values in favor of an "activity_allowed" column: #66

[schnuerle]

Besides discussion #66, what is everyone thinking of here with the latest Activities changes?

https://github.com/openmobilityfoundation/curb-data-specification/tree/feature-release-work-1/curbs#activities

Each has a positive and negative, except 'travel'. Coord added travel for a specific reason I think.

I feel like each of parking, loading, unloading, and stopping has a real world scenario and are on signs that are used in cities to mean specific things.

[zanebclark]

Maybe a table would be a useful method of defining the activities allowed/prohibited by each activity: #69

At the very least, the table does a good job of representing areas of ambiguity in my mind w/ question marks.

[jlarsonOmahaNE]

I also agree with unloading also being problematic. We talked internally and thought that loading should cover any loading/unloading at the curb.

To my other comments, I think that based on how the driver of the vehicle is acting when pulling up to the curb (ie. leaving the vehicle unattended or parking but coming back and forth) the other activities stopping and no stopping should stay.

[schnuerle]

FYI a WGSC member from Populus shared this image, where loading is a separate activity than unloading. Not sure what city this is. I was able to support this with currently as defined in the /zones endpoint.

[zanebclark]

activity seems to represent two separate dimensions: time and activity. I imagine you will have cases where the municipality doesn't care what you're doing, so long as you're only doing it for x minutes and other cases where the activity (e.g. loading) is more important than how long you're doing the activity.

cases where the municipality doesn't care what you're doing, so long as you're only doing it for x minutes

max stay does a good job of capturing this use case

@jlarsonOmahaNE, apologies for misunderstanding your earlier comment.

To my other comments, I think that based on how the driver of the vehicle is acting when pulling up to the curb

If we move the time element to max_stay and make the activity representative of only the activity, which activities would remain? For example, stopping could be represented as a small max_stay, so should it be an activity?

[zanebclark]

@jlarsonOmahaNE , I inserted the wrong github handle in the above comment earlier. Apologies.

[zanebclark]

@kenyaw , thanks for weighing in on PR #69. Can you weigh in on this suspicion: It feels like some activity definitions are attempting to reflect a max_stay value. For example, stopping can be reflected with a sufficiently short max_stay. Parking is similarly defined by a longer - or infinite - max stay. In the case of stopping or parking, the municipality isn't regulating how the vehicle is interacted with during that time. I would argue that stopping could be defined as follows:

{
  "activity": "any",
  "max_stay": 10
}

Parking could be defined similarly

{
  "activity": "any",
  "max_stay": 240
}

The max_stay values are examples and would vary from city to city

Note that the activity isn't constrained. I imagine we don't care if the operator is unloading or loading in those
situations. The activity should be reserved for interactions with the vehicle. loading and unloading are good examples. This information could be derived from optical sensors or from Events pushed to CDS (e.g. event_purpose). I think @jlarsonOmahaNE
made this point earlier in the thread, but I didn't grasp it.

Do you think this compatible with regulations in SF?

[zanebclark]

@kenyaw, @jlarsonOmahaNE, and @schnuerle, I'm stirring the pot on this discussion in anticipation of a lively discussion on Thursday

[zanebclark]

@schnuerle , thanks for leading the discussion on this subject today. It sounds like introducing some way to reflect a no travel policy would be useful. Would it make sense to split this attribute out into a boolean field? Or, keep it as an activity? If travel is not permitted, max_stay, no_return, and rate have no meaning, so we'd likely want to include that clause in the respective descriptions.

[schnuerle]

My thought is that for this release, we can add a no travel activity, to meet @kenyaw's ideas on changing a typical travel lane to a no travel lane and be able to communicate that.

Then while the items are all symmetrical now with positive and negative versions, I think should keep it as is now as text options, and explore splitting into a boolean option in next release. It seems easier for employees to think of these rules in terms of 'parking' and 'no parking' instead of 'parking' + 'allowed' or 'parking' + 'not allowed/prohibited' in 2 fields. Also I'm not sure if future uses will be symmetrical like this so I'd want to see if other activities come up when 1.0 is put into use.

We can clarify the spec text to note that some fields (max_stay, no_return, and rate) don't apply to all activities. We could get specific, but maybe a general comment would cover it.

[zanebclark]

👍

[schnuerle]

I clarified it activity use here, and added the 'no travel' activity. https://github.com/openmobilityfoundation/curb-data-specification/blob/feature-release-work-1/curbs/README.md#rule

I think we can save your table for this section for the next release too after we see how this is used.

[zanebclark]

@schnuerle , on a separate note, It sounds like we need to keep words like "stopping" and "parking" for the ease of policy definition and interpretation. The meaning of these terms will boil down to a municipality-specific max_stay value for each term. In the case of @jlarsonOmahaNE , stopping would be a max_stay of 2 minutes. By mixing these terms in with activity, we're still conflating some separate concerns:

In the case of stopping or parking, the municipality isn't regulating how the vehicle is interacted with during that time.... The activity should be reserved for interactions with the vehicle. loading and unloading are good examples. This information could be derived from optical sensors or from Events pushed to CDS (e.g. event_purpose).

So, how do we keep the term stopping and define it in a way that's machine interpretable without conflating multiple concerns in activity?

[jlarsonOmahaNE]

@zanebclark are you talking about no stopping in your last question? With the current definition of stopping a vehicle could pick up/drop off passengers with a time of under 1 - 2 min but greater than 0. I see no stopping having a max_stay of 0 min but could a flag just be used to determine if the vehicle stays greater than 0 min because we would want to be able to fine a vehicle for this action but also track how long they were in the no stopping area.

[zanebclark]

Great catch! I've updated:

In the case of @jlarsonOmahaNE , stopping would be a max_stay of 2 minutes

[zanebclark]

could a flag just be used to determine if the vehicle stays greater than 0 min because we would want to be able to fine a vehicle for this action but also track how long they were in the no stopping area.

@jlarsonOmahaNE , the short answer is yes, but I'd like to dig into your perceived use case. If we compare the details of the event to the details of the policy, rules, time spans, etc, we'll be able to flag the park as a violation. That's as far as I had considered metrics around violations. A boolean, if you will. You're saying that you want the violation boolean as well as details about the size of the violation? This is very interesting 🤔

[jlarsonOmahaNE]

Yes, I think that it would benefit cities if there was also tracking of how long a vehicle was in a no stopping area. An example I see is that you have a loading activity in a loading zone but the zone is closer to the end of a block segment where there is usually a sight distance consideration where vehicles would be in a no stopping area. In this example a camera would be able to watch both areas depending on angle/placement.

[schnuerle]

I believe the current version of the spec has resolved the conversations here, at least for the 1.0 release. Please chime in if there is more to discuss now, or track for the next release.

[zanebclark]

@schnuerle , I've moved my proposal to remove parking and stopping to this discussion: #94