Why does SQL Server Geometry accept SRIDs?

4
votes

I understand why we obviously need to supply coordinate system definitions for geography types, however it is unclear to me why we are able to specify geographic coordinate systems for geometry types? Per the MSDN documentation:

The planar spatial data type, geometry, is implemented as a common language runtime (CLR) data type in SQL Server. This type represents data in a Euclidean (flat) coordinate system.

http://technet.microsoft.com/en-us/library/cc280487.aspx

If the geography type is designed to be flat, how can we apply a geographic model to it? The documentation also states that the default behavior is for geometry not to have an associated SRID which I understand:

The default SRID for geometry instances in SQL Server is 0. With geometry spatial data, the specific SRID of the spatial instance is not required to perform calculations; thus, instances can reside in undefined planar space. To indicate undefined planar space in the calculations of geometry data type methods, the SQL Server Database Engine uses SRID 0.

http://technet.microsoft.com/en-us/library/bb895270.aspx#defaultsrid

What would make sense to me is assigning a projected coordinate system to geography types. However from what I can tell we are only able to use geographic coordinate systems.So back to my original question, why are we able to assign geographic coordinate systems for geometry types?

1
sql-servergisgeography

1 Answers

1
votes

Someone just voted up this question so I thought I'd answer it. From what I can tell, this only purpose of assigning SRIDs to geometry types is for metadata. If you externally transformed the geographic data into projected form, you could then store it as a geometry type in SQL Server as it is now flat.

The SRID is not used in any calculations, but exists for record keeping. In fact, if two geometry variables have different SRIDs then SQL Server will throw an error when trying to preform an operation.