You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@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.
The text was updated successfully, but these errors were encountered:
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.
/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.
@rf brought up some good thoughts about what should be considered a
service_area
:The text was updated successfully, but these errors were encountered: