[BUG] No character limit on long description

[+eigengott]

I hope this is not a feature, but currently one can create cache descriptions of almost arbitrary size. See GC3E16T for an example (not published, only visible to admins), which has a long description of 100000 chars. Not believing this, I created another one: GC3E17W with 10 Megabytes of boring "lorem ipsum" text.

 

In the past there was a limit on the long description field (something like 5000 chars). Many GPS devices even have stricter limits on description length and truncate after 3500 characters or so. Large descriptions also tend to have long load times, especially on mobile devices. I've already seen listings where people use the space to encode images as HTML inline.

[Moun10Bike]

Yes, this is a feature. We made the change at about the time that we went to the fixed width on cache pages and profiles.

[+eigengott]

OK, got it. 10 Megabyte long cache descriptions are a feature. I'm sure geocachers will find lots of creative use for this feature.

[geopt.org]

This is silly! Why would someone need to have descriptions of limitless size? It breaks paperless geocaching and smartphone caching!

[Moun10Bike]

Do you have examples of listings that are breaking paperless devices? I might be able to argue for a change to engineering if I can show them what is happening.

[+ToonAl]

Do you have examples of listings that are breaking paperless devices? I might be able to argue for a change to engineering if I can show them what is happening.

 

I believe this one will: GC2EXYA

 

i find a lot of earth caches cause this issue. What they are trying to teach you takes so much verbage that when you load it on your gpsr it gets cut off. This is not "break" per se but you have to print this out before you cannot figure what it is you need to do at the cache.

[Sandy]

We are discussing with Engineering - no final decisions yet, but we are representing this point of view. We appreciate the discussion point, but let's please avoid sarcastic comments when we discuss these matters. Thank you.

[+Lil Devil]

Do you have examples of listings that are breaking paperless devices? I might be able to argue for a change to engineering if I can show them what is happening.

Here is a documented case of a cache with a 15K+ description borking up a PN-60. Seems the DeLorme plugin will automatically truncate the description, but when using PQs, there is no protection.

 

I can also foresee a future where people are including images in data: urls and needlessly inflating PQs with images that 99% of GPS units cannot handle.

[geopt.org]

get the gpx for this one: http://coord.info/GC38V5Z

 

it has a 1.8MB gpx because of a huge description that includes a word image that is never shown!

[+The A-Team]

And there's also GC38V5Z from another topic. It has what I originally thought to be mal-formed HTML, but after some searching I realize it's actually an image embedded in the code, just like Lil Devil posited could happen. The single GPX file is 1.8 MB, over 24000 lines long, and contains 1.8 million characters. Even on my high-speed connection, the page takes 34 seconds to load on my PC, whereas most other caches will load up in a fraction of a second. The kicker is that the embedded image doesn't even seem to be a part of the cache. The 3 images displayed in the description are uploaded to the cache page, and there's no sign of the embedded image, presumably because the server is just ignoring those tags. Limiting the description length could help prevent this kind of messy Microsoft HTML code.

 

Edit: Looks like geopt.org beat me to it!

Edited March 7, 2012 by The A-Team

[+eigengott]

Here is a documented case of a cache with a 15K+ description borking up a PN-60. Seems the DeLorme plugin will automatically truncate the description, but when using PQs, there is no protection.

 

Similar for the Garmin Oregon series:

http://garminoregon.wikispaces.com/Geocaching#FAQ-GC6.%29%20Does%20the%20Garmin%20Oregon%20have%20a%20gpx%20file%20size%20limit?

 

So a single 10MB+ listing would kill paperless caching on it.

[cezanne]

Do you have examples of listings that are breaking paperless devices? I might be able to argue for a change to engineering if I can show them what is happening.

 

No, please do not make any changes. It is very important for example for my caches that I am offering in more than one language to not encounter the idiotic limits of some paperless devices. For caches offered in more than two languages, it gets even worse.

 

My caches are not suited at all for paperless caching anyway. One needs to prepare very carefully and needs paper anyway.

 

Also a lot of ECs need elaborate descriptions.

 

Cezanne

[cezanne]

