diff --git a/src/site/markdown/tutorials/direct-location-with-DEM.md b/src/site/markdown/tutorials/direct-location-with-DEM.md
index 0ce8751e921bbd9f8c12a1f938625ca23d4b630f..0375fec32cbf77f3fef618205ba703b5dcefeb1a 100644
--- a/src/site/markdown/tutorials/direct-location-with-DEM.md
+++ b/src/site/markdown/tutorials/direct-location-with-DEM.md
@@ -39,7 +39,7 @@ The class `VolcanicConeElevationUpdater` implements the interface `TileUpdater`
 
 Here's the source code of the class `VolcanicConeElevationUpdater` :
 
-import org.hipparchus.util.FastMath;
+    import org.hipparchus.util.FastMath;
     import org.orekit.rugged.raster.TileUpdater;
     import org.orekit.rugged.raster.UpdatableTile;
     import org.orekit.bodies.GeodeticPoint;
@@ -88,7 +88,7 @@ import org.hipparchus.util.FastMath;
 
 ### Important notes on DEM tiles :
 
-* Ground point elevation are obtained by bilinear interpolation between 4 neighbouring cells. There is no specific algorithm for border management. As a consequence, a point falling on the border of the tile is considered outside. DEM tiles must be overlapping by at least one line/column in all directions, in a similar way as for the SRTM DEMs. 
+* Ground point elevation are obtained by bilinear interpolation between 4 neighbouring cells. There is no specific algorithm for border management. As a consequence, a point falling on the border of the tile is considered outside. **DEM tiles must be overlapping by at least one line/column in all directions**, in a similar way as for the SRTM DEMs. 
 
 * In Rugged terminology, the minimum latitude and longitude correspond to the centre of the farthest Southwest cell of the DEM. Be careful if using GDAL to pass the correct information as there is half a pixel shift with respect to the lower left corner coordinates in gdalinfo.
 
@@ -169,4 +169,4 @@ In a similar way as in the first tutorial [DirectLocation](./direct-location.htm
     }
 
 ## Source code
-The source code is available in DirectLocationWithDEM.java
+The source code is available in DirectLocationWithDEM.java (package fr.cs.examples under src/tutorials)
diff --git a/src/site/markdown/tutorials/direct-location.md b/src/site/markdown/tutorials/direct-location.md
index 0866e25b8294db303cfcc5511e4fb4a3ec80e186..076c1c87f5bc7c0d1cdc7d53bc93ad7c178ba5a8 100644
--- a/src/site/markdown/tutorials/direct-location.md
+++ b/src/site/markdown/tutorials/direct-location.md
@@ -55,7 +55,7 @@ The raw viewing direction of pixel i with respect to the instrument is defined b
 
     List<Vector3D> rawDirs = new ArrayList<Vector3D>();
     for (int i = 0; i < 2000; i++) {
-        //20° field of view, 2000 pixels
+        // 20° field of view, 2000 pixels
         rawDirs.add(new Vector3D(0d, i*FastMath.toRadians(20)/2000d, 1d));
     }
 
@@ -161,7 +161,7 @@ Each attitude sample (quaternion, time) is added to the list,
 
 where, for instance, gpsDateAsString is set to "2009-12-11T10:49:55.899994"
 
-### Position and velocities
+### Positions and velocities
 
 
 Similarly the positions and velocities will be set in a list of `TimeStampedPVCoordinates`. Before being
@@ -307,11 +307,17 @@ Finally everything is set to do some real work. Let's try to locate a point on E
 for upper left point (first line, first pixel): 
 
     import org.orekit.bodies.GeodeticPoint;
-    Vector3D position = lineSensor.getPosition(); // This returns a zero vector since we set the relative position of the sensor w.r.T the satellite to 0.
+    Vector3D position = lineSensor.getPosition(); // This returns a zero vector since we set the relative position of the sensor w.r.t. the satellite to 0.
     AbsoluteDate firstLineDate = lineSensor.getDate(0);
     Vector3D los = lineSensor.getLOS(firstLineDate, 0);
     GeodeticPoint upLeftPoint = rugged.directLocation(firstLineDate, position, los);
 
+The line number can have negative values; the associated date must belong to the time span given when building Rugged with setTimeSpan(acquisitionStartDate, acquisitionStopDate,...).
+Otherwise a RuggedException will be thrown.
+
+The pixel number must be given between 0 and the (Sensor pixel size – 1); in our example between 0 and 1999.
+Otherwise an ArrayIndexOutOfBoundsException will be thrown.
+
 ## Source code 
 
