Jump to content

Geocaching APP vs C:Geo


Azlan1464

Recommended Posts

Hi there! :)

 

I currently use the C:Geo app that's available on Android (not sure about other devices/markets). I was curious as to if anybody else used this app or could compare it's functionality or services compared to the official app? I mean C:Geo does everything that I currently require it too, but does the official app have more perks or useful features? If anyone has any advice I'd be really appreciative. Thanks guys!

Link to comment

Hi there! :)

 

I currently use the C:Geo app that's available on Android (not sure about other devices/markets). I was curious as to if anybody else used this app or could compare it's functionality or services compared to the official app? I mean C:Geo does everything that I currently require it too, but does the official app have more perks or useful features? If anyone has any advice I'd be really appreciative. Thanks guys!

 

I'd say probably the biggest thing is the official app automatically loads any pocket queries you run but c:geo requires you to import them.

 

I have to say I'm really not all that impressed with the GC app. I bought it, but really only use it occasionally. c:geo and cachesense are more useful to me.

Link to comment

Hi there! :)

 

I currently use the C:Geo app that's available on Android (not sure about other devices/markets). I was curious as to if anybody else used this app or could compare it's functionality or services compared to the official app? I mean C:Geo does everything that I currently require it too, but does the official app have more perks or useful features? If anyone has any advice I'd be really appreciative. Thanks guys!

 

I'd say probably the biggest thing is the official app automatically loads any pocket queries you run but c:geo requires you to import them.

 

I have to say I'm really not all that impressed with the GC app. I bought it, but really only use it occasionally. c:geo and cachesense are more useful to me.

 

Awesome, i've heard others say that they managed just fine with c:geo and I have too, I just wondered about the official app. Thanks for the advice.

Link to comment

The most important difference is CGeo does not comply with the sites terms of use. It gets the information from the site in unauthorized ways and this can impact the efficiencies of the site. Do all the users of the site a favor and select one of the apps that is compliant with the site's TOS.

Link to comment

The most important difference is CGeo does not comply with the sites terms of use. It gets the information from the site in unauthorized ways and this can impact the efficiencies of the site. Do all the users of the site a favor and select one of the apps that is compliant with the site's TOS.

 

Even CacheSense, which IS on the API, is not terribly reliable and doesn't always work as I would expect it to. Perhaps if GS and its 'partners' could put out products that were as functional and reliable, there wouldn't be as many folks using c:geo. I spent $15 for these two apps, but they generally let me down when I consider what I get for something I paid good money for...a lot more than I paid for any other apps, mind you.

Link to comment

c:geo is a "damned if you do, damned if you don't" problem. It's open source, which means its code must be freely available. If it were to use the official API, it would have to expose GS's code to the world. Of course GS wouldn't like that. So it's stuck using unapproved means of getting its data, in order to stay open source.

 

Being a big fan of open source software myself, it is quite a conundrum.

Link to comment

With c:geo the issue is not so much that it would expose GS code. But that it does not abide by the restrictions that non premium members face with official API maps. Namely the limit to the number of cache details a non premium member can down load.

 

I would suggest many new geocachers start out with c:geo before buying premium membership. So to stop access to c:geo would not be a smart move.

Link to comment

With c:geo the issue is not so much that it would expose GS code. But that it does not abide by the restrictions that non premium members face with official API maps. Namely the limit to the number of cache details a non premium member can down load.

 

I would suggest many new geocachers start out with c:geo before buying premium membership. So to stop access to c:geo would not be a smart move.

 

According to TPTB, and someone else can Markwell it if they like, the problem with c:geo, beyond it violating the TOS, is that it accesses the site just like a user sitting at a PC using their browser, only it does it a heckuva lot faster than a user at a keyboard can. So if you get a bunch of people pounding on the GC servers at one time with the live map, the servers get hammered and, by extension, the GC user community at large gets slow service.

 

The reason c:geo is not blocked is, again, because it presents itself as a browser. If they tried blocking c:geo in the simplest way, they would have to shut down all access via browsers. ALL browsers.

 

I suppose they could find another way to block it, but I can only assume that they choose to put their resources to other uses than chasing wild geese.

Link to comment

With c:geo the issue is not so much that it would expose GS code. But that it does not abide by the restrictions that non premium members face with official API maps. Namely the limit to the number of cache details a non premium member can down load.

 

I would suggest many new geocachers start out with c:geo before buying premium membership. So to stop access to c:geo would not be a smart move.

 

According to TPTB, and someone else can Markwell it if they like, the problem with c:geo, beyond it violating the TOS, is that it accesses the site just like a user sitting at a PC using their browser, only it does it a heckuva lot faster than a user at a keyboard can. So if you get a bunch of people pounding on the GC servers at one time with the live map, the servers get hammered and, by extension, the GC user community at large gets slow service.

 

The reason c:geo is not blocked is, again, because it presents itself as a browser. If they tried blocking c:geo in the simplest way, they would have to shut down all access via browsers. ALL browsers.

 

I suppose they could find another way to block it, but I can only assume that they choose to put their resources to other uses than chasing wild geese.

 

