Go to content Go to navigation and search

Home

Current Oracle Spatial Blog Articles

    Tip: Drop that Spatial Index!
    Convert Single Geometry to Multi-part Geometry in Oracle Spatial
    Optimized Rectangle to 5 Point Polygon
    Centroid Package now supports Y ordinate seeding
    Convert GeoJSON document to Sdo_Geometry objects
    Implementation Of Travelling Salesman Problem
    Create Polygon From Bearings And Distances
    Function That Returns a Compass Point From a Whole Circle Bearing
    Playing around with Centroids by using different seed values
    GeoRaptor 4.x Update 2
    Simple Oracle C Sprintf or Java String.format
    Some Oriented Point Functions
    Extracting Inner Rings Changed Ordinate Ordering: A Trap For Players Who Don't Read Documentation!
    PLS-00306: wrong number or types of arguments in call to 'SDO_GEOMETRY'
    Converting Google Earth Formatted Longitude/Latitude points to decimal degrees
    Oracle Business Intelligence Warehousing and Analytics - Spatial Summit
    How far inside, is inside? Measuring actual distance.
    Noding and building a polygon from single, overlapping linestrings
    Analyzing Spatial Query Performance Improvements in Oracle Spatial and Graph 12c Through Cross-Vendor Comparison
    ST_VertexN / ST_PointN - Extracting a specific point from any geometry
    Convert Single Point stored in SDO_ORDINATES to SDO_POINT_TYPE
    Aggregate APPEND Islands and XOR polygons
    Circular Arcs in Geodetic Polygons
    Some SDO_GEOMETRY/DIMINFO handling functions
    Applying And Extending Oracle Spatial - Book Released
    Changing all DIMINFO sdo_tolerance values for all metadata records in one go.
    Building Polygons from Incomplete Linestrings using ST_PolygonBuilder
    Computing Cardinal Directions to nearby geometries
    Intersecting two aggregated polygon layers with SC4O
    Spatial and Oracle 12c
    Update Triggers and SDO_GEOMETRY Equality
    Duplicate Geometry data and Data Models
    CENTROID package update
    How to calculate cumulative length of a linestring
    Useful Package of Wrapper Functions for Sdo_Util.AffineTransforms
    Compute Location from known Lat/Long point using delta easting and northing in miles
    SDO_AGGR_SET_UNION
    Sorting SDO_GEOMETRY data using the ORDER BY clause of a SELECT statement
    Creating linestrings from points
    Rounding Coordinates or Ordinates in SDO_GEOMETRY
    Effects of Sdo_Geometry Ordinate Precision on Performance
    Effects of Sdo_Geometry Ordinate Precision on Storage
    The Spatial filtering of geometries: The effect of tolerances on relationships
    Application of Delaunay Triangulation and Inverse Distance Weighting (IDW) in Oracle for Soils Interpolation
    Selecting all SDO_GTYPE values for all tables/sdo_geometry columns in a schema
    CENTROID package - Tips for Use
    Announcing the Spatial Companion For Oracle (SC4O)
    Filtering Rings (Oracle Spatial)
    Splitting a polygon using one or more linestrings
    isValid, isSimple, Dimension and CoordDim methods for SDO_Geometry
    Line Merging or Collecting lines together: ST_LineMerger
    ST_DeleteVertex for Oracle SDO_Geometry based on Jaspa/JTS
    3D/4D and SRID aware Conversion functions for SDO_Geometry: WKT and EWKT
    Topological vs Non-Topological Simplification/Generalization of Aggregated Area Geometies in Oracle
    Filtering very short linestrings via bitmap function index
    CENTROID For Oracle
    Gridding a sdo_geometry line/polygon object (Oracle)
    Finding centre and radius of a circular geometry
    Constraining geometry type for sdo_geometry column in a table.
    CASE Statements and SDO_GEOMETRY
    The Power of Constraints and Indexes for Spatial Constraints: stopping duplicate points
    Replacement for SDO_GEOM.RELATE - ST_Relate based on JTS
    Changing Oracle Spatial Index Parameters on existing index
    Writing Excel Spreadsheets files from within the Oracle database using Java and PL/SQL
    Writing xSV (eg csv) files from within the Oracle database using Java and PL/SQL
    A simple spike finder for Spatial/Locator
    JTS Java class compilation for 11g and above
    Random Spatial Search Procedure
    Geometry Snapping using JTS in Oracle
    Exposing JTS's MinimumBoundingCircle functionality
    Exposing JTS's Densifier functionality
    Using JTS's Comparison Functions - HausdorffSimilarityMeasure & AreaSimilarityMeasure with SDO_GEOMETRY
    Free JTS-based Area/Length Functions
    Handy way of systematically fixing polygon geometries with 13349 and other errors
    Standalone CENTROID package now available for download
    Free Union, Intersection, Xor and Difference Functions for Oracle Locator - Part 4 Processing Geodetic data
    Configurable Buffer: JTS and Oracle
    Free Union, Intersection, Xor and Difference Functions for Oracle Locator - Part 3
    Free Union, Intersection, Xor and Difference Functions for Oracle Locator - Part 2
    Free Union, Intersection, Xor and Difference Functions for Oracle Locator - Part 1
    Building Lines into Polygons in Oracle Locator / Spatial
    Finding Intersection Points between Line and Polygon
    SDO2GeoJSON
    Free version of sdo_length
    Alternative to my SQL based GetNumRings function
    External Tables and SDO_Geometry data.
    layer_gtype keyword issue when indexing linear data on 11g
    String Tokenizer for Oracle
    Free Aggregate Method for Concatenating 2D Lines in Oracle Locator 10g
    Reducing 5 Vertex Polygon to Optimized Rectangle
    Square Buffer
    Converting decimal seconds to string
    SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT - 13356 Issues
    Valid conversion unit values for Oracle sdo_geom.sdo_length()
    Removing Steps in Gridded Vector Data - SmoothGrid for Oracle
    Oracle Spatial DISJOINT search/filtering
    Creating SDO_Geometry from geometric data recorded in the columns of a table
    Concave Hull Geometries in Oracle 11gR2
    Projecting SDO_GEOM_METADATA DIMINFO XY ordinates
    Instantiating MDSYS.VERTEX_TYPE
    New PL/SQL Packages - Rotate oriented point
    GeoRaptor Development Team
    Fast Refreshing Materialized View Containing SDO_GEOMETRY and SDO_GEOM.SDO_AREA function
    Performance of PL/SQL Functions using SQL vs Pure Code
    Implementing the BEST VicGrid Projection in Oracle 10gR2
    Making Sdo Geometry Metadata Update Generic Code
    ORA-13011 errors when using SDO_GEOM.VALIDATE_LAYER_WITH_CONTEXT()
    Extract Polygons from Compound Polygon
    Detecting sdo_geometries with compound (3-point Arcs) segments
    GEOMETRY_COLUMNS for Oracle Spatial
    Convert GML to SDO_Geometry in Oracle 10gR2
    Spatial Sorting of Data via Morton Key
    Swapping Ordinates in an SDO_GEOMETRY object
    New To_3D Function
    Extend (Reduce/Contract/Skrink) Function for Oracle
    Loading and Processing GPX 1.1 files using Oracle XMLDB
    Loading Spatial Data from an external CSV file in Oracle
    Calling the Oracle Spatial shapefile loader from within the Oracle database itself
    Implementing SDO_VertexUpdate/ST_VertexUpdate for Oracle
    Implementing SDO_RemovePoint/ST_RemovePoint for Oracle
    Implementing SDO_AddPoint/ST_AddPoint for Oracle
    ESRI ArcSDE Exverted and Inverted Polygons and Oracle Spatial
    Funky Fix Ordinates By Formula
    Implementing a SetPoint/ST_SetPoint function in Oracle
    Implementing an ST_SnapToGrid (PostGIS) function for Oracle Spatial
    Generating random point data
    Implementing an Affine/ST_Affine function for Oracle Spatial
    Implementing a Scale/ST_Scale function for Oracle Spatial
    Implementing a Parallel/ST_Parallel function for linestring data for Oracle Spatial
    Implementing a Rotate/ST_Rotate function for Oracle Spatial
    Limiting table list returned when connecting to Oracle Database using ODBC
    ST_Azimuth for Oracle: AKA Cogo.Bearing
    Implementing a Translate/ST_Translate/Move function for Oracle Spatial
    Elem_Info_Array Processing: An alternative to SDO_UTIL.GetNumRings and querying SDO_ELEM_INFO itself
    Minumum Bounding Rectangle (MBR) Object Type for Oracle
    How to extract elements from the result of an sdo_intersection of two polygons.
    How to restart a database after failed parameter change
    Fixing failed spatial indexes after import using data pump
    generate_series: an Oracle implementation in light of SQL Design Patterns
    Multi-Centroid Shootout
    Oracle Spatial Centroid Shootout
    On the use of ROLLUP in Oracle SELECT statements
    Surrounding Parcels
    Spatial Pipelining
    Using Oracle's SDO_NN Operator - Some examples
    Converting distances and units of measure in Oracle Locator
    Split Sdo_Geometry Linestring at a known point
    Forcing an Sdo_Geometry object to contain only points, lines or areas
    Unpacking USER_SDO_GEOM_METADATA's DIMINFO structure using SQL
    Generating multi-points from single point records in Oracle Spatial
    Object Tables of Sdo_Geometry
    Oracle Locator vs Oracle Spatial: A Reflection on Oracle Licensing of the SDO_GEOM Package
    FAST REFRESHing of Oracle Materialized Views containing Sdo_Geometry columns
    Australian MGA/AMG Zone Calculation from geographic (longitude/latitude) data
    Loading Shapefiles (SHP) into Oracle Spatial
    Oracle Spatial Mapping and Map Rendering Performance Tips
    The significance of sdo_lb/sdo_ub in USER_SDO_GEOM_METDATA: Do I need it?
    Oracle Spatial Forum - Melbourne April 2007
    Layer_GTypes for spatial indexes
    Oracle's SQL/MM Compliant Types
    Tips and Tricks

