« May 2010 | Main | July 2010 »

June 28, 2010

Creating a UMBS Trails, roads and basemap

Here are the files used to create the roads/trails portion of this map:

MI Geographic Framework Transportation (v9b) (Cheboygan)
Projected coordinate system name: NAD_1983_Hotine_Oblique_Mercator_Azimuth_Natural_Origin
Geographic coordinate system name: GCS_North_American_1983

I've been working on creating a basemap for UMBS. The working product is here.

And here are the layers I've employed thus far:

IFMAP/GAP Lower Peninsula Land Cover (Download)
Projected coordinate system name: Michigan GeoRef
Geographic coordinate system name: GCS_North_American_1983

DEQ Final Wetlands Inventory (Download)
Projected coordinate system name: Michigan GeoRef
Geographic coordinate system name: GCS_North_American_1983

DEM (converted to 30 ft interval contours && to hillshade)(Download)
Projected coordinate system name: NAD_1983_Hotine_Oblique_Mercator_Azimuth_Natural_Origin
Geographic coordinate system name: GCS_North_American_1983

Hydrology (Download)
Projected coordinate system name: NAD_1983_Hotine_Oblique_Mercator_Azimuth_Natural_Origin
Geographic coordinate system name: GCS_North_American_1983

Good link about taking a raster DEM to contour lines:

Posted by kkwaiser at 02:24 PM | Comments (0)

June 23, 2010

Limnology course data

Troy Keller, 2010's Limnology instructor, stopped by with the idea of collaborating to archive data collected by his students this summer. Here are some notes:

1 other, I believe

secchi depth
plankton (zoo)
physio-chemical - tp, tn, (pH, DO, temp profile)
benthic grab sample (dredge bottom for inverts)

Classes on Tues and Thursday. Data collection will commence on Tues, June 29th on Douglas Lake. GPS locations will be taken at each point, several points per lake.

One option is to create a project for the class and put their work (abstract, methods, data, personnel) under there. Will need to figure out how to organize the data (e.g., by lake) and how/whether to keep it separate from non-class data.

Posted by kkwaiser at 05:12 PM | Comments (0)

June 22, 2010

Drupal permissions


Need the ability to restrict access to specific (data) files based upon the user role but allow access to the metadata. The file and metadata are part of the same content type.

Ideally, when a file is uploaded the user would select which users can access the data.

Node Access will allow to a node based upon user role. Sledgehammer instead of scalpel as it blocks access to entire node and not just the filefield.

Content Permissions - "set field level permissions for CCK field." After enabling the module go to admin/user/permissions to set view and edit features for fields.

A recommended solution with .htaccess. Specific to directory though meaning would need separate directory for data sets not to be release.

A really great discussion on different methods.

Content Access module

Access Control List

Posted by kkwaiser at 10:55 AM | Comments (0)

June 17, 2010

Multiple GMap sizes in Views

The size of the GMap window can be set in several ways. The first is at admin/settings/gmap under Default Width and Height.

When you create a View which displays a GMap these defaults are inherited. This post explains how to override the defaults. Just paste the mentioned code into the Style Options (click the little wheel image) when you've set the Style to Gmap . Note, you can click override dafault to keep the other Displays at the default setting.

Note: see my comment with modified code.

Posted by kkwaiser at 10:15 AM | Comments (0)

June 10, 2010

Insert module and absolute vs relative paths

When using the Insert module to insert images into a text field in drupal, the default is to use absolute file paths. In order to use relative image file paths (e.g., /sites/default/files/Firefox_wallpaper_0.png) you need to update settings.php with this line.

Posted by kkwaiser at 12:52 PM | Comments (0)

June 09, 2010

CCK Autocomplete

As I've been evaluating what a sensor content type would look like I've realized that a "sensor type" field (e.g., fluorometer) will be necessary. However, I cannot possibly establish a complete list of sensor types a priori which means I need to make the field a taxonomic vocabulary or use the Autocomplete Widgets for CCK Text and Number module.

I'm pretty sure I'm going to go with the latter option because I don't think I would use a vocabulary outside of this content type and the module maintainer plans to upgrade to D7.

Posted by kkwaiser at 04:37 PM | Comments (0)

Building a "Sensor" Content Type

I've been toying with the idea of creating a "Sensor" content type for the Drupal site. As of now, the fields would mimic what is generally found on a sensor spec sheet but the Alliance for Coastal Technologies also has an implementation worth copying.

Once a sensor is created, then research projects, research sites and data files (or data sets?) that use a sensor could (node) reference it. There are several reasons to pursue this idea:

- A GMap mash-up could easily show where we have sensors deployed
- A dynamic list of the sensors, with their particulars, could be easily generated.
- At some point, the sensor metadata could be included in the overall metadata sheet that accompanies a data set and data file.

A use case example would be a researcher who wants to know if we are collecting a particular variable. A search of deployed sensors for that variable could indicate the general location, data sets and contact personnel.

Posted by kkwaiser at 04:24 PM | Comments (0)

June 07, 2010

NASA Data Requirements

A UM research scientist is submitting a proposal to NASA's Terrestrial Hydrology program to build and test snow sensors at the Station. Here is what I found in terms of data management requirements within the program:

(f) Meeting Geospatial Standards NASA pioneered the development of metadata and the accessibility and interoperability of space and Earth science data. When grants result in the development of data that NASA both identifies as geospatial and intends to distribute, then NASA awards will require that documentation (metadata) meet Federal Geographic Data Committee standards. NASA will assure that this documentation is electronically accessible to the Clearinghouse network (http://www.fgdc.gov/dataandservices/) and discoverable through Geospatial One Stop (http://www.GeoData.gov).

4.2 Data and Information Management
NASA’s space observation capabilities are a central part of the Agency’s contribution to Earth system science, along with the science information systems that compile and organize observations and related data for research purposes. The Earth Science Research Program has established a number of strategic principles for the development and deployment of its observing and information systems, recognizing the importance of providing active and informed stewardship for the large volume of data that are returned to Earth every day. The broad range of uses to which the data are put and the large and diverse user community require multiple temporal and spatial scales, emphasize the need for having a range of data products, and place stringent requirements on NASA for its data processing, archival, and data dissemination activities. These products and services will be variously useful to multiple classes of users, from sophisticated scientific users to other Government and private sector entities that use NASA’s information for policy and resource management decisions and including scientifically attentive members of the public who utilize data and information for general information and recreation.

NASA’s data and information management activities are described in NASA’s 2003 Earth Science Strategy at http://nasascience.nasa.gov/about-us/science-strategy/past-strategy-documents/earth-science-enterprise-plans. Three program elements in the area of data and information management are included in this NRA, only one of which is being solicited this year. The active element is Earth System Data Records Uncertainty Analysis (Appendix A.32). This program, solicited for the first time this year, provides support for in-depth analysis of the properties of long-term data sets, with a focus on detecting systematic error, better quantifying error, and properly attributing uncertainty sources. A second focus is to resolve known issues of such data sets. Resultant tool development is a third focus of the program. The two not being solicited are Making Earth System data
records for Use in Research Environments (MEaSUREs) program (Appendix A.33); and the Advancing Collaborative Connections for Earth System Science (ACCESS) program (Appendix A.34).



Posted by kkwaiser at 09:42 AM | Comments (0)