Mountain Project Layar app (android/iphone)

Hi,

I'm a software engineer/climber, and I'd love to work on an Layar app to expose the data on mountain project. Is anyone else working on an android/iPhone app for mountain project? What do administrators here think about this?

an android app would be an awesome idea.

Laura,

I am a developer and climber as well.

I had posed the question to them at one point and the answer I got was "We have a mobile website that works fine". I think there is immense value in using local data caching and gps features for a smart MP app. You could cache all your guides. Search for route info and partners locationally. ect ect...

I would also love to work on this just because I would love to have such a tool. Let me know if you gain any traction on it.

I would imagine there may be some overhead on their developers to create an API. However it would be well worth it to immensely expand the MP mobile experience.

Cheers,

Drew

I think it would be a great idea. A save page or route type function would be cool too. So, if you didn’t have cell coverage where you were going you could save the area or climb before you went.

Drew,

I think it is funny the different responses you get from this site depending on who responds first. I say, if you have the time and the capabilities it would be awesome to have it.

Cheers,
Aaron

Hi everyone,

We have had many offers to help with an iphone/android app, and we have not been very responsive. We are generally control freaks and have chosen not to make data dumps or an API available to others.

I would like to write the app myself, but after buying a mac and doing some tutorials, got a bit overwhelmed by Objective C. It's a bit more difficult than perl, php, c++, and some of the other languages I know.

Right now, I am leaning towards scrapping our existing "mobile app" and creating a new web-based app that would work on iphone, ipad, and android but would have limited offline capabilities (perhaps "save this page").

The holy grail is a completely offline app similar to the RRG app that has been reviewed elsewhere on this site. That's a bit far off in the future right now though, and to my knowledge, this has the significant drawback that iphone and android would be two different development projects.

Hey,

For the techies here, I am interested in working on a layar app at least partially because it would then be available to both iphone and android users. Also, layar is a geotagging ('augmented reality' is the term they use) platform, so developing a layar app would involve less development time then a from scratch app. I was planning on working on this as a fun project for my own enjoyment, I really don't think it would be something that could be ethically salable, because you'd need lots of people to geotag their local crags. If you were going to sell it, how would you compensate those people? Maybe a free copy of the app? But then a large portion of your user base is getting it for free... it kind of wrecks the model.

If the owners of Mountain Project were willing to make their databases available to such an app, I had been hoping to use that as a starting point. They don't seem to be willing to do that, and btw, I am totally cool with that, it is their intellectual property to do with as they see fit. So, I can start with my local crag, and hopefully ask people to submit geotagged photos and site info once I've got the platform up.

So.. is anyone interested in working on this with me given the fact that the only recompense would be... um... hopefully producing a really handy and neat looking app?? At this point, I'm looking for someone to help with the coding side of things, not the content collection :) I'm c++ person mostly, haven't done much web/app development, so if you have, that would be awesome. I'm no language bigot though, and as long as you have some solid general development experience, it's totally cool if you're learning the web/app ropes, I know I am :)

The Android API provides a class for acquiring user location, however most crags are too far from data service. Without it, no maps or information can be sent to the phone. The GPS can still find your location, however it cannot make use of it. It wouldn't be practical unless you are at a crag with data service, like RRG.

Yes, a couple posts in this thread have been getting me thinking about that :) I'm lucky (or not, depending on how you think about it) to live in an area with almost total cell coverage, so I hadn't been thinking about the ability to look up site info and then save it, but that will definitely be important.

Maybe you should take a survey of people who have data service at the crags vs those who don't. I could be wrong about most crags not having data service. Maybe NM is the odd man out. Just be sure to convey to the survey taker's the difference between cell reception and data reception.

Hi Everyone. I have a couple opinions to share about the closed (to developers) nature of Mountain Project's data.

---
Hi everyone, We have had many offers to help with an iphone/android app, and we have not been very responsive. We are generally control freaks and have chosen not to make data dumps or an API available to others. I would like to write the app myself, but after buying a mac and doing some tutorials, got a bit overwhelmed by Objective C.
---

I can understand the sentiment, but I'd like to point out the other side of the coin. In my experience, when you free your data, you end up with a mature ecosystem of great applications, a larger user base, and MORE data than when you started. Also, you get better applications. You're not iPhone developers. Let great iPhone developers write great iPhone software. Charge a licensing fee if you need to monetize it. Otherwise, ensure that the developer adequately preserves your brand in the application.

The simple fact that you tried to learn Objective C and were overwhelmed ought to speak volumes.

The *first* online database of climbing routes that offers an API is going to win. The rest will become obsolete quickly. I promise.

Making an API is easy. Your content is well organized. Start with an RSS feed.

---
It's a bit more difficult than perl, php, c++, and some of the other languages I know. Right now, I am leaning towards scrapping our existing "mobile app" and creating a new web-based app that would work on iphone, ipad, and android but would have limited offline capabilities (perhaps "save this page").
---

