There is one problem every ticketing system developer has to face at some point – a question of how to store the seating data. Seatmap.pro is no exception. We have spent quite some time choosing the best storage options for the seating charts.
Usually, the seats in ticketing systems are divided into:
- General Admission (GA) – no-seating or free-range venue sections
- Assigned seats (with section, row and a seat itself written on the ticket)
The generalization of data is a common path for developers to choose. This way, we are describing the most complex layer and try to squeeze everything else left into it. Taking the example of venues, the most frequently used model is SRS – a system where data is put into three layers – Section/Row/Seat. SRS is used most commonly for concert halls and stadiums, as this model allows us to identify each taken seat individually. Of course, there are more options of systems to choose from. For instance, those that reflect the features of a taken venue – a great example here would be adding the fourth layer with the Entrance name for bigger arenas.
If we are to talk about smaller event venues and clubs, the seating schema can vastly vary from the usual perspective. There can be other floors; the zones can be mapped out using different criteria. Besides, clubs can sell tickets for seats at tables as:
- A table sold as a single seat
- A table with free-range individual seats
- A table with each chair assigned
In this case, each object (the same table, for instance) can be described as a one-row section or the rows of one section. Anyway, it is usually enough to have a three-layer mapping system to describe the objects in a club.
Restrictions
Generally speaking, we can describe almost any venue using a system containing three layers. There might be exceptions to this rule, but usually the problem of those gets solved by adding an extra field in the description (see the example of stadium Entrance names above), or empty objects (describing a table at the club as a section or as a row).
More severe problems, however, may occur when transferring the venue data and selling the tickets through third-party platforms with the use of API. Integration issues for the systems selling the tickets through the API may occur from the very first steps of object mapping. It is undoubtedly that the venue will be the same for all the systems. Still, the differences in notation may become a problematic point.
GoS as universal formatting
We at Seatmap.pro went through an array of options before finding a universal format of storing and transmitting venue data – GroupOfSeats (GoS). The notion of GoS can imply any combination of seats or GA zones. SRS notation that we have already discussed above can be described as following using GoS:
The types of seat groups can also be expanded.
This is an example of a club notation:
Now we store all the seating data of Seatmap.pro in GoS. Of course, we still support SRS for backward compatibility.
GoS, however, allows us to integrate into any ticketing system smoothly.
Which seating data storage system are you currently using? Feel free to share your experience in the comments below.
