About the displacement map that MIGI said, I think we have some problems ,assume that we have a car on the terrain that moves from point A to point B,to finding the changes in height we must sample the the displacement map. now assume that we have 300~500 cars, i think this method cause to reduce texture bandwidth (this is just a think)!!!!!
i was just dealing with this issue myself.
all entity / unit / target movement for ground targets will need to reference game specific height map data of some sort, to set the "altitude" of the unit at its new position. for this reason, ground unit movement can not be totally de-coupled from game specific height map data, even using generic rectilinear kinematics. game specific collision checks during stepped movement is another intractable coupling between generic unit movement and game specific data.
its often a good idea to keep two separate representations of the world, one for graphics, and one for physics. using the graphics representation for doing physics stuff can sometimes be inefficient. using two representations can help address the issue you mention above.
you'll only need voxels to do arches and overhangs and stuff. if you don't need those, you can use a displacement mapped mesh of quads. since you're displacement mapping in the vertex shader, its automatically dynamic, based on the displacement map you use - which you can modify as needed before drawing.
for small maps you can use a single level map or chunks, made by hand in an editor.
for really big maps, you'll probably want to go procedurally generated heightmap and chunks.
texturing is just a matter of how bleeding edge you want to get.