It's important to be aware of some basic concepts about raster, including understanding what zones and regions are. So, here I have some points, lines and polygons, representing real world features with the vector data model. And now I'm going to convert them to the raster data model to compare. If you think of a raster data model as a grid of cells, then essentially what we're doing is imposing this grid on top of our vector data. Or you could just as easily be thinking of this in terms of imposing it on the real world. Either way, you're putting this group of cells over the thing that you're interested in, and then converting that into cell values. So, the rasterized version would look like this. So, notice that we have one color per cell, in other words, there's one value per cell. You can't have two different numbers inside one of those grid squares which we call cells. So, you'll notice that there's a loss of information that takes place when you convert from vector to raster. So, for example, there's little bits of the line here that are going to be missing. So that's not captured by the blue cells here and here. Same thing with this part here. You'll notice that there's parts of the green polygon here that are missing here, here and here. And you might be wondering, well, why is that? No matter how this is done, essentially, the basis of this is that you have to come up with some rules that need to be applied in order to decide which things become cells with values and which don't. So, those might be whether, for example, a line crosses through the middle of a cell, whether it touches any part of a cell, whether it's the majority of the cell. There's different rules that can be applied to this but what I'm just trying to get across here is that the fact that that is happening, and regardless of which of these rules there are, when you're dealing with real world features, and there's enough of these happening, there's going to be situations where part of that is going to be lost as it's converted from either the real-world to raster or vector to raster. And that's okay. It's not to say that this is a bad thing or you should ever use raster, it's really just a way of pointing out that this is a fact of life with the raster data model, is that that's what's happening. Now, you may say, well, then why don't we just use smaller cells? You can do that, but no matter how small the cells are, there will always be a little bit of this loss of information that takes place. So I just pointed that out. So, really, when we create a raster dataset, there aren't really any colors associated with that to begin with or even any kind of real-world features. I just like to think of it and this was the way I think it really is, is that there's just numbers in cells, that's all you have to work with. So, that's what I'm showing you here, is that, in this case we have some zeros and ones and twos and threes. And so those are what we started with as discreet objects in vectors, points, lines and polygons, those don't actually exist anymore. There are no individual features. You can't click on something to select a polygon. All you can do is say, I have cells with a value of two, let's select those values and then we can decide what those values of two represent, or maybe isolate some of those twos that are connected to each other, that are spatially contiguous as we would say. But I'm just trying to make this clear as that, its really easy with the vector data model to just click on a polygon, you see that as an individual record in a table, you can select that, you can do something with it, export it or do a calculation. With raster, it's a different way of approaching things. It's a different way of thinking really, is that you have to get your head around this idea that you're just working with cells, with numbers. Now, of course we can assign colors to those numbers to help us interpret what we're seeing and to be able to tell things apart, but that's really just something that we do for ourselves, that's not really being stored in the data per se. So, one raster concept that's really important to understand is the idea of a raster zone. Raster zone is just a way of describing cells in a data set that all have the same value, okay? So, for example here, we have cells with a value of zero. All of those cells with a value of zero together would be referred to as one zone. Then we have another zone for the cells that have a value of one, another zone for the cells that have a value of two, and another zone for the cells that have a value of three. So, here we have four different zones in our dataset. And this isn't just me wanting you to memorize terminology for its own sake, you'll notice as we go along and as you start to work with raster yourself, is it's just a way of being able to refer to things in a shorthand, or to be more efficient, when you're setting things as parameters in a tool or when you're talking to somebody else about a dataset, is you have to know how to refer to these things and that's the kind of terminology that we use. So, here these are raster zones. So, again as a comparison, I've got some vector data that I'm going to convert into raster. These are real polygons for land use for part of Toronto. I've zoomed in quite a bit here just so you can see the details a little more clearly. And really it doesn't matter too much at this point what those zones are. Just accept that they're different polygons with different attributes. So, this is the rasterized version of that vector dataset. So, in the software, you can pretty easily convert back and forth from raster to vector, vector to raster, and the software now is very good at being able to work with either type of data model. There's lots of tools available to use both. Long ago, when I first started studying and using GIS, you had separate software for raster versus vector, and that was just the way it was, and so it was actually quite difficult to work back and forth between the two. We've come a long way since then, and it's really nice that we have these tools so you can conveniently go back and forth between them depending on what it is that you're doing and what you think which tools would be most appropriate. So, you'll notice here that there's this kind of staircase effect that happens when you go from, especially with any kind of diagonal line, in a vector to a raster. That's just an artifact or something that's going to take place when you rasterize data. Again, you could use smaller cells but you'll still end up with that staircase, you just have to zoom in more to see it, but it's always going to be there in one degree to another. Here's a comparison between the original vector boundaries and the raster boundaries. Again you can see there's that loss of information, it's not captured exactly, correctly, when you go over to raster. I don't mean over emphasize this. I just want you to see the difference between the two different models. So, as I was saying, with the vector model, you can select a polygon such as this one here, and you can open up the attribute table. And the whole idea of the vector data model is that you can have one record in the attribute table for each of the features in your feature class. So, here I have one polygon that I've selected. It has the category of employment industrial. And I could do this with any of them of course. And like I was saying before, you can then do whatever you want with that selection. You can create a buffer around it or export that one thing on its own or use that as part of another selection, but you have that convenience with the vector model of having that way of being able to select individual features and see the associated record with it in the attribute table. So, there's one record per polygon. With the raster version of this data, there are no polygons. If we open up the attribute table, you'll see that there is no individual records for each feature. All we have is one entry per zone. So, we have values of one that in this case happen to represent open space. We have values of two that represent commercial and so on. Just to make sure this is clear is that, things like open space and commercial aren't being stored in the cells. The only thing that gets stored in the cell is a number and then it's up to us to be able to associate that number with some other attributes that make more sense to us from probably are more meaningful to us. So, here just so it's clear. No individual polygons, just cells with the same value. So, as a quick little quiz, how many zones are there in this image? Well, if we look at the attribute table for this, we see that there are five different values, each zone is represented by a value or values or zones. So, that means if there's five different values, there's five different zones. Now, within each zone, you can have more than one region. So, regions are cells that have the same value but that are also contiguous. So, contiguous just means that they share a boundary with each other or they touch each other. So, one zone can have many regions. So, what about this? When this situation, when you see two cells that are diagonal, that are only touching by that little corner, are those contiguous? Would we define those as being part of the same region or not? It depends on how we want to treat this situation. There's actually two different options available to us in the software. If we use rook's case, this is a term that's adopted from chess. If you are familiar with chess, the rook can only move horizontally and vertically and so, if we have a cell that we're considering in terms of what other cells are contiguous or attached to it, are considered adjacent to it, if you want to think of it that way are touching. Then because the rook can only move horizontally or vertically, then the only cells that would be considered contiguous with the rook's case, would be these blue cells. So, in that case, those two cells with the values of two would not be considered contiguous. If we use a different chess term, which is queens case, if you're familiar with chess the queen is able to move horizontally and vertically but also diagonally. So, if we take that same cell and we're trying to decide what's contiguous with it, then all of the cells around it would be considered contiguous. So, in this case, those two cells that are highlighted in red there would be considered contiguous and we'd be connected. So, why am I telling you about rook's case in Queen, s case and regions, it's just another way of being able to refer to the type parts of a raster dataset and also to decide how you want to treat the things that you're mapping. So, for example, if we look at the blue cells here that I have that have a value of two, what are those two's representing? So, I've colored them blue here. I guess I was thinking that I would sort of indicate that they're like a river. So, if that was a river and we've rasterized it in a way that some of them are only touching by the corners, then we would want to use queen's case in order to make sure that those cells are considered to be contiguous with one another. So, if we're trying to do something like flow modeling or something where we wanted make sure that they're treated as though they're connected, then we would want our regions to be defined using queen's case. However, if those two's represented say buildings, it's quite possible that those are actually two corners of two different buildings that happened to look like they're connected but aren't really, in which case maybe the rook's case would be more appropriate. So, you do have to think about the data that you're using or the features that you're mapping and whether it makes more sense to treat them as rook's case versus queen's case. So, this is just an example of one of the raster tools where you are presented with the option of having rook's case or queen's case. Of course, I'm calling them those because those are the generic terms that are used but in Esri software the option or the parameter that you're setting here a is referred to as the number of neighbors to use. I guess they're just opting for more plain language and so the options are either four neighbors or eight neighbors but that's exactly the same thing as I was just saying that would be rook's case versus queen's case. So, if we look at this in terms of this dataset, then we have different numbers of regions depending on which case we're using. So, with rook's case here, we have the cell values of zero that are actually two different regions. So, even though some of those are touching by the corner with rook's case would not be considered to be connected or contiguous and so this would be one region of zeros and this a whole other section over here would be a whole other section or region of zeros. With the purple ones, they are completely separate from one another. The ones and so those would be the lone regions. Each of those were three regions there, with the two's, we actually would have five regions. So, because we're not counting anything that's connected by a corner, this is a separate region from that. These are a separate region, that's a separate region, that's a separate region. So, we have one, two, three, four, five different regions within that zone with values of two. Again, it depends on what you're mapping was to whether that makes sense. In this case, intuitively I'm kind of thinking that doesn't seem like it makes lot of sense but you need to be aware of these things so that you're you're making these choices consciously as you go along. Just to finish off with the green, the number three there's only two regions. This one seems fairly straightforward. We just have those two there. However, if we look at the same dataset with queen's case, then you'll see for the zone one, we only have one region because they are touching by the corners here and here and here and here and so that would be considered to be connected, those would be considered to be contiguous and so that whole zone with the zeros and it would all be considered as one region. So, one region inside one zone. The purple ones, those are the same because we don't really have to worry about that. It doesn't really matter which case it is. It's not connected to anything else. So, those would each be their own regions. So, three regions there. With the values of two, these are now considered one region because they're all touching by the corners. Then this would all be considered to be one region and then the values with three would be two separate regions as well. So, some of the features in this dataset, it does make a difference whether you go with rook's case or queen's case. So, always something to think about. If we go back to this example, how many regions are there in the green zone? Well, it depends on which case you're using. If you're using rook's case, then these would not be considered to be contiguous with one another because they're only touching diagonally. But if we use queen' s case, then they would be considered to be contiguous. So, with queen's case, we have one zone, two zones. With rook's case we have one, two, three. I hope that's clear. I just wanted to make sure that you are aware of the terminology and what those things mean. So, what a zone is, what a region is, what contiguity means, that's another way of saying contiguous and rook's case versus queen's case.
