Nano size?

[+bigcheesenz]

Can we please have a new 'size option' for Nano caches?

 

Some people call them Micro and some call them Other.

Edited December 1, 2015 by bigcheesenz

[+T.D.M.22]

Can we please have a new 'size option' for Nano caches?

 

Some people call them Micro and some call them Other.

 

Well since there is no official nano size (even though Groundspeak sells nano caches) what you're thinking of would be a micro.

 

Anyway, it's been suggested. Tons, and tons of times.

[+niraD]

+1

[+dprovan]

The longer I cache, the less I feel that an additional size "nano" would be useful. I'm perfectly fine with the micro size covering the entire range all the way down.

[+Die Nemos]

I don't see a need for an extra size as it is already described in the cache sizes:

 

Out of Container Explained:

micro: Less than 100ml. Examples: a 35 mm film canister or smaller, typically containing only a logbook or a logsheet. A nano cache is a common sub-type of a micro cache that is less than 10ml and can only hold a small logsheet.

[+Walts Hunting]

This issue comes up on a regular basis and the problems it would create with units trying to read a gpx file that contains unexpected data have been explained numerous times. i wouldn't hold your breath

[+J Grouchy]

It eventually has to stop because of ranges, no? I mean, there has to be a range beginning at zero and another range encompassing everything larger than a given volume. If the reasoning is to add a "nano" size to define zero up to a given volume, then logically you could make the argument that there needs to therefore be a "mega" size since "large" is not adequate to describe a shipping container or abandoned car or bomb shelter.

 

No. "Micro" is perfectly fine. The REAL problem is just getting people to actually properly categorize their tiny containers as micros. Labeling them as "other" makes no sense whatsoever unless they are intentionally trying to obfuscate the cachers looking for it.

[+ecanderson]

Locally, 'other' has been used extensively for both nano caches and things like mag strips and pouches that defy description. Technically, a mag strip is a 0ml container - not even a 'micro'.. This local custom seems to be working pretty well for us here since a consensus about its use in this manner is pretty well in place.

[+J Grouchy]

Locally, 'other' has been used extensively for both nano caches and things like mag strips and pouches that defy description. Technically, a mag strip is a 0ml container - not even a 'micro'.. This local custom seems to be working pretty well for us here since a consensus about its use in this manner is pretty well in place.

 

But that's not really a response. In fact, it reinforces my point, since a nano has interior volume...which falls under the "micro" category. I never would have argued that magnetic strips wouldn't be "other". Folks can argue about the meaning of "container", but anything that has an interior space for storing a log sheet is a micro. It's about as simple as can be, yet people still insist on calling nanos "other" size.

[+Harry Dolphin]

Locally, 'other' has been used extensively for both nano caches and things like mag strips and pouches that defy description. Technically, a mag strip is a 0ml container - not even a 'micro'.. This local custom seems to be working pretty well for us here since a consensus about its use in this manner is pretty well in place.

 

But that's not really a response. In fact, it reinforces my point, since a nano has interior volume...which falls under the "micro" category. I never would have argued that magnetic strips wouldn't be "other". Folks can argue about the meaning of "container", but anything that has an interior space for storing a log sheet is a micro. It's about as simple as can be, yet people still insist on calling nanos "other" size.

 

A magnetic strip is required to have a 'container' as well. Usually a ZipLock bag attached to the back.

[+J Grouchy]

Locally, 'other' has been used extensively for both nano caches and things like mag strips and pouches that defy description. Technically, a mag strip is a 0ml container - not even a 'micro'.. This local custom seems to be working pretty well for us here since a consensus about its use in this manner is pretty well in place.

 

But that's not really a response. In fact, it reinforces my point, since a nano has interior volume...which falls under the "micro" category. I never would have argued that magnetic strips wouldn't be "other". Folks can argue about the meaning of "container", but anything that has an interior space for storing a log sheet is a micro. It's about as simple as can be, yet people still insist on calling nanos "other" size.

 

A magnetic strip is required to have a 'container' as well. Usually a ZipLock bag attached to the back.

 

Then you get into the whole debate about whether the baggie inside the ammo can is the "real" container, making it a small or micro.

It's useless to talk about such distinctions.

Of the dozen or so magnetic strip caches I've found, only one has ever had a baggie on the bag. All the rest just have a sheet of paper adhered directly to the back.

That's all beside the point, anyway.

[+ecanderson]

A magnetic strip is required to have a 'container' as well. Usually a ZipLock bag attached to the back.

That will come as news to (I believe) every cache owner in this region who has placed a mag strip style device. The smart ones use one of the better brands of waterproof paper on the back, and nothing else other than the strip, with the front sometimes disguised as digits, or painted to match the mating surface, or similar camo. Local reviewers have certainly never expressed any misgivings about them, and they know there are plenty out here.

 

