For easy creation photo spoiler you can suport same funcionality as Garmin. Then I generate one folder with photos and copy into garmin navigation and locus.
More info: http://garmin.blogs.com/softwareupdat...
I need thjs feature to see the spoilerphoto in the locus app
I would like to see this feature also, Seeing the images posted by other cachers is helpful. Other geocaching apps have a tab for images.
Thanks for your consideration
Thank you, I will check out that forum link.
all people are talking about spoilers ...
nice example is this cache GC2378H
spoilerSync download one image. Same image is visible on bottom of web page but there is no information about it in GPX file as I can see. So the only way is to download whole page, parse it and check if there is not any image in some hidden ? Or is any other method how to get info about spoilers?
As I see, there is also method for getting all images over Geocaching LIVE. This method anyway return ALL!! images also some photos in logs. Is there any "all the time same name for spoilers"? like ... "spoiler"? Thanks
I think there is noch alltimesamename.
Best is, to Parse and download all pictures
So enjoy new "GC Offlinizer" :)
feedback is as usually very welcome. Suggestion: start with Geocaching tools
Wow this is awesome! Thank you for the quick implementation!
Here is my feedback:
Downloading the data seems to work very good!
Numbering is confusing, they do not seem to make sense? - What does the red or green number mean? Maybe you can explain it to me?
about the data itself:
It seems it only downloads Pictures that meet both of the criteria:
-uploaded to the cache page
-linked (used) in the description
please regard the following example:
The pictures "pb120179" and "pb120181" get downloaded,
but "pb120180" not
This is already a HUGE Improvement! Thank you again!
However I see two issues (possible further development options):
1. spoiler pictures are commonly uploaded to the cache page but not visible in the cache description just like "pb120180" in this case - and would therefore not be downloaded. It would be great if these "hidden" Pictures were visible on a separate tab (like "spoilersync" is displayed I believe) or maybe if there were a clickable (offline-)link in the bottom of the cache description
2. Sometimes important information is stored in external pictures which are not stored on the groundspeak servers. (See an example: http://www.geocaching.com/seek/cache_...)
In this case the GC Live API would not help however the image link should be in the cachediscription in plaintext and I believe it should be possible to parse it relatively easy from the GPX File (or the description Locus extracted from it) and download it from the web.
What do you think about it?
Thank you for making our favorite app better and better every day :-)
With the ongoing improvement you can not only do paperless caching but also true offline caching :-)
I can see Im late:) I just came back from 14h bicycle geocache hunting trip. My legs are dead. Anyway, i didnt tested new feaure yet, but i want to give you the example from opecaching.pl (if you still didnt have it) : http://www.sendspace.com/file/ky4day
firstly, for this I`m not using GC Live API. I just simply search for all http links on images in long description of cache, that`s all. That`s also reason why pb120180 is not loaded. If you look into GPX file, there is no information about this image
if you don`t understand images, I have to change them. They aren`t too important but I`ll make them more obvious
and points ...
1) I would like to, but as I wrote already here https://getsatisfaction.com/locus/top... , I have no idea where to get links to these images!
2) I think if you test this cache, it will be correctly cached because images are included in long description
I`m afraid opencaching.pl gpx format is not working. Empty `no spoiler found.txt` files are only created in geocaching directory.
Thank you for clarification. Still I don`t understand the numbers. For example for this cache I get 0 | 2, Total: 0
about 2) so if I understood you correctly the procedure I described is what you are using already? I tried it serveral times and it seems to work with other caches. However for this particular cache it doesn`t seem to download the pictures automatically. maybe there was an other error?
about 1): would it be possible to use the api method you mentioned earlier? or would that be to much traffic?
I discovered one issue that prevent from downloading of some images. If you see in current version number 0 | 2, this mean that 0 images was downloaded successfully, and 2 failed. In most cases this should be fixed now.
anyway as Robin wrote, if you have created "no spoiler found.txt" file, this means that Locus do not find any available images in long description of cache. If there are any images and you still have such file in geocaching directory, just send me GPX with this cache and I`ll check it. It`s still possible that I incorrectly detect images in description
and to Marcus, ad 1. - as I wrote above "As I see, there is also method for getting all images over Geocaching LIVE. This method anyway return ALL!! images also some photos in logs. Is there any "all the time same name for spoilers"? like ... "spoiler"? Thanks " ... so problem is that for cache where people upload images, I see no difference in images in logs vs images listing, so locus will download 100 images even if not needed. Not a good way I think
I agree with you! In some caches (like earthcaches) it is common for users to upload dozens of pictures that would be pointless for finding the cache.
If you filter for certain words like "Spoiler", "hint", "spoilerpic" you would get around 70-80% of the useful pictures I believe. (with rarely any false positives)
Can you please tell us which information about the pictures is provided from the API besides filename? Can you even selectively download?
Which this information we might be able to narrow down the selection of useful pictures.
For example if I look at gallery of the cache we discussed earlier (http://www.geocaching.com/seek/galler...) I could imagine to look for pictures that where uploaded at the same day as the cache was hidden. I think that would get 90% of the relevant pictures with a few false positives. (Supposing the API gives you access to the date)
Kind Regards, Markus
I`m already working on it, anyway this is what return GC API
<a:ImageData><a:Description/><a:ImageGuid>1532abaf-6386-4300-9378-12c89d7d5b63</a:ImageGuid><a:MobileUrl>Mural" rel="nofollow noopener" target="_blank">http://img.geocaching.com/cache/display/1532abaf-6386-4300-9378-12c89d7d5b63.jpgMural quadrant 1</a:Name><a:ThumbUrl>http://img.geocaching.com/cache/1532abaf-6386-4300-9378-12c89d7d5b63.jpghttp://img.geocaching.com/cache/thumb/1532abaf-6386-4300-9378-12c89d7d5b63.jpghttp://img.geocaching.com/cache/1532abaf-6386-4300-9378-12c89d7d5b63.jpg;
so only interesting part is tag ... nothing more. Don`t worry a lot about it. I`ll create some system and give it here for testing :)
Thank you for caring!
Let me just note one more thing (I don`t know how much you know about GC):
I think we have to differentiate between two things here that are equally important.
1. Offline availability of pictures in the cache desciption
2. Spoiler pictures that you usually only want to see when you are stuck.
While the first one has been achieved (which makes me really happy!!), the latter is (what I think) Jarda actually requested. However this is somewhat more complicated as we realized.
I think the most promising is keyword filtering, even if it won`t catch all relevant pictures (maybe make an option for that?) it will be still a huge improvement!
Anyway, I will leave the rest to you ;-)
I think elmuSSo tried to show you a gpx from opencaching: http://www.sendspace.com/file/ky4day.
I`ve mailed you another example of gpx file.
heh, I really don`t expect that I`ll do it whole day ...
believe you`ll like it! And what`s new?
1. support for Live API (allow to download spoilers! If this will not download any spoiler images, send me GC code and I`ll fix it)
2. system run as a service, so more memory resistant and stable
3. new tab with images
wow! this concept is great! what about adding one more checkbox "Only download pictures the contain `spoiler` in the description/filename"?
also one minor concern: Pictures that are already in the description don`t need to be shown in the images tab again - Though this is only cosmetic :-)
Overall a very nice solution!!!
It`s great work, thanks. Fast testing new functionality and I noticed that something is wrong with OP4734 (in gpx I`ve mailed you previously). Two from three pictures are not downloaded.
hmm weird, for me it downloaded all three images. Try please to delete directory locus/data/geoaching/4/3/OP4734 and try it again
Ok, it`s helped. I`ve mailed you another gpx with one cache. I think, something is wrong because only one of two pictures is downloaded.
Now I`ve two pictures downloaded for OP1FAB. I`ve just run GC Offliner second time.
Another thing. I suspect that gif type pictures are omitted.
fine so ...
1) support for GIF also
2) ability to download only spoilers ;) (in this case is usually need to use Live API because spoilers are not usually directly in imported GPX files)
I was not looking directly word "spoiler". In czech should be used word "fotohint". And there is other languages ...
I did a little research: I spidered 1000 cachen in Berlin and analyzed the pictures.
there where 1060 pictures. 62 of them contained the word spoiler (of which only one was not helpful)
Additional 9 helpful pictures were found if you also consider the keyword "hint".
Though with "hint" also 3 pictures came up which were not helpfull (like "Turm von Hinten").
1 important spoiler picture of the 1000 pictures hat a cryptic name and would not be found by any filter (which is negligible).
So now I would recommend if "only spoilers" is checked you would also filter for "hint" to get the success rate from 90% to 99%
It is true that you would get around 3 "unnessesary" pictures for 1000 caches, but the sounds like a fair trade-off to me. What do you think?
thanks for testing. I think that support for "hint" (in case of spoilers testing) can be only useful. As well as testing on "fotohint" text. Both added
EDIT: ah, "fotohint" is included in "hint" :)
do you filter only for exact matches or in a fashion that would also find combinations like "spoilerpic.jpg" if you search for "spoiler"?
I`d recommend the latter, because it is very common, that "spoiler" (or Hint) is only part of the picture name.
(If so, also "fotohint" and anything similar would already be included if you filter just for "hint")
yes, I`m testing "specific words" to be contained in text (and also ignore lower/upper cases). So spoilerpic.jpg and also fotohint will be successfully included during testing now ..
I agree with you that it makes sense to filter for "whole words" in case of "hint" (and fotohint etc.), because hint is a root of a few german words (like Hintergrund or hinten, ...) to exclude the false positives I had found. (Though there are not to many)
Edit: please note that sometimes hint/spoiler is followed by (multiple) special characters like "!" or similar
However in the case of "spoiler" I`d recommend to test for anywhere in the string, because there a lot of examples that people combining the word with other without spaces in between (like Megaspoiler, spoilerpicture, spolierbild, spoilerfoto, spoilerhint, microspoiler, spoiler2, SemiSpoiler ... (all seen in my research, and many more)).
Since there are so many possible positive combinations but virtually none wrong coincidently matches with other meaning words, I believe it is justified to accept any "*spoiler*", even inside words.
I`m not aware of the variety of countries Locus is used for Geocaching. Following the approach above will allways lead to somebody having a request for another filterword. Why not leave this open for the user with some suggestion from the system:
Enter filterword (like *spoiler|*poile*|hint|*ilf*):
Just my 2cents for a function which is definitely getting Locus to the very top of apps used for Geocaching (even if You don`t implement what I`m suggesting at:
back to work here ...
Look on it from opposite side. Most users will not know how locus search for spoilers. They just want them! If I leave system open, so everyone will be able to define own words, it ends with fact, that experienced users will have own "words database" and feature will works nice to them. Basic users will not use this feature because "it not work"
When I leave words hardcoded in Locus, it will lead to way, that experienced users will tell me which words are missing and I`ll be slowly adding them, so in the end, most words should be covered
So, I would like to keep simple solution - use it! When you`ll miss some images at any cache, write me "Hey, this GCXXX not work, fix it!" and I`ll fix it :D
Sounds reasonable. But you could open a little backdoor (hardcode it into the cfg file, which is very unknown even for experienced users) (grin)
I want to check your great tool, but dropbox sends 404 to all your download links. Can you please check?
probably tomorrow (or in worst case in monday) will be release of new version, so ... :)
and nlgel ... I still think that backdoor are not necessary. I react very fast so one sentence on email and in next version will be all new words added - for all
is this still available? The Dropbox-Links still give me a 404, I really love to check it out. Or will be be available in the market some time?
where is this nice tool now?
I would like to try it now :)
did you look into "Geocaching tools"? It`s a good startpoint
Oh, thanks, Menion. There it is. I didn`t get this idea ;)
Now I can try it :)
this feature is indeed very nice! However it`s urgently needed to zoom the pictures smaller than 100 percent. right now it is only possible to make them bigger, but as they have often already high resultion we would need to diplay them smaller to see them in one piece on the screen
exactly this should be fixed in last market release (2.5.6). Isn`t this working for you? If not, write me GC code of cache that have such troubles and I`ll check it again
nice!!! Just saw the update in the market :-)
you can really read my mind, can`t you? ^^
Btw: can you tell us which filter you use at the moment? did you now include every combination with "spoiler" as mentioned above?
no I can`t :) Someone already asked me for this ...
and filter - my code looks simply
so all these three words. I know that "hint" or "finale" may be also included in some common words, but i think it`s better to have more images then miss some
very nice! I`m totally thrilled with this feature!
I think this is really the best way to do it and I also agree with you that this is better hardcoded then optional, though I usually prefer choice.
btw, I new version is under "Geocaching tools" new option to search for all unused pre-downloaded images (it simply check which cache directories don`t have imported cache in database) and delete them.
I was thinking to do some automatic deleting and I can imagine cases when people delete cache for example by accident or during some imports etc. so such one-time action, once a time, seems better and more under user control
btw: would it make sense to consider the following minor tweak:
in the gc offlinizerdialog: change the order of "use Live API" and "only spoilers" and disable "only spoilers" (gray it out) if "Live API" is not selected, because you would hardly find a cache that has the spoilerpic visible in the description so this combination (only spoilers, not live-api) would not find any pictures anyway.
I was also thinking about it but wasn`t sure about that. Are you sure that spoilers "cannot" be in normal GPX listing?
well ... I can not guarantee it completely impossible, but I haven`t seen it so far and in my opinion it wouldn`t make any sense ....
however consider the usefulness of this feature which would only return maybe one picture in 10000 caches. I think as most people don`t know even know what live-api is, the disappointment would be much higher than a possible benefit from this feature.
btw: the picture count in the notification bar hardly counts any images? Or does it reset after every cache? I think it would be more intuitive if it counts the total number of downloaded pictures.
- spoiler only for API - agree, done
- total number of images in top panel - agree, done
very nice! looking forward to the new version :-)
In the meantime I tested Offlinizer, and it works perfectly. Thank You Menion. Anyway I think there should be some more report why some of the photos have Failure download status, and maybe give the opportunity to the user to Retry downloading failed photos?
Replies have been locked on this page!