[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    KDE/kdeedu/marble
From:       Torsten Rahn <tackat () kde ! org>
Date:       2008-01-21 23:08:32
Message-ID: 1200956912.062076.19483.nullmailer () svn ! kde ! org
[Download RAW message or body]

SVN commit 764493 by rahn:


- More small adjustments



 M  +5 -0      TODO  
 M  +5 -4      docs/layermanagement.txt  


--- trunk/KDE/kdeedu/marble/TODO #764492:764493
@@ -39,6 +39,11 @@
     To get useful temperature/precipation/... maps we need to be able
     to add items to the legend in the .dgml file:
 
+    This is also a first step towards the new DGML version format that 
+    we need for the new layer management class.
+
+    see also: docs/layermanagement.txt.
+
 <Legend>
     <heading>Temperature</heading>
     <LegendItem>
--- trunk/KDE/kdeedu/marble/docs/layermanagement.txt #764492:764493
@@ -25,12 +25,13 @@
 	
 - "Execution order" of the different backends should be based on the following \
mechanisms:  a) each backend should provide "hardcoded" hints which describe \
dependencies (e.g. the texture colorization depends on the result of a texturemapping \
backend ) and allowed ranges for the rendering order (e.g. floating items should \
always be displayed on top of the map,  a starry background needs to get drawn before \
                the globe is painted)
-	b) the layermanagement class needs to fetch information from the .dgml-parser about \
the different types of backends that get used in a map. The .dgml file also needs to \
provide information about the rendering order. +	b) In Marble the structure of each \
map gets described in the map's .dgml file. So the layermanagement class needs to \
fetch information from the .dgml-parser about the different types of backends that \
get used in a map. The .dgml file also needs to provide information about the \
rendering order.  c) for backend types where there are no hard requirements on the \
rendering order the LMC should decide itself which order to take.  
-- According to the concept described so far it should be possible to paint different \
layers based on the very same backend  directly on top of each other (e.g. a cloud \
layer on top of a satellite map layer. This would result in two different layers. \
However for reasons of performance it needs to be possible to merge the data into a \
                single layer ("MergedLayer"). 
-This gets already done for placemarks where data from different files gets merged \
into a single file. It also gets done already for clouds on top of the satellite \
image data. However what's missing is a more generic approach where a \
MergedLayerPainter class operates directly on the tiles based on the information it \
receives from the LMC. Before telling the MergedLayerPainter class which layers need \
to get painted on top of the tiles the LMC needs to check whether tiles or \
sourceimage data is available for the map. If there is no such data available the LMC \
needs to either notify the TileLoader that it needs to create tiles or the LMC will \
simply ignore the missing data and will skip asking the MergedLayerPainter to render \
the missing data.  +- According to the concept described so far it should be possible \
to paint different layers based on the very same backend  directly on top of each \
other (e.g. a cloud layer on top of a satellite map layer. Normally this would result \
in two different layers. However for reasons of performance it needs to be possible \
to merge the data into a single layer right from the start("MergedLayer").  
+This gets already done for placemarks in current SVN where data from different files \
gets merged into a single file. It also gets done already for clouds on top of the \
satellite image data. However what's missing is a more generic approach where a \
MergedLayerPainter class operates directly on the tiles based on the information it \
receives from the LMC. Before telling the MergedLayerPainter class which layers need \
to get painted on top of the tiles the LMC needs to check whether tiles or \
sourceimage data is available for the map. If there is no such data available the LMC \
needs to either notify the TileLoader that it needs to create tiles or the LMC will \
simply ignore the missing data and will skip asking the MergedLayerPainter to render \
the missing data.  +
 - The plugin-backend concept should allow CUSTOM BACKENDS created by third party \
                developers. 
 - Creating new geographical features on the map should happen using a Qt-like API \
(which would include the QPainter API to draw in screen coordinates):  
@@ -47,7 +48,7 @@
 	painter.drawGeoEllipse( here.lon(), here.lat(), 5, 5 ); 
 	
 
-- It should be possible to use this Qt-like Geo-API either from outside the \
MarbleWidget or from inside the custom backend plugin. +- It should be possible to \
use this Qt-style Geo-API either from outside the MarbleWidget or from inside the \
custom backend plugin.  
 
 FUTURE low-priority enhancements (for usage in "real" light GIS apps that might use \
Marble in the future):


[prev in list] [next in list] [prev in thread] [next in thread]