Frequently Asked Questions

Who can be an editor?

Anyone. The biggest part about being an editor is being able to work with the Lodge in question (or its collectors or child lodge for merged and superceded entities) to accurately capture the history and reflect that in the listings.

Why do you renumber issues?

For as great a resource as it was, the 2006 Blue Book still had many errors. Our goal (and the goal of ISCA's OAIG as well) is to accurately represent these listings based on real history, not someone's preferred numbering scheme. To that end, we list the old Blue Book 2006 entry number along with the current lodge-determined listing, so people can compare and update their lists.

Why do you list item types that are outside of insignia?

When we started, many of our SR-7A collectors already included mugs, pins, and other memorabilia in their collection listings. We specifically called out that we would be more than insignia as "The high-quality catalog for Scouting memorabilia". While we start with the ISCA 2017 OAIG documentation, there are some changes in the way we've implemented the database, and we leave it up to the lodge to determine how a flap or other issue should be cataloged.

Why don't you just use cell phone photos of patches?

Because there are dozens of sites with low quality or poorly lit images that don't help the collectorate when you have minor variations or other issues. We're focused on archival quality imagery: each patch could be printed at 300 dpi on a US Letter piece of paper. A scan gives you roughly equal lighting and minimizes many of the common pitfalls of photography, even with high-end DSLR cameras. When an item does not work well on a scanner (e.g. 3d objects, such as mugs, belt buckles, etc) we tend to use a photography and we try to shoot in a soft box with a good camera whenever possible. There are some images that are not as perfect as we'd like, as they are the best that was provided by the owner. Over time we hope to get better scans or photographs of those rarer pieces.

Why are Chapters considered "issuing entites" in PatchVault?

This is a programatic decision that we made to allow a few things. First off, PatchVault won't let an issuing entity have two issues with the same name. So if all chapters were just lumped under the lodge, you could not have two cX1 issues (per OAIG2017 numbering) with our database validations. So a Chapter is a child of a Lodge (which reflects reality), and then the issues of that Chapter are scoped under the chapter itself. We roll them up to display them at the Lodge level as well, but from a programming viewpoint, the Chapter owns the issue. The c prefix designator becomes irrelevant at that point, so we removed it.

Have a question? Send it in and we'll add it here!