Search

    Browse

RSS / Atom

Email me

textpattern

Creative Commons License
All Blog Articles, Data Models and Free Source Code by Simon Greener, The SpatialDB Advisor is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Effects of Sdo_Geometry Ordinate Precision on Storage

Monday April 02 2012 at 07:29

Keywordssdo_ordinate_array number binary_double effect storage volume digits of precision
Summary

The effect of storage of too many digits of precision in an sdo_geometry sdo_ordinate_array value is highlighted. The result is that it is recommended that only those digits of precision that correctly describe an sdo_geometry should be held.

In this article I am going look at the effect ordinate precision has on the storage space occupied by tables containing sdo_geometry data. In a related article I will also look at the effect storage precision may have on performance (ie searching and returning data in SQL).



Sdo_Geometry Coordinate Precision

There is a little known side effect of using too many digits of precision when describing and storing spatial data using Oracle’s SDO_GEOMETRY object type. That side effect is that the storage requirements can be significantly greater than expected.

Unlike other spatial storage formats (normally some sort of compressed binary) Oracle storage is open. Very open. Oracle stores the ordinates describing the spatial data (SDO_GEOMETRY) in an array of NUMBER called SDO_ORDINATE_ARRAY.

Note: This is an array of NUMBER and not an array of binary double. Oracle stores a NUMBER in a variable storage format so small numbers take less space than larger NUMBERs. A BINARY_DOUBLE’s storage size is fixed regardless as to the precision of the data being held.

