We have some seasonal service request types that present this problem. E.G.,
each fall we provide loose leaf collection service to residents – they rake
fallen leaves into the street and we vacuum them to be mulched. We have a
service request type for reporting piles of leaves that we missed. Soon after
our collection season ends, we stop advertising that service request type in
/services.xml even though /requests.xml and /requests/NNNNN.xml will reveal
information about existing service requests. My opinion is that for existing
service requests, the service_name attribute in each request object is
sufficient -- consumers don’t need to see other data like the service request
type’s description -- so it’s OK that /services.xml omits that type.
We also have a service request type that is not listed in /services.xml but
whose existing service requests are exposed via /requests.xml and
/requests/NNNNN.xml -- snow and ice removal. We have a dedicated website for
requesting that a roadway be plowed, one that can apply additional temporal and
geographic tests before creating a service request (e.g., it knows to never
accept a request for private roadways, and only to accept requests for street
segments that we believe are passable). As with the seasonal service request
types, I’ve thought this was OK.
My recommendation would be to do exactly what you say you want to – continue to
provide info about existing requests but don’t include the service request type
in /services.xml.
-Peter
Have there been any recommendations for dealing with services which a city no
longer accepts reports?
A few of our services were for temporary initiatives. Once the initiatives are
over, we'd like to remove the service from Open311 clients when they're asking
for the list of services to report on. However, it seems like we would want to
continue to make the data available via GET service_requests.
What is the recommendation for listing services that would essentially be
read-only?
each fall we provide loose leaf collection service to residents – they rake
fallen leaves into the street and we vacuum them to be mulched. We have a
service request type for reporting piles of leaves that we missed. Soon after
our collection season ends, we stop advertising that service request type in
/services.xml even though /requests.xml and /requests/NNNNN.xml will reveal
information about existing service requests. My opinion is that for existing
service requests, the service_name attribute in each request object is
sufficient -- consumers don’t need to see other data like the service request
type’s description -- so it’s OK that /services.xml omits that type.
We also have a service request type that is not listed in /services.xml but
whose existing service requests are exposed via /requests.xml and
/requests/NNNNN.xml -- snow and ice removal. We have a dedicated website for
requesting that a roadway be plowed, one that can apply additional temporal and
geographic tests before creating a service request (e.g., it knows to never
accept a request for private roadways, and only to accept requests for street
segments that we believe are passable). As with the seasonal service request
types, I’ve thought this was OK.
My recommendation would be to do exactly what you say you want to – continue to
provide info about existing requests but don’t include the service request type
in /services.xml.
-Peter
Have there been any recommendations for dealing with services which a city no
longer accepts reports?
A few of our services were for temporary initiatives. Once the initiatives are
over, we'd like to remove the service from Open311 clients when they're asking
for the list of services to report on. However, it seems like we would want to
continue to make the data available via GET service_requests.
What is the recommendation for listing services that would essentially be
read-only?