Index: /trunk/docs/workshop/2010/ogr_base_vect_ops.txt
===================================================================
--- /trunk/docs/workshop/2010/ogr_base_vect_ops.txt	(revision 264)
+++ /trunk/docs/workshop/2010/ogr_base_vect_ops.txt	(revision 265)
@@ -2,5 +2,5 @@
 
 Creating OGR based Web Services
-###############################
+===============================
 
 .. contents:: Table of Contents
@@ -9,5 +9,5 @@
 
 Introduction
-************
+------------
 
 In this part, we are going to create a ZOO ServicesProvider containing several Services 
@@ -29,5 +29,5 @@
 
 Preparing ZOO metadata file
-***************************
+---------------------------
 
 A ZOO Service is a combination of a ZOO metadata file (``.zcfg``) and the runtime module 
@@ -196,5 +196,5 @@
 
 Implementing single geometry services
-*************************************
+-------------------------------------
 
 In order to learn the Services Provider creation and deployement step-by-step, 
@@ -213,8 +213,8 @@
 
 Boundary
-========
+********
 
 C Version
----------
+^^^^^^^^^
 
 As explained before, ZOO Kernel will pass the parameters to your Service function 
@@ -436,5 +436,5 @@
       geometry=createGeometryFromWFS(conf,tmp->value);
 
-Basicaly, if we get an input with a mimeType set to application/json, then we will 
+Basically, if we get an input with a mimeType set to application/json, then we will 
 use our ``OGR_G_CreateGeometryFromJson`` in other case, our ``createGeometryFromWFS`` local function.
 
@@ -577,5 +577,5 @@
 
 Python Version
---------------
+^^^^^^^^^^^^^^
 
 For those using Python to implement their ZOO Services Provider, the full code to copy in 
@@ -634,8 +634,7 @@
 
 Testing the Service using Execute Request
------------------------------------------
-
-The simple and unreadable way
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+**The simple and unreadable way**
 
 Everybody should now get his own copy of the OGR Boundary Service stored as a ZOO 
@@ -731,6 +730,5 @@
    :align: center
 
-Simplification and readability of request
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+**Simplification and readability of request**
 
 As you can see in the simple example we used since the begining of this workshop, 
@@ -812,6 +810,5 @@
 ``@mimeType=application/json`` as we discussed before. 
 
-storeExecuteResponse parameter and GetStatus Service 
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+**storeExecuteResponse parameter and GetStatus Service**
 
 If you go in your local ``/home/user/zoows/sources/zoo-services/utils/status``, you'll 
@@ -880,5 +877,5 @@
 
 Creating Services for other functions (ConvexHull and Centroid)
-===============================================================
+***************************************************************
 
 As the Boundary sample service code is available, you can now easily add ConvexHull and 
@@ -888,5 +885,5 @@
 
 C Version
----------
+^^^^^^^^^
 
 Please add first the following code to the service.c source code : 
@@ -1022,5 +1019,5 @@
 
 Python Version
---------------
+^^^^^^^^^^^^^^
 
 .. code-block:: guess
@@ -1107,5 +1104,5 @@
 
 Create the Buffer Service
-=========================
+*************************
 
 We can now work on the Buffer Service, which takes more arguments than the other ones. 
@@ -1118,5 +1115,5 @@
 
 C Version
----------
+^^^^^^^^^
 
 If you go back to the first Boundary Service source code, you should not find the 
@@ -1226,5 +1223,5 @@
 
 Python Version
---------------
+^^^^^^^^^^^^^^
 
 As we already defined the utility functions createGeometryFromWFS and outputResult, 
@@ -1251,5 +1248,5 @@
 
 The Buffer MetadataFile file
-----------------------------
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
 You must add BufferDistance to the Service Metadata File to let clients know that