additional/modified fields/descriptions for Buildings table in db

[stevedahlberg]

additional/modified fields for Buildings table in db:

[make clear that "description" is both historical and architectural description - or, break out the two kinds of descriptions into different fields?] Here are some architectural descriptions to give an idea of what I'm talking about and whether it's worth it to break architectural description out from general short historical description:

930-932-934 Massachusetts. (1972) Non-contributing
This modern two-story commercial structure with some traits of the Brutalism style. There is a recessed central entry flanked by two storefronts, which are divided by full height brick columns. A wide, flat overhanging canopy with concrete panels extends the width of the two storefronts, each of which have their own entry doors. The second story features a continuous band (except for the brick columns) of dark, fixed sash windows, set within vertical concrete panels.

928 Massachusetts, Commercial Hotel. (c. 1878) Contributing
A three-story Late Victorian example of a two-part commercial block building. The painted brick upper stories each have three 2/2 double-hung windows. The second story windows have semi-circular arches, while the third story have segmental arches. The projecting cornice has corbelled brick brackets. There is a recessed entry on the north, with full-height display windows and free-standing cast iron columns.

715 Massachusetts, Anderson Building. (c. 1866; altered c. 1919) Contributing
This two-part commercial block building has simple geometric detailing typical of Early Twentieth Century Commercial buildings. The hard-fired red and multi-colored brick facade has two pairs of 1/1 double hung windows with raised brick header sills on the second story. The lintel is comprised of vertical brick stretchers. A large rectangular panel is above, formed by a raised course of brick headers. Centered within is a stone plaque with the name "ANDERSON". The cornice area has three courses of projecting bricks. The stepped parapet roof has stone coping. The storefront has a recessed centered entry front flanked by large display windows with brick bulkheads, steel lintels, and three large transom windows above. There is a secondary entry door to the upper level on the north. There is a vacant lot to the north, and the north side of the building has been covered with stucco.

Current/Common name: [text label for UI for "name"]

-------- dates related to buildings -----------------

Construction date: [construction, rebuild, and renovation dates versus start/end fields - how to handle? Break out? Just use start/end in db and use code to present info as [construction, rebuild, and renovation dates in UI? ] MORE:

Also, How to handle exact vs circa dates?

FWIW, the National Register of Historic places (several of our buildings are on it or nominated to be on it) tends to use this nomenclature: "c." for circa, and "xx" as wildcards. Uses lone date or decade (1960;s) for construction date (possibly with c. for circa), then the following other identifiers for dates: altered, rehabilitated, addition (in that order of frequency). Here are some typical entries:

805-807 Massachusetts. (c. 1860s; altered c. 1930s)
842 Massachusetts. (c. 1870; rehabilitated 199xx)
804 Massachusetts, Ridenour & Baker Store/Barteldes Seed Co. Building. (c. 1865; addition 1871, 1905)
844-846 Massachusetts. (c. 1888; altered c. 1955; rehabilitated 199x)
845-847 Massachusetts. (c. 1879; altered c. 1930s)
901-905 Massachusetts. (c. 1807; 1911; altered 1971)

[ruralocity]

I can see why we'd need to at least be able to provide a circa date. I'm storing years as integers right now if for no other reason than to sort chronologically but maybe I can find some other means of keeping both.

[stevedahlberg]

Regarding the Description field, this could already be broken out into several categorical description fields. For now I'm doing this manually by using the following "template":

Right now I've been using these labels in the single Description field for Buildings table entries:

Built:

Address:

Also Known As:

Historical Summary:

Architectural Description:

Sources:

[ruralocity]

I'm apt to think that sources is its own table, and everything could have a source. An item like a building, with multiple fields like this, could have multiple sources.

Also, looking at some of the examples you've added, I wonder if we need something like a "notable date" class to collect more than just a building's lifespan. We've got lots of alteration dates (esp. for the officially historical stuff) but other classes might need these as well--for example if an existence were remodeled on the interior, we might want to know when that happened.

Thoughts?

[stevedahlberg]

Great idea on the table for Sources - that's exactly right. In thinking about notable dates, the main thing I'm grappling with right now is the issue of how to handle when the footprint of a building changes to assimilate a neighboring building at a certain date in time, yet isn't really a new building (as in it didn't burn down or get demolished and get rebuilt). But, what happens is that the postal address range for that building expands and another Building ends. I talked about this some in most recent email to you.

[ruralocity]

I've got a crude initial setup for sources--just a text area to paste in the info. No editing/deleting yet. Buildings, locations, establishments, and existences can all have sources added.

[stevedahlberg]

Excellent. Don't forget to port to admin gem for Buildings, Establishments, Existences tables along with other recent changes for Existence editing when you do that update.

Once editing is available in both places, I'll bust out the source info from where I've been adding it in the Building Description and try to add a few in Establishments and Existences as well.

[ruralocity]

Looks like the admin_assistant gem can't handle the special model/table type I'm using for sources, so by proxy it won't work for comments or images eventually, either. We've got a couple of options:

• continue to build in the needed controls in the main interface.
• use one of the other admin panel gems available. The most full-featured can be tried out at http://activeadmin.info. It's nice, but has a lot of dependencies I'm not certain about.
• build our own admin panel.

Otherwise, I think we're good on this for now, right? We decided to stick with one description field for now if I recall correctly.

[stevedahlberg]

Hmm, seems hard for me to envision operating and troubleshooting without some sort of table view into the db to see all the fields (not just ones typically revealed in a data entry screen). It was the only way to distinguish multiple Eldridge buildings, intially, for example, or to troubleshoot oddball behavior by actually seeing contents of indexed ID fields, etc.

Good I think on overall issue, not sure how to proceed on the admin view issue. Mainly itching to start entering more Establishments and many Existences for them and a couple more Buildings from earlier/later points in time at same location plus a couple expansions but reticent until am able to specify footprints for Buildings and Existences in terms of multiple locations (other thread) since that info is typically handy at the time and harder to go back through and dig it up again, But, will play by ear

[stevedahlberg]

May want to add a second description field for the short summary that would accompany a block, building or business view.