search

burroughsapp / burroughs

Burroughs is an historical database of places in Lawrence, Kansas with a time-machine experience for the user dialing back exterior and interior views of city blocks, buildings, and businesses through the years, decades, and centuries, with building and business histories as well as public discussion walls tied to each physical location.
0 stars 1 forks source link

Image content - high priority #14

Open stevedahlberg opened 11 years ago

stevedahlberg commented 11 years ago

As we talked about on the phone, and tracking along similar to the Sources model - the ability to upload images and tag (or trickle up/out to) most other objects and where they are able to be multiply associated and also to locate them in time, similar to Buildings and Existences.

For example, some images may just be a block shot and used to show one or both sides of a block (might need to be able to tag with one or both sides of the block at entry, since only the user will know from looking if the photo reliably shows both sides of a block or just one side). We will have other images for both Buildings and Existences that are derived from block shots where we've selected a bit of the block shot on either side of the target building and watermarked it down some in terms of light/contrast to emphasize the target - these could be used for both the building in questions and any associated Existences in the time period of that image.

Also note the incorporation of the code module Aaron found for managing image uploads.

To me, this is a critical step towards getting something that can then allow testing the "time machine" functionality - being able to query for image (and possibly descriptive text, if we don't just let the entire history of a Building or Existence be in a single text description for each instance rather than location key items of that in time as well as the visual content - probably need to discuss pros and cons of that single issue) based on a certain Location and time and viewing mode (Block/Building/Business) ...

stevedahlberg commented 11 years ago

UPDATE:

  1. After some thought I believe the way we need to integrate image content into the existing project is very similar to what we've done with buildings and existences - I believe there will be a many-to-many relationship between image content and location and that it makes sense to build another model and associated class / junction table "content_location" that has a one to many relationship with both a new "content" table and the existing Locations table. This way, a single image can be associated with multiple locations (as in a block or a building with a footprint comprised of more than one location) and conversely a single location can be associated with several different images.
  2. Image categories: Rather than using a Boolean for exterior facade versus interior views, it seems more flexible and scalable if we create two category lookup tables for content and use categories for classifying content types in two ways:

a. "View" category. Could start with only two entries in this lookup table - "facade" and "interior". Then, if we every need to use more kinds of views, whether they be other kinds of exterior or interior or alley or aerial etc views, we just drop another category in the table. I assume the lookups would actual happen with record ID's.

b. "Content_type" category. It will be useful to know if the content in question is an image, an audio clip, or a video clip. The Content_type lookup table could start with those three entries.

It might also be useful to know even for audio if it's interior (sewing machines humming, printing press clanking away) or exterior (horse and wagon sounds, antique car horns tooting) and probably the same for a video clip. But then, we'd have to decide how to handle an edited oral history from an interview that describes both the outside and inside aspects of a building or business). Could just create as many lookup tables as we need, but the alternative would be to unflatten the Content table and break it out into three tables for the various kinds of media (image, video, audio) so that they each could have their own table - it might provide more control in working with specific kinds of content but then each one of those would need a corresponding junction table ("image_location", "audio_location", and "video_location", etc) so not sure it's worth trading away the simplicity of throwing all content into a single Content table with a single junction table "content_location" at least for now when it won't be multi-media rich.