Go to content Go to navigation and search


Current SQL Server Blog Articles



RSS / Atom

Email me


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.

COGO: Creating a stroked polygon from a circle's centre x,y and radius

Thursday May 05 2011 at 00:55

The relevant standards covering spatial data types within databases provide functionality at many levels (and miss some that is required by pratitioners like myself) from object definition through to API specification.

One area within those standards that has limited support within commercial GIS software and database implementations is the case of circular arcs (line and polygon boundary) and circles. Oracle Spatial has always supported them (though they aren’t that easy to work with for the newcomer). Some database implementations, like PostGIS 1.x, support circular arcs though not comprehensively; Microsoft’s SQL Server’s “strict” implementation of OGC SFS 1.1 does not support them at all.

Why do we need circular arcs and circles you may ask?

Where man (or woman if the generic English noun grates) has engineered structures in the natural world, those structures (buildings, roads, railways etc) use many Euclidean geometric forms in the definition. Thus we most often see straight lines defining rectangles and squares (or combinations thereof) in buildings, and we have always seen circles in buildings (think of the unglazed circular opening at the top of the Pantheon in Rome). The Sydney Opera House initially tried to use parabolas and ellipsoids to define the pre-cast segments of its “sail” roof – impossible mathematics and construction in pre-computing Sydney – before finally settling on segments derived from a much simpler spheres). Horizontal and vertical curves in roads and railways are just that: curves! In forestry, circular plots are often used when conducting in statistical inventory in the field.

Given all this, the reasons why there is such patchy support is perplexing. But that is for another day. But what is important to note is that some spatial software (not just SQL Server 2008) simply do not support them.

Many years ago I was required to expose circular forest inventory plots, stored in an Oracle database as as three columns in a table (long,lat and radius) into something the enterprise GIS mapping software could use to produce maps. That software did not support Oracle circles so we had to find a method for representation. We ended up using synchronized materialized views and a function I wrote in PL/SQL called CIRCLE2POLYGON (this is available in my free COGO package). Here is a version of that function for SQL Server 2008.

Note that I have a schema call cogo in which I create functions like this. You can use anything you like.

* @function   : Circle2Polygon
* @precis     : Returns 2003 Polygon shape from Circle Centre XY and Radius
* @version    : 1.0
* @usage      : FUNCTION Circle2Polygon ( @p_dCentreX  float,
*                                         @p_dCentreY  float,
*                                         @p_dRadius   float,
*                                         @p_iSegments integer,
*                                         @p_srid      integer,
*                                         @p_precision integer)
*                RETURNS GEOMETRY
*               eg select cogo.circle2polygon(100,100,5.0,12,0,3);
* @param      : p_dCentreX    : X Ordinate of centre of Circle
* @paramtype  : p_dCentreX    : FLOAT
* @param      : p_dCentreY    : Y Ordinate of centre of Circle
* @paramtype  : p_dCentreY    : FLOAT
* @param      : p_dRadius     : Radius of Circle
* @paramtype  : p_dRadius     : FLOAT
* @param      : p_iSegments   : Number of arc (chord) segments in circle (+ve clockwise, -ve anti-clockwise)
* @paramtype  : p_iSegments   : INTEGER
* @param      : p_srid        : SRID of output shape
* @paramtype  : p_srid        : INTEGER
* @param      : p_precision   : Precision of any XY value ie number of significant digits. If null then 3 is assumed (ie 1 mm): 3456.2345245 -> 3456.235 
* @paramtype  : p_precision   : INTEGER
* @return     : geometry      : Polyon geometry with required rotation of outer shell.
* @rtnType    : geometry      : GEOMETRY
* @note       : Does not throw exceptions
* @note       : Assumes planar projection eg UTM.
* @history    : Simon Greener  - Feb 2005 - Original coding.
* @history    : Simon Greener  - May 2011 - Converted to SQL Server
* @copyright  : Licensed under a Creative Commons Attribution-Share Alike 2.5 Australia License. (http://creativecommons.org/licenses/by-sa/2.5/au/)
Function cogo.Circle2Polygon( @p_dCentreX  float,
                              @p_dCentreY  float,
                              @p_dRadius   float,
                              @p_iSegments integer,
                              @p_srid      integer,
                              @p_precision integer)
Returns geometry

The function can be used to generate a coarse circle of 3 segments per 90 degree slice (4 quarters of circle to give 3 * 4 = 12 segments or slices) as follows:

select cogo.circle2polygon(100,100,5.0,12,0,3);

Which looks like this:

Or, having a bit of fun:

select cogo.circle2polygon(100,100,
                           a.intValue/6 + 5.0,
  from dbo.generate_series(144,0,-12) a;

select b.Radius,
       cogo.circle2polygon(100 + b.Radius/2,
                           100 + b.Radius/2,
  from (select (a.intValue/6 + 5.0) as Radius,
                a.intValue as segments 
          from dbo.generate_series(144,0,-12) a 
        ) b;

If anyone is interested in this function or would like me to create custom TSQL functions to meet your spatial business requirements, please contact me.

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 [2]

Dear sir,

I do appriciate the knowledge you share here but i do wonder. Is there a specific reason why you implemented your own circle construction function? i would love to know if there is a performance hit accompanied with your implementation.

The native function to draw a circle provided by microsoft is following:
declare g Geometry set g = ‘Point(10 10)’
select @g.STBuffer(5)

As you can see, we do specify a point as centre. then we add a buffer of n meter which will be the radius of the circle.

Kind regards
Kevin Bosteels

— Kevin Bosteels · 29 May 2012, 11:06 · #


Two reasons.

1. 2008 did not have Circular arcs and circles and methods for segmenting them.
2. Control over the number of segments in the circle: there is no control over things like arc to chord separation in your method.

(2012 has 1 and some control of 2 – but that’s what happens in software: things change with versions.)

Of course, the performance of your approach will be better as it is core to the product. Performance was never the reason I did what I did. It was mainly a learning exercise in which I ported stuff I had done in Oracle to SQL Server.

Another reason why my approach is not so good: if the data is geodetic/geographic.


— Simon Greener · 29 May 2012, 11:40 · #