Top 5 Recent Articles
- Algorithms (15)
- All (401)
- Biography (1)
- Blog (44)
- Business Requirements (1)
- Commentary (1)
- Customers (2)
- Data Models (1)
- Education (2)
- GeoRaptor (13)
- Image Processing (2)
- Import Export (8)
- Licensing (2)
- Linear Referencing (4)
- Manifold GIS (3)
- Mapping (1)
- MySQL Spatial (7)
- Networking and Routing (including Optimization) (3)
- Open Source (18)
- Oracle Spatial and Locator (192)
- PostGIS (34)
- Published Articles (1)
- Recommendations (1)
- Services (1)
- Software Change Log (1)
- Source Code (35)
- Space Curves (9)
- Spatial Database Functions (104)
- 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)
- Topological Relationships (1)
- Training (2)
Geometry object size when exchanging of WKT/WKB encoded geometries.
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.
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
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.