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

0001 
0002 I. Layer Management Class
0003 =========================
0004 
0005 Overview:
0006 ---------
0007 
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.
0011 
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
0018 
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 ).
0023 
0024 However the whole process of rendering using those classes is
0025 hardcoded and not very flexible.
0026 
0027 The Layer Management Class ("LMC") is supposed to solve this issue. In
0028 short the new LMC concept aims to:
0029 
0030 - Create a QTPLUGIN (type: Lower-Level-API) architecture for the
0031   rendering process.
0032 
0033 - The backend functionality of the current rendering classes should go
0034   into BACKEND PLUGINS.
0035 
0036 - The backend classes should be QT-THREAD-based. (NYI)
0037 
0038 - The backend classes should encourage the Model-View concept and make
0039   use of Qt's INTERVIEW framework.
0040 
0041 - It should be possible to instantiate each backend class multiple
0042   times resulting in multiple layers.
0043 
0044 Note that we distinguish between "BACKEND"-classes and the objects
0045 based on the BACKEND-classes called "LAYERS".
0046 
0047 Due to different usage and technical requirements layers might either
0048 be:
0049 
0050   a) PROJECTION-BASED LAYERS (i.e. they get applied on top of the
0051      globe using the respective projection transformations).
0052         
0053   b) SCREEN LAYERS (i.e. they don't care about the projection and are
0054      layers "on top of the screen"
0055 
0056 "Execution order" of the different backends should be based on the
0057 following mechanisms:
0058 
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)
0065 
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. 
0071 
0072      ( For more information on this topic have a look at dgml2.txt )
0073 
0074 
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.
0081 
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").
0088 
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.
0095 
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.
0102 
0103 - The plugin-backend concept should allow CUSTOM BACKENDS created by
0104   third party developers.
0105 
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):
0109 
0110   Code snippet:
0111 
0112     bool MarbleTestPlugin::render( GeoPainter *painter, ViewportParams *viewport, const QString& renderPos, GeoSceneLayer * layer )
0113     {
0114     painter->autoMapQuality();
0115     painter->setPen( Qt::red );
0116 
0117     GeoDataCoordinates flensburg( 9.4, 54.8, 0.0, GeoDataCoordinates::Degree );
0118     GeoDataCoordinates madrid( -3.7, 40.4, 0.0, GeoDataCoordinates::Degree );
0119 
0120     painter->drawLine( flensburg, madrid );
0121         
0122   ( For more information on this topic have a look at paintingmaps.txt )
0123 
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.
0126 
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.
0130 
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.
0134 
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).
0142 
0143 - LMC should also work fine with OpenGL-based backend-plugins.
0144 
0145 FUTURE low-priority enhancements (for usage in "real" light GIS apps
0146 that might use Marble in the future):
0147 
0148 - Make it possible to specify custom changes to the rendering order of
0149   the layers using the LMC-API.
0150 
0151 - Make it possible to create layer groups. This would e.g. enable the
0152   user to show/hide many "grouped" layers at once.
0153 
0154