Do you have examples of listings that are breaking paperless devices? I might be able to argue for a change to engineering if I can show them what is happening.

 

No, please do not make any changes. It is very important for example for my caches that I am offering in more than one language to not encounter the idiotic limits of some paperless devices. For caches offered in more than two languages, it gets even worse.

 

My caches are not suited at all for paperless caching anyway. One needs to prepare very carefully and needs paper anyway.

 

Also a lot of ECs need elaborate descriptions and many of the European ones (in particular the older ones) are offered in more than language.

 

Implementing the feature to separate different language versions might help, but still there will be caches that require very long descriptions due to their very nature.

 

You might consider the introduction of an attribute "not suited/recommended for paperless caching" however. I would set this attribute instantly for almost all my caches and it would allow cachers to filter out such caches.

 

Cezanne

[cezanne]

We are discussing with Engineering - no final decisions yet, but we are representing this point of view. We appreciate the discussion point, but let's please avoid sarcastic comments when we discuss these matters. Thank you.

 

Please consider that by introducing a length limit based on the wishes of some group of paperless cachers you are ruining the many hours of work some cachers have put into their elaborate caches (physical ones as well as many Earthcaches) that are not directed to the paperless audience anyway. In case my caches do not work any longer, I would be extremely frustrated and disappointed. I do not think that a single group with their preferences can somehow dictate how the others have to cache.

 

My suggestion to introduce an attribute "not recommended for paperless caching" could be an option to serve the needs of both groups.

 

Cezanne

[+Lil Devil]

I can see Cezanne's point, but I think a limit of 1 or 2 MB would eliminate the GPS-breaking nonsense that has been shown above, while still giving plenty of room for multi-language Earthcache descriptions.

[cezanne]

I can see Cezanne's point, but I think a limit of 1 or 2 MB would eliminate the GPS-breaking nonsense that has been shown above, while still giving plenty of room for multi-language Earthcache descriptions.

 

There are different forms of GPS-breaking and some of the examples linked in this thread have descriptions that are way shorter than some of my caches and than some of the caches I really enjoyed enormously.

 

Some GPS-units have troubles with the vast majority of ECs and other caches with longer descriptions - they break off the description at some very early point. Setting down the upper limit for the length of cache descriptions down to the limit which every unit used for paperless caching can work with ruins many caches.

 

I do not object against setting a limit that just excludes a few pathological cases (mostly not intended ones). The limit needs to be reasonable however and not be dictated by users of some particular type of GPS-units.

 

Caches like this one

http://www.geocaching.com/seek/cache_details.aspx?guid=bf1fbe4b-3df6-44e3-80ad-1ef4a93543be

(just an arbitrary example)

require a lot of effort and are not designed to be done in a paperless manner and spontaneously anyway.

 

 

Cezanne

[+The A-Team]

No, please do not make any changes. It is very important for example for my caches that I am offering in more than one language to not encounter the idiotic limits of some paperless devices. For caches offered in more than two languages, it gets even worse.

I don't think we need to limit cache descriptions to the paperless device limits. Like Lil Devil suggested, a limit of 1 or 2 MB would be more than sufficient. After scanning through your caches, "Near Quino's former home (Quino III)" seems to be one of the longest. When I download the GPX file, it's only 61 kB. "Apotheken in Graz - AiG" is even smaller at 44 kB. Really, unless a description has A LOT of fancy HTML, it shouldn't be very big and wouldn't be affected. It's just the occasional case of a cache that has over-used HTML or used a poor HTML editor (like MS Word) that seems to be causing these gigantic cache descriptions. Using your cache as an example, and assuming a limit of 1 MB, you could make your description 16 times longer and still be OK. Since you already have 2 languages, that means you could expand it to include up to 32 languages! I can't see any caches needing such a description.

[jholly]

Actually, after reading some of the comments in this thread I think Jeremy might want to re-think his position on the request to have a way to ignore all caches by a given cache owner. If the limit has been lifted and CO's make listings that brick the paperless units I could see a lot of people wanting to use that feature. If not adding to the ignore list, at least a checkbox on the PQ's and the API to ignore caches with a long description more than some number, say 3,000 characters? I can't imagine trying to read a 3,000 character description on a paperless unit. Or at least a number that the current crop of paperless units and smartphones support.

