A SQL Server IO module for NTS which works directly with the serialization format

License	Actions	NuGet	MyGet (pre-release)

Read geography and geometry columns like this.

var geometryReader = new SqlServerBytesReader { IsGeography = true };
var bytes = dataReader.GetSqlBytes(columnOrdinal).Value;
var geometry = geometryReader.Read(bytes);

Write parameters like this.

var geometry = new Point(-122.129797, 47.640049) { SRID = 4326 };
var geometryWriter = new SqlServerBytesWriter { IsGeography = true };
var bytes = geometryWriter.Write(geometry);
var parameter = command.Parameters
    .AddWithValue(parameterName, new SqlBytes(bytes));

// TODO: Set these if you're using Microsoft.Data.SqlClient
//parameter.SqlDbType = SqlDbType.Udt;
//parameter.UdtTypeName = "geography";

SqlServer and NetTopologySuite have a slightly different notion of a geometry's validity. SqlServer stores this information along with the geometry data and the SqlServerBytesWriter uses NetTopologySuite's Geometry.IsValid value. You might get SqlServer geometries that return STIsValid() = true but STIsValidReason() = false.

SqlServer geography types include FULLGLOBE, basically a polygon where the globe is the outer ring (shell) and the interior rings (holes) define areas that are excluded. To achive this, SqlServer is rigid about ring orientations for geographies.

This is currently not representable using NetTopologySuite geometries and the SqlServerBytesWriter throws an ArgumentException if writing a geometry is requested that has an exterior ring oriented clockwise.

SqlServer geography types use the metric system for measures like length, distance and area. For NetTopologySuite geometries everything is planar and thus all return values are in the unit of the input coordinates. In case the coordinates are geographic these values are mostly useless.
Furthermore you can easily create buffers of geometries that exceed the extent of a hemisphere. SqlServer rejects these.