Hydrologists are used to jumping through hoops to access data. But it doesn’t have to be that way all the time! In a single semester, the stellar Tecnológico de Monterrey (ITESM) WaterFront Project Team developed software that will easily display monthly summaries of streamflow at multiple USGS stream gages. As a bonus, we can quickly view flow duration curves for the same gages.

Thanks to the ITESM team’s expertise and hard work, this software will be used to generate Extension hydrology reports for the Platte River in Nebraska. Platte River streamflows are critical for agricultural production and for important wildlife habitat in Nebraska.

The UNL GaugeCam Team, along with Doug Hallum at the West Central Research, Education and Extension Center, presented this challenge to the capstone student group in the Departamento de Computación and Escuela de Ingeniería y Ciencias. ITESM students, led by Professor Elizabeth López Ramos, tackled this project in two phases.

PHASE 1: Gather list of client requirements and develop proposal.

• Requirement gathering and analysis based on meetings with client.
• Research and brainstorm to devise innovative and practical solutions.
• Create a concise proposal outlining solutions, timeline, budget, and benefits for the client.
• Present refined proposal to the client, highlighting alignment with requirements and receiving feedback.

PHASE 2: Build out the software based on the accepted proposal.

• Construct platform, including features and functionality described in the proposal.
• Test software functionality, performance, and security to meet client requirements and industry standards.
• Present the software to the client for feedback and iterate to meet expectations and requirements.
• Deliver a functional Windows installer and documentation to the client.

Just like real world situations, we (UNL) came into this project with many ideas for the team. In other words, we gave them the very real challenge of (1) setting realistic expectations for the client, and (2) helping the client know what they actually want for a final product. And what we got was a streamlined, professional Windows application and good documentation.

Check out the animation below to see some of the WaterFront features.

• Select a range of months to summarize
• Display monthly statistics by hovering mouse
• Display additional USGS gage sites
• Show flow-duration curves
• Download graphics and data

We are truly grateful to the ITESM WaterFront Team for their dedication to this project.

• Joel Fernando Santillán Santana
• Jorge Luis Salgado Ledezma
• Milton Eduardo Barroso Ramírez
• Miriam Paulina Palomera Curiel
• José Ricardo Vanegas Castillo

Special thanks also to Professor Elizabeth López Ramos and Professor Gildardo Sánchez Ante for a wonderful experience working with your class. We hope we can continue working together!

There are six key components to be concerned about when setting up the GaugeCam octagon calibration target in the field.

1. The facet lengths of the octagon must be the exact same length.
2. The background in the stream must be mounted orthogonal to the water surface.
3. The camera should be mounted as directly in front of the background as possible.
4. Field measurements must be made from the upper left vertex to the water level.
5. The size of the octagon (in pixels) in the image must be large enough to be detected by the GRIME2 search algorithm.
6. The thickness (in pixels) of the black border around the octagon must be large enough to be detected.

As you might guess, based on the bold text above, we are focusing on the last two items in this blog post, which are both related to the size of the octagon in images to achieve successful calibration for water level measurement.

To provide guidelines for the octagon dimensions (in pixels) required for successful calibration, we used imagery from the Kearney Outdoor Learning Area (KOLA). The image used was about 1MB when stored as a .jpg, as captured with a Reconyx trail camera.

In this simple test we resampled the images to reduce resolution. As the resolution was reduced, the size of the octagon was reduced. In other words, there were fewer pixels displayed across the width and facet lengths of the octagon. Similarly, the black border around the octagon became more pixelated.

The animation above shows when the octagon search algorithm began to break down as the resolution of the image is decreased. The decrease is represented by the scale annotation in the image. The scale value shown is the size of the image in percentage of the original image size (2304 x 1295 pixels, including the black strips at top and bottom of the image). Major failures of the octagon find and calibration started to occur at less than 60% of the original image resolution. The horizontal width of the blue area in the octagon target is 137 pixels in the 60% image.

Below is a table showing the desired width of the black border around the octagon. The suggested width for robust detection is 15 pixels, although the 60% image had a width of only about 11 pixels. The width of the black border can be measured in your images using the measurement tool in GRIME2.

The major takeaway here is that, whatever the size of the images captured, the current GRIME2 octagon search and calibration algorithm should be robust for images where the blue part of the octagon is at least 137 pixels wide and the width of the black border is at very minimum 11 pixels wide but preferably at least 15 pixels wide. These values are based on a very simple test with an ideal image. Greater sizes (in pixels) of the octagon target are generally going to be preferable, and the overall performance of the system is still highly dependent on image scene quality (fewer shadows, glare, etc.) and proper installation of the target background in the stream.