The ramification of this is that your storage costs are in relation to the number of digits used.

Simple Example

The Google Mercator Map coordinates that are created by projection from the original longitude/latitude data are unnecessarily large as can be shown from the following example:

  1. SELECT sdo_cs.transform(sdo_geometry(2002,8311,NULL,
  2.                                      sdo_elem_info_array(1,2,1),
  3.                                      sdo_ordinate_array(147.123,-32.456,147.672,-33.739)),3785) AS geom
  4.   FROM dual;
  5. -- Results
  6. --
  7. GEOM
  8. -------------------------------------------------------------------------------------------------------------------
  9. MDSYS.SDO_GEOMETRY(2002,3785,NULL,
  10.                    MDSYS.SDO_ELEM_INFO_ARRAY(1,2,1),
  11.                    MDSYS.SDO_ORDINATE_ARRAY(16377657.4439788,-3800381.82007675,16438771.8444243,-3970070.49100647))

Being that the input data was only specified to 0.001 of a degree, an output – in meters – specified to 8 decimal places seems somewhat excessive.

But if I rounded this data to 1 decimal place what would be the potential saving in storage?

Oracle’s documentation shows how to calculate the size of a NUMBER as stored in the database. As such, an analysis was carried out on a table of Australian land parcels to see what the effect of rounding the ordinates to 1cm and 1mm would have on data size.