[cezanne]

No, please do not make any changes. It is very important for example for my caches that I am offering in more than one language to not encounter the idiotic limits of some paperless devices. For caches offered in more than two languages, it gets even worse.

I don't think we need to limit cache descriptions to the paperless device limits. Like Lil Devil suggested, a limit of 1 or 2 MB would be more than sufficient.

 

As I have mentioned above, I do not object against a limit that just weeds out occasional pathological examples due to bad html code or something the like.

I just do not want that a limit is introduced that is based on paperless device limits and weeds out many interesting caches.

 

I have not thought about whether 1 MB is reasonable or whether this is too tight. One would need to check with respect to some involved ECs. My caches have a long texts, but typically not many pictures. Some Ecs also need a lot of images.

 

Cezanne

[cezanne]

I can't imagine trying to read a 3,000 character description on a paperless unit. Or at least a number that the current crop of paperless units and smartphones support.

 

I can't either, but such caches are set up for a completely different audience. As I mentioned, I would instantly use an attribute not suited/recommended for paperless caching once it exists. The length is not the only reason why paperless caching might not be a good idea for some types of caches. So such an attribute could make sense also independently from the length issue.

 

Cezanne

Edited March 7, 2012 by cezanne

[+Lil Devil]

I have not thought about whether 1 MB is reasonable or whether this is too tight. One would need to check with respect to some involved ECs. My caches have a long texts, but typically not many pictures. Some Ecs also need a lot of images.

Images are irrelevant to this discussion. The current GPX format does not include images, and the upcoming GPX format will only include links to images.

[+Lil Devil]

Different, but related to this discussion, I would love to see data: urls added to the list of banned html in cache descriptions.

[cezanne]

I have not thought about whether 1 MB is reasonable or whether this is too tight. One would need to check with respect to some involved ECs. My caches have a long texts, but typically not many pictures. Some Ecs also need a lot of images.

Images are irrelevant to this discussion. The current GPX format does not include images, and the upcoming GPX format will only include links to images.

 

Thanks for this information - I need to admit that I am not using GPX-files and thus are not very familiar with what they store and what they do not store. Anyway, I think the limit should be above and not below the 100000 characters the OP commented upon.

 

Cezanne

[jholly]

I can't imagine trying to read a 3,000 character description on a paperless unit. Or at least a number that the current crop of paperless units and smartphones support.

 

I can't either, but such caches are set up for a completely different audience. As I mentioned, I would instantly use an attribute not suited/recommended for paperless caching once it exists. The length is not the only reason why paperless caching might not be a good idea for some types of caches. So such an attribute could make sense also independently from the length issue.

 

Cezanne

I have no objection to an attribute and I am sure you would religiously apply them to your listings. I can not say that about all other cache owners or future cache owners. We could insert a discussion on terrain 1 and wheelchair access here. That is why I suggested a checkbox in the PQ and also the ability for the API to not download caches that exceed a given long description size. Your free to make your long description what ever size you wish, I'm free to exclude them from my paperless unit, and if I decide to do one of your caches I'm free to print out the listing and take it with me. The attribute is nice, but probably not universally applied. The programmatic solution can be universally applied without regard to an attribute. And given a choice between the sledge hammer of ignoring all caches by a cache owner, I prefer the scalpel of a checkbox.

[geopt.org]

No, please do not make any changes. It is very important for example for my caches that I am offering in more than one language to not encounter the idiotic limits of some paperless devices. For caches offered in more than two languages, it gets even worse.

I don't think we need to limit cache descriptions to the paperless device limits. Like Lil Devil suggested, a limit of 1 or 2 MB would be more than sufficient.

 

As I have mentioned above, I do not object against a limit that just weeds out occasional pathological examples due to bad html code or something the like.

I just do not want that a limit is introduced that is based on paperless device limits and weeds out many interesting caches.

 

I have not thought about whether 1 MB is reasonable or whether this is too tight. One would need to check with respect to some involved ECs. My caches have a long texts, but typically not many pictures. Some Ecs also need a lot of images.

 

