radek

You can somewhat do this currently. An option when creating a trail is to draw in the point. The more points you put in the more accurate the grade will be. Additionally as you are adding a trail you can see the topo. Example: https://www.pinkbike.com/photo/16876938/ Also there is a "planned" option when adding a trail. A planned trail is only visible to those that have admins to an area, which should be associations and builders in a region. Once you add a trail, you simply sync the region and the planned trail along with grade info will be available on the app ( if you have admin ) . You also can see what the grade is at any point in the trail by sliding your finger on the elevation chart. Example: https://www.pinkbike.com/photo/16876980/

We will be adding this in the next update.

The larger elevation on the trail is still there. This was always below all the trail data so you have to scrill down on the trail page.

@xyrion: We don't do anything nefarious and only build features and use data that is required for the app features. But, I do want to understand your point of view so here is a couple of questions. The tracker app test you pointed to just scans the app for the existence of a code library. Say in the case of fb. Yes there is a lib that will be used to do the fb login, but only when you actually decide to use that feature. If you never do a fb login, there is never any kind of call made to fb. How do you envision us making it work for someone like yourself, but yet still have the ability to provide a feature for those who choose to use fb login?

@brentkratz: Not yet, but it will be soon.

@xyrion: From this article sounds like one should use an iphone instead of an android phone "For comparison’s sake, a similar experiment found that on an iOS device with Safari but not Chrome, Google could not collect any appreciable data unless a user was interacting with the device.". We are going to double check, but our app only interacts with fb when you decide to use "login with fb". If you don't use that feature then there is no interaction with fb at all. And if you do it only interacts one time on the login screen to do the login verification.

If a trail is just gentle green with hardly any grade we think there is no need to amplify this visually to the user. The reason why we think that the fully shaded graph without direction bars is less ideal is that you are forced to relate the color to the sometimes minor, compressed, or hard to see elevation changes in the profile graph to figure out if the grade is related to uphill or downhill. Also with colors and bars we have more resolution in that not only can we represent a grade with a few shades of color, but also with the size of bar and the direction of the bar. We can convey more information/data to the user. The trail direction and therefore the elevation profile on trailforks is from green circle to red square. This trail direction is computed from millions of trail ride logs and recommended to be set that way to the associations. So a trail is made a particular direction because say 80% of the riders ride it that way. Of course you may ride it the other way and the default elevation profile and the grade will be backwards but I think people already intuitively compute that in their head. If the slope shown is downhill from left to right, but if im riding backwards, then i'm actually going uphill. We might even make this easier by having a button to toggle the direction and therefore switch the elevation profile and grade graphs for the user.

@Levelheadsteve: Maybe because riding a trail is not very instant?