Let’s apply a bit of SQL to compute NUMBER size for the above Google Mercator geometry before and after a potential rounding of its ordinates:

  1. SELECT SUMX,SUMY,
  2.        SUMXR2,SUMYR2,100 - ROUND(((SUMXR2+SUMYR2)/(SUMX+SUMY) * 100),1) AS PCT_Save_cm,
  3.        SUMXR3,SUMYR3,100 - ROUND(((SUMXR3+SUMYR3)/(SUMX+SUMY) * 100),1) AS PCT_Save_mm
  4.   FROM (SELECT SUM(vsize(t.x)) AS SUMX, SUM(vsize(ROUND(T.X,2))) AS SUMXR2, SUM(vsize(ROUND(T.X,3))) AS SUMXR3,
  5.                SUM(vsize(t.y)) AS SUMY, SUM(vsize(ROUND(T.Y,2))) AS SUMYR2, SUM(vsize(ROUND(T.Y,3))) AS SUMYR3
  6.           FROM (SELECT sdo_cs.transform(
  7.                           sdo_geometry(2002,8311,NULL,
  8.                                        sdo_elem_info_array(1,2,1),
  9.                                        sdo_ordinate_array(147.123,-32.456,147.672,-33.739)),3785) AS geom
  10.                   FROM dual) S,
  11.                TABLE(SDO_UTIL.GETVERTICES(S.GEOM)) T
  12.         ) f;
  13. -- Results
  14. --
  15. SUMX SUMY SUMXR2 SUMYR2 PCT_SAVE_CM SUMXR3 SUMYR3 PCT_SAVE_MM
  16. ---- ---- ------ ------ ----------- ------ ------ -----------
  17. 18   20   12     14     31.6        14     15     23.7

So, trimming the X and Y ordinates to 1cm (2 digits of precision) should produce a 31.6 percent reduction in storage, while trimming to 1mm should produce a 23.7 percent reduction in storage.

That’s a single object, what about geometries stored in tables?

Trimming or Rounding

To execute the trimming of an actual sdo_geometry object requires a relatively simply PL/SQL function. I created just such a function a long time ago which is available in my GEOM PL/SQL package available for free on this website. A standalone version of this function is presented in an associated article on this website called Rounding Coordinates or Ordinates in SDO_GEOMETRY

Baseline

Note that the original parcel data is also over specified:

  1. SELECT geom
  2.   FROM parcel a
  3.  WHERE sdo_util.getNumVertices(a.geom) < 6
  4.    AND rownum < 2;
  5. -- Results
  6. --
  7. GEOM
  8. ----------------------------------------------------------------------------------------------------------------
  9. MDSYS.SDO_GEOMETRY(2003,82469,NULL,
  10.                    MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1),
  11.                    MDSYS.SDO_ORDINATE_ARRAY(447291.935307683,6470098.06758179,447294.953958522,6470116.87270875,
  12.                                             447258.829362703,6470122.5382358,447255.811490383,6470103.73299092,
  13.                                             447291.935307683,6470098.06758179))

So, before using the RoundOrdinates function, we need to get a baseline measure of storage.

  1. WITH object_storage AS (
  2. SELECT segment_name AS TABLE_NAME, 'ALL' AS column_name, '' AS segment_name, '' AS segment_subtype, s.bytes, s.blocks, s.extents
  3.   FROM dba_segments s
  4.  WHERE s.owner = 'LAND'
  5.    AND s.segment_name IN ('PARCEL')
  6. UNION ALL
  7. SELECT l.TABLE_NAME,l.column_name, s.segment_name, '' AS segment_subtype, s.bytes, s.blocks, s.extents
  8.   FROM user_lobs l,
  9.        dba_segments s
  10.   WHERE l.TABLE_NAME IN ('PARCEL')
  11.     AND s.segment_name = l.segment_name
  12. )
  13. SELECT TABLE_NAME,column_name,segment_name,
  14.        to_char(SUM(bytes),'FM9,999,999,999,999') AS bytes,SUM(blocks) AS blocks,SUM(extents) AS extents
  15.   FROM object_storage
  16.  GROUP BY TABLE_NAME,column_name,segment_name;
  17. .
  18. TABLE_NAME  COLUMN_NAME            SEGMENT_NAME              BYTES      BLOCKS EXTENTS
  19. ------ ---------------------- ------------------------- ---------- ------ -------
  20. PARCEL ALL                                              29,360,128 3584   43
  21. PARCEL "GEOM"."SDO_ORDINATES" SYS_LOB0000077718C00021$$ 6,291,456  768    21
  22. PARCEL "GEOM"."SDO_ELEM_INFO" SYS_LOB0000077718C00020$$ 65,536     8      1

