Marble uses Qt's Model/View framework as a way to signal updates to a model to interested parts. In that respect, a Model class can wrap any possible data.
The multiple models in Marble each fit the purpose of feeding some GeoData classes to interested widgets. The way those models are fed could be improved however:
The solution to this is twofold:
This solution however is not a one size fit all, because an interested class with some knowledge of the GeoDataTypes for example would be far better off manipulating the methods of GeoData classes.
As a consequence, a choice should be made whether to access GeoData through the model-view framework (nice for a List Widget or for a generic presentation of 'data as a tree', really not so nice for a class which for example would like to calculate the bounding box of all geometric data of a GeoDataDocument, or even for the File read/write, as the knowledge of data types is really known).
There are multiple models with various levels of implementation. Some are needed, others should die...
Here is the list of Model class, and a description of how they are used.
It has signals/slots to react to files being added or removed in the FileManager.
It represents a data file, parsed into a GeoDataDocument tree structure.
It is used by the DataViewPlugin debug plugin (and is broken atm)
It represents the list of opened files. The FileManager appends the documents it opens.
It represents the list of all Placemarks of all opened files. the PlaceMarkManager appends all the placemarks after reading a file.
It should be replaced by a more generic model, which would hold all open documents and provide both features and geometries. It could also be replaced with a ProxyModel around this new model.