Automating Omeka Deployment with Capistrano

April 20th, 2010 § 0 Wayne Graham

If you’ve done much web development, you’ll know that deploying applications can be a real pain. Typically you get some code (like Omeka), FTP it to your server, run the install, then go grab some plugins and themes and FTP them to your server. If you’re a bit more sophisticated, you may have put this in to an source code management (SCM) system like git, mercurial, or subversion, which then changes your workflow to editing on your local machine, committing the changes to your SCM, logging on to the command line interface for your server, running an update on the code, praying nothing breaks; if it does, you then try to roll back to a working version (you remembered to run svn info on the code before updating so you know what number to go back to). Even if everything goes swimmingly, that’s a lot of steps and way more applications than I like to fool with, and since it’s essentially doing the same thing over and over again, wouldn’t it be nice to automate this process? » Read the rest of this entry «

Omeka Timeline Plugin

April 14th, 2010 § 0 Wayne Graham

As part of our ongoing efforts on our Neatline grant, we needed to include a way of displaying temporal information and interacting with other data stored in Omeka. Just about the time we were starting to write this code, CHNM announced their Plugin Rush which pays an honorarium to give folks some incentive to pitch in and develop a plugin or two. Since we were going to develop the plugin anyway, we’re donating this back to the Omeka project, but we thought this might be a good opportunity to talk a little more about the development cycle for Omeka plugins, and hopefully inspire others to get involved. » Read the rest of this entry «

Scholars’ Lab Newsletter

April 6th, 2010 § 0 Ronda Grizzle

We’re pleased to announce that the inaugural issue of our monthly newsletter is now available for download. The newsletter will highlight projects currently in progress in the Scholars’ Lab, report on professional activities of the Scholars’ Lab staff, and list monthly events. If you have suggestions for projects that you’d like to see highlighted in future newsletters, please email me at rag9b@virginia.edu.

Scholars’ Lab News for April 2010 (PDF version)

Scholars’ Lab News April 2010 (text-only version)

Mr. Voronoi, meet the US state boundaries

March 25th, 2010 § 0 Kelly Johnston

In the Scholars’ Lab we are working with remarkably detailed datasets showing changes to US political boundaries over time.  We’ve all been fascinated with visualizations where the familiar outlines of the US states emerge from thousands of boundary changes to their underlying counties over the last few hundred years.  Did you know Virginia once spanned from the Atlantic Ocean to the Mississippi River?

Virginia

We’re developing a new web-based tool for visualizing these historic boundary changes and it’s nearly ready for prime time.  We’ll announce the beta release here soon.

So with the knowledge that US state boundaries have already been subject to drastic change over time, let’s have some fun with geographic information systems to visualize drastic mathematically-induced changes to those familiar US state boundaries.

For our experiment, let’s keep all our current state capital cities right where they are since they are laden with the necessary infrastructure of government.  But we’ll move the state boundary lines Voronoi-style so anywhere you travel in each of our new states you’ll be closer to the state capital than any other state capital.  In other words, when you’re standing anywhere inside our newly outlined Virginia, you will always be closer to the Virginia state capital, Richmond, than any other state capital.  That seems very efficient.  Let’s have a look.

US States with capitals

Here’s that familiar grade-school wall map of the lower 48 US states and their capital cities.   Now let’s tweak the map with GIS software to reconfigure the states, Voronoi-style.

US Voronoi states with capitals

Wow, what a difference Voronoi makes.

Let’s measure just how much the states have changed in our new layout.   In absolute terms, Utah and New Mexico make the biggest land grabs while Texas and California lose the most real estate.  But as a percentage of their current area, Rhode Island is the big winner ballooning in size by over 240% while Massachusetts shrinks 60%.

To visualize the state-by-state changes, Todd Burks from neighboring Clemons Library overlayed the two maps.

Intrigued?  Read more about Voronoi and Thiessen polygon GIS techniques.

Digital Therapy: Cesaire and Hawthorne

February 18th, 2010 § 0

Graduate students Alex Gil and Ryan Cordell present their recent work on digital editions of works by Nathaniel Hawthorne and Aimé Césaire.

 

