How do you create a buffer of a geometry in SQL Server 2012?

Question

Hello,
I am new to SQL Server 2012 and spatial data. I built a geometry object of coordinates from a polygon that I stored in a database.  The code is below:
DECLARE @digb GEOMETRY;
SET @digb = GEOMETRY::STGeomFromText('POLYGON ((-79.927138 40.362654, -79.91883 40.364224, -79.915966 40.361067, -79.917897 40.359266, -79.927398 40.360142, -79.927138 40.362654))', 4269);
I am using SRID 4269 (Latitude/Longitude NAD83).  I have no issues getting this geometry to load properly when the query is executed. (shown below)
My problem is that I am unable to create a valid buffer of 150 feet on this geometry.  I have tried using these 3 statements below (I assumed BufferWithCurves() would be the one that would work); however, ALL of them returned to an invalid buffer of
the polygon (shown below):
-     DECLARE @digbb GEOMETRY = @digb.STBuffer(2);
-     DECLARE @digbb GEOMETRY = @digb.BufferWithCurves(2)
-     DECLARE @digbb GEOMETRY = @digb.BufferWithTolerance(@BufferSize,250.0,1);
Does anyone have any idea of how creating this buffer of a geometry object (polygon mentioned above) in SQL Server 2012? 
Thanks in advance for any help.
Nick

Answer 1

Hi Nick,
BTW, please do ask questions on the forum, that's what it's for. I only meant "if my explanation in that specific answer was unclear, let me know and I'll clarify". Feel free to start a new thread for each topic because that way, it's
might be easier for folks to search on.
Specific answers:
I haven't worked directly with the MapInfo loader but if you're working with SQL Server, I assume what they may be doing is looking for "geodesic SRIDs" that SQL Server supports (the ones listed in sys.spatial_reference_systems) and loading those
as geography, else geometry. That may be a good thing to do.
If you want to decide yourself, here's some (short) background.
Only SQL Server (I think PostGIS might have added it) has separate geography and geometry types. Everyone else always uses "geometry" and gives you (maybe) the ability to convert between SRIDs in the database. SQL Server doesn't have
this built-in; you'd need to use a library like PROJ4.
You can use geometry type to refer to geodesic SRIDs, but it doesn't have a way to "take the area using spatial instances in decimal degrees and come up with meters". So, if you only use it to display on a map, it will display correctly.
Or close enough. Same with intersects, intersection and the like. But anything like area, distance, or, in your case buffer using a specific number of meters, you need to use geography.  You could have gotten somewhat similar-looking
results with geometry by making your input to STBuffer a sufficiently small fraction, but it would be a guess on your part, not a "150 feet" buffer.
You can't CAST/CONVERT between geometry and geography because they didn't want people to assume that these would do SRID conversion. However, there is a codeplex library "SQL Server Spatial Tools" (http://sqlspatialtools.codeplex.com/) that
has two methods: VacuousGeometryToGeography and vice-versa, that does the equivalent (but optimized) of taking one type, spitting it out in well-known text format, then using it to initialize the other type. Or you can do this in your own code.
In general, geography is for anything geodesic; geometry is for planar or projected coordinate systems (e.g state plane coordinate systems in US, that don't use Long/Lat). But geography is slightly slower in calculations (like intersects) because it's more
complex than simple Euclidian geometry. And folks in other platforms are used to using "geometry" and having the platform do the (sometimes fairly expensive) conversions on-the-fly. Or maybe you don't care about the area, distance, etc.
Even in the geography type, WKT specifies (Long Lat) not (Lat Long). This is because the OGC standard doesn't distinguish and calls things (X Y), and if you think about it, (X Y) is (Long Lat) not (Lat Long). The SQL Server geography-specific method MakePoint
has latitude first as a parameter. OGC or SQL/MM standard methods and property names start with "ST" in SQL Server (e.g. STIntersects); SQL Server-specific methods and properties do not (e.g. MakePoint, ReorientObject).
Finally, attempting to do spatial calculations with unlike SRIDs (e.g. intersects between SRID 4269 and 4326 instance) returns NULL.  
One more post coming on this thread with some info/links.
Cheers, Bob