Warning, /education/marble/docs/layermanagement.txt is written in an unsupported language. File is not indexed.

0002 I. Layer Management Class
0003 =========================
0005 Overview:
0006 ---------
0008 Currently Marble is already capable of visualizing different kinds of
0009 information based on different rendering classes which paint onto the
0010 map canvas.
0012 These classes:
0013  - apply texture mapping
0014  - and apply effects (e.g. colorizing textures, shading) to the
0015    resulting images.
0016  - add placemarks,
0017  - create vectors
0019 There are also classes which create items that display information or
0020 add controls on top of the whole map, called "floating items"
0021 (e.g. compass, scale bar, planned: overview world map, on-map
0022 navigation control ).
0024 However the whole process of rendering using those classes is
0025 hardcoded and not very flexible.
0027 The Layer Management Class ("LMC") is supposed to solve this issue. In
0028 short the new LMC concept aims to:
0030 - Create a QTPLUGIN (type: Lower-Level-API) architecture for the
0031   rendering process.
0033 - The backend functionality of the current rendering classes should go
0034   into BACKEND PLUGINS.
0036 - The backend classes should be QT-THREAD-based. (NYI)
0038 - The backend classes should encourage the Model-View concept and make
0039   use of Qt's INTERVIEW framework.
0041 - It should be possible to instantiate each backend class multiple
0042   times resulting in multiple layers.
0044 Note that we distinguish between "BACKEND"-classes and the objects
0045 based on the BACKEND-classes called "LAYERS".
0047 Due to different usage and technical requirements layers might either
0048 be:
0050   a) PROJECTION-BASED LAYERS (i.e. they get applied on top of the
0051      globe using the respective projection transformations).
0053   b) SCREEN LAYERS (i.e. they don't care about the projection and are
0054      layers "on top of the screen"
0056 "Execution order" of the different backends should be based on the
0057 following mechanisms:
0059   a) Each backend should provide "hardcoded" hints which describe
0060      dependencies (e.g. the texture colorization depends on the result
0061      of a texturemapping backend ) and allowed ranges for the
0062      rendering order (e.g. floating items should always be displayed
0063      on top of the map, a starry background needs to get drawn before
0064      the globe is painted)
0066   b) In Marble the structure of each map gets described in the map's
0067      .dgml file. So the layermanagement class needs to fetch
0068      information from the .dgml-parser about the different types of
0069      backends that get used in a map. The .dgml file also needs to
0070      provide information about the rendering order. 
0072      ( For more information on this topic have a look at dgml2.txt )
0075   c) For backend types where there are no hard requirements on the
0076      rendering order the LMC should decide itself which order to
0077      take. So if for example a custom backend-plugin doesn't get
0078      mentioned in the .dgml file the LMC should make a well-educated
0079      guess at which place inside the layer structure it would be best
0080      to insert the layer.
0082 According to the concept described so far it should be possible to
0083 paint different layers based on the very same backend directly on top
0084 of each other (e.g. a cloud layer on top of a satellite map layer.
0085 Normally this would result in two different layers.  However for
0086 reasons of performance it needs to be possible to merge the data into
0087 a single layer right from the start ("MergedLayer").
0089 This gets already done for placemarks in current SVN where data from
0090 different files gets merged into a single file. It also gets done
0091 already for clouds on top of the satellite image data. However what's
0092 missing is a more generic approach where a MergedLayerPainter class
0093 operates directly on the tiles based on the information it receives
0094 from the LMC.
0096 Before telling the MergedLayerPainter class which layers need to get
0097 painted on top of the tiles the LMC needs to check whether tiles or
0098 sourceimage data is available for the map. If there is no such data
0099 available the LMC needs to either notify the TileLoader that it needs
0100 to create tiles or the LMC will simply ignore the missing data and
0101 will skip asking the MergedLayerPainter to render the missing data.
0103 - The plugin-backend concept should allow CUSTOM BACKENDS created by
0104   third party developers.
0106 - Creating new geographical features on the map should happen using a
0107   Qt-like API (which would include the QPainter API to draw in screen
0108   coordinates):
0110   Code snippet:
0112     bool MarbleTestPlugin::render( GeoPainter *painter, ViewportParams *viewport, const QString& renderPos, GeoSceneLayer * layer )
0113     {
0114     painter->autoMapQuality();
0115     painter->setPen( Qt::red );
0117     GeoDataCoordinates flensburg( 9.4, 54.8, 0.0, GeoDataCoordinates::Degree );
0118     GeoDataCoordinates madrid( -3.7, 40.4, 0.0, GeoDataCoordinates::Degree );
0120     painter->drawLine( flensburg, madrid );
0122   ( For more information on this topic have a look at paintingmaps.txt )
0124 - It should be possible to use this Qt-style Geo-API either from
0125   outside the MarbleWidget or from inside the custom backend plugin.
0127 - It should be possible to create custom PROPRIETARY PLUGINS which are
0128   able to provide PROPRIETARY DATA in a manner that prevents exporting
0129   the whole data at once.
0131   Yes, while we strongly believe in free maps and free data we would
0132   also like to see proprietary apps use our widget - as always patches
0133   sent to us under a free license are very much appreciated.
0135 - Expiring layer data: The LMC should get notified about expiration
0136   dates of layer data. If layer data expires the LMC should trigger a
0137   reload of each chunk of data. Initially it would be enough if we
0138   supported reloading the whole data set of a single layer. In the
0139   future reloading single data chunks of a layer would be nice to
0140   have. (Examples for tile expiration: Real-time cloud layers,
0141   Improvements for OpenStreetMap data).
0143 - LMC should also work fine with OpenGL-based backend-plugins.
0145 FUTURE low-priority enhancements (for usage in "real" light GIS apps
0146 that might use Marble in the future):
0148 - Make it possible to specify custom changes to the rendering order of
0149   the layers using the LMC-API.
0151 - Make it possible to create layer groups. This would e.g. enable the
0152   user to show/hide many "grouped" layers at once.