Please don't take this the wrong way: your current mobile app is less than useful. On a recent trip to the Red River Gorge, I tried to use it to look up routes at a new wall (not in any guidebook yet) and tick routes. I couldn't do it.

---
The holy grail is a completely offline app similar to the RRG app that has been reviewed elsewhere on this site. That's a bit far off in the future right now though, and to my knowledge, this has the significant drawback that iphone and android would be two different development projects.
---

The RRG app is a great implementation. If you published an API, I guarantee you someone would write an implementation that is functionally equivalent or better. My company, for one, would probably take it up as an internal project.

And or what it's worth, if you want to target Android and iPhone with the same app, there are cross platform frameworks like Appcelerator's Titanium that can help abstract away some of the implementation details.

You are, of course, free to do whatever you want with your website. My $0.02 would be to open it up rather than try to control everything that happens. Chaos can be good for innovation.

Please don't get me wrong: I appreciate the free service you provide to climbers around the world. Mountain Project is a great site, and the free information is really useful. I think you're missing a great opportunity, however, by trying to hang on to too much control.

Just an opinion.

Peter Jackson wrote:The *first* online database of climbing routes that offers an API is going to win. The rest will become obsolete quickly. I promise.

Great post Peter. I also don't really see a good reason not to offer an API to access data that has been contributed by a community of users, though I understand the sentiment. I hope it is one day opened up.

This risk with opening up the data is that someone could wholesale "pirate" it and create a duplicate site. Mobile or otherwise.

I'm all for openess, but at the same time Nick, myself, and the admins have invested literally tens of thousands of hours and we'd sure hate to see the data pirated.

It would require significantly more effort to write a bot that navigated the site and scraped the data. If we provide an API, anyone that knows how to write a loop could have a mirror site up and running in a few days time.

Any suggestions on how to mitigate that risk?

Andy

I don't think public API is best idea for the intentions of MP. They should have control over who, what and how people access their content.

However I do think they should let talented software designers and developers who have a passion for climbing and interest in helping the goals of MP develop mobile apps for popular smartphone frameworks... at no charge?

Drew

Hi guys,

Thanks for the thoughtful replies. I think you raise a really good point about mirrors and piracy. I'd also hate to see your hard work be stolen, rebranded, and pirated. It'd really do the climbing community a disservice to have that kind of fragmentation.

I do have a few suggestions. Most people who struggle with this issue take a two pronged approach: legal, and technical. As an engineer, I find the technical solutions to be more elegant, but my lawyer friends swear by the legal route.

1. Don't open up the API to everyone. Make people apply for developer keys, and have them sign Terms and Conditions. Know the people who you give the keys to. Make sure you have a phone number for them that works. Call them if you need to. You might even be total freaks and make them meet you in person before you approve them.

2. Charge money for the API key and make the developer keep a credit card on record. Store this information in a payment gateway and make it an annual charge. As a developer who wants to make high-value applications that use MountainProject, I would pay $100/year for the privilege without hesitation. If I made money off of an application, a revenue share wouldn't be too much to ask either. You could use the money to fund compliance efforts (see below).

3. Aggressively pursue pirates. Use the DMCA's cease-and-desist provisions to make mirrors or pirates remove pirated content, then refer them to the FBI if they do not comply. SImilarly, you can crush a pirate's SEO possibilities using some avenues at Google. Google doesn't like pirates.

4. Limit API access. Don't serve up ALL of your content over the API. Beta Photos, for example, are a high value offering. Maybe you keep those in house and provide URLs to them instead.

5. Limit API velocity. A single instance of an external application has no need to hit your API more than a few times per second, several times per minute, or a couple hundred times a day. People who are trying to steal your content will have that need, but legitimate users will look different.

6. Somewhat more controversial: make a developer submit an application to you for approval before allowing access to your production data. It works for Apple, though iPhone developers dislike the process. I don't think it's too much to ask, though.

There are lots of other technical solutions you can implement: signed applications, requiring a user login for every request, request monitoring, geographical restrictions, etc. I'd say: go slow. You can always add more stuff to your API later once you're comfortable that you have a model that protects you from piracy.

You have a great resource that developers are itching to use to make applications. I suspect you could get away with whatever you want if you were offering that access.

Again, thanks for the free, useful service. The tens of thousands of hours of hard work is appreciated. As a professional in the industry, I know you're probably underestimating the time, too. So: kudos.

Thanks!

--Pete

NERDS!

Bob Packwood wrote: Less "nerdy", more "nosy, anal retentive control freaky". Look at all the shit I know! Give us access to your database and all will be well, and all the lame urban toolsacks who bring their digital devices climbing will have a smorgasbord, whoo-ahhh.

An excellent response, thanks Peter.