More on Pandora: genres, genomes, and musical taste…

February 15th, 2010 § 2 Jason Kirby

Hello. In my last blog, I began my discussion of Pandora.com, the streaming audio website which offers a new kind of web radio to listeners. Enter a “seed” song into Pandora’s search engine, and the site will create a streaming “station” composed of songs that resemble your seed song. This process is powered by the Music Genome Project, a massive research endeavor which began in the early 2000s and is based out of the company’s Oakland, California headquarters.

How is Pandora’s song-recommendation engine different than web radio platforms that came before it? Well, the majority of other online radio stations, such as last.fm, operate off a system called collaborative filtering. What is collaborative filtering? In layperson’s terms, collaborative filtering involves matching one user’s taste to another’s (or a series of other people). On a site like last.fm, over time a user amasses a playlist of songs they’ve expressed a preference for—a sort of musical taste profile. Last.fm’s search tools automatically identify other users with whom your tastes seem to overlap, and uses this information to power “radio” stations you can stream on the site. The process is pretty simple, and based on personal intuition and the data existing users have already entered into the system. Collaborative filtering powers aspects of many media websites, such as Amazon.com’s personal recommendation feature for shoppers.

» Read the rest of this entry «

Lisa Rosner: the Anatomy Murders

February 10th, 2010 § 1

Up the close
And down the stair
Visualizing the worlds
Of Burke and Hare

 

The 1907 Massie map of Albemarle Co.

January 27th, 2010 § 0 Dave Richardson

The 1907 Massie Map of Albemarle Co., VA

The 1907 Massie Map of Albemarle Co., VA

While going through our archives of scanned maps, we recently ran across a copy of Frank A. Massie’s 1907 “A new and historical map of Albemarle County, Virginia” [Special Collections, University of Virginia Library], commonly referred to as the Massie map, which contains a wealth of detailed historical information for the county in which the University of Virginia sits.

» Read the rest of this entry «

Calculating county-to-county distances with GIS

January 7th, 2010 § 2 Kelly Johnston

In the Scholars’ Lab we recently worked with a researcher whose study areas focused on several groups of US counties. Of interest was the distance from every county within a group to every other county in that same group. We used geographic information systems (GIS) software to calculate these distances.

» Read the rest of this entry «

Large Files and Omeka

December 16th, 2009 § 0 Wayne Graham

This issue came up for a friend of the Scholars’ Lab today on Twitter, but it’s hard to answer in 140 characters. It’s a question about allowing for larger file sizes in Omeka and there are a few ways to handle this. (Because we want our new blog to be a combination of thoughtful essays on digital scholarship and quick answers to real-world technical problems, I thought I’d post here.)

Since Omeka runs on PHP, this is actually a PHP configuration issue and not something you can currently tweak in Omeka. Basically, you just need to tell PHP to allow larger files sizes that are larger than the default. A very easy way to do this is to edit the .htaccess file that Omeka ships with along the following lines:

php_value upload_max_filesize 20971520
php_value post_max_size 20971520

I’ll note here that doing things this way only affects your Omeka project. Another way to go about this is to add the above to the Apache configuration that defines from where Omeka should be served. For example:


<VirtualHost *:80>

ServerName www.coolomeka.org
DocumentRoot /var/www/omeka

<Directory "/var/www/omeka">
    Options FollwSymLinks
    AllowOverride All
    Order allow,deny
    Allow from all
</Directory>

    ErrorLog logs/omeka_error_log
    TransferLog logs/omeka_transfer_log

    php_value upload_max_filesize 20M
    php_value post_max_size 20M
</VirtualHost>

Lastly, you can edit the php.ini file (usually in /etc/php.ini or /etc/php5/apache2/php.ini). Just do a search in the file and change the following settings:

  memory_limit = 32M
  post_max_size = 20M
  upload_max_size = 20M

You typically don’t need to reload Apache (as long as you did not edit the Apache configuration file) to get these settings to work.

For more info on this, check out these resources

« Older Entries

Newer Entries »