Now, let’s make the change to the ordinates.

Changed Ordinates

  1. DROP   TABLE LM_PARCEL_P;
  2. .
  3. CREATE TABLE LM_PARCEL_P (FID,AREA,GID,LOT_NUMBER,SECTION,DP_NUMBER,ID_PARCEL_TYPE,ID_PARCEL_LEGAL_STATUS,ASSET,ADMIN_CODE,ID_ORIGIN,ID_ACCURACY,NARRATIVE,GEOM)
  4. NOLOGGING
  5. AS
  6. SELECT FID,AREA,GID,LOT_NUMBER,SECTION,DP_NUMBER,ID_PARCEL_TYPE,ID_PARCEL_LEGAL_STATUS,ASSET,ADMIN_CODE,ID_ORIGIN,ID_ACCURACY,NARRATIVE,CODESYS.ROUNDORDINATES(p.GEOM,0.0005) AS GEOMETRY
  7.   FROM PARCEL p;
  8. commit;
  9. .
  10. ALTER TABLE LM_PARCEL_P LOGGING;
  11. .
  12. -- Calculate space usage of table and LOBs
  13. WITH object_storage AS (
  14. SELECT segment_name AS TABLE_NAME, 'ALL' AS column_name, '' AS segment_name, '' AS segment_subtype, s.bytes, s.blocks, s.extents
  15.   FROM dba_segments s
  16.  WHERE s.owner = 'LAND'
  17.    AND s.segment_name IN ('PARCEL_P')
  18. UNION ALL
  19. SELECT l.TABLE_NAME,l.column_name, s.segment_name, '' AS segment_subtype, s.bytes, s.blocks, s.extents
  20.   FROM user_lobs l,
  21.        dba_segments s
  22.   WHERE l.TABLE_NAME IN ('PARCEL_P')
  23.     AND s.segment_name = l.segment_name
  24. )
  25. SELECT TABLE_NAME,column_name,segment_name,
  26.        to_char(SUM(bytes),'FM9,999,999,999,999') AS bytes,SUM(blocks) AS blocks,SUM(extents) AS extents
  27.   FROM object_storage
  28.  GROUP BY TABLE_NAME,column_name,segment_name;
  29. .
  30. TABLE_NAME  COLUMN_NAME            SEGMENT_NAME              BYTES       BLOCKS EXTENTS
  31. -------- ---------------------- ------------------------- ----------- ------ -------
  32. PARCEL_P ALL                                              25,165,824  3072   39
  33. PARCEL_P "GEOM"."SDO_ORDINATES" SYS_LOB0000077747C00021$$ 3,145,728   384    18
  34. PARCEL_P "GEOM"."SDO_ELEM_INFO" SYS_LOB0000077747C00020$$ 65,536      8      1

Results

The difference in sdo_ordinate storage is:

3,145,728 / 6,291,456 * 100 = 50%.

And of the table’s storage:

25,165,824 / 29,360,128 = 85%

Not bad.

So, the benefits of a decrease in disk storage and traffic should be obvious to all. But can we see any statistical benefits in this change? (These calculations should be ratified before making any decisions with respect to your data.) I will include some numbers in the next few days.

I hope this is useful to someone.

If you found this article informative, try the followup article on the effect rounding has on precision.

Effects of Sdo_Geometry Ordinate Precision on Performance

Creative Commons License

post this at del.icio.uspost this at Diggpost this at Technoratipost this at Redditpost this at Farkpost this at Yahoo! my webpost this at Windows Livepost this at Google Bookmarkspost this to Twitter

Comment [8]

Hi Simon,
Thanks for your function.It helped me.

