Template talk:Stadium

From BR Bullpen

This is an attempt to make an infobox template for stadiums including a shot of the park from overhead. I am collecting the info on many of these and want to start adding it all. See Haymarket Park. Feedback would be appreciated about what info to include, and how.

Which others belong?

| broke_ground = | renovated = | expanded = | closed = | demolished = | owner = | operator = | construction_cost = | architect = | former_names =

--Shawn 17:40, 4 September 2006 (EDT)

Could we change the table format to match the other "infoboxes" (i.e. fixed width, a slight offset, etc. shown at the right).

{{{name}}}

{{{coordinates}}}

Address: {{{address}}}
Capacity: {{{capacity}}}
Opened: {{{construction}}}
Surface: {{{surface}}}
Header
Also known as: {{{names}}}
Current resident(s): {{{resident}}}
Field dimensions: {{{field}}}

What descriptors could be included:

  • Name
  • Alternate names and nicknames
  • Image

Facility Information[edit]

  • address/location: the address of the stadium on two lines or the location of the stadium if the address is not available.
    • It would be mutually exclusive and require parser functions to maintain seperate Address: and Location: headers.
  • opened: date opened (not only for baseball)
  • closed: date closed (not only for baseball)
  • broke_ground: date(s) broke ground
  • renovated: date(s) renovated
  • expanded: date(s) expanded
  • demolished: date demolished
  • first_game: first baseball game
  • first_night_game: first night baseball game
  • last_game: last baseball game
  • owner: owner of stadium, only list the most recent with as of date or list all under a subheader.
  • architect: architect of stadium
  • operator: operator of stadium, only list the most recent with as of date or list all under a subheader.
  • construction_cost: original construction cost of stadium
  • former_names: list all under a subheader?

Tenants[edit]

  • list of tenants with leagues and years

Facility Statistics[edit]

  • style: open-air, dome, retractable roof, etc.
  • construction: wooden, concrete/steel, etc.
  • surface: grass, artifical turf (possibly type of grass/turf)
  • capacity: only list the most recent with as of date or list all under a subheader.
    • Expanded seating could be listed in parenthesis. Using Hawks Field at Haymarket Park as an example: 4,500 (8,000 with berm seating)
  • (field) dimensions: only list the most recent with as of date or list all under a subheader; which should be listed?
    • I think that the lines, alleys, and center field are a must, while the backstop could be listed as well.
  • (outfield) wall heights: only list the most recent with as of date or list all under a subheader; which should be listed?

For the larger decriptions (field dimensions, capacity, etc.) may be able to be hidden, see here for an example. However, it may require another extension as direct copying the template doesn't seem to work.

Most descriptors should be conditionally hidden.

I would move the google maps image out of the template and onto the main page in a section called location or something like that where points of interest (mainly mass transit locations or nearby places) could be added to the map. For example here is the Tokyo Dome: <googlemap width=400 height=400 lat="35.704966" lon="139.752735" zoom="16" controls="small" type="satellite"> 35.705591,139.751810,Tokyo Dome 35.707362,139.751383,Korakuen Station
Marunouchi line 35.702021,139.753454,Suidobashi Station
JR Chou line 35.703947,139.754988,Suidobashi Station
Toei Mita line 35.706687,139.753389,LaQua 35.704369,139.754291,Tokyo Dome City 35.705524,139.749033,Koishikawa-Korakuen Park </googlemap>

However we are going to have two problems. The first is that the parserfunction IF is broken and has not been fixed yet, so conditional descriptions cannot be used. Second is that we are unable to scale images, which means that adding images for the stadiums should be held off until that feature is added. --MichaelEng 00:20, 7 September 2006 (EDT)

Thanks for your comments. Yes, I will standardize the table format to match the others. I originally wanted to do the conditional parser thing, but, as you've noted, it's broken at the present time. But won't it be overkill to include so much info in the infobox? Those are all the choices from the wikipedia website stadium template that you mentioned above.

I do disagree about the aerial view however. I think the order of preference should be reversed, as the aerial view is a)available instantly - no need to search out images, b) gives the best idea of the shape of the playing surface and the context of the stadium in its landscape, c) we won't have to wait for the image scaling to start putting these infoboxes up, and d) the aerial view also usefully provides quick directions for a user to get to a stadium, something that most teams bury deep in their web-sites. The points of interest is a great idea too, I didn't know that was possible. Thanks. --Shawn 02:08, 7 September 2006 (EDT)

Having the clean aerial view over the external view makes sense, but not over a good interior view. An overhead view with a bunch of pins would not give a good sense of the stadium. Some of the descriptors would be overkill (style for instance), but I listed all the ones that I could come up with to get some ideas. Also, Template:Qif can be used in place of if for the meantime. --MichaelEng 23:42, 17 September 2006 (EDT)