[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]