User:Shereth/No Red Dots

No Red Dots is an unofficial name for the unofficial Updating Cities With, and Adding To The Infobox A .SVG Map Of That City's Location And Then Removing From City Articles All Old Maps That Are Either Inaccurate, Show Just A Dot On Them, or Were Made In MSPaint In About 23 Seconds project started by Ixnayonthetimmay. No Red Dots is a user subpage where I will put forth a few of my ideas regarding the non-project, as it is easier than trying to explain things piecemeal in back-and-forth user talk page comments.

What are red dots?


Back in the early days at Wikipedia a number of users created the so-called "Red Dot" maps for a number of US cities. These maps generally consisted of an outline of a state with the county divisions, and a red dot to denote the location of the city within that state. Most of these maps were created in PNG file format. While some cities have since received different types of maps, several still use this "Red Dot" map format.

Red dot maps were a great start to a more comprehensive mapping of US cities. Not only did they show the location of a city within the state but provided some additional visual context by showing the location of the city in relation to the county or counties that it resides in. Red dot maps were also quick and efficient and easy to generate.

Why no more red dots?
The simple answer : Cities are not dots.

The more comprehensive answer is that cities, as municipal corporations within the united states, have distinct geographical boundaries that are sometimes complex and sometimes very large. Some of the larger cities such as Jacksonville, Florida are nearly as large as the state of Rhode Island in terms of area. No one would think of representing Rhode Island as a red dot on an outline of the United States, now would they? It is no more appropriate to represent Jacksonville as a red dot on an outline of Florida.



Even if cities don't cover a vast expanse of land they can have complex and unusual boundaries. Unlike state boundaries which are set by relatively permanent means such as state constitutions, many cities grow and change through a series of annexations that often leaves them with unusual shapes. There aren't many cities which resemble a big red dot, no matter how far away from them you are.

By providing maps that show the actual outline of the city as it appears within the state, particularly when shown against neighboring cities, the reader is provided with much better visual context to judge just how big a city is and where that city is at in relation to other nearby geopolitical entities. Perhaps with a map like that they will understand just how you can pass a "Welcome to Los Angeles" sign on the freeway and be nowhere near downtown LA. And they won't expect a big red dot.

Why SVG?
Okay, so we'll get rid of the red dot maps to give the users better visual cues by which to judge a city's size and location. But what's this deal with SVG maps? Some folks have already taken the initiative to replace red dot maps with fancy municipal boundary maps. Like the one for LA above.

That map up there is a PNG image. It's what's called a raster graphic. Raster graphics are like a big grid of pixels, and work great for things like photographs that have thousands and thousands of pixels. But there is a catch. When you want to resize a raster image - stretch it out or shrink it down - the software has to make a decision. Certain pixels either have to be duplicated or omitted to make room in the new image. That's fine for complictaed photos where missing a few pixels won't be too noticeable, but in something with nice sharp lines, like a map, this can be a problem. Take a look at the map above, and you probably notice it looks a wee bit blurry. This is because the actual map is a lot bigger, and the browser had to shrink it down and lost a lot of pixels. Raster images only look right at certain specific sizes, and this can be bad for maps.



SVG are vector graphics. This means instead of a big collection of dots, it's really kind of a special set of instructions to tell the computer how to draw the image, such as how long to make a line, how thick to make it, where to curve it and so on. This would be bad for pictures, since there aren't many nice lines and shapes for the computer to draw. But it's great for maps, which really are just a few lines. Even better, if you have to stretch or shrink a vector image, you don't lose any parts of the drawing. The computer just recalculates how to draw it on a smaller scale.

Compare this map of Buckeye to the one from LA up above. Both images have been shrunk down quite a bit, and you can see a big difference in terms of which map looks sharper, cleaner and overall better looking. That's the beauty of vector graphics working in our favor, and that's why the No Red Dots unoffocial project is also about switching from PNG to SVG, and not just getting rid of red dots. And wouldn't you know, but that map of Buckeye was one of the first to come out of the unofficial project!

Arizona and Beyond
The unofficial project's initial scope is just the state of Arizona. Why? Because the two people participating live there, that's why! More than just that, though, is the handy set of circumstances that makes mapping Arizona easy. A large, wide open state with only 15 counties means only 15 base maps for the whole state. The cities tend to be large and wide open too, making them all around pretty easy to map out. Arizona is a logical choice for a testing grounds for this new mapping method.

But now that the maps for the state are practically done, where to next? Going county-by-county for other states seems logical at first, but you quickly run in to a few problems. As a general rule of thumb, as you move east, counties shrink. That means as you go from Arizona with its 15 counties, you wind up in places like Texas, with 254 counties, and 254 basic maps - quite the headache for the prospective amateur cartographer! In light of that it might seem to make more sense to try and tackle an extended project from another angle - map out major metropolitan areas first, and then consider mapping more rural counties at a later date.

That still leaves the mapper with another big problem, caused by little counties. Eventually you start to run in to cities that span an entire county all by themselves, or even worse, cities that span multiple counties. They exist. New York City encompasses five seperate counties all by itself. It would be fairly nonsensical to map out these counties individually, as you would be defeating the whole idea of creating maps for visual context.

The natural conclusion to that line of thought is to come up with a compromise. Map by counties when the metropolitan areas fit neatly within a single county, or map by metropolitan areas when they exceed county lines. But wait! Whose definition does one use in order to make this determination, and why does it matter?

I present, as a case in point, north-central Utah. It's a bit of a compromise - the counties are still large enough that individual cities don't start gobbling them up, but small enough that the metro area crawls over the lines. If you want to get an idea as to what the metropolitan Salt Lake City area is, well, it depends upon who you ask. One definition is to consider the Wasatch Front to be the metro area, and that might not be inaccurate. It is a series of essentially interconnected cities, with a least minimal suburban development between them. However, the urbanized area is extremely long and narrow, crossing over a number of county lines, rendering it a bit unweildy to map. Additionally it does not follow county divisions very well, and this is important for the sake of continuity - new maps should fit neatly along with old maps, and creating arbitrary division lines becomes problematic.



An alternative is to use the official Metropolitan Statistical Areas as defined by the Census bureau. The advantages are that these areas have defined boundaries, and furthermore these all follow county lines. Take for example the map of the Ogden-Clearfield MSA included here.