-The source code is available in DirectLocation.java
+The source code is available in DirectLocation.java (package fr.cs.examples under src/tutorials)
diff --git a/src/site/markdown/tutorials/inverse-location.md b/src/site/markdown/tutorials/inverse-location.md
index 42bb4a550efcb57fdbd21899c08c91d6a88c99f4..daa4ff0bd97fb71946ec42b4d1e43db7d4bd57ad 100644
--- a/src/site/markdown/tutorials/inverse-location.md
+++ b/src/site/markdown/tutorials/inverse-location.md
@@ -19,10 +19,10 @@ The aim of this tutorial is to compute the inverse location of a point on Earth
 We will also explain how to find the date at which sensor sees a ground point, which is a kind of inverse location only focusing on date.
 
 ## Inverse location of a point on Earth
-The initialisation of Rugged is similar as in the [Direct location](direct-location.html) tutorial up to the addition of the lines sensor.
+The initialization of Rugged is similar as in the [Direct location](direct-location.html) tutorial up to rugged initialization..
 
 ### Point defined by its latitude, longitude and altitude
-Once Rugged initialised, one can compute the line number and the pixel number of a point defined by its Geodetic coordinates:
+Once Rugged initialized, one can compute the line number and the pixel number of a point defined by its Geodetic coordinates:
 
     import org.orekit.bodies.GeodeticPoint;
     import org.orekit.rugged.linesensor.SensorPixel;
@@ -30,7 +30,7 @@ Once Rugged initialised, one can compute the line number and the pixel number of
     SensorPixel sensorPixel = rugged.inverseLocation(sensorName, gp, minLine, maxLine);
 where minLine (maxLine, respectively) is the minimum line number for the search interval (maximum line number, respectively). 
 
-The inverse location will give the sensor pixel number and the associated line number seeing the point. In case the point cannot be seen between the prescribed line numbers, the return result is null. No exception will be thrown in this particular case.
+The inverse location will give the sensor pixel number and the associated line number seeing the point on ground. *In case the point cannot be seen between the prescribed line numbers, the return result is null. No exception will be thrown in this particular case*.
    
 ### Point defined by its latitude and longitude (no altitude)
 Similarly, one can compute the line number and the pixel number of a point defined solely by its latitude en longitude. The altitude will be determined automatically with the DEM.
@@ -38,7 +38,7 @@ Similarly, one can compute the line number and the pixel number of a point defin
      SensorPixel sensorPixel = rugged.inverseLocation(sensorName, latitude, longitude, minLine, maxLine);
 
 ## Date location 
-Once Rugged initialised, one can compute the date at which sensor sees a point on Earth.
+Once Rugged initialized, one can compute the date at which sensor sees a point on Earth.
 
 ### Point defined by its latitude, longitude and altitude
 For a point defined by its Geodetic coordinates:
@@ -50,5 +50,27 @@ Similarly, for a point defined solely by its latitude en longitude (altitude det
 
      AbsoluteDate dateLine = rugged.dateLocation(sensorName, latitude, longitude, minLine, maxLine);
 
+## Determine the min/max lines interval
+Rugged provides a way to determine a **very** rough estimation of the line using only the position-velocities of the satellite. It assumes the position-velocities are regular enough and without holes.
+
+     OneAxisEllipsoid oneAxisEllipsoid = ruggedBuilder.getEllipsoid();
+     Frame pvFrame = ruggedBuilder.getInertialFrame();
+     RoughVisibilityEstimator roughVisibilityEstimator= new RoughVisibilityEstimator(oneAxisEllipsoid, pvFrame, satellitePVList);
+
+One can compute the approximated line with the rough visibility estimator:
+
+     AbsoluteDate roughLineDate = roughVisibilityEstimator.estimateVisibility(gp);
+     double roughLine = lineSensor.getLine(roughLineDate);
+
+The result will never be null, but may be really far from reality if ground point is away from trajectory.
+With this rough line, taken some margin around (for instance 100), one can initialize the min/max lines as search boundaries for inverse location, taken into account sensor min and max lines:
+
+     int minLineRough = (int) FastMath.max(FastMath.floor(roughLine - margin), sensorMinLine);
+     int maxLineRough = (int) FastMath.min(FastMath.floor(roughLine + margin), sensorMaxLine);
+
+then one can compute the inverse location:
+
+     SensorPixel sensorPixel = rugged.inverseLocation(sensorName, gp, minLineRough, maxLineRough);
+
 ## Source code
-The source code is available in InverseLocation.java 
+The source code is available in InverseLocation.java (package fr.cs.examples under src/tutorials)