Data is read from files with the GeoDataParser framework in order to be displayed.
The Link between GeoData and GeoGraphicsItems has to permit:
Previously, GeoData has been accessed through shallow copy from the rendering objects. this posed problems as GeoData uses data sharing internally and updates in GeoData were thus not seen in Items.
Also, the Model-View framework from Qt has been used many times with various shades of success for that specific matter (see Model View status for more info).
A "Model" in the Model-view framework in Qt is an interface to facilitate access to lists of data from widgets which need not know what data is inside. The interface may sound nice, but the abstraction is a bit too much when the interaction between data and its representation increases. These "Model" are also not data stores in order to avoid the previous issue.
Multiple inheritance could be possible where GeoGraphicsItems would also be GeoNodes:
To display the GeoDataFeature- and GeoDataGeometry-objects we want to use GeoGraphicsItems on a global GeoGraphicsScene. This leads to the problem when to create the GeoGraphicsItems for displaying on the scene:
We should follow an Observer Pattern logic for the first goal whereas GeoGraphicsItems would observe the GeoData.
Multiple options are available for an observer pattern implementation:
After all, this is one of Qt's best success.
For reference, Qt4.6 snapshot doc regarding animation proposes for GraphicsItems to inherit QObject to receive signals from animation framework.
A less obtrusive solution is possible with some intermediary QObject-derived class which would manipulate GeoGraphicsItems when GeoData updates.
More info needed to see if it fits the observer solution...
A first glance at [ItemView-ng Project API] shows not much radical change in the model interaction compared to previous itemview...
We should think carefully about storing data to provide the second goal, so that editing is done in the GeoData and then updates happen in GeoGraphicsItems as a result.
It's unclear, if it is reasonable to save ALL GeoData* classes as a value, with "implicit sharing" making it fast. Multi-level data stored as a value is a bit complicated. This will be discussed in Marble/GeoData/PointerVsImplicitShare