Policy-Driven Trip Events

[quicklywilliam]

Is your feature request related to a problem? Please describe.

Cities want to be able to perform Policy compliance monitoring (both real-time and historical) for vehicles in motion. Currently, it is not possible to meet this need without requiring precise trip location data.

Describe the solution you'd like

The idea is that vehicles would emit events whenever they enter or leave a geography defined in the Policy endpoint. Then, instead of sharing the exact vehicle location, these events would simply give the UUID for the geography. This would be accomplished via the following changes:

Rename events for entering and leaving municipal areas so they apply to all Policy geographies.

• enter_municipal_area ⇒ enter_geography
• leave_municipal_area ⇒ leave_geography

Add the geography information to the event.

• Add a new event_geography field containing the geography UUID to Provider. This field is required if event_location is not present.
• Add a new event_geography field containing the geography UUID to Agency. This field is required if telemetry is not present.

Remove requirement for precise location data for vehicles during trips.

• Make event_location in Provider optional in the case of vehicle_state:in_use events
• Make telemetry in agency optional in the case of vehicle_state:in_use events

Is this a breaking change

• Yes, breaking

Impacted Spec

For which spec is this feature being requested?

• agency
• provider

Describe alternatives you've considered

None at this time.

Additional context

Note that this proposal assumes/builds on the already proposed changes that unify and simplify Policy and Agency events:
#271

This issue is also related to a proposal to unify the way municipal boundaries and Policy geometries are expressed:
#474

[Retzoh]

Discussed during WG call:

• How to manage the entrance into several geographies at once?
• Is it possible to leverage this idea to let planning team identify the most used routes in the city?
• Could events be sent in real time with only geography, and then updated later with exact location once real-time privacy concerns are over?

[johnclary]

At the City of Austin, we have been hesitant to adopt the policy API because of the required exchange of telemetry data. This approach would provide a needed and welcome alternative. I'm offering our strong support for this change.

[marie-x]

I like this idea! The draft of the PR for #271 is ready for an initial review too: lacuna-tech#7

I still need to update the lacuna-tech repo to be based off 0.4.1 instead of 0.4.0.

[schnuerle]

Mentioned on the call for further discussion:

• What if you have one ping in another geography, does that count? Maybe minimum amount of time in a new area?
• Operating areas that overlap, what to do when a vehicle is in both?
• GPS bounce issues - how to account for that?

Also note this should be flagged as beta for a release so everyone can try it out.

[marie-x]

I think we would want to be careful about how we declare which geographies would apply. I would want to limit it to e.g. "Geography objects described by in-effect-at-that-moment Policy and Jurisdiction documents". Like, you don't scrape /geography for all of them.

[quicklywilliam]

@Karcass I think that's a good idea. I could see the Geometries gaining a boolean field (default false) that indicates whether entry/leaving events should be emitted. I could also see this being a field on a Policy, but that might make it less flexible and wouldn't cover the jurisdiction case. This proposal is using Geometries in a really new way so it might be a good lens to use in thinking about how Geographies, Policy and Jurisdictions inter-relate.

[quicklywilliam]

@schnuerle I believe the PR addresses multiple areas.

As for what to do for quick pings in a geometry or due to GPS bounce, that might warrant a larger discussion at a higher level. I can see that being an issue for existing jurisdiction events (though this PR might make them more common), and of course GPS inaccuracy is going to be an issue for any realtime event-driven system (ie agency).

[bhandzo]

In general this makes a lot of sense as a way to track vehicles moving into and out of jurisdictions.

The mental model of saying "These events are sent for any geography that currently has a policy related to fleet count" feels very sensible here.

For overlapping I think it's simplest to send the geographies as an array, there are many examples where geographies may overlap, for example if the city has an overall vehicle cap, and then minimum distribution requirements.

This does introduce an extra degree of freedom, in that if a provider's geographies are out of date or they have an issue with their geospatial querying it could make their data inaccurate. This isn't a reason not to do it, but something to consider in the design.

[dirkdk]

Here some notes on using location for determining if a vehicle is in a certain area as we work with them at Spin.

Background info:
Vehicles are not aware of geofences. A vehicle will autonomously send its location to our backend, where we determine if a vehicle is in a geofenced area. We only use GPS data to determine location. Mobile phones may use Wifi information and cellphone tower information (Assisted GPS). This is not mainstream for micromobility vehicles as of now. Vehicles while deployed available will broadcast its location at minutes long intervals, while on a trip we bring this down to a few seconds. This is a balance between draining the battery and not overloading our backend infrastructure with vast amounts of data from a large number of vehicles on trips. Also we will occasionally use the location from a mobile phone, e.g. when we deploy a vehicle onto the street. Mobile phones can vary in quality of location determination.

Things to consider regarding GPS receivers