Peter Jackson wrote:Hi guys, Thanks for the thoughtful replies. I think you raise a really good point about mirrors and piracy. I'd also hate to see your hard work be stolen, rebranded, and pirated. It'd really do the climbing community a disservice to have that kind of fragmentation. I do have a few suggestions. Most people who struggle with this issue take a two pronged approach: legal, and technical. As an engineer, I find the technical solutions to be more elegant, but my lawyer friends swear by the legal route. 1. Don't open up the API to everyone. Make people apply for developer keys, and have them sign Terms and Conditions. Know the people who you give the keys to. Make sure you have a phone number for them that works. Call them if you need to. You might even be total freaks and make them meet you in person before you approve them. 2. Charge money for the API key and make the developer keep a credit card on record. Store this information in a payment gateway and make it an annual charge. As a developer who wants to make high-value applications that use MountainProject, I would pay $100/year for the privilege without hesitation. If I made money off of an application, a revenue share wouldn't be too much to ask either. You could use the money to fund compliance efforts (see below). 3. Aggressively pursue pirates. Use the DMCA's cease-and-desist provisions to make mirrors or pirates remove pirated content, then refer them to the FBI if they do not comply. SImilarly, you can crush a pirate's SEO possibilities using some avenues at Google. Google doesn't like pirates. 4. Limit API access. Don't serve up ALL of your content over the API. Beta Photos, for example, are a high value offering. Maybe you keep those in house and provide URLs to them instead. 5. Limit API velocity. A single instance of an external application has no need to hit your API more than a few times per second, several times per minute, or a couple hundred times a day. People who are trying to steal your content will have that need, but legitimate users will look different. 6. Somewhat more controversial: make a developer submit an application to you for approval before allowing access to your production data. It works for Apple, though iPhone developers dislike the process. I don't think it's too much to ask, though. There are lots of other technical solutions you can implement: signed applications, requiring a user login for every request, request monitoring, geographical restrictions, etc. I'd say: go slow. You can always add more stuff to your API later once you're comfortable that you have a model that protects you from piracy. You have a great resource that developers are itching to use to make applications. I suspect you could get away with whatever you want if you were offering that access. Again, thanks for the free, useful service. The tens of thousands of hours of hard work is appreciated. As a professional in the industry, I know you're probably underestimating the time, too. So: kudos. Thanks! --Pete

Andy... god knows I'm not advocating anyone do this, and certainly would never do this myself, but scraping MP for the kind of data we are talking about here wouldn't be hard at all. Sure, it's 'easier' to do such a thing with an API, but the technical barrier to entry is about the same, frankly. What's stopping people from doing such a thing is twofold:
1st) not that many people have the skill set to do any of the things we are talking about here
2nd) Those that do and would also be interested in doing such a thing probably have some ethics

An API gives you control over your data flow, you can make people sign contracts, you can specify how they use the data, you know exactly who is playing in your sand box.

But as I've said in earlier posts, the data on MP is yours to do with as you wish, and I completely respect your right to control that data. I do hope you decide to do an API as a way to get control over who's doing what with your data, if nothing else. I'll be the first to sight the developer's agreement. If you decide not to, you should really consider taking some steps to protect the data on your site, and I'm sure there are lots of people, (myself included) who would be happy to help you with that.

i for one would love to have a partnership with mountainproject. i'm working on an iphone app to have data similar to mountain project data available on the iphone. but recreating the data set will take some time.

Nick, if you ever change your mind about opening up an API, let me know.

olivier

This is a great thread.

Stepping back a little. Mountain Project is one of the only places with a comprehensive flexible database of climbing based data. Opening the data to developers who can add value to the site as well as relieve the current developers of some burden seems like a worthy goal. There are some critical and relatively simple shortcomings of Mountain Project that prevents it from becoming a truly useful resource "in the field". For example, having climbs for a crag entered in some spatial order so we can easily print (print formats = another useful improvement) a document to serve as a guide would be incredibly useful. Of course any user could order the climbs in the crag description but that is not as useful as having it built into the web-site framework. Opening the data to developers is a start toward people being able to reference MP's wealth of information at the crag without having to print out pages of inefficient content.

The truth is that we spend too much money on guide books for already outdated information. No offense to you awesome climbers who put all that work into making those guides. But, if the MP framework was improved upon to support the climber who wants to use the information at the crag and developers built applications to access/update/create data it would be an incredibly useful website that would relieve guidebook authors of the headache of working with publishing companies... Who don't give the authors enough money anyway.

The argument I am trying to make is... As Mountain Project becomes more useful and comprehensive more people will religiously use the site. There shouldn't be much worry of others steeling content to replicate the site because MP already is an incredible resource that most climbers want to thrive and improve. Those ideas to prevent theft are great but Laura is right. If someone wants the data bad enough they will scrape it. It's not that hard. If mountain project maintains it's usefulness (easier to do by opening their/our contributed data) and doesn't piss off too many developers they will collaborate in a way that can make MP a resource unparalleled into the future.