Cascade Route Wiki/Database

[jon]

Hi Folks,

 

In a different thread there has been a request for a cc.com route wiki. Funny thing is we already have something on the planning table. I was hoping to get some input on what you would like to see in a route wiki or database application. What kind of structure would you like, alphabetical, map based? Ideally how would you like photo handled? Should we make it permission based so that only people who have approval to edit it are allowed? Give us your thoughts.

[marc_leclerc]

A wiki would be an excellent idea... instead of alphebetical I would prefer having it broken into regions (Picket Range.. Slesse Group... stuff like that) to sort it all out. But im not against other ideas. Permission based is a somewhat good idea, but I doubt people would go and write retarded stuff for route descriptions...

[mkporwit]

I would like to see something map-based rather than name-based. Maybe cross-referenced with CAG? Make the metadata for the route somewhat extensible so that various types of queries would be possible.

 

Permission to edit would be something you have automatically and it would be revoked by moderators, so anyone can contribute but if they fuck up they can be appropriately contained.

[mkporwit]

Oh, and of course have the ability (requirement?) to bind current/new TRs to entries in the wiki.

[Tony_Bentley]

The search UI should allow by type of climbing, season, area, etc. Also the wiki should not be limited to internal content. There is additional information to be used in all of the Mountaineers journals, NWMJ and other online resources.

 

I also think skiing should be part of it. Lowell has a great database that could be used for ski descents as well as Turns All Year trip reports.

 

[TrogdortheBurninator]

a topo drawing tool would be good. also, some sort of grading consensus thing like mountain project would be nice.

[gapertimmy]

Make the metadata for the route somewhat extensible so that various types of queries would be possible.

Any specifics on what meta type info we should have on such a database?

 

It seems that meta might be defendant on meta so to speak, like depending on the classification of the route/ski/ice different meta should be exposed/required.

 

Someone want to do a brain dump on the various options?

[olyclimber]

WINTER BRAIN STORM ALERT:

 

 

Route info:

 

 

 

Type - Ski decent/ice climb/alpine rock/crag route

 

Location - Massif?/Quad?/Grouping?/coordinates?

 

Rating - 5.X, WI.x, M.x, etc

 

Route quality consensus - vote what you thought of the quality of the route

 

Date or season - Winter only?/summer rock?/etc

 

rack info - gear to ?

 

pictures - link to them

 

guidebooks referencing climb or area?

 

approach information - roads, trails, mileage from X, gullys, etc

 

crag camping info?

 

closure info - like Midnight Rock, etc

 

links to TRs of the route/list of board members you might ask for beta because they have done the route before

 

Maps - Topo, satellite

 

Nearby routes- similiar grade/just near by different grade/etc

 

Historical info - Who did FA, FFA, etc

 

Associated climbing steward group - Access Fund, WCC, etc

 

Gear shops close to the area in case you forget something

 

 

please add to list

 

 

 

 

 

 

[robert]

Any specifics on what meta type info we should have on such a database?

 

It seems that meta might be defendant on meta so to speak, like depending on the classification of the route/ski/ice different meta should be exposed/required.

 

I would love to see something map based. Maps.google.com I think is the best option. I love maps.live.com and the aerial/sat images are better in our area, but no topography yet is a huge drawback. Some modes of travel lend themselves to topographic maps better than others, skiing = great, crag climbing = harder to show much information as travel is vertical. Rock climbing or ice climbing would benefit from a topo generating tool. I would like to be able to see geotagged photos tied to the routes.

 

I agree that that the meta data will need to be customized by mode of travel. I can see that if you pick skiing you get choices like slope angle, avalanche danger, slope characteristic (trees, gladed, clear cut, open, glacier) and some others I can't think of right now. If you choose crag climbing, you get choices like rating, number of pitches, gear required, anchors, rock quality, aesthetics, approach. I am fine with having subjective criteria as well as objective data for all entries. I think as the wiki matures the quality of the data, subjective and objective will increase and it will become a tremendous resource.

[Tony_Bentley]

Keep in mind that even though we are discussing a route wiki, there is something to be said for some lack of information. One of the issues I can see is that there could be too much information and the experience would be different than reading a guidebook. If everything was right there, like every detail on the approach or a 100-photo gallery or a map with gps coordinates, etc can really detract from the experience. I'm not saying don't include it but maybe be creative on how it would be delivered.

[robert]

I think that the users can take what they want from the data. If they don't want to see the photos from the route or approach, or don’t want waypoints, elevations or whatever piece of information they can choose not to consume it. I could see that simply looking at a line on a topo map and a beautiful photo taken along the route might be sufficient to inspire someone to grab their USGS map and plan a trip. Others might choose to view every photo, read every linked TR and spend hours in Google Earth going over the approach. They would each have their own experience of the trip. I would rather have the information and make a choice to use it or not than not have the information available at all.

[TRbetaFlash]

Does anyone have an example sandbox version to look at for a proof of concept?

 

It would probably be best to have tons of route metadata that could be filled in, but the only stuff that shows is what you'd see in CAG, for instance. If you wanted a GPS track, that's some collapsed section at the bottom. Most wiki engines can do this already.

 

You would think that something like wikipedia would end up being too much information and perhaps bad info, but the oversight by the rest of the users should balance it out. It usually ends up being the most accurate collective view on the subjects in the wiki.

 

You can already link out into maps in live and google based on lat/lon GPS coordinates. Photo sites like flickr and panoramio already have geotagging built in. This should just be a list of links below the article on the climb.

 

Would you make this only available on cc.com or as a public site for the rest of world?

[olyclimber]

it maybe be difficult to comprehend some times, but cc.com DOES serve the whole world! just not all of them choose to come to our site.

 

it would be open to all, served up by cc.com

 

Thats a good idea there TRbeta, we can definitely get something worked up. In the meantime, continue posting ideas here. some people clearly haven't expressed the storm in their brain.

 

gracias.

[jon]

We had a meeting yesterday and have fleshed out some of the details of the wiki and agreed upon some of the basic functionality and how it will integrate with the message board, the trip reports, and the photos. We'll be starting development on it in the next week. We still have a number of questions, for instance what kind of hierarchy should be used to organize and categorize this information. If there are any individuals that would like to help provide some input and this project moves along please send me a PM and I will invite you in to a private forum.

[John Frieh]

Wiki (further down in thread):

 

http://www.gravsports-ice.com/icethreads/ubbthreads.php?ubb=showflat&Number=3797&page=1

 

 

 

[dberdinka]

Any process on this CC.com wiki?

[jon]

I'm assuming you meant progress. We're working on it. This is one of those things we really want to get right, so we are evaluating two very different solutions, one a modified existing solution and one homebrewed. We want the information extensible to other and future features and applications, like linking to the TR system. Hang in there we are VERY committed to this.

[jon]

Anyone interested in participating in some feedback and brainstorming in a private forum for the wiki drop me a PM.