Add service area type to the agency API. Add service areas to the provider API

[cttengsfmta]

We propose adding the following functionality to the Service Area API. The agency API would allow agencies to also indicate restricted zones and preferred pick-up/drop-off zones. We envision this as a mechanism to communicate both permanent and temporary (e.g., special event) prohibited/incentive zones, rather than ad-hoc communications (e.g., emailing a shapefile).

We presume the providers also have their own prohibited/incentive zones. The Provider API would return the full set of prohibited/incentive zones (whether indicated by the provider or the agency).

[hunterowens]

LGTM. 0.3.0 breaking change

[hunterowens]

need to add JSON schema docs for this. Will do later today.

[black-tea]

I completely get the point of having this be a part of agency, and to some degree we already have a (basic) version of it for the conditional permit in LA. For example, we have a service hosted here that shows where scooters are not allowed during the conditional permit period. I am very much in favor of adding this to the agency side and could see it becoming very useful.

@cttengsfmta Could you describe a bit more about how you would see the use-case for the provider version of this endpoint? Our big-picture thinking about provider, taken from the main page is:

provider API is to be implemented by mobility as a service providers, for data exchange and operational information that a municipality will query.

I'd be curious to hear more about how you think cities would be querying this information, and why we wouldn't just want to focus on the actual activity that occurred, which we get through status_changes and trips.

Also - is it required? If so, how would we have any way of enforcing the accuracy of the information? If it is not required, I'd be interested to hear more from the providers themselves (@noonhub @asadowns @babldev ) on whether they would see a provider implementation as having any use.

My gut feeling is that this is a very good idea for agency but is a bit of a stretch in applying to provider.

[babldev]

It makes sense for agencies to be able to declare "this is where we are allowing providers to pickup/dropoff."

I'm confused as to what it means to have this in the provider API. Is this designed to say "this is where providers are operating?" I'd like to understand why agencies would need this API.

[hunterowens]

@babldev exactly. The idea here is we should have an idea of approve area (ie, agency declares) vs operating areas, which is where the company actually operates. They could be the same or the approved area (expressed in agency) could be larger than the operating area (expressed in provider)

[asadowns]

I realize I'm a bit late to the conversation here but I don't think it makes sense to have service area information in the provider API. I think I would agree with the points @black-tea and @babldev made.

I have several concerns

• What value does knowing provider service areas provide to agencies?
• Volume of data. Are agencies going to poll and paginate thousands of areas some with large, complex geometries to get a small number of geometries that are added/updated in any period?
• Agency/Provider separation

From my perspective, the agency API makes sense because it benefits both agencies and providers when agencies can push information to providers that give them timely updates on when areas should be restricted or preferred. I don't see a reciprocal use case for agencies to use provider service areas.

Provided the agency is given all data in their jurisdiction, what is the rationale for providers to provide individual service areas and types?

It also appears this API is opinionated about what types of areas a provider may have as well as how they choose to represent their geometries. This seems mistaken. Additionally, what is the value in providers separating agency/provider geometries and reflecting agency geometries (pulled from the agency API, presumably) back to the agency?

[babldev]

Provided the agency is given all data in their jurisdiction, what is the rationale for providers to provide individual service areas and types?

I agree that Agencies are the source-of-truth for service areas so I don't see value in Providers also serving it. There are costs for maintaining such functionality, so if it's not going to be used it's best left out of the Provider API.

[hunterowens]

@asadowns @babldev Thanks for your comments. This in the dev branch now, so I'm not opposed to removing service_areas from providers, as we can probably generate that (per @asadowns suggestion) by looking at service_start events from /status_changes

[asadowns]

@hunterowens looks like this got merged in with service_areas in providers. Given the above comment it didn't look like that would be part of this PR. Is this something we can revert? Thanks!

[hunterowens]

@asadowns @babldev please see #203 for refactor