That said, a drilled out screw (we're not talking some decent sized bolt here, either) with a nasty < 0.5 ml volume deserves some sort of special annotation if the CO wishes to specify a size. "Anything smaller than a 'small'" covers a bit too much ground. As the spectrum of container sizes goes, the smaller they get, the more relevant it can be to have an appreciation for the size for which you're searching.

 

@Grouchy

If you do come out our way, plan to see this local custom observed in many instances. It may save you a bit of time in your searches when the containers get tiny. We've applied the ? to suit us. Don't do it in your neighborhood if it chafes. The note above to Harry explains WHY people have resorted to this practice here, and evidently in other areas of the world as well. Clearly, many communities see a need for a way to express sizes to a finer level of detail, and "?" is all that they have (for now) that won't break software and firmware.

[+The A-Team]

A magnetic strip is required to have a 'container' as well. Usually a ZipLock bag attached to the back.

That will come as news to (I believe) every cache owner in this region who has placed a mag strip style device. The smart ones use one of the better brands of waterproof paper on the back, and nothing else other than the strip, with the front sometimes disguised as digits, or painted to match the mating surface, or similar camo. Local reviewers have certainly never expressed any misgivings about them, and they know there are plenty out here.

AFAIK, such caches haven't been acceptable for many years. I just did some quick searching and found posts from Keystone and briansnat going back to at least 2012 saying that such caches wouldn't be published. Existing ones may be grandfathered beyond a certain date (I'm not sure), but new ones aren't supposed to be published (assuming the reviewer knows).

[+J Grouchy]

@Grouchy

If you do come out our way, plan to see this local custom observed in many instances. It may save you a bit of time in your searches when the containers get tiny. We've applied the ? to suit us. Don't do it in your neighborhood if it chafes. The note above to Harry explains WHY people have resorted to this practice here, and evidently in other areas of the world as well. Clearly, many communities see a need for a way to express sizes to a finer level of detail, and "?" is all that they have (for now) that won't break software and firmware.

 

As I've said before, just because it's done that way doesn't make it correct. The line had to be drawn somewhere and anything LESS THAN that line fits into one category. Perhaps you'd rather "small" be grown to include magnetic keyholders and film canisters (many are already labeled as such, so it wouldn't be a stretch)...but "micro" is pretty clearly defined and I'm just not understanding why "nano" needs its own special category.

[+ecanderson]

A magnetic strip is required to have a 'container' as well. Usually a ZipLock bag attached to the back.

That will come as news to (I believe) every cache owner in this region who has placed a mag strip style device. The smart ones use one of the better brands of waterproof paper on the back, and nothing else other than the strip, with the front sometimes disguised as digits, or painted to match the mating surface, or similar camo. Local reviewers have certainly never expressed any misgivings about them, and they know there are plenty out here.

AFAIK, such caches haven't been acceptable for many years. I just did some quick searching and found posts from Keystone and briansnat going back to at least 2012 saying that such caches wouldn't be published. Existing ones may be grandfathered beyond a certain date (I'm not sure), but new ones aren't supposed to be published (assuming the reviewer knows).

Had no idea. We have had that style of cache here in Colorado for many years, and new ones are still being published. Had several more new ones in our area last month. Add to that the fact that we've had several different reviewers of that period. If possible, toss me one of the more recent links that you referenced, or give me an idea of how you searched.

[+ecanderson]

As I've said before, just because it's done that way doesn't make it correct. The line had to be drawn somewhere and anything LESS THAN that line fits into one category. Perhaps you'd rather "small" be grown to include magnetic keyholders and film canisters (many are already labeled as such, so it wouldn't be a stretch)...but "micro" is pretty clearly defined and I'm just not understanding why "nano" needs its own special category.

Because looking for a 35mm film can and looking for something smaller than the brass from a .22 short are to many cachers two rather different endeavors.

 

If you look at the current layout, the biggest difference in sizes is a 2X order of magnitude, with others having less size difference:

 

Nano (per gc.com) min >0 ~ max 10ml

Micro = min >0 ~ max 100ml (overlapping the above)

Small = min 100ml ~ max 1000ml (1l)

Regular = min 1000ml ~ max 20000ml (20l)

Large = min 20000ml

 

So the smaller containers run 10X the potential size of the size below, and a regular runs 20X the potential size of a small.

 

WHY are those relevant? They change the nature of the search. Even a regular vs. large search may be approached differently due to the site and its possible hiding places. Size does matter when conducting a search.

 

What happened? When laying out the original specs, gc.com really never anticipated that containers might become popular that were again a full order of magnitude SMALLER than the maximum size of a Micro. There are many containers out there of 2ml internal volume or less (sample tubes, 'blinky' nanos, etc.) and the approach to searching for one of those may well require an entirely different approach, just as would be the case for searching for a 'regular' vs. a 'small'. And the change in approach, after all, is the entire point for requesting that COs include a size in their listings to begin with.

 

gc.com's own definitions appreciate the order of magnitude difference, as is evident in their own description of a 'micro':

"micro: Less than 100ml. Examples: a 35 mm film canister or smaller, typically containing only a logbook or a logsheet. A nano cache is a common sub-type of a micro cache that is less than 10ml and can only hold a small logsheet."

 

As the process for adding another size definition creates massive headaches in so very many ways and would break so much legacy firmware and legacy software that the chances of seeing it added are about nil, and I think those that give it some thought understand this. So as to flag these caches for finders in both physical and online searches, the use of the "?" has been adopted in many regions as a means of indicating that you're up against something truly tiny. That will either inform your search methods, or for some, will let you know that you don't want to be looking for them.

 

So as I say, you can complain that it isn't right to your way of thinking, but it's sensible when you look at the existing established sizes and their relative scales, and it's being used quite successfully by owners and finders alike as a much appreciated workaround to a quite intractable firmware/software issue, so get over it.

[+niraD]

A magnetic strip is required to have a 'container' as well. Usually a ZipLock bag attached to the back.

That will come as news to (I believe) every cache owner in this region who has placed a mag strip style device. The smart ones use one of the better brands of waterproof paper on the back, and nothing else other than the strip, with the front sometimes disguised as digits, or painted to match the mating surface, or similar camo. Local reviewers have certainly never expressed any misgivings about them, and they know there are plenty out here.

AFAIK, such caches haven't been acceptable for many years. I just did some quick searching and found posts from Keystone and briansnat going back to at least 2012 saying that such caches wouldn't be published. Existing ones may be grandfathered beyond a certain date (I'm not sure), but new ones aren't supposed to be published (assuming the reviewer knows).

I recall a recent forum post from a reviewer that explained that a magnetic strip with a separate log sheet stuck to it is okay, but that a magnetic strip that is painted so finders sign the magnetic strip itself is not okay. The magnetic strip forms a container for the separate log sheet, even if the log sheet is stuck to the magnetic strip with tape or adhesive. But if finders sign the magnetic strip itself, then you don't have a separate container and log sheet.

 

I don't have a link right now though...

[+L0ne.R]

1449311771[/url]' post='5551812']

1449098281[/url]' post='5551427']

1449096414[/url]' post='5551419']

1449009459[/url]' post='5551162']

A magnetic strip is required to have a 'container' as well. Usually a ZipLock bag attached to the back.

That will come as news to (I believe) every cache owner in this region who has placed a mag strip style device. The smart ones use one of the better brands of waterproof paper on the back, and nothing else other than the strip, with the front sometimes disguised as digits, or painted to match the mating surface, or similar camo. Local reviewers have certainly never expressed any misgivings about them, and they know there are plenty out here.

AFAIK, such caches haven't been acceptable for many years. I just did some quick searching and found posts from Keystone and briansnat going back to at least 2012 saying that such caches wouldn't be published. Existing ones may be grandfathered beyond a certain date (I'm not sure), but new ones aren't supposed to be published (assuming the reviewer knows).

I recall a recent forum post from a reviewer that explained that a magnetic strip with a separate log sheet stuck to it is okay, but that a magnetic strip that is painted so finders sign the magnetic strip itself is not okay. The magnetic strip forms a container for the separate log sheet, even if the log sheet is stuck to the magnetic strip with tape or adhesive. But if finders sign the magnetic strip itself, then you don't have a separate container and log sheet.

 

I don't have a link right now though...

 

Is there anything in the Help Centre? There's a CO around here that hides containerless signs. I'd like to point to the guideline in my log.

[+ecanderson]

[i recall a recent forum post from a reviewer that explained that a magnetic strip with a separate log sheet stuck to it is okay, but that a magnetic strip that is painted so finders sign the magnetic strip itself is not okay. The magnetic strip forms a container for the separate log sheet, even if the log sheet is stuck to the magnetic strip with tape or adhesive. But if finders sign the magnetic strip itself, then you don't have a separate container and log sheet.

 

I don't have a link right now though...

I'm not sure I'm following the distinction you are making 100% (probably because it's so obvious!), but what we see here are either painted blank mag strips or mag strips pre-decorated (perhaps mag numbers) or mag strips with some kind of outside overlay (again, could be numbers or anything else for camo) where a strip of Write-in-the-Rain or similar quality paper is being affixed to the back with some kind of adhesive. That seems to be what you describe in the first instance above . I'm not sure what your second instance represents ... a logless cache? That, I agree, would be completely unacceptable, but I'm not seeing or talking about anything like that. Harry seems to have run across something that nixes the use of the former, though, and requires some kind of container with actual volume (pouch, ZipLoc, etc.). THAT comes as news. Edited December 5, 2015 by ecanderson

[+niraD]

Is there anything in the Help Centre? There's a CO around here that hides containerless signs. I'd like to point to the guideline in my log.

I think it's just the current interpretation of this guideline:

 

Geocache containers include a logsheet or logbook.

For all physical caches, there must be a logbook, scroll or other type of log for geocachers to record their visit.

 

I didn't find anything more illuminating in the Help Center.

[+L0ne.R]

Is there anything in the Help Centre? There's a CO around here that hides containerless signs. I'd like to point to the guideline in my log.

I think it's just the current interpretation of this guideline:

 

Geocache containers include a logsheet or logbook.

For all physical caches, there must be a logbook, scroll or other type of log for geocachers to record their visit.

 

I didn't find anything more illuminating in the Help Center.

 

That's too bad. I can see the cache owner interpreting "or other type of log for geocachers to record" as permission to allow them to sign the back of a sign, or magnetic strip.

[+J Grouchy]

As I've said before, just because it's done that way doesn't make it correct. The line had to be drawn somewhere and anything LESS THAN that line fits into one category. Perhaps you'd rather "small" be grown to include magnetic keyholders and film canisters (many are already labeled as such, so it wouldn't be a stretch)...but "micro" is pretty clearly defined and I'm just not understanding why "nano" needs its own special category.

Because looking for a 35mm film can and looking for something smaller than the brass from a .22 short are to many cachers two rather different endeavors.

 

If you look at the current layout, the biggest difference in sizes is a 2X order of magnitude, with others having less size difference:

 

Nano (per gc.com) min >0 ~ max 10ml

Micro = min >0 ~ max 100ml (overlapping the above)

Small = min 100ml ~ max 1000ml (1l)

Regular = min 1000ml ~ max 20000ml (20l)

Large = min 20000ml

 

So the smaller containers run 10X the potential size of the size below, and a regular runs 20X the potential size of a small.

 

WHY are those relevant? They change the nature of the search. Even a regular vs. large search may be approached differently due to the site and its possible hiding places. Size does matter when conducting a search.

 

What happened? When laying out the original specs, gc.com really never anticipated that containers might become popular that were again a full order of magnitude SMALLER than the maximum size of a Micro. There are many containers out there of 2ml internal volume or less (sample tubes, 'blinky' nanos, etc.) and the approach to searching for one of those may well require an entirely different approach, just as would be the case for searching for a 'regular' vs. a 'small'. And the change in approach, after all, is the entire point for requesting that COs include a size in their listings to begin with.

 

gc.com's own definitions appreciate the order of magnitude difference, as is evident in their own description of a 'micro':

"micro: Less than 100ml. Examples: a 35 mm film canister or smaller, typically containing only a logbook or a logsheet. A nano cache is a common sub-type of a micro cache that is less than 10ml and can only hold a small logsheet."

 

As the process for adding another size definition creates massive headaches in so very many ways and would break so much legacy firmware and legacy software that the chances of seeing it added are about nil, and I think those that give it some thought understand this. So as to flag these caches for finders in both physical and online searches, the use of the "?" has been adopted in many regions as a means of indicating that you're up against something truly tiny. That will either inform your search methods, or for some, will let you know that you don't want to be looking for them.

 

So as I say, you can complain that it isn't right to your way of thinking, but it's sensible when you look at the existing established sizes and their relative scales, and it's being used quite successfully by owners and finders alike as a much appreciated workaround to a quite intractable firmware/software issue, so get over it.

 

I'd argue searching for a small bison tube and searching for a nano is NOT that much different.

I'd also like to know why describing it as "other" even helps anyway.

 

You're really over-thinking it. Nanos are "micro" size. It's so amazingly uncomplicated to classify them as such.

[+Walts Hunting]

1449311771[/url]' post='5551812']

1449098281[/url]' post='5551427']

1449096414[/url]' post='5551419']

1449009459[/url]' post='5551162']

A magnetic strip is required to have a 'container' as well. Usually a ZipLock bag attached to the back.

That will come as news to (I believe) every cache owner in this region who has placed a mag strip style device. The smart ones use one of the better brands of waterproof paper on the back, and nothing else other than the strip, with the front sometimes disguised as digits, or painted to match the mating surface, or similar camo. Local reviewers have certainly never expressed any misgivings about them, and they know there are plenty out here.

AFAIK, such caches haven't been acceptable for many years. I just did some quick searching and found posts from Keystone and briansnat going back to at least 2012 saying that such caches wouldn't be published. Existing ones may be grandfathered beyond a certain date (I'm not sure), but new ones aren't supposed to be published (assuming the reviewer knows).

I recall a recent forum post from a reviewer that explained that a magnetic strip with a separate log sheet stuck to it is okay, but that a magnetic strip that is painted so finders sign the magnetic strip itself is not okay. The magnetic strip forms a container for the separate log sheet, even if the log sheet is stuck to the magnetic strip with tape or adhesive. But if finders sign the magnetic strip itself, then you don't have a separate container and log sheet.

 

I don't have a link right now though...

 

Is there anything in the Help Centre? There's a CO around here that hides containerless signs. I'd like to point to the guideline in my log.

 

You might feel you are doing some sort of community good but will most likely be labeled "Cache Cop" and generate some hostility. If you don't like his caches just put them all on your ignore list and move on. You might want to give your plans some serious thought first.

[+niraD]

I'd argue searching for a small bison tube and searching for a nano is NOT that much different.

Well, if the small Bison tube is "less than 10ml", then it falls into the range Groundspeak describes as a nano cache. It certainly has the "can only hold a small logsheet" part.

 

You're really over-thinking it. Nanos are "micro" size. It's so amazingly uncomplicated to classify them as such.

You're really over-thinking it. A significant number of geocachers want to know whether a cache is a "large micro" (less than 100ml, but not less than 10ml) or a "small micro" (less than 10ml). These geocachers would like these two groups of cache containers to have separate size ratings. It's so amazingly uncomplicated to understand this desire.

[+ecanderson]

[You're really over-thinking it. Nanos are "micro" size. It's so amazingly uncomplicated to classify them as such.

If the fact that this practice is as widespread as it is hasn't yet caused you to begin to appreciate why so many have adopted it (even if you would not do so yourself, which no one requires), you may in turn be underthinking it. This practice didn't come into being without cause. Your fellow cachers didn't adopt it because they had nothing else to do on a Sunday afternoon. They felt it would assist them in playing the game. You just don't appreciate that perspective -- which is OK, but is insufficient to call their practice 'wrong'. It's making the best of an otherwise impossible software situation at Groundspeak and every GPS manufacturer that doesn't update code for 10 year old units. It's a situation that seems to have been acknowledged here by Groundspeak as the real reason that an additional 'nano' size will probably never be formally adopted.

 

Looking at it from another perspective (the GPS firmware and PC software side), it's a shame that something as simple as the addition of new and unexpected content to an XML element should cause any piece of code to fail. When parsing XML, any decent coder would never assume that the input data was golden, and would have good fallback procedures in place to account for unexpected content within an element. Encountering an unknown something that is as trivial as <Groundspeak:container>nano</Groundspeak:container> should, competently coded, fall back to something reasonable (in this case, quite possibly "?" or "X"), not cause some sort of grief. Bounds checking and list checking against input data, along with robust fallback positions for 'problem' input, is SOP, especially THESE days where security vulnerabilities can result. The only time you can fairly get away with less is if you control the input data as well as the parser that will be eating it, and even then, it's poor practice.

 

In short, adding 'nano' shouldn't have been such a PITA for legacy equipment and apps to begin with. At least it shouldn't have broken anything.

[+ecanderson]

Hey - if nothing else, I'm coming to more fully appreciate your caching handle.

[+on4bam]

Around here nano's have been "other" most of the time but "other" is also used for larger objects like a 50cm wooden log with a hole that has a container inside of for a fake magnetic "high voltage" sign.

[+J Grouchy]

[You're really over-thinking it. Nanos are "micro" size. It's so amazingly uncomplicated to classify them as such.

If the fact that this practice is as widespread as it is hasn't yet caused you to begin to appreciate why so many have adopted it (even if you would not do so yourself, which no one requires), you may in turn be underthinking it. This practice didn't come into being without cause. Your fellow cachers didn't adopt it because they had nothing else to do on a Sunday afternoon. They felt it would assist them in playing the game. You just don't appreciate that perspective -- which is OK, but is insufficient to call their practice 'wrong'. It's making the best of an otherwise impossible software situation at Groundspeak and every GPS manufacturer that doesn't update code for 10 year old units. It's a situation that seems to have been acknowledged here by Groundspeak as the real reason that an additional 'nano' size will probably never be formally adopted.

 

Looking at it from another perspective (the GPS firmware and PC software side), it's a shame that something as simple as the addition of new and unexpected content to an XML element should cause any piece of code to fail. When parsing XML, any decent coder would never assume that the input data was golden, and would have good fallback procedures in place to account for unexpected content within an element. Encountering an unknown something that is as trivial as <Groundspeak:container>nano</Groundspeak:container> should, competently coded, fall back to something reasonable (in this case, quite possibly "?" or "X"), not cause some sort of grief. Bounds checking and list checking against input data, along with robust fallback positions for 'problem' input, is SOP, especially THESE days where security vulnerabilities can result. The only time you can fairly get away with less is if you control the input data as well as the parser that will be eating it, and even then, it's poor practice.

 

In short, adding 'nano' shouldn't have been such a PITA for legacy equipment and apps to begin with. At least it shouldn't have broken anything.

 

If you're talking about nanos being more difficult to find, there is already a mechanism in place for classifying them: The D rating

If you're talking about not knowing what to look for...isn't that really part of the game? It's totally up to the CO whether or not they tell you what the container is. If they don't, the D rating more often than not reflects that added level of difficulty. If they DO tell you what you are looking for, then there is absolutely no need for a separate size classification.

 

So, again...amazingly uncomplicated. YOU, dear friends, are over-thinking (and trying to over-complicate) it all.

[+ecanderson]

Your logic seems to make the concept of "size" in a listing entirely unnecessary. Since most cachers would disagree...

[+dprovan]

If the fact that this practice is as widespread as it is hasn't yet caused you to begin to appreciate why so many have adopted it (even if you would not do so yourself, which no one requires), you may in turn be underthinking it.

Using "other" to mean "nano" is a standard limited to a few areas, so you can't really claim that the fact that it's widely used in your culture means everyone feels a need to make the distinction.

 

Looking at it from another perspective (the GPS firmware and PC software side), it's a shame that something as simple as the addition of new and unexpected content to an XML element should cause any piece of code to fail. When parsing XML, any decent coder would never assume that the input data was golden, and would have good fallback procedures in place to account for unexpected content within an element. Encountering an unknown something that is as trivial as <Groundspeak:container>nano</Groundspeak:container> should, competently coded, fall back to something reasonable (in this case, quite possibly "?" or "X"), not cause some sort of grief. Bounds checking and list checking against input data, along with robust fallback positions for 'problem' input, is SOP, especially THESE days where security vulnerabilities can result. The only time you can fairly get away with less is if you control the input data as well as the parser that will be eating it, and even then, it's poor practice.

 

In short, adding 'nano' shouldn't have been such a PITA for legacy equipment and apps to begin with. At least it shouldn't have broken anything.

I agree that in a perfect world, this should be a trivial change. But we live in the real world. From what I've seen, I'd guess that both the XML file design and the multiple pieces of code processing it were done by people that knew a lot about geocaching but didn't have enough experience in XML to anticipate this kind of change. (This happens a lot in software development, it's not a specific problem to geocaching.) This problem doesn't rule out adding the size nano, but it does mean such a change should result in a significant improvement, and I'm not really seeing it. After all, a CO can say "nano" in the description and accomplish 90% of the advantages cited for an official size.

 

Your logic seems to make the concept of "size" in a listing entirely unnecessary. Since most cachers would disagree...

No, the argument is that the distinction between micro and nano would go beyond the goal of the field to indicate a general size and, instead, force the CO to reveal a significant detail about the hide. There no slippery slope here that leads to having no size any more than there's a slippery slope to having a hundred sizes. The argument is that there's no important difference between "micro" and "nano".

[+The A-Team]

Looking at it from another perspective (the GPS firmware and PC software side), it's a shame that something as simple as the addition of new and unexpected content to an XML element should cause any piece of code to fail. When parsing XML, any decent coder would never assume that the input data was golden, and would have good fallback procedures in place to account for unexpected content within an element. Encountering an unknown something that is as trivial as <Groundspeak:container>nano</Groundspeak:container> should, competently coded, fall back to something reasonable (in this case, quite possibly "?" or "X"), not cause some sort of grief. Bounds checking and list checking against input data, along with robust fallback positions for 'problem' input, is SOP, especially THESE days where security vulnerabilities can result. The only time you can fairly get away with less is if you control the input data as well as the parser that will be eating it, and even then, it's poor practice.

 

In short, adding 'nano' shouldn't have been such a PITA for legacy equipment and apps to begin with. At least it shouldn't have broken anything.

I agree that in a perfect world, this should be a trivial change.

It is a trivial change.

 

When they added attributes to the GPX schema, they dealt with potential compatibility problems by designating the existing schema as version 1.0 of the Groundspeak extensions, and made a new version 1.0.1 that included the attributes. All they need to do is make version 1.0.2 and add the Nano size (and maybe make some other changes). Users with software/devices that can't handle the new information can keep using version 1.0/1.0.1. Users with software/devices that can handle the new information can use the new version 1.0.2. Over time, software/devices would gradually be updated to take advantage of the newly-available information and more users would be able to switch to 1.0.2.

[+J Grouchy]

Your logic seems to make the concept of "size" in a listing entirely unnecessary. Since most cachers would disagree...

No, the argument is that the distinction between micro and nano would go beyond the goal of the field to indicate a general size and, instead, force the CO to reveal a significant detail about the hide. There no slippery slope here that leads to having no size any more than there's a slippery slope to having a hundred sizes. The argument is that there's no important difference between "micro" and "nano".

 

Pretty much.

[+The A-Team]

For those who see a significant difference between a nano and a micro, the same arguments could apply within the Large size. That is, my searching method would vary depending on whether the cache is a 5 gallon bucket or a 2000-square-foot house*. Does that mean we need "Small-Large", "Medium-Large", "Massive-Large", etc.? Do we really need separate size ratings to cover every order-of-magnitude of container volume?

 

What I'm trying to get at is that at some point, generalization needs to kick in and additional information can be provided in the description. For the house-sized cache, it could be rated as a Large and the description can say that you're looking for something really big. For a nano, it can be rated as a Micro and the description can say that you're looking for something really tiny.

 

*I'm sure I read somewhere about a house being used as a cache container

[+ecanderson]

No, the argument is that the distinction between micro and nano would go beyond the goal of the field to indicate a general size and, instead, force the CO to reveal a significant detail about the hide. There no slippery slope here that leads to having no size any more than there's a slippery slope to having a hundred sizes. The argument is that there's no important difference between "micro" and "nano".

Again, the issue is one of scale. The user base doesn't employ this technique without a reason. Some just don't agree with the reason.

No, nothing forces the CO to reveal a significant detail. The CO can leave out size altogether and specify it with an "X" and leave you to wonder if you're looking for a 55 gallon drum or a 2ml sample tube.

 

The argument that "there's no important difference between 'micro' and 'nano'" is belied by the fact that many seem to believe that there is, and that it is sufficient to warrant use of a different size attribute. If nobody thought it was important, nobody would bother.

 

As to your other argument, I have seen this technique employed both in various areas of North America and Europe (Farthest from home? GC1AJ6V, in Malaga). It's certainly not solely a feature here in our region. A quick review of my finds in GSAK indicates that I've found 551 of them with an "Other" ("?") size specified. Obviously there are some folks who find it useful whether you and Grouchy do or not.

Edited December 7, 2015 by ecanderson

[+dprovan]

It is a trivial change.

 

...All they need to do is make version 1.0.2 and add the Nano size (and maybe make some other changes).

Changing version number is pretty much the definition of a non-trivial change.

 

A trivial change is one where GS starts producing XML with the new size without even bothering to tell anyone. Most XML consumers start using and showing the new size without any development, others would report it as "micro" and need a minor correction to teach them the difference between micro and nano, and a few might say "unknown size" or some such and would need a minor fix before we'd really say they were working right. Once you say, "and no app will understand 'nano' until it goes through a development cycle to handle the new XML version number," you're way past an easy change.

[+The A-Team]

The CO can leave out size altogether and specify it with an "X" and leave you to wonder if you're looking for a 55 gallon drum or a 2ml sample tube.

That's no longer an option. When the new Cache Submission Process was rolled out in the May 13, 2014 release, the "Not chosen" size ceased to be an option. Existing caches using this size still exist, but existing caches can't be changed to this size and it can't be used when creating a new cache. All of the remaining sizes require the disclosure of at least a basic amount of information about the size of the container (either some generalized size information implied by the use of Micro, Small, Regular, or Large; or "See the cache description for information" for Other).

 

I'm seeing some people misusing the "Other" size as a replacement for "Not chosen", which isn't what it's meant for and just muddies the waters. "Other" is for:

Unusual geocache containers that just don't fit into other categories.

[+The A-Team]

It is a trivial change.

 

...All they need to do is make version 1.0.2 and add the Nano size (and maybe make some other changes).

Changing version number is pretty much the definition of a non-trivial change.

 

A trivial change is one where GS starts producing XML with the new size without even bothering to tell anyone. Most XML consumers start using and showing the new size without any development, others would report it as "micro" and need a minor correction to teach them the difference between micro and nano, and a few might say "unknown size" or some such and would need a minor fix before we'd really say they were working right. Once you say, "and no app will understand 'nano' until it goes through a development cycle to handle the new XML version number," you're way past an easy change.

When you put it that way, I agree and stand corrected. It would be a trivial change for Groundspeak (they already have support for multiple versions of GPX schema), but it wouldn't be trivial for the data consumers.

[+niraD]

For those who see a significant difference between a nano and a micro, the same arguments could apply within the Large size. That is, my searching method would vary depending on whether the cache is a 5 gallon bucket or a 2000-square-foot house*. Does that mean we need "Small-Large", "Medium-Large", "Massive-Large", etc.? Do we really need separate size ratings to cover every order-of-magnitude of container volume?

Given that micro caches make up slightly more than half the available caches, it might not be a bad idea to subdivide them into larger (10ml to 100ml) micros and smaller (less than 10ml) nanos.

 

In contrast, large caches make up less than 1% of the available caches, so there doesn't seem to be as much need to subdivide them.

[+ecanderson]

I think the A-Team missed it with all of that "Small-Large, Medium-Large, Massive-Large" business as well. In fact, that's not even a particularly good straw man considering that end of the size spectrum has never been questioned in this or any other nano thread. Both a 'medium-large' (a VW bus?) and 'massive-large' (a 4100' house?) in a field present pretty much the same profile.

 

Nobody is looking to subdivide anything on the low end any tighter than an order of magnitude, which is the same scale that is already being used from Regular on down through Small and to Micro. I find it telling that Groundspeak choose to go exactly another order of magnitude smaller in their own description of a 'nano'. No, we don't need 'separate size ratings to cover every order-of-magnitude', at least not on the HIGHER end. Within the range of field-normal coordinates, it's not like you're going to hide either the VW bus or a house where I might miss it. However, within the potentially difficult field-normal coordinate accuracy we often have in urban canyons and in spots in the mountains out here, searching for a nano vs. micro within the somewhat larger 'circle of error' is an issue, yes. A nano really can be orders of magnitude more difficult to find than the larger of micros. Nice to know what you're looking for .. a needle, or a spool of thread in the haystack.

[+J Grouchy]

I think the A-Team missed it with all of that "Small-Large, Medium-Large, Massive-Large" business as well. In fact, that's not even a particularly good straw man considering that end of the size spectrum has never been questioned in this or any other nano thread. Both a 'medium-large' (a VW bus?) and 'massive-large' (a 4100' house?) in a field present pretty much the same profile.

 

Nobody is looking to subdivide anything on the low end any tighter than an order of magnitude, which is the same scale that is already being used from Regular on down through Small and to Micro. I find it telling that Groundspeak choose to go exactly another order of magnitude smaller in their own description of a 'nano'. No, we don't need 'separate size ratings to cover every order-of-magnitude', at least not on the HIGHER end. Within the range of field-normal coordinates, it's not like you're going to hide either the VW bus or a house where I might miss it. However, within the potentially difficult field-normal coordinate accuracy we often have in urban canyons and in spots in the mountains out here, searching for a nano vs. micro within the somewhat larger 'circle of error' is an issue, yes. A nano really can be orders of magnitude more difficult to find than the larger of micros. Nice to know what you're looking for .. a needle, or a spool of thread in the haystack.

 

Which brings you right back to my point. There is already a system in place for rating difficulty. If the CO chooses to tell you what you are looking for, then there is no reason to add a new size category. If the CO chooses to NOT tell you and labels it a micro, the difficulty rating more often than not reflects that added level of difficulty and, again, there is no reason to add a new size category.

 

Really, it just seems to me that what you are TRULY asking for is for the COs to be more forthcoming on their cache pages exactly what type of container they used. Adding a new size category serves no real purpose beyond taking away the smallest level of uncertainty in your search. Are you REALLY trying to argue that "it's harder to find a nano!" should be the reason for changing the entire size classification system?

[+NYPaddleCacher]

It is a trivial change.

 

...All they need to do is make version 1.0.2 and add the Nano size (and maybe make some other changes).

Changing version number is pretty much the definition of a non-trivial change.

 

A trivial change is one where GS starts producing XML with the new size without even bothering to tell anyone. Most XML consumers start using and showing the new size without any development, others would report it as "micro" and need a minor correction to teach them the difference between micro and nano, and a few might say "unknown size" or some such and would need a minor fix before we'd really say they were working right. Once you say, "and no app will understand 'nano' until it goes through a development cycle to handle the new XML version number," you're way past an easy change.

 

Adding "Nano" as a cache size would not require a version change. The 1.0.1 schema (and I suspect the previous version as well) specifies that the container element is just a string without any constraints. That is, the value of the element can be *any* string, not just one of the standard values GS has been using (micro, small, regular, ...). When this discussion came up awhile back I hand edited a GPX file, changing the container element for a cache from Micro to "Nano" and downloaded it to my Oregon. It displayed Nano just fine. The problem is that some app developers *assume* that the container field will be one of the standard sizes (even though the spec does not enforce it) so that they can do something like test the value of the string and display an appropriate icon or something. If an app breaks because GS started to put Nano in that element that's the fault of the app developer.

[+ecanderson]

Are you REALLY trying to argue that "it's harder to find a nano!" should be the reason for changing the entire size classification system?

It's the reason for adding one category to the list, often discussed, if the CO wishes to do so. Nothing more. It serves no other purpose than providing all of the existing sizes from which the CO may choose when placing a cache.

 

Conflating the size vs. difficult factors isn't making any sense. Each element (size, difficulty and terrain) all provide some clue as to the nature of the search. You seem to suggest that with difficulty provided, there's really no point in adding 'size' to the equation at all. Why, one wonders, do we even need to bother with the size 'micro' if it doesn't change the nature of the search from searching for a 'small', and up and up.

[+ecanderson]

The problem is that some app developers *assume* that the container field will be one of the standard sizes (even though the spec does not enforce it) so that they can do something like test the value of the string and display an appropriate icon or something. If an app breaks because GS started to put Nano in that element that's the fault of the app developer.

True enough, and while there's certainly no reason not to test the value to create an icon or check a box, if the app breaks, you're quite correct that that's on the writer of the app/firmware. Assuming that the content will be 'one of the standard sizes' isn't a sufficiently robust approach to parsing and analyzing data in a decent piece of code. Never assume that source data will be what you expect, and be sure you've got some method for dealing with it when it's not! Learned that the hard way many years ago.

[+Nerre]

When there was the suggestion system (I think between 3 and 5 years ago) this was a suggestion that was over 10.000 upvotes. Still no nano type, so there seems to be no interesst from Groundspeak to ever provide it to the community.

 

For any decent app developer it should be not more than 10-15 minutes work to add one more type, unless they did pretty bad coding.

[+ecanderson]

When there was the suggestion system (I think between 3 and 5 years ago) this was a suggestion that was over 10.000 upvotes. Still no nano type, so there seems to be no interesst from Groundspeak to ever provide it to the community.

 

For any decent app developer it should be not more than 10-15 minutes work to add one more type, unless they did pretty bad coding.

Unfortunately, this hobby has been around long enough that there's a ton of legacy hardware out there whose firmware will never be touched again, and a few apps that have gone by the wayside as well. So however much time it should take, the effort won't be spent. Think Garmin could even find the project files for a Summit HC or probably even Mapsource?