Wrap within 80 cols

git-svn-id: http://svn.osgeo.org/postgis/trunk@9544 b70326c6-7e19-0410-871a-916f4a2858ee

diff --git a/MIGRATION b/MIGRATION
index b3a3e4497706d38a3bb93f2674c224f2b0058ade..a91a1e1ca075629237a97ffecc5ce2d4c5f41fe1 100644 (file)
--- a/MIGRATION
+++ b/MIGRATION
@@ -8,39 +8,42 @@ for some applications. This document lists those changes.
 Deprecated Functions Removed
 ----------------------------
 
-Since PostGIS 1.2, we have been encouraging users to use functions with the ST_
-prefix. The ST_ prefixed functions are part of the ISO SQL/MM standard and 
-used by other spatial SQL databases, so we want to conform as closely to the 
-industry usage as we can.
+Since PostGIS 1.2, we have been encouraging users to use functions with
+the ST_ prefix. The ST_ prefixed functions are part of the ISO SQL/MM
+standard and used by other spatial SQL databases, so we want to conform
+as closely to the industry usage as we can.
 
-At 2.0, we have finally removed the old functions. If you have an application
-that *still* requires the old function signatures, please look to the legacy_*.sql 
-files to add the old signatures back in.
+At 2.0, we have finally removed the old functions. If you have an
+application that *still* requires the old function signatures, please
+look to the legacy_*.sql files to add the old signatures back in.
 
-If you are using MapServer, upgrade to the latest versions of the 6.0 or 6.2 
-releases. For earlier releases, you will have to install the legacy.sql files.
+If you are using MapServer, upgrade to the latest versions of the 6.0
+or 6.2 releases. For earlier releases, you will have to install the
+legacy.sql files.
 
 
 Unknown SRID
 ------------
 
-The "unknown SRID", assigned to geometries when SRID is not specified, is now 0, not -1. 
-ST_SRID will now return 0 when called on a geometry with no known SRID. 
+The "unknown SRID", assigned to geometries when SRID is not specified,
+is now 0, not -1.  ST_SRID will now return 0 when called on a geometry
+with no known SRID.
 
 
 ST_AsBinary, ST_AsText and 3D
 -----------------------------
 
-Previous versions of PostGIS returned 2D versions of objects when ST_AsBinary 
-and ST_AsText were called. PostGIS 2.0 returns ISO SQL/MM versions when 3D or 4D
-objects are used.  For example, a 3D point with a Z dimension will return 
-as 'POINT Z (0 0 0)'. A 4D point will return as 'POINT ZM (0 0 0 0)'.
+Previous versions of PostGIS returned 2D versions of objects when
+ST_AsBinary and ST_AsText were called. PostGIS 2.0 returns ISO SQL/MM
+versions when 3D or 4D objects are used.  For example, a 3D point with a
+Z dimension will return as 'POINT Z (0 0 0)'. A 4D point will return as
+'POINT ZM (0 0 0 0)'.
 
-For WKB, extra dimensionality is indicated in the type numbers. The Z, M, and ZM 
-type numbers are indicated by adding 1000, 2000, and 3000 respectively to the 
-usual 2D type numbers. So, for example, a 2D Point has a type number of 1. A 4D
-PointZM has a type number of 3001.  A 2D polygon has a type number of 3. A PolygonZ has a 
-type number of 2003.
+For WKB, extra dimensionality is indicated in the type numbers. The Z,
+M, and ZM type numbers are indicated by adding 1000, 2000, and 3000
+respectively to the usual 2D type numbers. So, for example, a 2D Point
+has a type number of 1. A 4D PointZM has a type number of 3001.  A 2D
+polygon has a type number of 3. A PolygonZ has a type number of 2003.
 
 
 geometry_columns
@@ -85,14 +88,14 @@ a table to a view.
                
        You will need to drop and recreate the view. 
        Sadly CREATE OR REPLACE will not work since the casting
-       makes geometries be treated as a different type as far as CREATE OR REPLACE 
-       is concerned.
+         makes geometries be treated as a different type as far as
+         CREATE OR REPLACE is concerned.
        
        NOTE for this, it might help to lookup in geometry_columns 
            to see the raw table srid/type
        Alternatively you can convert some of your table columns to typmod, 
-       then you would only need to CAST when doing processing.  This however still
-       requires you rebuild your dependent views
+       then you would only need to CAST when doing processing. 
+       This however still requires you rebuild your dependent views
        DROP VIEW vwparcels;
        CREATE OR REPLACE VIEW vwparcels AS
                SELECT gid, parcel_id, 
@@ -114,8 +117,8 @@ restore into a fresh PostGIS 2.0 database unless you
 
 or 
 
-2) Install the legacy functions srid() and ndims() found in the legacy.sql file
-before you try to restore these tables.
+2) Install the legacy functions srid() and ndims() found in the legacy.sql
+  file before you try to restore these tables.
 
 Function is not unique after restore
 -------------------------------------
@@ -123,12 +126,12 @@ After you restore old data into a fresh PostGIS 2.0 database,
 YOU MUST install the uninstall_legacy.sql
 file after the restore.  If you don't you will run into 
 "function is not unique" errors in your applications.
-The other issue with having the old functions is the old functions you restore
-will be bound to the old postgis library which is incompatible with the
-new postgis geometry structures.
+The other issue with having the old functions is the old functions you
+restore will be bound to the old postgis library which is incompatible
+with the new postgis geometry structures.
 
-If you still require legacy functions, you can install the legacy.sql file 
-after the uninstall_legacy.sql.
+If you still require legacy functions, you can install the legacy.sql
+file after the uninstall_legacy.sql.
 
 GOTCHA with uninstall_legacy.sql
 --------------------------------