As you may have seen in the most recent issue of the journal (SEP/OCT '06), Eric Nies wrote an article on "Taking the Search Out of Search and Rescue". We have received some funding for a pilot project to get this effort off the ground and develop the web interface (the support we received is for the Feather River watershed in CA but the idea is that the tools could be applied to other rivers). The basic premise is that we would have GPS coordinates for rapids or key landmarks along a run and that these could be projected on a map with links back to descriptions (Google maps comes to mind as one obvious way to do this and we have had a couple volunteers playing around with this). There would also be a companion piece that would include a printed map.

My question is do you think the way to start this is to just add lat/long as a field in the rapids database? Or do we need to think of a different way of organizing the information? If you are not familiar with the rapids database take a look at the descriptions for the following runs:
Upper Gauley
[www.americanwhitewater.org]
Moose
[www.americanwhitewater.org]
Upper Yough
[www.americanwhitewater.org]

I have never been a huge fan of this format with the run description followed by individual rapids (doesn't apply as well to some rivers--particularly in the West--where we don't have everything named and rapids are less discrete). But I'm not sure I have a better idea of how to organize the information.

I would appreciate any thoughts on what the interface should look like and anyone willing to volunteer with this is encouraged to join the team looking at this.

Thomas O'Keefe
Pacific Northwest Stewardship Director
American Whitewater
3537 NE 87th St.
Seattle, WA 98115

425-417-9012
okeefe@amwhitewater.org

Tom,

I share your hesitation on how best to incorporate GPS data. I do think that we will develop and tweak formats a lot in the future, so it will be good to gather data now in such a way that requires minimal reinput in the future.

I think that it is ok and good to add Lat and Long coordinates to the river rapids database for people who do use that system. If in the future we want to do something else with those coordinates, we already have them in database format. I do not think that should be the only way we accept GPS data.

On the Green River in Desolation Canyon,
[www.americanwhitewater.org]
Karen Hensley provided lat & Long. coordinates for a variety of locations of interest, canyons, bottoms, and rapids. The information is in text form, so it is easy to print it out and take it along on the river with you. The variables are also comma seperated so it can be imported into a database with minimal effort.

I think this text file method is probably best initially, partly because it may be much easier for the person doing the work. But I do not see this as conflicting with having GPS info in the rapids data base. If GPS text files are formatted properly we may be able to automatically import them into the rapids database if needed.

As far as utilizing GoogleMaps, in my most recent effort, I created googlemap links for the put-in and take-out on a section of Piru Creek.
[www.americanwhitewater.org] With coordinates in a database, this sort of think could be done more automatically, perhaps.

Paul Martzen

There are a couple of things to consider here.

First off, the lat / long data need to be very accurate, which would probably required collecting data with a GPS in the field. You won't get the required level of accuracy by extrapolating coordinates from maps. I've tested this extensively and found significant variation between map and GPS even when accounting for differences in datum, etc with a high degree if precision using GIS software. We wouldn't want to send rescue squads on a wild goose chase.

Second, I doubt that plotting points on Google maps would work since Google doesn't give much detail apart from major state and country roads. If you look at the Google maps of the Western States you'll find that a very small percentage of Forest Service and BLM roads are included, so they aren't to useful when you get out in the backcountry where most of our rivers are.

The idea of collecting lat long data on key river features is a good one, but I think it is probably a more complex task that what has been considered. Any GPS way points should be supplemented heavily with descriptions of topography, terrain and available access points, landmarks. etc If you need any volunteers to help out with this please let me know. I've got quite a bit of experience in GIS and land navigation.

Todd Hoffman

When you say that we won't get the required level of accuracy, what level of accuracy are you thinking is needed?

Paul,

If the idea is to potentially use the data for rescue purposes, I would say accuracy needs to be within 50 yards, especially for trying to locate individual rapids or access points on roadless runs. On a lot of the remote runs I've paddled in Idaho, it can be very difficult to locate particular roads or trails even for those familiar with the area. The Bruneu and Owhyee country would be a good example. There are old cattle trails and spur roads running all over the desert and many are poorly mapped, just getting close wouldn't be good enough.

Also image if a waypoint for a specific rapids was off by say a 1/4 mile, which would be about the margin of error you'd be working with by extrapolating lat and long from a map. Working your way a 1/4 mile up or down a vertically walled canyon like the Bruneau could be quite difficult.

Todd






pmartzen Wrote:
-------------------------------------------------------
> When you say that we won't get the required level
> of accuracy, what level of accuracy are you
> thinking is needed?

I have conducted some informal tests, by entering recent GPS readings from my etrex into google earth and into Topozone. Used readings from my back yard and from a recent Green River trip in Utah. Topozone and google earth both seem to show almost exactly the correct position. Locations appear to me to be within 30 feet or so of accuracy, which is the general accuracy of my etrex measurements. The same coordinates in Topozone and Google earth give very close to the same views. From a navigation standpoint the amount of error seems insignificant.

When we combine GPS information along with landmark and terrain descriptions, I think we have a very effective method of pinpointing locations.

Back to Tom's original question.

I think we should include lat and longitude inputs with rapid descriptions. Even if only some streamkeepers use rapid descriptions, those that do should have that easy ability. I use the edit rapids method of describing rapids on several of my rivers, and i would like to tie GPS coordinates to those rapids.

On the other hand, for some reaches it would be nicer to just paste a text file with a list of coordinates and locations. Would be nice if that text could be on a seperate page or tab rather than taking up space on the front page of a reach.

The Quality Control issue is an important one. I'm not sure of the best way to tackle it. The idea was to do a project with a high level of accuracy with the County Search and Rescue folks on the Feather. The one thing I would say on Google is that if you go to the satellite view you can get very high accuracy (I can see the raised vegetable beds in my back yard or individual rapids on my backyard runs) and you can easily get within 20-30 feet. I realize it's not this easy at every location--shading in canyons can prove a challenging and GPS does not work well when you don't have a good view of the satellites. On some rivers we have helicopter overflights with coordinates.

Thomas O'Keefe
Pacific Northwest Stewardship Director
American Whitewater
3537 NE 87th St.
Seattle, WA 98115

425-417-9012
okeefe@amwhitewater.org

Best would of course be to generate the data using GPS; I've done that for several Eastern streams, including the Gauley, Upper Yough, Moose (Lower and Bottom), and others. However, if all that users have are approximate coordinates obtained from Google or other satellite locations, those should be included--with a disclaimer ("lat/lon coordinates obtained from Google satellite"). If we can give S&R the location of a rapid within 50 yards, that's great! But if we get within 200 yards, that can often be enough to enable them to get to the scene quickly.

How do we do this? I don't care that much. Initially I thought adding a field to the Rapids database would be the way to go; however, many StreamTeamers don't use it for various reasons--so it may be better to simply add the info as a text list. We should be consistent, however; we should go with either a simple text or a separate field. If we don't reach a consensus on this issue using the Forum, this should be a topic for the next Cyber Committee meeting.

I do not see any conflict or inconsistency between entering GPS data via a text list or entering it into the rapids database. Both entry methods need to be able to smoothly fit into a GPS database.

When people submit a text list of GPS points, the data needs to be in an order and format that can be automatically imported into a spreadsheet/database. What needs to be discussed is the other data fields we want associated with the GPS data.

The few text lists that I have seen include 3 data fields: Lat, Long, and name of location. Adding GPS fields to the rapids feature associates the data with some additional fields: Lat, long, Name of location (rapid), Reach ID, Distance from put-in, difficulty, description, Photo ID, Video ID.

Having additional fields in the rapids feature does not create any inconsistency, especially if it is part of a relational database.

From a pragmatic standpoint, it could be a while before Ryan has time to add additional fields to the rapids feature, but people can be compiling GPS text lists or GPS spreadsheets/databases. If we can agree on a common template it will be much easier to import those text lists into a GPS database once we get around to creating one.