You are asking a lot of things here, maybe too much for a single thread.

What about the engine you plan to use? Are you going to code all from scratch? A question like "How to load 3d world from file?" tell me that you're a beginner, and 99% you're approaching a task bigger than your current level.

Try to focus on a small, atomic part of the problem, and ask for that after some tries.

I am now having problems planning the design ... The game will be a 3d game... My actual problem is designing the world ... How to load 3d world from file?

You may be having trouble planning the design because you haven't narrowed down what you want to accomplish. The Supreme Architect created the world in seven days - but it is unknown how long He worked on the design prior to that. It seems likely, however, that He had a pretty good idea what He wanted before He started designing it.

With regard to loading the World from a file - there are scholarly dissertations that conclude that the Universe cannot be described by any means that takes less room that the Universe itself.

Suggestion: RUN, don't walk, away from your computer. Decide what types of "things" you want in your world. If you don't know where you're going, it's difficult to code the path. Develop a bit more detailed concept of the final product before you code the tools to build it.

Then, if you're going to use a component/entity approach, become familiar with it. That will give you a much better idea of what data you'll need to create, store, transfer and load it.

Note again, I do not need to render anything here, just need to manage collision detection and the actual 3 lists and entity interaction.

Some tough love comin' atcha'.

It appears you're still tripping all over yourself. You have lots of ideas about the general form of a fairly extensive app, but, from the questions you're asking, it seems apparent, however, that you're not familiar with the aspects of programming the concepts you want to incorporate.

As mentioned a couple times above, your first step should be to become familiar with the types of things you want in the app you're thinking about. Have you actually written a program that loads a height map, just a height map without entities, locations, collision engines, etc.? If not, then, per your request for suggestions: googling for "height map file" yields 164 million hits. Take a look at a few of them and try one or two to get a better understanding of what it takes to load a height map.

For other aspects you mentioned, do the same. E.g., try out a collision engine or two. Become familiar with what it takes to use one. That will provide you with a better idea of how to incorporate it into your program. Get experience with the individual pieces that make up the whole.

Just a comment: IF you're planning on graphics being part of your program, and you want to import, manage and save the state of a whole list of things, you really should consider what it will take to render them. That will influence greatly what form you'll want your import/export/management/collision data to be in.

Let's see if I got all the questions.

1. How to load 3d world from file?
2. How does that relate to underling containers of entities?
3. What are standard map file formats ...
4. ... what info do they include?
5. Do i split the world in x,y,z cell grid, maybe use some other approach?
6. How are the containers important in relation to client side/render engine?
7. is it possible to export (lets say from some terrain generator program) a heighmap, textures and navigation meshes, collision detection rules, etc?
8. How do I manage {a terrain scene}? As in, how do I get the size of the landscape (bounds of those 3 lists), so I can later place objects (trees, etc) to specific locations.
9. Can I use any existing solution for this?

1. First you figure out at high level what your game/app needs to do. Then you figure out what information you need to make that happen. Then you take this abstract information and sketch out a document specification where you describe how info x gets mapped to a certain set of bits and you get a file format out there. At that point you probably know already how to load it. I suggest writing your own format for engine use and go with standard formats for DCC tools.
2. In general, there will be a special structure being "the world". The world might be solid or not or include "solidity" info. If the world is nonsolid then it's likely there will be another special entity being "the physical world". The rest of the structures might be for example put a light here, there and there. They usually have a very bland correlation with the world, both graphical and physical, at this stage of your app. I strongly suggest using a physics library.
3. No standard.
4. ID based engines basically include (3). Unreal based engines are fairly more advanced but if you cut a lot of corners they're basically the same thing and you can bet at this 10,000ft of abstraction everything looks pretty much the same.
5. Splitting in fixed sized cells is relatively inflexible but some games go with it and they work fine. For a first iteration, I suggest to just reduce the batch count as much as you can and optimize your life by minimizing your efforts first. Then you figure out what you need with the experience you got from rigging up the prototype.
6. What are you asking here?
7. Yes... for some program... for some import filter... for some data.
8. Size of terrain is a 3D vector. Terrain has an origin which is a 3D vector. It might also have a orientation which is either a quaternion or a 3x3 matrix. Placing terrains is often not very different from placing entities, and entities are usually (but not always!) very loose on definition.
9. Yes, a pre-made engine. You will also get a ready to go toolchain. Have a look at Unity or UDK.