Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify what constitutes a service_area #259

Closed
whereissean opened this issue Mar 4, 2019 · 2 comments
Closed

Clarify what constitutes a service_area #259

whereissean opened this issue Mar 4, 2019 · 2 comments
Labels
Agency Specific to the Agency API
Milestone

Comments

@whereissean
Copy link
Contributor

@rf brought up some good thoughts about what should be considered a service_area:

In the case where an agency doesn't want to allow providers to operate in all areas of their jurisdiction, I wouldn't necessarily expect service_areas to cover the whole jurisdiction but I'd definitely expect providers to include events that happen in those prohibited areas. It's probably worth either distinguishing service areas from jurisdictional boundaries or clarifying that agencies are expected to include either unrestricted or restricted areas covering their full jurisdiction in the service_areas endpoint.

The former makes more sense to me—it seems unnecessarily onerous to make agencies carve up their whole city boundary into restricted and unrestricted zones to serve in the API, and also I would imagine providers would rather have a stable concept of a given city's boundaries instead of having to trust that the agency will always give them a set of service areas that add up to a consistent boundary.

@whereissean whereissean added the Agency Specific to the Agency API label Mar 4, 2019
@whereissean
Copy link
Contributor Author

The Agency needs to define what is ground truth for the area that they are responsible for and the expectation for operations over that area. My evolving view is that service_areas are the mechanism for Agency to do that and that service_areas should be complete (describing the entire municipal area) and non-overlapping. This will create a solid foundation for determining in and out of Agency jurisdiction and what the expectation is for operation/deployment.

I think there is then the need to define a construct for additional areas that can represent more specific sub regions that are tied to specific policies (e.g. preferred parking zone) and may become more complex.

As far as effort involved in carving up the municipal area, my assumption is that there are likely already constructs (e.g. city districts) that would likely be used for service_areas. If an Agency would like to specify only the areas they want to allow operation, I think there is a fairly easy way to create the inverse areas and label them as restricted.

@hunterowens hunterowens added this to the 0.4.0 milestone Jun 27, 2019
@marie-x
Copy link
Collaborator

marie-x commented Sep 18, 2019

/service_areas will be deprecated in favor of Policy, which captures parking-zones, pick-up and drop-off, and a wide variety of other rules/guidelines/etc.

@marie-x marie-x closed this as completed Sep 18, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Agency Specific to the Agency API
Projects
None yet
Development

No branches or pull requests

3 participants