v_dim := TRUNC + CASE WHEN MOD,10) = 0 THEN 0 ELSE 1 END;
is the second part necessary?
It means a Gtype of 3301 has 4 dimensions!

and it doesn’t check for point geometries with sdo_point equals to null, like: select RoundOrdinates( SDO_GEOMETRY(3301, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1, 1), SDO_ORDINATE_ARRAY(9, 3, 5.84)), 1) as geom from dual;

— Farid Cheraghi · 5 August 2011, 02:41 · #

Farid,

Ahh, so you found the errors I sprinkled in the code to see if anyone was paying attention!

Well done.

While you didn’t provide a fix, I have done so and updated the blog article.

regards
Simon

Simon Greener · 5 August 2011, 09:23 · #

Hi Simon,
I used your function RoundOrdinates on my dataset to reduce storage and improve performance which it did perfectly. However, since then I see strange behaviour in my web cartographic application. When I click outside of some polygon with the show info tool, it display the info but it should not. This strange behaviour clearly appeared after applying RoundOrdinate function on my data which were loaded with EasyLoader (MapInfo) into Oracle 10g. Have you an idea what could be the source of that problem? Thank you
Maxime

— Maxime · 6 September 2012, 19:50 · #

Maxime,

Wrt to the strange behaviour:

1. What version of RoundOrdinates are you using? The one linked to from this article or one of the versions in my free PL/SQL packages?
2. What sdo_tolerance did Easy Loader create for the data it loaded? Check user_sdo_geom_metadata.
3. Can you show me a sample set of vertices before and after application of RoundOrdinates?
<code><pre>
select v.x, v.y from quad d, table(sdo_util.getvertices(d.geom)) v
where d.quad_id = 1 and rownum < 2;
</pre></code>

regards
Simon

— Simon Greener · 6 September 2012, 23:05 · #

Hi Simon,

1. I use the standalone function found on that forum: https://forums.oracle.com/forums/thread.jspa?messageID=10280797

2. The tolerance used by EasyLoader is X: 7.9013E-6 and Y: 1.01201E-5

3. Before: X: -65,052964545967 Y: 48,9062675076125 After: X: -65,05296 Y: 48,90627

What about the spatial index? Should I recreate a new index after rounding?

— Maxime · 7 September 2012, 12:56 · #

Maxime,
Use the function on my website or in my published pl/sql packages.
The tolerance from Easy Loader is not that recommended by Oracle. For geographic/geodetic data the precision should be 5cm or 0.05m.
My RoundOrdinates function however expects its precision in terms of number of decimal digits of precision. For Lat/Long that is more like 6-9. This is NOT the same as sdo_tolerance which has to be expressed in meters and not decimal lat/long. This is confusing: provide my RoundOrdinates function with the number of digits of decimal precision on decimal degrees and not meters.
When changing precision like this, yes, drop and re-create any spatial indicies.
regards
Simon

— Simon Greener · 7 September 2012, 13:13 · #

Im not sure to understand it well. Should I transform the geometry to the SRID 4326 (it was at 8307) and set the tolerance to something like 0.01 before running the RoundOrdinate ?

— Maxime · 7 September 2012, 18:33 · #

Maxime,

Suggested steps for long/lat data:

1. Drop index on existing sdo_geometry column.
2. For long/lat data the suggested rounding value (not tolerance) should be something of the order of 6-8 digits of precision. Do not use the suggested Oracle sdo_tolerance of 5cm, or 0.05m, because this is in meters but the ordinate values themselves are in decimal degrees. (0.000001 decimal degrees is roughly 5cm in metric terms.
3. Test the rounding before applying it via:
select geom,roundOrdinates(geom,6) as roundedValue from (select SDO_GEOMETRY(2001,4326,SDO_POINT_TYPE(145.238711840668,-41.5021467607697,NULL),NULL,NULL) as geom from dual);
You should validate the rounded data so that the rounding does not introduce errors. If errors occur, try increasing the rounding value from 6 to 7 etc. Note also you can use a different rounding value for your x/long and y/lat ordinates.
4. When you are happy with the results of 2/3, apply the change:
update <table> t set t.geom = roundOrdinates(t.geom,7/*final value*/); commit;
5. When the update has succeeded, rebuild the spatial index.

HTH.

regards
Simon

— Simon Greener · 8 September 2012, 00:33 · #