Improving their own app would be a great start...

Link to comment

With c:geo the issue is not so much that it would expose GS code. But that it does not abide by the restrictions that non premium members face with official API maps. Namely the limit to the number of cache details a non premium member can down load.

 

I would suggest many new geocachers start out with c:geo before buying premium membership. So to stop access to c:geo would not be a smart move.

 

According to TPTB, and someone else can Markwell it if they like, the problem with c:geo, beyond it violating the TOS, is that it accesses the site just like a user sitting at a PC using their browser, only it does it a heckuva lot faster than a user at a keyboard can. So if you get a bunch of people pounding on the GC servers at one time with the live map, the servers get hammered and, by extension, the GC user community at large gets slow service.

 

From what I heard it goes beyond that. It's been a long time since I looked at the source code for c:geo but, as you suggest, it it uses an automated http request mechanism (a browser also communicates with a server by sending http requests) for retrieving data. Every request http request made to a server contains various header information, including a field which indicates what type of browser is sending the request. The c:geo code set that field such that it appeared to be coming from a manually operated web browser. From what I understand, GS asked the author of c:geo to change the header such that the requests could be identified as coming from the c:geo application and the author refused to do so. If the c:geo apps works correctly automating the http requests shouldn't issue but if it didn't GS would have no way of blocking the request as they would be indistinguishable from someone clicking on links from a web browser and effectively turn c:geo into a source for s denial of service attack.

Link to comment

With c:geo the issue is not so much that it would expose GS code. But that it does not abide by the restrictions that non premium members face with official API maps. Namely the limit to the number of cache details a non premium member can down load.

 

I would suggest many new geocachers start out with c:geo before buying premium membership. So to stop access to c:geo would not be a smart move.

 

According to TPTB, and someone else can Markwell it if they like, the problem with c:geo, beyond it violating the TOS, is that it accesses the site just like a user sitting at a PC using their browser, only it does it a heckuva lot faster than a user at a keyboard can. So if you get a bunch of people pounding on the GC servers at one time with the live map, the servers get hammered and, by extension, the GC user community at large gets slow service.

 

From what I heard it goes beyond that. It's been a long time since I looked at the source code for c:geo but, as you suggest, it it uses an automated http request mechanism (a browser also communicates with a server by sending http requests) for retrieving data. Every request http request made to a server contains various header information, including a field which indicates what type of browser is sending the request. The c:geo code set that field such that it appeared to be coming from a manually operated web browser. From what I understand, GS asked the author of c:geo to change the header such that the requests could be identified as coming from the c:geo application and the author refused to do so. If the c:geo apps works correctly automating the http requests shouldn't issue but if it didn't GS would have no way of blocking the request as they would be indistinguishable from someone clicking on links from a web browser and effectively turn c:geo into a source for s denial of service attack.

 

Yup. And as I recall, GC offered to work with the c:geo author(s?) to make the application API compliant but they refused. I recall reading on c:geo's page some kind of story to justify doing so, but I don't recall what it was.

Link to comment

With c:geo the issue is not so much that it would expose GS code. But that it does not abide by the restrictions that non premium members face with official API maps. Namely the limit to the number of cache details a non premium member can down load.

 

I would suggest many new geocachers start out with c:geo before buying premium membership. So to stop access to c:geo would not be a smart move.

 

According to TPTB, and someone else can Markwell it if they like, the problem with c:geo, beyond it violating the TOS, is that it accesses the site just like a user sitting at a PC using their browser, only it does it a heckuva lot faster than a user at a keyboard can. So if you get a bunch of people pounding on the GC servers at one time with the live map, the servers get hammered and, by extension, the GC user community at large gets slow service.

 

From what I heard it goes beyond that. It's been a long time since I looked at the source code for c:geo but, as you suggest, it it uses an automated http request mechanism (a browser also communicates with a server by sending http requests) for retrieving data. Every request http request made to a server contains various header information, including a field which indicates what type of browser is sending the request. The c:geo code set that field such that it appeared to be coming from a manually operated web browser. From what I understand, GS asked the author of c:geo to change the header such that the requests could be identified as coming from the c:geo application and the author refused to do so. If the c:geo apps works correctly automating the http requests shouldn't issue but if it didn't GS would have no way of blocking the request as they would be indistinguishable from someone clicking on links from a web browser and effectively turn c:geo into a source for s denial of service attack.

 

Yup. And as I recall, GC offered to work with the c:geo author(s?) to make the application API compliant but they refused. I recall reading on c:geo's page some kind of story to justify doing so, but I don't recall what it was.

 

http://faq.cgeo.org/#1_21

Link to comment

As a general rule we do not allow discussions on products without permission from Groundspeak. This app scrapes the website and has chose to ignore using the API. There are many products that use the Groundspeak API and an offical app. We recommend that you select one of those.

 

If you wish to continue this discussion please move the discussion to other websites.

 

Closing and locking the thread.

Edited by BlueRajah
Link to comment
Guest
This topic is now closed to further replies.
×
×
  • Create New...