Enhanced Venues

[game7]

Sportified currently uses a Venue entity to represent a location where an event can take place. This is currently a very simple entity that has just a name and a short_name. There are many scenarios where a more structured location domain would be beneficial:

• Multiple venues that share a common physical address can be better organized through a location-facility (parent-child) structure
• Some sports like hockey take place in arenas that contains multiple playing surfaces as well as multiple locker rooms for which teams are to be assigned. Grouping these facilities (surfaces, locker rooms) under a common location (arena) facilitates assignment and also can be used to ensure that only related facilities of a common location are used together
• For the purpose of digital signage #52 we would require the ability to have a common dashboard for all events occurring at a common physical location. Structuring playing services and/or meeting rooms under a common location entity would facilitate this feature

[game7]

@leaguetek01 would like to start some conversation on this card. We currently have a venue class that we use to represent the location for an event. The objective of this card is to extend this design to handle additional scenarios... including but not limited to:

• Locations (with an address) that have multiple fields/courts/rinks where games and/or events can take place.
  • When maintaining games/events the location will be selected first, then a secondary dropdown will enable the selection of the specific playing surface where the event will take place ("playing surface" is an abstract term for where a game would occur, but we should also consider that generic events might take place in sub-locations that are categorically-different (rooms, studios, etc).
• Additional facilities (belonging to a location) or resources (not belonging to a location) that can be defined and associated with games and/or events.
  • For hockey there would be locker rooms (facilities) that each team would be assigned to
  • For all sports there might be resources that would be assigned to a game/event, in which case a resource is a might a certain piece of equipment or perhaps even a human resource that will serve some role at said event

Thoughts?

[leaguetek01]

Today we create separate locations. IE DM1, DM2. And schedule against those. Keeping the simple model, is there an advantage to tracking the lower level detail and breaking out by venue?
Thinking if other activities. Rooms is intriguing, but is it just as simple to create multiple locations?

On Feb 2, 2016, at 11:24 PM, game7 notifications@github.com wrote:

@leaguetek01 would like to start some conversation on this card. We currently have a venue class that we use to represent the location for an event. The objective of this card is to extend this design to handle additional scenarios... including but not limited to:

Locations (with an address) that have multiple fields/courts/rinks where games and/or events can take place. When maintaining games/events the location will be selected first, then a secondary dropdown will enable the selection of the specific playing surface where the event will take place ("playing surface" is an abstract term for where a game would occur, but we should also consider that generic events might take place in sub-locations that are categorically-different (rooms, studios, etc). Additional facilities (belonging to a location) or resources (not belonging to a location) that can be defined and associated with games and/or events. For hockey there would be locker rooms (facilities) that each team would be assigned to For all sports there might be resources that would be assigned to a game/event, in which case a resource is a might a certain piece of equipment or perhaps even a human resource that will serve some role at said event Thoughts?

— Reply to this email directly or view it on GitHub.

[game7]

For hockey it is important to be able to show a combined schedule for multiple playing surfaces as most modern ice arenas have multiple sheets of ice. If, for example, we were to support a city-wide hockey league there would be multiple arenas each with 1-3 sheets of ice and 4 locker rooms per sheet (4-12 total), so in this case it would be much more convenient to first choose a location and then have a smaller, scoped set of options for playing surface and team locker room.

I think there's actually a pretty simple compromise. Each event and/or game will require a location... and if that location happens to have sub-locations the UI will require one to be selected... otherwise location is just fine. This will allow the simpletons to stay simple and the structured to have more-structure.

As for "sub locations", I'm thinking that these will be known as facilities. Each location may optionally have n-number of facilities and each facility shall be designated as a playing surface or a locker room. When scheduling a game the game itself will require a location and if that location has playing surfaces maintained shall also require a playing surface. If that location has locker rooms maintained then there will be the option for each team participating in that game to be assigned a locker room.

This should provide a very explicit structure that will meet current needs yet also leave the door open for future facility types that might be used in specific scenarios (meeting rooms, studios, etc)