Hi Sean,
thank you for the hint and your paper. It's interesting to read and
covers some of the aspects that we like to solve (e.g. load balancing
using a partition).
But we are still looking for a way to transfer issues and users between
the instances, so we will investigate some more options and maybe build
upon your approach.
Matthias
>>> Sean Barbeau <<email obscured>> 03.08.2018 19:58 >>>
Matthias,
We encountered a similar challenge when adding Open311 support for
issue
reporting to the open-source OneBusAway app for real-time bus arrival
info.
In our OneBusAway setup each region has servers managed by agencies in
that
region. So, Seattle has it's own OneBusAway server instance with it's
real-time arrival info, Tampa has it's server, etc. Each of these
regions
could also have an Open311 server API endpoint, although it's not
guarateed
- in that case, we fall back to legacy issue report solutions.
We worked with the vendor SeeClickFix (which was already being used by
agencies in the Tampa, FL, USA area) to implement a Open311 server
discovery protocol.
Here's a paper we presented at TRB earlier this year that discusses
this
project:
https://www.dropbox.com/s/gfhtty073c8o1u6/OneBusAway%20Open311-v11.pdf?dl=0
The Deployment section includes this text:
"To ensure that issues for a geographic area are submitted to the
correct
issue reporting server, the project team designed and implemented a
discovery protocol for Open311 servers within a OneBusAway region. As
mentioned earlier, the OneBusAway Regions API now supports the
definition
of multiple Open311 server addresses. When a user reports an issue,
each
of the Open311 servers for the region are queried to determine which
issue
categories exist for that geographic location. If only one
“Other”
category is reported for a specific Open311 server, then that area is
not
monitored by that server. If no Open311 servers are monitoring that
area,
then the issue is sent to the OneBusAway server. If an Open311 server
returns more than one category, then the issue is sent to that Open311
server. If no Open311 servers exist for a region, then issues are sent
to
the OneBusAway server for that region (i.e., the same process that
existed
prior to the implementation of enhanced issue reporting capabilities).
The project team worked with the SeeClickFix engineering team to
design,
implement, and test software that executes this new Open311 server
discovery protocol. It was successfully deployed during this project,
with
Pinellas County being monitored by the SeeClickFix server, and
Hillsborough
County initially being unmonitored (and therefore issues were still
reported to the OneBusAway server for Hillsborough County).
Hillsborough
Area Regional Transit started monitoring Hillsborough County in
SeeClickFix
in January 2017, at which point issues reported in Hillsborough County
were
instantly directed to SeeClickFix and successfully received by HART.
Future work could examine proposing this implementation as part of the
Open311 standard."
Note this is just a simple REST API request/response protocol initiated
by
the client to discover whether it should be submitting issues to an
Open311
API endpoint - it doesn't include any more sophisticated data exchange
like
moving issue back and forth between different Open311 compliant
servers.
I'd be happy to answer any other questions!
Sean
Sean J. Barbeau, Ph.D.
<email obscured>
http://www.linkedin.com/in/seanbarbeau
――
View topic http://lists.open311.org/r/topic/5KMR0WkT6riYRrtgkHCvNB
Leave group mailto:discuss@lists.open311.org?subject=Unsubscribe
Start groups https://OnlineGroups.net
thank you for the hint and your paper. It's interesting to read and
covers some of the aspects that we like to solve (e.g. load balancing
using a partition).
But we are still looking for a way to transfer issues and users between
the instances, so we will investigate some more options and maybe build
upon your approach.
Matthias
>>> Sean Barbeau <<email obscured>> 03.08.2018 19:58 >>>
Matthias,
We encountered a similar challenge when adding Open311 support for
issue
reporting to the open-source OneBusAway app for real-time bus arrival
info.
In our OneBusAway setup each region has servers managed by agencies in
that
region. So, Seattle has it's own OneBusAway server instance with it's
real-time arrival info, Tampa has it's server, etc. Each of these
regions
could also have an Open311 server API endpoint, although it's not
guarateed
- in that case, we fall back to legacy issue report solutions.
We worked with the vendor SeeClickFix (which was already being used by
agencies in the Tampa, FL, USA area) to implement a Open311 server
discovery protocol.
Here's a paper we presented at TRB earlier this year that discusses
this
project:
https://www.dropbox.com/s/gfhtty073c8o1u6/OneBusAway%20Open311-v11.pdf?dl=0
The Deployment section includes this text:
"To ensure that issues for a geographic area are submitted to the
correct
issue reporting server, the project team designed and implemented a
discovery protocol for Open311 servers within a OneBusAway region. As
mentioned earlier, the OneBusAway Regions API now supports the
definition
of multiple Open311 server addresses. When a user reports an issue,
each
of the Open311 servers for the region are queried to determine which
issue
categories exist for that geographic location. If only one
“Other”
category is reported for a specific Open311 server, then that area is
not
monitored by that server. If no Open311 servers are monitoring that
area,
then the issue is sent to the OneBusAway server. If an Open311 server
returns more than one category, then the issue is sent to that Open311
server. If no Open311 servers exist for a region, then issues are sent
to
the OneBusAway server for that region (i.e., the same process that
existed
prior to the implementation of enhanced issue reporting capabilities).
The project team worked with the SeeClickFix engineering team to
design,
implement, and test software that executes this new Open311 server
discovery protocol. It was successfully deployed during this project,
with
Pinellas County being monitored by the SeeClickFix server, and
Hillsborough
County initially being unmonitored (and therefore issues were still
reported to the OneBusAway server for Hillsborough County).
Hillsborough
Area Regional Transit started monitoring Hillsborough County in
SeeClickFix
in January 2017, at which point issues reported in Hillsborough County
were
instantly directed to SeeClickFix and successfully received by HART.
Future work could examine proposing this implementation as part of the
Open311 standard."
Note this is just a simple REST API request/response protocol initiated
by
the client to discover whether it should be submitting issues to an
Open311
API endpoint - it doesn't include any more sophisticated data exchange
like
moving issue back and forth between different Open311 compliant
servers.
I'd be happy to answer any other questions!
Sean
Sean J. Barbeau, Ph.D.
<email obscured>
http://www.linkedin.com/in/seanbarbeau
――
View topic http://lists.open311.org/r/topic/5KMR0WkT6riYRrtgkHCvNB
Leave group mailto:discuss@lists.open311.org?subject=Unsubscribe
Start groups https://OnlineGroups.net