Cezanne

 

you should not have a problem, as the images are not included in a "normal" cache page... only these problematic cache descriptions created with ms word or similar have these codes that are not used! In a regular html page, with the image stored on the geocaching or another server, a image should not take more than 100 bytes or so in the html! You could have hundreds of pictures with a 1MB cache description limit! I don't think this is a problem!

[cezanne]

In the past there was a limit on the long description field (something like 5000 chars).

 

Definitely not. My Quino III cache has about 32000 characters in a tidied up version where I removed quite some material (for different reasons) about 2 years ago.

The original must have been close to 50000 characters. The cache is back from May 2004.

 

4000 is the limit for logs and I have to break up many logs into two parts. I do not have a single cache which works with 5000 characters.

 

Cezanne

[cezanne]

I can't imagine trying to read a 3,000 character description on a paperless unit. Or at least a number that the current crop of paperless units and smartphones support.

 

I can't either, but such caches are set up for a completely different audience. As I mentioned, I would instantly use an attribute not suited/recommended for paperless caching once it exists. The length is not the only reason why paperless caching might not be a good idea for some types of caches. So such an attribute could make sense also independently from the length issue.

 

Cezanne

I have no objection to an attribute and I am sure you would religiously apply them to your listings. I can not say that about all other cache owners or future cache owners. We could insert a discussion on terrain 1 and wheelchair access here. That is why I suggested a checkbox in the PQ and also the ability for the API to not download caches that exceed a given long description size. Your free to make your long description what ever size you wish, I'm free to exclude them from my paperless unit, and if I decide to do one of your caches I'm free to print out the listing and take it with me. The attribute is nice, but probably not universally applied. The programmatic solution can be universally applied without regard to an attribute. And given a choice between the sledge hammer of ignoring all caches by a cache owner, I prefer the scalpel of a checkbox.

 

I am perfectly fine with your suggestions (checkbox for PQ, option for using the API) - my attribute idea would complement your suggestions from a different angle.

 

I am not feeling comfortable, however, with weeding out automatically caches with longer descriptions for everyone and in particular not if the limit is so low as suggested by eigengott who started the discussion. A limit of say 5000 characters or 10000 characters would be much worse than what you refer to as sledgehammer above.

I welcome every sort of help that the site provides the cachers with to select what they want to obtain. I am just asking for enough flexibility in offering different styles of caches.

 

What I tried to say above is just that while I occasionally enjoy caches with extremely long descriptions, I would get tired already by reading even very moderate ones on a paperless device even in case the device is capable of displaying everything. I'm very bad in reading longer texts on small displays.

 

Cezanne

[+Markwell]

Hey - what about an automatically applied attribute for Long Description? If the long description is more than that 4,000 characters (the previous limitation), it gets an automatic attribute - whether or not the person applies it.

[+Markwell]

http://forums.Groundspeak.com/GC/index.php?showtopic=27665&view=findpost&p=358317

 

From the man himself:

There is no limit that I know of for the Cache's long description. The short description is limited to 500 characters.

[jholly]

Hey - what about an automatically applied attribute for Long Description? If the long description is more than that 4,000 characters (the previous limitation), it gets an automatic attribute - whether or not the person applies it.

Works for me.

[+niraD]

Hey - what about an automatically applied attribute for Long Description? If the long description is more than that 4,000 characters (the previous limitation), it gets an automatic attribute - whether or not the person applies it.

Works for me.

That sounds good, as long as it is possible to include caches with the Long Description attribute in a PQ or in an API download. Some may not want to include them, but others of us may.

[+Markwell]

Hey - what about an automatically applied attribute for Long Description? If the long description is more than that 4,000 characters (the previous limitation), it gets an automatic attribute - whether or not the person applies it.

Works for me.

That sounds good, as long as it is possible to include caches with the Long Description attribute in a PQ or in an API download. Some may not want to include them, but others of us may.

That's the whole thing about attributes. In a pocket query, you can include only the ones with a long description, exclude the ones with a long description, or ignore the length and get them all (the default setting).