jmckenna
/
postgis
forked from postgis/postgis
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Wrap within 80 cols 

git-svn-id: http://svn.osgeo.org/postgis/trunk@9544 b70326c6-7e19-0410-871a-916f4a2858ee
stable-2.0
Sandro Santilli 2012-03-26 13:17:31 +00:00
parent 1e8124a337
commit 75e3e1ee84
1 changed files with 34 additions and 31 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

65
MIGRATION
View File

@ -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
--------------------------------