We're about to develop an enhancement to our public web UI for our Open311
backend, adding a service type that will require the POST /requests.FMT
requests to specify address_id rather than lat+long or address_string. For this
new request type, we want the customer to identify the exact asset that needs
service. (For other service types related to locations, we will continue to
only require that the client provide a lat+long within our jurisdictional
boundaries.)
I'd love to hear how others have tackled this, especially with any GeoReport
extensions, so that we can formalize an approach for a future GeoReport spec.
It seems like the most important things here are
1. To decide how to let clients know this service type only accepts valid
address_id locations.
I think it'd probably be best for GET /services.FMT to only include info about
such a service if the client passed an argument indicating it was prepared to
handle such service types. I don't want customers facing bad UX if a vanilla
Open311 client offered this service type but couldn't actually create requests
for it.
2. To decide how the client should obtain a list of valid assets/address_id
values.
The easiest thing for us would be to have our customer UI obtain data from our
GIS services, much as it currently queries our ESRI ArcGIS services to geocode
customer-supplied address strings using different geocoders for different
service types (so potholes are mapped in the roadway and building code
violations are mapped to buildings)** -- our service definition could just give
the client a URL for an ESRI mapserver service. But we're open to the idea of
creating a new GeoReport GET method that would return an array of asset/address
objects, especially if there seems to be community interest in others' customer
interfaces being able to offer similar asset-driven reporting interfaces.
Our UI plan is, in brief:
* In the service definition include additional information specifying
* Which assets it relates to (this might be a RESTful service URL whose
path provides that info)
* The preferred minimum zoom level at which the client should request a
list of assets (save bandwidth, prevent map clutter)
* Require the customer to identify the approximate location on a visible
map.
* Zoom to the preferred minimum zoom level if not already zoomed in that
much and ask our backend for an array of objects representing the known assets
within that map's boundaries. Data returned will include for each asset at
least such things as:
* The address_id for the specific asset
* The lat+long of the asset
* Boolean expressing whether we will accept a service request for this
asset
* Information about whether there are existing, open service requests
for this asset
* Our UI will then add map markers, likely with different iconography to
show at a glance whether the asset is
* Something we will accept a service request for, and which has no open
requests
(i.e., something we take care of and think is currently in good shape)
* Something we will accept a service request for, and which already has
at least one open request
(i.e., something we take care of and already know needs service)
* Something we will not accept a service request for
(i.e. something we know exists but whose maintenance is not our responsibility)
* If the customer selects an asset that we will accept a service request
for, we will allow the customer to continue and submit a request, with the
location identified by its address_id. Our backend will validate the
address_id.
The specific case here is accepting reports of malfunctioning street lights.
Our electric utility company insists on having the unique ID numbers located on
the poles before it will send crews out to repair them. I don't think it's
reasonable to ask our residents to stop, find that info, and record it in order
to report outages (especially if they're in a motor vehicle). We have GIS data
about all poles. We hope that a customer, once looking at a map that's been
zoomed in a reasonable amount, will be able to identify the location of the
pole when shown markers for all nearby poles. If the customer can do that, we
can look up the unique ID number for the pole (even if the pole number is
damaged not legible, etc.) and pass the report along to the utility company for
repair.
Without asking the customer to specify the exact pole (as we used to allow), we
end up with ambiguous locations, and cannot create good repair requests for the
utility company without field work. Furthermore it's expensive to follow up and
get the pole ID number if we're only given an approximate address as our staff
have to survey the location at night. Also sometimes customers want to report
lights that fail intermittently, so even a nighttime field survey might fail to
identify the correct asset. Therefore accepting a simple lat+long location does
not work well for this service type.
Thanks,
Peter
** I didn't propose the per-service geocoder info as an extension largely
because, to save dev time and reduce architectural complexity, we coded our
clients against ESRI ArcGIS standard services rather than try to make a
GeoReport GET geocode service.
backend, adding a service type that will require the POST /requests.FMT
requests to specify address_id rather than lat+long or address_string. For this
new request type, we want the customer to identify the exact asset that needs
service. (For other service types related to locations, we will continue to
only require that the client provide a lat+long within our jurisdictional
boundaries.)
I'd love to hear how others have tackled this, especially with any GeoReport
extensions, so that we can formalize an approach for a future GeoReport spec.
It seems like the most important things here are
1. To decide how to let clients know this service type only accepts valid
address_id locations.
I think it'd probably be best for GET /services.FMT to only include info about
such a service if the client passed an argument indicating it was prepared to
handle such service types. I don't want customers facing bad UX if a vanilla
Open311 client offered this service type but couldn't actually create requests
for it.
2. To decide how the client should obtain a list of valid assets/address_id
values.
The easiest thing for us would be to have our customer UI obtain data from our
GIS services, much as it currently queries our ESRI ArcGIS services to geocode
customer-supplied address strings using different geocoders for different
service types (so potholes are mapped in the roadway and building code
violations are mapped to buildings)** -- our service definition could just give
the client a URL for an ESRI mapserver service. But we're open to the idea of
creating a new GeoReport GET method that would return an array of asset/address
objects, especially if there seems to be community interest in others' customer
interfaces being able to offer similar asset-driven reporting interfaces.
Our UI plan is, in brief:
* In the service definition include additional information specifying
* Which assets it relates to (this might be a RESTful service URL whose
path provides that info)
* The preferred minimum zoom level at which the client should request a
list of assets (save bandwidth, prevent map clutter)
* Require the customer to identify the approximate location on a visible
map.
* Zoom to the preferred minimum zoom level if not already zoomed in that
much and ask our backend for an array of objects representing the known assets
within that map's boundaries. Data returned will include for each asset at
least such things as:
* The address_id for the specific asset
* The lat+long of the asset
* Boolean expressing whether we will accept a service request for this
asset
* Information about whether there are existing, open service requests
for this asset
* Our UI will then add map markers, likely with different iconography to
show at a glance whether the asset is
* Something we will accept a service request for, and which has no open
requests
(i.e., something we take care of and think is currently in good shape)
* Something we will accept a service request for, and which already has
at least one open request
(i.e., something we take care of and already know needs service)
* Something we will not accept a service request for
(i.e. something we know exists but whose maintenance is not our responsibility)
* If the customer selects an asset that we will accept a service request
for, we will allow the customer to continue and submit a request, with the
location identified by its address_id. Our backend will validate the
address_id.
The specific case here is accepting reports of malfunctioning street lights.
Our electric utility company insists on having the unique ID numbers located on
the poles before it will send crews out to repair them. I don't think it's
reasonable to ask our residents to stop, find that info, and record it in order
to report outages (especially if they're in a motor vehicle). We have GIS data
about all poles. We hope that a customer, once looking at a map that's been
zoomed in a reasonable amount, will be able to identify the location of the
pole when shown markers for all nearby poles. If the customer can do that, we
can look up the unique ID number for the pole (even if the pole number is
damaged not legible, etc.) and pass the report along to the utility company for
repair.
Without asking the customer to specify the exact pole (as we used to allow), we
end up with ambiguous locations, and cannot create good repair requests for the
utility company without field work. Furthermore it's expensive to follow up and
get the pole ID number if we're only given an approximate address as our staff
have to survey the location at night. Also sometimes customers want to report
lights that fail intermittently, so even a nighttime field survey might fail to
identify the correct asset. Therefore accepting a simple lat+long location does
not work well for this service type.
Thanks,
Peter
** I didn't propose the per-service geocoder info as an extension largely
because, to save dev time and reduce architectural complexity, we coded our
clients against ESRI ArcGIS standard services rather than try to make a
GeoReport GET geocode service.