Updated Compositing (markdown)

Ideas_Compositing.md

@@ -6,10 +6,10 @@
 
 [TopOSM](http://wiki.openstreetmap.org/wiki/TopOSM/Details) is pretty inspirational. How about an XML dialect for specifying the composition of multiple Mapnik-rendered layers into a single map. This example is based on [TopOSM's compositing steps](http://wiki.openstreetmap.org/wiki/TopOSM/Details#Combining_images_into_a_final_composite), which also incorporate `gdalwarp`-generated hill shadings. (These could be integrated using a [RasterSymbolizer](http://trac.mapnik.org/wiki/RasterSymbolizer), or a thin wrapper could be generated at runtime.)
 
- * Note: see also artem's test images (generated with AGG): http://trac.mapnik.org/wiki/Compositing
+* Note: see also artem's test images (generated with AGG): http://trac.mapnik.org/wiki/Compositing
- * Note: see also the GSOC page on related ideas: http://trac.mapnik.org/wiki/GSOC2010/Ideas?version=17#LayerComposites
+* Note: see also the GSOC page on related ideas: http://trac.mapnik.org/wiki/GSOC2010/Ideas?version=17#LayerComposites
- * Note: Research possibility of use RPN (reverse polish notation) for specifying the rendering and compositing order. It would be hard to understand complex compositing schemes, but easy to implement
+* Note: Research possibility of use RPN (reverse polish notation) for specifying the rendering and compositing order. It would be hard to understand complex compositing schemes, but easy to implement
- * Note: Research multithreaded/multiprocess rendering and compositing of layers. In a nutshell, rendering of two different layers to be composed could be handled by different threads, all compositing should be multithreaded. Research and benchmark if it makes sense performance-wise.
+* Note: Research multithreaded/multiprocess rendering and compositing of layers. In a nutshell, rendering of two different layers to be composed could be handled by different threads, all compositing should be multithreaded. Research and benchmark if it makes sense performance-wise.
 
 
         <?xml version="1.0"?>
@@ -28,7 +28,7 @@
             <!-- then, lightened and using the multiply blend mode -->
             <Map type="raster" href="hillshade.tiff" blend="multiply">
             <Transform type="level">0,80%,1.0</Transform>
-      </Layer>
+            </Map>
     
             <!-- (at this point, we should have a hill shaded area map) -->
     
@@ -59,8 +59,8 @@ The idea here is that the composition starts with an empty buffer and draws laye
 
 Basically, each XML results in an image operation:
 
- * `<Group>` and `<Layer>` operations create new rendering contexts, the results of which are composited onto the buffer of the parent context (optionally specifying a blend mode).
+* `<Group>` and `<Layer>` operations create new rendering contexts, the results of which are composited onto the buffer of the parent context (optionally specifying a blend mode).
- * `<Transform>` and `<Filter>` operations modify the buffer of the parent rendering context. The blur filter and color transforms in this example use [ImageMagick](http://www.imagemagick.org/script/command-line-options.php) semantics, but they could be expressed otherwise.
+* `<Transform>` and `<Filter>` operations modify the buffer of the parent rendering context. The blur filter and color transforms in this example use [ImageMagick](http://www.imagemagick.org/script/command-line-options.php) semantics, but they could be expressed otherwise.
- * `<Channel>` operations render their child layers or groups into a temporary buffer, one or more channels of which are then applied to the parent context (optionally specifying a bitwise operator?).
+* `<Channel>` operations render their child layers or groups into a temporary buffer, one or more channels of which are then applied to the parent context (optionally specifying a bitwise operator?).
 
 Recursively rendered Mapnik stylesheets should inherit their SRS from the `<Composite>` element, if provided.