Each cell in the world has a terrain type. This type should be thought of as the predominant contents of the cell, whether it be open ground, forest, city streets, or the vacuum of deep space. The type can be anything you want, and should be adapted to fit the game you're designing. Sure, the real world has swamps, but if you're designing a game set in the Sahara, don't bother defining a swamp terrain type. Also, the type doesn't carry any preconceptions about elevation or climate, so you can have swamps at 20,000 feet just as easily as at sea level.
The limit on the number of terrain types is large (up to about 127, depending on the implementation), but in practice, 6-10 types offer variety without being confusing. Ideally, several of those types will be uncommon in the world, so that map displays will consist mostly of 3-4 types of terrain.
Some game designs involve entities that are very large and do not move around. Such entities could plausibly be represented either as non-moving units or as a distinct terrain type. To make the right choice, you need to consider the special characteristics you want to implement. Terrain cannot (usually) be changed during the game, nor can it be moved, but units can be damaged or belong to different sides. A realistic example of this choice occurs in the monster game - should a destroyed building become a "rubble-pile" unit or should the building stand on rubble-pile terrain and vanish when it is destroyed? Both choices are plausible; if the rubble-pile is a unit, then the original building is then on top of an empty city block, and after the building is destroyed, the rubble-pile unit can itself be cleaned off, exposing the empty city block again. However, you have to decide whether the rubble-pile unit belongs to a side, how it interacts with other units, and so forth. Rubble-pile terrain is simpler, but the players then get descriptions of brand-new buildings sitting in the midst of rubble-piles, which is confusing. This is a case where there is no "right" answer.