We are working on enhancing our website for the upcoming changes to the ADA. We have SYOS covered thanks to the new "Reserve Held Seats" option for T_DEFAULTS with V10, which now works with ReserveTicketsSpecifiedSeats and that we use holds for wheelchair seats.
Initially we decided we would only enhance the SYOS ticketing path, but we have situations where we deliberately disable SYOS due to volumes, leaving Best Available as the only option. The problem is that while ReserveTicketsEx allows the parameter for special requests, wheelchair being one of them, that will not work for held seats.
Has anyone done anything dealing with wheelchair seats and Best Available?
Thank you in advance.
Paul
What we're attempting to do is enhance the ability of the best seating system to seat both wheelchair locations and companion locations appropriately. So in essence, the new procedure will look at the number of wheelchair location requests as compared to the total number of seats requested. The difference between the two will be considered companion seats, which will be divided as equally as possible between the number of wheelchair location requests. Then the process will select each wheelchair location (in normal best seating order) and then attempt to select that wheelchair location's companion seats as close as possible to the selected wheelchair location. Calculating "close as possible" is done using both row and seat contiguity.
I can't get much more specific than that until we are through with development and testing. But our goal is to both adhere to the spirit of the new regs which call for being able to accommodate best seat requests in a like manner whether wheelchair locations are included or not, and to stay backward compatible with the existing best seating process.
Was this ever implemented? Did I miss the solution in another thread?
We implemented this internally for two reasons: 1) the accessible seating system in Tessitura wasn't going to be updated by the drop-dead deadline (um, March 15th, 2011) and 2) our interpretation and implementation of the rules was a little different to the direction that Tessitura went: namely that the 2nd and 3rd companion seats could be assigned from nearby wheelchair spaces. That is to say, our layout typically looks like this (S: Standard, W: Wheelchair space, C: Companion seat):
SSWCCWWCCWWCSS
So someone asking for one Wheelchair and three other tickets would be entitled three companion spaces, but we would provide two Companion seats and one Wheelchair space, e.g.:
SS[WCCW]WCCWWCSS
To do this, I have had to divert online requests that include wheelchair spaces, and instead of using Best Seat API methods, I pull a custom table that matches wheelchair spaces in each venue with companion seats in order (set up by the box office manager), and run my own (rather complex) algorithm to generate a specific seat request (or identify that the request cannot be executed).
--Gawain
We experimented with the plan that you mentioned, trying to find companion seats as close as possible to the selected wheelchair seats. The problem that we ran across was that it worked as expected for some house configurations and in a totally unexpected manner for other facilities, depending on how they were built. We could never succeed in making the process consistent enough to release.
So we decided to take another approach and added the ability to do best seating out of a specific hold code. In v11 you can pass a special request of a holdcode to the ReserveTicketsEx method and the best seat request will honor that hold code. This allows a web developer to take special action on ADA seating requests and even have different pools of seats for different situations--one hold code for wheelchair locations and a different hold code for hearing impaired seats, for example.
This has proven to be a better solution overall. In addition, we added the hc_no (hold code number) element to the GetSeats methods to facilitate indicating special pools of seats in any seatmap rendering a developer might want to do.
A quick note to v11 developers--we discovered a problem with this functionality in the released version of the web api and a hotfix has been posted in TASK under the Version Upgrades and Patches project, in the v11 Post v11.0.3 Hot Fixes solution.