1. It takes time for a GPS receiver to get a location fix. It needs data from preferably 4 but minimal 3 satellites to calculate position and elevation. Certain information is valid for only a limited time. If expired, a GPS receiver will need to update this information first. In order to speed this up, a GPS receive may decide to lower accuracy to give at least a (less precise) response or pass on its last known location. This means that data at the beginning of a trip may be less accurate than later in the trip.
2. This communication with a satellite is ideally via a clear line-of-sight (LOS). High rise buildings, bridges or mountains may influence line of sight and hence precision. Signals bouncing off buildings also can give vastly inaccurate readings.
3. As current micromobility vehicles are mostly shared vehicles that need to be built for durability, location of GPS locator on the vehicle might not be perfect hence limiting signal strength.
4. Vehicles travel at speed. If we assume a 5 second interval and 15 miles per hour, the distance between two positions will be 110 feet. So 10 feet before the geofence a vehicle may send its location which means we would mark it as not in the geofence. A 100 feet later we only get the new location update and determine it is in the geography.

Thus, determination via GPS if a vehicle is in a certain area is not exact science. How can this be improved?

1. Requiring a minimum size of the geography of a minimum of 200 x 200 feet if not more.
2. Enlarging geographies in areas with high rise.
3. Requiring a certain minimum locations within a geography before signaling the vehicle crossed in or out a geography. E.g. a minimum of 3 readings in a new geography before signaling the vehicle has passed into it.
4. Be in particular aware of limitation of location precision at the beginning of a trip.
5. Revisiting frequency of location transmission by vehicles.
6. Do statistical analysis of a subset of locations and determine what outliers there are and discard those. This may be hard to do realtime.

[avatarneil]

I think that there are a few problems that could arise from this, most of which have already been mentioned by others.

It may not be necessary to create new events simply to indicate that a vehicle is within a particular geography. The main purpose of spatially-defined events as they are today is simply to indicate when a vehicle has left a regulating entity's boundaries while operating in the PROW (for micromobility, this should logically only occur during a trip). With the new Jurisdictions API, these boundaries are clearly defined. While technically Jurisdictions have their geospatial boundaries defined by a Geography, I think it's a mixture of concerns to try and generalize the enter/leave events to being on a per-Geography basis; anecdotally, having done a lot of work on analyzing data consumed by Agency (particularly around computing Compliance for Policy, which is essentially what this issue is trying to solve), I don't think that it is necessary to create new events for general Geography crossing.

My counter proposal, (building off of @bhandzo's comment) would be that there is the option (depending on a city's SLAs, of course) to provide a geography_ids parameter to Telemetry points for a vehicle in lieu of GPS coordinates (or, perhaps, in combination with GPS data that drops the last few points of precision). I think that this should address the privacy concerns that @johnclary brought up. Additionally, I think that the event names are going to be changed to something like trip_enter/leave_jurisdiction as part of the Reconciliation.

My proposal, however, does not satisfy the concern that has also been brought up around keeping Providers' definitions of Geography in sync with the Agency's published definitions. These could perhaps be resolved with a set cadence upon when new Geographies/Policies/Jurisdictions should be published (daily, hourly, ...), however there has been interest in having highly dynamic Policies/Geographies for being able to block off streets in the case of natural disasters, immediate closures due to criminal activity, etc.

Something which has not been tackled sufficiently in my opinion, though, is a fundamental concept behind Agency: how we can build a truly bidirectional interface. I think that this proposal (applicable to the original proposal as well as my counter proposal) is a perfect example of why having just RESTful APIs is not necessarily sufficient, and we may need to look at something like long polling, websockets, etc...

[sanjivnanda]

A question for city planners, including @schnuerle. In addition to origin-destination location obfuscated to geography, it seems to me that the routes chosen would be helpful in planning slow streets, crossings, special purpose lanes etc. Is the assumption, that street design is done by planners using other information, not MDS trip data? Or is the idea behind this proposal that geographies may be defined in a way to understand street usage?

[quicklywilliam]

@sanjivnanda I don't want to speak for city planners, but I wanted to clarify our intentions for this proposal.

The aim of Policy Driven Events is to deliver a way to meet compliance monitoring needs without precise location data. There are a raft of other use cases related to city planning, program evaluation, etc which this proposal intentionally doesn't address. For those use cases, we're imagining cities would turn to a different MDS capability such as the trips endpoint or the upcoming Metrics endpoint (see in particular #556).

[quicklywilliam]

Quick update on this issue since it has been a while. We're working to get a PR ready for it and you can find the most recent change set here:
dev...RideReport:policy-driven-events

One important note: we've expanded Policy Driven Events to cover events for parked vehicles. This is in recognition of the fact that parking events constitute trip endpoints, and the endpoints of a trip are often more sensitive than the actual route followed. One consideration could be to have provider and agency drop off events continue to provide precise location data, since these events do not reveal trip data and may be of interest for compliance.

[quicklywilliam]

This also came up in #503. I'd like to propose an effort in the future to add the richness of telemetry data to endpoints throughout Provider.