## Top 5 Recent Articles

##### ARTICLES CATEGORIES

- Algorithms (13)
- All (407)
- Biography (1)
- Blog (44)
- Business Requirements (1)
- Commentary (1)
- Customers (2)
- Data Models (1)
- Education (2)
- GeoRaptor (5)
- Image Processing (2)
- Import Export (5)
- Licensing (2)
- Linear Referencing (3)
- Manifold GIS (3)
- Mapping (1)
- MySQL Spatial (7)
- Networking and Routing (including Optimization) (3)
- Open Source (16)
- Oracle Spatial and Locator (178)
- PostGIS (33)
- Published Articles (1)
- Recommendations (1)
- Services (1)
- Software Change Log (1)
- Source Code (35)
- Space Curves (9)
- Spatial Database Functions (101)
- Spatial DB comparison (1)
- Spatial XML Processing (10)
- SQL Server Spatial (General) (83)
- SQL Server Spatial (LRS) (38)
- Standards (1)
- Stored Procedure (15)
- Tessellation or Gridding (9)
- Tools (2)
- Training (2)

# Geometry object size when exchanging of WKT/WKB encoded geometries.

## Introduction

The ordinates stored in an geometry objects, across all spatial data types do not have any rounding applied to their values. This is one aspect of data management that is seldom considered by most practitioners. Other articles in this website deal with how to round their values.

This article is about a related topic”

*The size of WKT/WKB objects and the effect of that size on the exchange of encoded geometries by spatial web services.*

### Imprecision

Double or floating point numbers are imprecise beasts. Few consider the effect this might have generating WKT representations of geometries.

For example, after importing a shapefile into a database, the floating point / double precision have more decimal digits than the practitioner was aware of. I have heard, many times, colleagues ask the question: why are there so many decimal digits when their data was “accurate” to 1mm ie 0.001 meters.

### Well Known Text

Here is the WKT from a geometry object:

POLYGON ((-183910.92569999956 -1460867.7657999992, -183702.8114 -1461645.8010000009, -182184.92850000039 -1461275.9758000001, -182382.32780000009 -1460495.3444999997, -183910.92569999956 -1460867.7657999992))

One can see from this WKT that the values appear to be accurate to 4 decimal places yet are represented by values expressed to 10 or 11 decimal places.

In a specific dataset of 1,983 rows, the total length of all the unmodified WKT objects was 1,230,674 characters.

SELECT SUM(LEN([geom].STAsText())) FROM [dbo].[table_of_data]; GO

If I round the data to 4 decimal places and recalculate the length I get 860,871 characters which is 70 percent of the size of the original calculation.

SELECT SUM(LEN([dbo].[STRound]([geom],4,4,0,0).STAsText())) FROM [dbo].[table_of_data]; GO

### Well Known Binary

If one turns to WKB, the saving is even more stark, at 512,705 characters/bytes or 42 percent of the unchanged geometries.

SELECT SUM(LEN([geom].STAsBinary())) FROM [dbo].[table_of_data]; GO

Note: Rounding the ordinates of a geometry before conversion to WKB has no effect on the final size.

SELECT SUM(LEN([dbo].[STRound]([geom],4,4,0,0).STAsBinary())) FROM [dbo].[table_of_data]; GO (No column name) 512705

### Conclusion

Knowledge is power, so they say, and so having the data about the size of unmodified and modified WKT, along with WKB, means one can make choices that may improve the performance of your web mapping or web processing software.

## Documentation

- MySQL Spatial General Function Documentation
- Oracle Spatial Exporter Package Documentation
- Oracle Spatial Object Function Documentation
- Oracle Spatial Object Function Documentation (Multi Page Version)
- PostGIS pl/pgSQL Function Documentation
- SC4O Oracle Java Topology Suite (Stored Procedures) Package Documentation
- SQL Server Spatial General TSQL Function Documentation
- SQL Server Spatial LRS TSQL Function Documentation