Introduction - Microsoft



[MS-SSCLRT]: Microsoft SQL Server CLR Types Serialization FormatsIntellectual Property Rights Notice for Open Specifications DocumentationTechnical Documentation. Microsoft publishes Open Specifications documentation (“this documentation”) for protocols, file formats, data portability, computer languages, and standards support. Additionally, overview documents cover inter-protocol relationships and interactions. Copyrights. This documentation is covered by Microsoft copyrights. Regardless of any other terms that are contained in the terms of use for the Microsoft website that hosts this documentation, you can make copies of it in order to develop implementations of the technologies that are described in this documentation and can distribute portions of it in your implementations that use these technologies or in your documentation as necessary to properly document the implementation. You can also distribute in your implementation, with or without modification, any schemas, IDLs, or code samples that are included in the documentation. This permission also applies to any documents that are referenced in the Open Specifications documentation. No Trade Secrets. Microsoft does not claim any trade secret rights in this documentation. Patents. Microsoft has patents that might cover your implementations of the technologies described in the Open Specifications documentation. Neither this notice nor Microsoft's delivery of this documentation grants any licenses under those patents or any other Microsoft patents. However, a given Open Specifications document might be covered by the Microsoft Open Specifications Promise or the Microsoft Community Promise. If you would prefer a written license, or if the technologies described in this documentation are not covered by the Open Specifications Promise or Community Promise, as applicable, patent licenses are available by contacting iplg@. License Programs. To see all of the protocols in scope under a specific license program and the associated patents, visit the Patent Map. Trademarks. The names of companies and products contained in this documentation might be covered by trademarks or similar intellectual property rights. This notice does not grant any licenses under those rights. For a list of Microsoft trademarks, visit trademarks. Fictitious Names. The example companies, organizations, products, domain names, email addresses, logos, people, places, and events that are depicted in this documentation are fictitious. No association with any real company, organization, product, domain name, email address, logo, person, place, or event is intended or should be inferred.Reservation of Rights. All other rights are reserved, and this notice does not grant any rights other than as specifically described above, whether by implication, estoppel, or otherwise. Tools. The Open Specifications documentation does not require the use of Microsoft programming tools or programming environments in order for you to develop an implementation. If you have access to Microsoft programming tools and environments, you are free to take advantage of them. Certain Open Specifications documents are intended for use in conjunction with publicly available standards specifications and network programming art and, as such, assume that the reader either is familiar with the aforementioned material or has immediate access to it.Support. For questions and support, please contact dochelp@. Revision SummaryDateRevision HistoryRevision ClassComments8/7/20090.1MajorFirst release.11/6/20090.1.1EditorialChanged language and formatting in the technical content.3/5/20100.2MinorClarified the meaning of the technical content.4/21/20101.0MajorUpdated and revised the technical content.6/4/20101.0.1EditorialChanged language and formatting in the technical content.6/22/20102.0MajorUpdated and revised the technical content.9/3/20103.0MajorUpdated and revised the technical content.2/9/20113.1MinorClarified the meaning of the technical content.7/7/20113.1NoneNo changes to the meaning, language, or formatting of the technical content.11/3/20113.1NoneNo changes to the meaning, language, or formatting of the technical content.1/19/20123.1NoneNo changes to the meaning, language, or formatting of the technical content.2/23/20123.1NoneNo changes to the meaning, language, or formatting of the technical content.3/27/20123.1NoneNo changes to the meaning, language, or formatting of the technical content.5/24/20123.1NoneNo changes to the meaning, language, or formatting of the technical content.6/29/20123.1NoneNo changes to the meaning, language, or formatting of the technical content.7/16/20123.1NoneNo changes to the meaning, language, or formatting of the technical content.10/8/20123.1NoneNo changes to the meaning, language, or formatting of the technical content.10/23/20123.1NoneNo changes to the meaning, language, or formatting of the technical content.3/26/20133.1NoneNo changes to the meaning, language, or formatting of the technical content.6/11/20133.1NoneNo changes to the meaning, language, or formatting of the technical content.8/8/20133.1NoneNo changes to the meaning, language, or formatting of the technical content.12/5/20133.1NoneNo changes to the meaning, language, or formatting of the technical content.2/11/20144.0MajorUpdated and revised the technical content.5/20/20144.0NoneNo changes to the meaning, language, or formatting of the technical content.5/10/20165.0MajorSignificantly changed the technical content.8/16/20176.0MajorSignificantly changed the technical content.10/16/20197.0MajorSignificantly changed the technical content.Table of ContentsTOC \o "1-9" \h \z1Introduction PAGEREF _Toc22047256 \h 51.1Glossary PAGEREF _Toc22047257 \h 51.2References PAGEREF _Toc22047258 \h 51.2.1Normative References PAGEREF _Toc22047259 \h 51.2.2Informative References PAGEREF _Toc22047260 \h 61.3Overview PAGEREF _Toc22047261 \h 61.4Relationship to Protocols and Other Structures PAGEREF _Toc22047262 \h 71.5Applicability Statement PAGEREF _Toc22047263 \h 71.6Versioning and Localization PAGEREF _Toc22047264 \h 71.7Vendor-Extensible Fields PAGEREF _Toc22047265 \h 82Structures PAGEREF _Toc22047266 \h 92.1GEOGRAPHY and GEOMETRY Structures PAGEREF _Toc22047267 \h 92.1.1Basic GEOGRAPHY Structure (Version 1) PAGEREF _Toc22047268 \h 92.1.2Basic GEOGRAPHY Structure (Version 2) PAGEREF _Toc22047269 \h 112.1.3FIGURE Structure PAGEREF _Toc22047270 \h 132.1.4SHAPE Structure PAGEREF _Toc22047271 \h 142.1.5GEOGRAPHY POINT Structure PAGEREF _Toc22047272 \h 152.1.6GEOMETRY POINT Structure PAGEREF _Toc22047273 \h 162.1.7SEGMENT Structure PAGEREF _Toc22047274 \h 162.2HIERARCHYID Structure PAGEREF _Toc22047275 \h 172.2.1Logical Definition PAGEREF _Toc22047276 \h 172.2.2Physical Representation PAGEREF _Toc22047277 \h 172.3CLR UDTs PAGEREF _Toc22047278 \h 182.3.1Native UDT Serialization PAGEREF _Toc22047279 \h 192.3.1.1Binary Format of Each Byte PAGEREF _Toc22047280 \h 202.3.1.2Binary Format of Primitive Types PAGEREF _Toc22047281 \h 202.3.1.3Nested Structures PAGEREF _Toc22047282 \h 212.3.2User-Defined UDT Serialization PAGEREF _Toc22047283 \h 223Structure Examples PAGEREF _Toc22047284 \h 233.1GEOGRAPHY and GEOMETRY Structures PAGEREF _Toc22047285 \h 233.1.1Empty Point Structure PAGEREF _Toc22047286 \h 233.1.2Geometry Point Structure PAGEREF _Toc22047287 \h 233.1.3Linestring Structure PAGEREF _Toc22047288 \h 243.1.4Geometry Collection Structure PAGEREF _Toc22047289 \h 253.1.5Object Serialized in Version 2 PAGEREF _Toc22047290 \h 283.2HIERARCHYID Structure PAGEREF _Toc22047291 \h 293.3CLR UDT Serialization PAGEREF _Toc22047292 \h 304Security Considerations PAGEREF _Toc22047293 \h 325Appendix A: Product Behavior PAGEREF _Toc22047294 \h 336Change Tracking PAGEREF _Toc22047295 \h 357Index PAGEREF _Toc22047296 \h 36Introduction XE "Introduction" The SQL Server CLR types serialization formats are the binary formats of the GEOGRAPHY, GEOMETRY, HIERARCHYID, and common language runtime (CLR) user-defined type (UDT) structures that are managed by the protocol server. The protocol server provides the geography, geometry, and hierarchyid protocol server data types as well as the CLR UDTs that use these structures.The geography and geometry protocol server data types implement the OpenGIS Consortium’s (OGC) Simple Feature Specification (SFS) [OGCSFS] section 8. Thus, the content of these structures closely mirrors the SFS.The hierarchyid protocol server data type represents a position in a certain hierarchy. The content of an individual entry of this data type within a column of hierarchyid data does not represent a hierarchy tree, and therefore it is the application that needs to generate and assign values in such a way that will represent the desired relationship between rows in the column.CLR UDTs enable users to extend the protocol server type system by creating new types. These types can include any fields and methods defined by the user. The exact structure depends on the user who is implementing CLR UDTs. The protocol client program has to contain the knowledge of the internal structure of each CLR UDT before it can read that type’s binary format.Sections 1.7 and 2 of this specification are normative. All other sections and examples in this specification are informative.Glossary XE "Glossary" This document uses the following terms:common language runtime (CLR): The core runtime engine in the Microsoft .NET Framework for executing applications. The common language runtime supplies managed code with services such as cross-language integration, code access security, object lifetime management, and debugging and profiling support.little-endian: Multiple-byte values that are byte-ordered with the least significant byte stored in the memory location with the lowest address.user-defined type (UDT): User-defined types can extend the scalar type system of the protocol server database, enabling storage of common language runtime objects in a protocol server database. UDTs can contain multiple elements, and they can have behaviors to differentiate them from the traditional alias data types that consist of a single protocol server system data type.MAY, SHOULD, MUST, SHOULD NOT, MUST NOT: These terms (in all caps) are used as defined in [RFC2119]. All statements of optional behavior use either MAY, SHOULD, or SHOULD NOT.References XE "References" Links to a document in the Microsoft Open Specifications library point to the correct section in the most recently published version of the referenced document. However, because individual documents in the library are not updated at the same time, the section numbers in the documents may not match. You can confirm the correct section numbering by checking the Errata. Normative References XE "References:normative" XE "Normative references" We conduct frequent surveys of the normative references to assure their continued availability. If you have any issue with finding a normative reference, please contact dochelp@. We will assist you in finding the relevant information. [IEEE754] IEEE, "IEEE Standard for Binary Floating-Point Arithmetic", IEEE 754-1985, October 1985, [MS-NRBF] Microsoft Corporation, ".NET Remoting: Binary Format Data Structure".[MS-TDS] Microsoft Corporation, "Tabular Data Stream Protocol".[OGCSFS] Herring, J. R., Ed., "OpenGIS Implementation Specification for Geographic information – Simple feature access – Part 1: Common architecture", OGC 06-103r3 Version 1.2.0, October 2006, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, References XE "References:informative" XE "Informative references" [IRE-MRC] Huffman, D., "A Method for the Construction of Minimum-Redundancy Codes", Proceedings of the I.R.E., vol. 40, pp. 1098-1101, September 1952, [MS-BINXML] Microsoft Corporation, "SQL Server Binary XML Structure".[MSDN-CLRUDT] Microsoft Corporation, "CLR User-Defined Types", [MSDN-UDTR] Microsoft Corporation, "Creating User-Defined Types - Requirements", XE "Overview (synopsis)" The geography and geometry data types are used by the protocol server to represent two-dimensional objects. The geography data type is designed to handle ellipsoidal coordinates that are defined from a variety of standard Earth-shape references, and is used specifically to accommodate geospatial data. The geometry data type is nonspecific and can be used for geospatial and other spatial applications that use Cartesian coordinates.Instances of the geometry and geography data types can be composed of a variety of complex features whose definitions are stored in various structures. These structures are described in detail later in this document.The hierarchyid data type is used by a protocol server application to model tree structures in a more efficient way than was formerly possible. This data type significantly improves on the performance of current solutions (for instance, recursive queries).Values of the hierarchyid data type represent nodes in a hierarchy tree. This data type is a system common language runtime (CLR) type, so applications interpret it the same way they would interpret any protocol server CLR user-defined type (UDT). The binary structure of the data type, described in detail later in this document, uses a variant on Huffman encoding to represent the path from the root of a tree to a particular node in that tree. For more information about Huffman encoding, see [IRE-MRC].CLR UDTs can represent any type defined by the user. The user implements a CLR UDT as a structure by using the CLR type system. The binary format of a CLR UDT depends on two factors. The first factor is the CLR UDT’s internal structure, as defined by the user. The second factor is the serialization format also chosen by the user. To decode the binary format of a CLR UDT, it is necessary to know these two properties of the CLR UDT.The user implementing CLR UDTs can include primitive types and other structures. The structures can include other CLR UDTs. The set of types available for fields might be limited, depending on the serialization format chosen by the user.The user can choose between two available serialization formats: protocol server native UDT serialization, and user-defined UDT serialization. Protocol server native UDT serialization is designed for simple CLR UDTs that have a simple structure and use only a specified set of simple primitive types. User-defined UDT serialization is more flexible and enables users to define complex and more dynamic CLR UDTs.To learn more about CLR UDTs, see [MSDN-CLRUDT].Relationship to Protocols and Other Structures XE "Relationship to protocols and other structures" All structures described in this document are designed to be transported over Tabular Data Stream protocol as described in [MS-TDS] section 2.2.5.5.2.Applicability Statement XE "Applicability" The spatial data format presented in this document is designed for the native code programmer (who uses code such as C and C++, for example) and documents the disk representation for the protocol server geography and geometry data types. Programmers who use managed code (such as Microsoft .NET Framework) are encouraged to use the SQL CLR Types library (SQLSysClrTypes.msi) and the corresponding builder API.The HIERARCHYID format presented in this document is designed to be used solely with managed code by using the SQL CLR Types library (SQLSysClrTypes.msi) and the corresponding APIs.The format of common language runtime (CLR) user-defined types (UDTs) is designed to be used solely with managed code by using the same classes that define CLR UDTs in a protocol client program. As stated earlier in this document, without knowledge of the internal structure of a CLR UDT and the serialization format that it is using, it is impossible to read the CLR UDT from the binary data representing it.Versioning and Localization XE "Versioning" XE "Localization" This document describes only a single version of the serialization formats that apply to the HIERARCHYID and common language runtime (CLR) user-defined type (UDT) structures, so there are no versioning implications involved.This document describes version 1 and version 2 of the serialization format that is used for the GEOGRAPHY and GEOMETRY structures. HYPERLINK \l "Appendix_A_1" \o "Product behavior note 1" \h <1> Aspects of later serialization format versions that do not apply to earlier versions are specifically identified throughout this document: Version 1 of the GEOGRAPHY and GEOMETRY structures is described in section 2.1.1.Version 2 of the GEOGRAPHY and GEOMETRY structures is described in section 2.1.2.Differences between versions 1 and 2 in the FIGURE structure are described in section 2.1.3.Differences between versions 1 and 2 in the SHAPE structure are described in section 2.1.4.The new SEGMENT structure that was added in version 2 is described in section 2.1.7.There are no localization implications for these structures.The protocol server does not define any versioning scheme for CLR UDTs. Any version data created by the user needs to be part of a CLR UDT itself.Vendor-Extensible Fields XE "Vendor-extensible fields" XE "Fields - vendor-extensible" The GEOMETRY, GEOGRAPHY, and HIERARCHYID structures do not contain any extensible fields.All fields of a common language runtime (CLR) user-defined type (UDT) are defined by the user who creates the type. The serialization format of these fields can also be selected by the user.Structures XE "Structures"GEOGRAPHY and GEOMETRY Structures XE "Structures:GEOMETRY" XE "Structures:GEOGRAPHY" XE "GEOMETRY structure" XE "GEOGRAPHY structure"The GEOGRAPHY and GEOMETRY structures are serialized by using the binary format described later in this section. Each structure contains several fixed fields (or header fields) and building elements HYPERLINK \l "Appendix_A_2" \o "Product behavior note 2" \h <2> that are repeated, as necessary, to describe the geography fully.The GEOGRAPHY POINT and GEOMETRY POINT structures contain the coordinates for an individual point and are repeated for as many points as are present in the GEOGRAPHY or GEOMETRY structure. One shape structure appears for each OGC simple feature that is contained in the GEOGRAPHY or GEOMETRY structure. A shape can consist of multiple figures, each of which is defined by a single figure structure. The GEOGRAPHY and GEOMETRY structures contain flags and counts that indicate how many of these building elements are contained in the GEOGRAPHY and GEOMETRY structures.The structures that are used to transfer geography and geometry data types are identical. Therefore, in the remainder of this document, the term "GEOGRAPHY structure" refers to both the GEOGRAPHY and GEOMETRY structures, except where it is necessary to distinguish between the two structures. Likewise, "geography data type" refers to both the geography and geometry protocol server data types.Note??The term "GEOGRAPHY POINT structure" does not also refer to the GEOMETRY POINT structure in this document.Basic GEOGRAPHY Structure (Version 1) XE "GEOGRAPHY packet" XE "Basic GEOGRAPHY structure"Version 1 of the GEOGRAPHY structure is formatted as shown in the following packet diagram. All double fields contain double-precision floating-point numbers that are 64 bits (8 bytes) long. Integers and double-precision floating-point numbers are expressed in little-endian format.01234567891012345678920123456789301SRIDVersionSerialization PropertiesNumber of Points (optional, unsigned)...Points (optional, variable) (16 * Number of Points bytes) (variable)...Z Values (optional, 8 * Number of Points bytes) (variable)...M Values (optional, 8 * Number of Points bytes) (variable)...Number of Figures (optional, unsigned)Figures (optional, 5 * Number of Figure bytes) (variable)...Number of Shapes (optional, unsigned)Shapes (optional, 9 * Number of Shapes bytes) (variable)...SRID (4 bytes): (32 bit integer) The spatial reference identifier (SRID) for the geography. GEOGRAPHY structures MUST use SRID values in the range of 4120 through 4999, inclusive, with the exception of null geographies. A value of -1 indicates a null geography. When a null geography is indicated, all other fields are omitted. Default SRID for GEOGRAPHY instances is 4326. Default SRID for GEOMETRY instances is zero (0). For GEOMETRY instance, SRID can be any value: SRID is not constrained.Version (1 byte): The version of the GEOGRAPHY structure. HYPERLINK \l "Appendix_A_3" \o "Product behavior note 3" \h <3>Serialization Properties (1 byte): A bit field that contains individual bit flags that indicate which optional content is present in the structure, as well as other attributes of the geography. The first 3 bits of the serialization properties are reserved for future use.01234567000LPVMZWhere the bits are defined as:ValueDescriptionZ(0x01)The structure has Z values.M(0x02)The structure has M values.V(0x04)Geography is valid.For GEOGRAPHY structures, V in version 1 is always set.P(0x08)Geography contains a single point. When P is set, Number of Points, Number of Figures, and Number of Shapes are implicitly assumed to be equal to 1 and are omitted from the structure. In addition, Figures is implicitly assumed to contain one figure representing a Stroke with a Point Offset of 0 (zero). Lastly, Shape is implicitly assumed to contain one shape of type Point, with a Figure Offset of 0 (zero) and without any parents (Parent Offset set to -1). This is an optimization for the common case of a single point.L(0x10)Geography contains a single line segment. When L is set, Number of Points is implicitly assumed to be equal to 2 and does not explicitly appear in the serialized data. Number of Figures and Number of Shapes are implicitly assumed to be equal to 1 and do not explicitly appear in the serialized data. In addition, Figures is implicitly assumed to contain one stroke figure (0x01) with a Point Offset of 0 (zero). Lastly, Shape is implicitly assumed to contain one shape of type 0x02 (LineString), with a Figure Offset of 0 and without any parents (Parent Offset set to -1).P and L are mutually exclusive properties.Number of Points (optional, unsigned) (4 bytes): The number of points in the GEOGRAPHY structure. This MUST be a positive number or 0 (zero). If either the P or L bit is set in the Serialization Properties bit field, this field is omitted from the structure.Points (optional, variable) (16 * Number of Points bytes) (variable): A sequence of point structures. The point coordinates are contained in GEOGRAPHY POINT structures in GEOGRAPHY structures. Likewise, coordinates are contained in GEOMETRY POINT structures in GEOMETRY structures. Both structures contain a pair of doubles.If neither the P nor L bit is set in the Serialization Properties bit field, there will be Number of Points points in the sequence. If the P bit is set, there will be one point. If the L bit is set, there will be two points.Z Values (optional, 8 * Number of Points bytes) (variable): A sequence of double values for the Z value of each point. If the Z bit is set, there will be Number of Points doubles in the array. If a Z value for an individual point is NULL, it is represented by QNaN [IEEE754].M Values (optional, 8 * Number of Points bytes) (variable): A sequence of double values for the M value of each point. If the M bit is set, there will be Number of Points doubles in the array. If an M value for an individual point is NULL, it is represented as QNaN.Number of Figures (optional, unsigned) (4 bytes): The number of figures in the structure. This MUST be a positive number or 0 (zero).Figures (optional, 5 * Number of Figure bytes) (variable): A sequence of figure structures.Number of Shapes (optional, unsigned) (4 bytes): The number of shapes in the structure. This MUST be a positive number.Shapes (optional, 9 * Number of Shapes bytes) (variable): A sequence of shape structures.Basic GEOGRAPHY Structure (Version 2) XE "GEOGRAPHY packet"Version 2 of the GEOGRAPHY structure is formatted as shown in the following packet diagram. All double fields contain double-precision floating-point numbers that are 64 bits (8 bytes) long. Integers and double-precision floating-point numbers are expressed in little-endian format.01234567891012345678920123456789301SRIDVersionSerialization PropertiesNumber of Points (optional, unsigned)...Points (optional, variable) (16 * Number of Points bytes) (variable)...Z Values (optional, 8 * Number of Points bytes) (variable)...M Values (optional, 8 * Number of Points bytes) (variable)...Number of Figures (optional, unsigned)Figures (optional, 5 * Number of Figure bytes) (variable)...Number of Shapes (optional, unsigned)Shapes (optional, 9 * Number of Shapes bytes) (variable)...Number of Segments (optional)Segments (optional) (1 * Number of Segments bytes) (variable)...SRID (4 bytes): (32 bit integer) The SRID for the geography. GEOGRAPHY structures MUST use SRID values in the range of 4120 through 4999, inclusive, with the exception of null geographies. A value of -1 indicates a null geography. When a null geography is indicated, all other fields are omitted. Default SRID for GEOGRAPHY instances is 4326. Default SRID for GEOMETRY instances is zero (0). For GEOMETRY instance, SRID can be any value: SRID is not constrained.Version (1 byte): The version of the GEOGRAPHY structure. HYPERLINK \l "Appendix_A_4" \o "Product behavior note 4" \h <4>Serialization Properties (1 byte): A bit field that contains individual bit flags that indicate which optional content is present in the structure as well as other attributes of the geography. The first 3 bits of the serialization properties are reserved for future use.0123456700HLPVMZWhere the bits are defined as:ValueDescriptionZ(0x01)The structure has Z values.M(0x02)The structure has M values.V(0x04)Geography is valid. For GEOGRAPHY structures, V in version 2 is always set.P(0x08)Geography contains a single point. When P is set, Number of Points, Number of Figures, and Number of Shapes are implicitly assumed to be equal to 1 and are omitted from the structure. In addition, Figures is implicitly assumed to contain one figure representing a Stroke with a Point Offset of 0 (zero). Lastly, Shape is implicitly assumed to contain one shape of type Point, with a Figure Offset of 0 (zero) and without any parents (Parent Offset set to -1). This is an optimization for the common case of a single point.L(0x10)Geography contains a single line segment. When L is set, Number of Points is implicitly assumed to be equal to 2 and does not explicitly appear in the serialized data. Number of Figures and Number of Shapes are implicitly assumed to be equal to 1 and do not explicitly appear in the serialized data. In addition, Figures is implicitly assumed to contain one stroke figure (0x01) with a Point Offset of 0 (zero). Lastly, Shape is implicitly assumed to contain one shape of type 0x02 (LineString), with a Figure Offset of 0 and without any parents (Parent Offset set to -1).P and L are mutually exclusive properties.H(0x20)In version 2 of the serialization format, geography is larger than a hemisphere.Number of Points (optional, unsigned) (4 bytes): The number of points in the GEOGRAPHY structure. This MUST be a positive number or 0 (zero). If either the P or L bit is set in the Serialization Properties bit field, this field is omitted from the structure.Points (optional, variable) (16 * Number of Points bytes) (variable): A sequence of point structures. The point coordinates are contained in GEOGRAPHY POINT structures in GEOGRAPHY structures. Likewise, coordinates are contained in GEOMETRY POINT structures in GEOMETRY structures. Both structures contain a pair of doubles.If neither the P nor L bit is set in the Serialization Properties bit field, there will be Number of Points points in the sequence. If the P bit is set, there will be one point. If the L bit is set, there will be two points.Z Values (optional, 8 * Number of Points bytes) (variable): A sequence of double values for the Z value of each point. If the Z bit is set, there will be Number of Points doubles in the array. If a Z value for an individual point is NULL, it is represented by QNaN [IEEE754].M Values (optional, 8 * Number of Points bytes) (variable): A sequence of double values for the M value of each point. If the M bit is set, there will be Number of Points doubles in the array. If an M value for an individual point is NULL, it is represented by QNaN.Number of Figures (optional, unsigned) (4 bytes): The number of figures in the structure. This MUST be a positive number or 0 (zero).Figures (optional, 5 * Number of Figure bytes) (variable): A sequence of figure structures.Number of Shapes (optional, unsigned) (4 bytes): The number of shapes in the structure. This MUST be a positive number.Shapes (optional, 9 * Number of Shapes bytes) (variable): A sequence of shape structures.Number of Segments (optional) (4 bytes): In version 2 of the serialization format, the number of segments in the structure. This MUST be a positive number.Segments (optional) (1 * Number of Segments bytes) (variable): In version 2 of the serialization format, a sequence of segment structures.FIGURE Structure XE "FIGURE packet" XE "Structures:FIGURE" XE "FIGURE structure"The FIGURE structure defines the partitions in the Points, Z Values, and M Values sequences for each constituent of the simple feature represented by the geography. A simple feature can have more than one part, whereas the collection of simple feature types can contain more than one simple feature.01234567891012345678920123456789301Figures Attribute (byte)Point Offset (32-bit integer)...Figures Attribute (byte) (1 byte): Determines the role of this figure within the GEOMETRY structure.In version 1 of the serialization format, valid values are as follows:0 (0x00): Figure is an interior ring in a polygon. Interior rings represent holes in exterior rings.1 (0x01): Figure is a stroke. A stroke is a point or a line.2 (0x02): Figure is an exterior ring in a polygon. An exterior ring represents the outer boundary of a polygon.In version 2 of the serialization format, valid values are as follows:0 (0x00): Figure is a point.1 (0x01): Figure is a line.2 (0x02): Figure is an arc.3 (0x03): Figure is a composite curve, that is, it contains both line and arc segments.The order of the coordinates in each ring of a geography polygon (but not a geometry polygon) is important. The outer rings for polygons are constructed by using the "left-hand" rule to determine the interior region of a polygon shape. Thus, outer polygon rings have their GEOGRAPHY POINT coordinate pairs ordered in a counter-clockwise direction. Polygon holes are constructed by using the "right-hand" rule. Thus, the GEOGRAPHY POINT coordinate pairs of a polygon holes are ordered in a clockwise direction.Point Offset (32-bit integer) (4 bytes): The offset to the FIGURE structure’s first point in the Points, Z Values, and M Values sequences.SHAPE Structure XE "SHAPE packet" XE "Structures:SHAPE" XE "SHAPE structure"The SHAPE structure identifies each simple feature contained in the GEOGRAPHY structure. It links together the simple feature type, the figure that represents it, and the parent simple feature that contains the present simple feature (if there is one).01234567891012345678920123456789301Parent Offset (32-bit integer)Figure Offset (32-bit integer)OpenGIS Type (1 byte)Parent Offset (32-bit integer) (4 bytes): The offset to the SHAPE structure’s parent (containing) shape in the Shapes sequence if the shape has a parent, such as an outer ring if a hole, or a multipart simple feature.Figure Offset (32-bit integer) (4 bytes): The offset to the SHAPE structure’s Figure in the Figures sequence.OpenGIS Type (1 byte) (1 byte): The type of simple feature represented by the SHAPE structure.In version 1 of the serialization format, valid values are as follows:1 (0x01): Point2 (0x02): LineString3 (0x03): Polygon4 (0x04): MultiPoint5 (0x05): MultiLineString6 (0x06): MultiPolygon7 (0x07): GeometryCollectionVersion 2 of the serialization format adds the following valid values:8 (0x08): CircularString9 (0x09): CompoundCurve10 (0x0A): CurvePolygon11 (0x0B): FullGlobeGEOGRAPHY POINT Structure XE "GEOGRAPHY POINT packet" XE "Structures:GEOGRAPHY POINT" XE "GEOGRAPHY POINT structure"The GEOGRAPHY POINT structure contains latitude and longitude coordinates as double values representing a point located on a spheroid.01234567891012345678920123456789301Latitude (double)...Longitude (double)...Latitude (double) (8 bytes): The GEOGRAPHY POINT structure’s latitude.Longitude (double) (8 bytes): The GEOGRAPHY POINT structure’s longitude.The following rules apply to the structure's latitude and longitude coordinates:The example structure that is provided in this section uses the Well-Known Text (WKT) protocol that is described in [OGCSFS] section 7.Latitude and longitude coordinates are stored as decimal degree values. Negative values are used to designate south latitude and west longitude values.Latitude values MUST be between -90 and 90 degrees, inclusive.Longitude values MUST be between -15069 and 15069 degrees, inclusive.Latitude and Longitude values MUST NOT contain Infinity or NaN [IEEE754]. GEOMETRY POINT Structure XE "GEOMETRY POINT packet" XE "Structures:GEOMETRY POINT" XE "GEOMETRY POINT structure"The GEOMETRY POINT structure contains x-coordinates and y-coordinates as double values representing a point located on a plane.01234567891012345678920123456789301X Coordinate (double)...Y Coordinate (double)...X Coordinate (double) (8 bytes): The GEOMETRY POINT structure's x-coordinate.Y Coordinate (double) (8 bytes): The GEOMETRY POINT structure's y-coordinate.The following rules apply to the structure's x and y coordinates:X Coordinate and Y Coordinate values MUST NOT contain Infinity or NaN.The example structure that is provided in this section uses the Well-Known Text (WKT) protocol that is described in [OGCSFS].SEGMENT Structure XE "SEGMENT packet"In version 2 of the serialization format, the SEGMENT structure defines the structure of a compound curve figure. It contains only one byte, which represents type of the segment. Segments are stored only for figures whose Figure Attribute value is 0x03.01234567891012345678920123456789301Segment TypeSegment Type (1 byte): Determines the type of the segment within the figure.Valid values are as follows:0 (0x00): Segment is a line.1 (0x01): Segment is an arc.2 (0x02): Segment is a first line.3 (0x03): Segment is a first arc.The first line and first arc segments mark the start of the sequence of segments of the same type, which are line and arc respectively. Subsequent segments have types line and arc.HIERARCHYID Structure XE "HIERARCHYID structure"Logical Definition XE "HIERARCHYID structure:Logical definition"A hierarchy tree is an abstract ordered tree. This means that for each node n, there is a "less-than" (<)?order relation on all children of n. This tree has infinite depth. For each node n in the tree, the children of n are in 1-to-1 correspondence with finite nonempty sequences of integers, which are called node labels. Given any two children m1 and m2 of n, m1 < m2 if and only if the label of m1 comes before the label of m2 in the lexicographical order in integer sequences. Thus, for a node n, each child of n has siblings before and after it, and any two children of n have siblings between them.The logical representation of a node label for a child of a given node is a sequence of integers separated by dots (for example, 1, 1.3, or -7.0.-8.9). The hierarchyid HYPERLINK \l "Appendix_A_5" \o "Product behavior note 5" \h <5> data type logically encodes information about a single node in the hierarchy tree by encoding the path from the root of the tree to the node. Such a path is logically represented as a sequence of node labels of all children visited after the root. Each label is followed by a slash, and a slash begins the representation. Thus, a path that visits only the root is represented by a single slash. For example, /, /1/, /0.3.-7/, /1/3/, and /0.1/0.2/ are valid hierarchyid paths of lengths 1, 2, 2, 3, and 3, respectively.The hierarchyid data type represents a node in the hierarchy tree based on a binary encoding of the following logical representation. This encoding is described in section 3.2.Physical Representation XE "HIERARCHYID structure:Physical representation"The logical representation of a node in the hierarchy tree is encoded into a sequence of bits according to the following representation:L0O0F0LiOiFi. . .LkOkFkW In the preceding diagram, each L/O pair encodes one integer in the logical representation of the node; each Fi is a single bit that is 0 (zero) if the integer is followed by a dot in the logical representation, and 1 if it is followed by a slash. W is a string of 0 to 7 bits, padding the representation to the nearest byte; all bits in W have value 0.In the following text, each Li/Oi/Fi triple is referred to as a level. If Fi is 0 (zero), the level is said to be fake; otherwise, it is said to be real.Li/Oi pairs encode an integer according to the following description. If the ith integer in the logical representation of the node is n, the Li/Oi pair encodes n for real levels and n+1 for fake levels. This is done so that, in varbinary (variable-length binary data) comparisons, fake levels compare above real levels.Each Li prefix of an Li/Oi pair specifies a range of integers and a bit size for the following Oi field, as shown in the following table. Each Oi field has some antiambiguity bits that are always of a fixed value for a particular Li value. These bits are used to enable unambiguous backward parsing of the representation. The third column in the table shows the format of Li/Oi pair with antiambiguity bits in the Oi field, with all other bits of the Oi field shown as dots.The actual value of the integer encoded is the value of the Oi field (ignoring antiambiguity bits and interpreting the rest of the bits as an unsigned integer) added to the lower limit of the range corresponding to the Li field.LiBit size of Oi (without/with antiambiguity bits)Full format of the Li/Oi pairRange00010048/53000100..............0.....................0......0...0.1...-281479271682120 to -429497146500010132/36000101...................0......0...0.1...-4294971464 to -416900011012/15000110.....0...0.1...-4168 to -7300106/80010..0.1...-72 to -9001113/300111...-8 to -1012/201..0 to 31002/2100..4 to 71013/3101...8 to 151106/8110..0.1...16 to 79111010/131110...0...0.1...80 to 11031111012/1511110.....0...0.1...1104 to 519911111032/36111110...................0......0...0.1...5200 to 429497249511111148/53111111..............0.....................0......0...0.1...4294972496 to 281479271683151No integer outside of the range -281479271682120 ? 281479271683119 can be represented in this encoding.Also, note that the encoding used in the hierarchyid data type is limited to 892 bytes. Consequently, nodes that have too many levels in their representation to fit into 892 bytes cannot be represented by the hierarchyid data type.The encoding for the root node is a binary string of length 1. Thus, there is one level and no W field.Note??The encoding represented in the preceding table has three useful properties:It is parsable. That is, for any binary string, there is at most one interpretation of it as a sequence of Li/Oi/Fi triples, and there is an efficient parsing algorithm.The representation is also parsable backward (that is, starting from the last byte). This enables an algorithm to determine a node’s parent without having to parse the entire binary paring two encodings by lexicographical binary comparison is equivalent to conducting depth-first comparisons on the corresponding tree nodes.CLR UDTsThis section describes the binary format of common language runtime (CLR) user-defined types (UDTs).Two serialization formats affect the binary format of a CLR UDT:Native UDT serialization is designed for simple CLR UDTs that have a simple structure and use only a certain set of simple primitive types.User-defined UDT serialization is more flexible and lets the user define complex and dynamic CLR UDTs. For more information, see [MSDN-UDTR].Native UDT SerializationNative user-defined type (UDT) serialization is designed to simplify the serialization of simple common language runtime (CLR) UDTs. Therefore, CLR UDTs that use native UDT serialization have to adhere to certain limitations, as specified in this section.All primitive fields MUST be of one of the following types:BOOLBYTESBYTEUSHORTSHORTUINTINTULONGLONGFLOATDOUBLESqlByteSqlInt16SqlInt32SqlInt64SqlBooleanSqlSingleSqlDoubleSqlDateTimeSqlMoneyCLR UDTs that use native UDT serialization can contain nested structures. Fields defined by these nested structures are required to adhere to the same limits that apply to fields of CLR UDTs that use native UDT serialization.The binary format of a CLR UDT that uses native UDT serialization is defined by all of the UDT’s fields, in the order in which they are defined by the user. The format of each field depends on its type.Binary Format of Each ByteEach data type that is formatted by using native user-defined type (UDT) serialization consists of a series of bytes. Each byte is formatted as 8 bits representing the byte value in binary representation in a little-endian bit ordering (formatting all bits in order of their significance, starting with the least significant bit and ending with the most significant bit).Binary Format of Primitive TypesBOOL values are represented as a single byte. Depending on the BOOL value, the byte takes one of the following two values: 0x01 for True or 0x00 for False.BYTE values are represented as a single byte.SBYTE values are represented as a single byte, but the most significant bit is reversed from 0 (zero) to 1 or from 1 to 0.USHORT values are represented as 2 bytes. The most significant byte is first, followed by the least significant byte.SHORT values are represented as 2 bytes. The most significant byte is first, and it has the most significant bit reversed from 0 (zero) to 1 or from 1 to 0. It is followed by the least significant byte.UINT values are represented as 4 bytes, in the order of their significance, starting with the most significant byte and ending with the least significant byte.INT values are represented as 4 bytes, in the order of their significance, starting with the most significant byte and ending with the least significant byte. The most significant byte has the most significant bit reversed from 0 (zero) to 1 or from 1 to 0.ULONG values are represented as 8 bytes, in the order of their significance, starting with the most significant byte and ending with the least significant byte.LONG values are represented as 8 bytes, in the order of their significance, starting with the most significant byte and ending with the least significant byte. The most significant byte has the most significant bit reversed, from 0 (zero) to 1 or from 1 to 0.FLOAT values are represented as defined by 4-byte, [IEEE754] single-precision, floating-point format, but the order of the bytes is reversed.For positive values (including positive 0 (zero)), the most significant bit of the first byte is reversed from 0 (zero) to 1.For negative values, all bits of all bytes are reversed, from 0 (zero) to 1 or from 1 to 0.For negative 0 (zero), all bits remain unchanged.DOUBLE values are represented as defined by 8-byte, double-precision, floating-point format, but the order of the bytes is reversed.For positive values (including positive 0 (zero), the most significant bit of the first byte is reversed, from 0 (zero) to 1.For negative values, all bits of all bytes are reversed, from 0 (zero) to 1 or from 1 to 0.For negative 0 (zero), all bits remain unchanged.SqlByte values are represented as 2 bytes. The first byte is a BOOL value that indicates whether or not the SqlByte value is NULL (True indicates that this value is not NULL; False indicates that it is NULL). The second byte is the actual BYTE value representing the SqlByte value.SqlInt16 values are represented as 3 bytes. The first byte is a BOOL value that indicates whether or not the SqlInt16 value is NULL (True indicates that this value is not NULL; False indicates that it is NULL). The other 2 bytes are the actual SHORT value representing the SqlInt16 value.SqlInt32 values are represented as 5 bytes. The first byte is a BOOL value that indicates whether or not the SqlInt32 value is NULL (True indicates that this value is not NULL; False indicates that it is NULL). The other 4 bytes are the actual INT value representing the SqlInt32 value.SqlInt64 values are represented as 9 bytes. The first byte is a BOOL value that indicates whether or not the SqlInt64 value is NULL (True indicates that this value is not NULL; False indicates that it is NULL). The other 8 bytes are the actual LONG value representing the SqlInt64 value.SqlBoolean values are represented as a single byte. Depending on the value of SqlBoolean, this byte can have any of the following three values: 0x00 for NULL, 0x01 for False, or 0x02 for True.SqlSingle values are represented as 5 bytes. The first byte is a BOOL value that indicates whether or not the SqlSingle value is NULL (True indicates that this value is not NULL; False indicates that it is NULL). The other 4 bytes are the actual FLOAT value representing the SqlSingle value.SqlDouble values are represented as 9 bytes. The first byte is a BOOL value that indicates whether or not the SqlDouble value is NULL (True indicates that this value is not NULL; False indicates that it is NULL). The other 8 bytes are the actual DOUBLE value representing the SqlDouble value.SqlDateTime values are represented as 9 bytes. The first byte is a BOOL value that indicates whether or not the SqlDateTime value is NULL (True indicates that this value is not NULL; False indicates that it is NULL). The next 4 bytes are an INT value representing the date as the number of days elapsed since 1/1/1900 (for dates before 1/1/1900, this will be a negative value). The final 4 bytes are an INT value representing the number of ticks elapsed since midnight of the day represented by the date part. The following rules can be used to calculate the number of elapsed ticks from the number of elapsed milliseconds:Each second consists of 300 ticks. All ticks represent values with the number of milliseconds ending in 0, 3, or 7. For example: 000, 003, 007, 010, 013, 017, 020, …, 990, 993, 997.The valid range for SqlDateTime values is from 1753-1-1 00:00:00.000 through 9999-12-31 23:59:59.997.SqlMoney values are represented as 9 bytes. The first byte is a BOOL value that indicates whether or not the SqlMoney value is NULL (True indicates that this value is not NULL; False indicates that it is NULL). The other 8 bytes are a LONG value representing the SqlMoney value multiplied by 10000.Nested StructuresCommon language runtime (CLR) user-defined types (UDTs) that use native UDT serialization can include nested structures. Nested structures are also created by the user and are represented by formatting all their fields in the order in which they are defined by the user who created the nested structure. The knowledge of the definition of the nested structure is necessary to decode it—the serialization format only contains the serialized data of the nested structure, but not the definition of the structure itself.User-Defined UDT SerializationUser-defined user-defined type (UDT) serialization is used when native UDT serialization does not provide enough flexibility to express more complex and dynamic structures. The user-defined approach lets users implement their own serialization formats by using types defined in .NET Remoting Binary Format.For more details about .NET Remoting Binary Format, see [MS-NRBF].Structure Examples XE "Structure examples"GEOGRAPHY and GEOMETRY Structures XE "Examples:GEOGRAPHY and GEOMETRY Structures" XE "GEOGRAPHY and GEOMETRY Structures example" The following examples illustrate how a selection of simple features is represented in the structures defined in this document.Empty Point Structure XE "Examples:Empty point structure"POINT EMPTY is designed to handle a non-null condition when a function returns an empty set. This can occur, for instance, when two disjoint spatial features are intersected.POINT EMPTY is represented by the following binary string:0x00000000 01 04 00000000 00000000 01000000 FFFFFFFF FFFFFFFF 01This string is interpreted as shown in the following table.Binary valueDescription00000000SRID = 001Version = 104Serialization Properties = V (is valid)00000000Number of Points = 0 (no points)00000000Number of Figures = 0 (no figures)01000000Number of Shapes = 1FFFFFFFF1st Shape Parent Offset = -1 (no parent)FFFFFFFF1st Shape Figure Offset = -1 (no figure)011st Shape OpenGIS Type = 1 (point)Geometry Point Structure XE "Examples:Geometry point structure"POINT(5 10) holds a 0-dimension feature that represents a point location. The following figure shows a geometry point feature located at the intersection of 5 on the x-axis and 10 on the y-axis (the actual point is surrounded by a circular symbol to make it easier to see).Figure SEQ Figure \* ARABIC 1: A geometry pointPOINT (5 10) in SRID 4326 is represented by the following binary string: 0xE6100000 01 0C 0000000000001440 0000000000002440This string is interpreted as shown in the following table.Binary valueDescriptionE6100000SRID = 432601Version = 10CSerialization Properties = V + P (geometry is valid, single point)0000000000001440X = 50000000000002440Y = 10Linestring Structure XE "Examples:Linestring structure"LINESTRING is an ordered series of connected points. LINESTRING (0 1 1, 3 2 2, 4 5 NULL) contains a Z value for each point location, with the last Z value being NULL. The following figure represents the x and y coordinates only for a geometry type.Figure SEQ Figure \* ARABIC 2: A geometry linestringLINESTRING (0 1 1, 3 2 2, 4 5 NULL) is represented by the following binary string:0xE6100000 01 05 03000000 0000000000000000 000000000000F03F 0000000000000840 0000000000000040 0000000000001040 0000000000001440 000000000000F03F 0000000000000040 000000000000F8FF 01000000 01 00000000 01000000 FFFFFFFF 00000000 02This string is interpreted as shown in the following table.Binary valueDescriptionE6100000SRID = 432601Version = 105Serialization Properties = V + Z (geometry is valid, has Z values)03000000Number of Points = 300000000000000001st point X = 0000000000000F03F1st point Y = 100000000000008402nd point X = 300000000000000402nd point Y = 200000000000010403rd point X = 400000000000014403rd point Y = 5000000000000F03F1st point Z = 100000000000000402nd point Z= 2000000000000F8FF3rd point Z = QNaN01000000Number of Figures = 1011st Figure Attribute = 1 (stroke)000000001st Figure Point Offset = 0 (figure starts with 1st point)01000000Number of Shapes = 1FFFFFFFF1st Shape Parent Offset = -1 (no parent)000000001st Shape Figure Offset = 0 (shape starts with 1st figure)021st Shape OpenGIS Type = 2 (linestring)Geometry Collection Structure XE "Examples:Geometry collection structure"GEOMETRYCOLLECTION is a heterogeneous collection of simple features. The following figure shows a geography containing a single point, a single linestring, and a polygon with an interior ring (hole).Figure SEQ Figure \* ARABIC 3: A geometry collection containing a point, a linestring, and a polygon with a holeGEOMETRYCOLLECTION (POINT (4 0), LINESTRING (4 2, 5 3), POLYGON ((0 0, 3 0, 3 3, 0 3, 0 0), (1 1, 1 2, 2 2, 2 1, 1 1))) is represented by the following binary string: 0xE6100000 01 04 0D0000000000000000000000 0000000000001040 0000000000000040 0000000000001040 0000000000000840 0000000000001440 0000000000000000 0000000000000000 0000000000000000 0000000000000840 0000000000000840 0000000000000840 0000000000000840 0000000000000000 0000000000000000 0000000000000000 000000000000F03F 000000000000F03F 0000000000000040 000000000000F03F 0000000000000040 0000000000000040 000000000000F03F 0000000000000040 000000000000F03F 000000000000F03F04000000 01 00000000 01 01000000 02 03000000 00 0800000004000000 FFFFFFFF 00000000 07 00000000 00000000 01 00000000 01000000 02 00000000 02000000 03This string is interpreted as shown in the following table.Binary valueDescriptionE6100000SRID = 432601Version = 104Serialization Properties = V (geography is valid)0D000000Number of Points = 1300000000000000001st point latitude = 000000000000010401st point longitude = 400000000000000402nd point latitude = 200000000000010402nd point longitude = 400000000000008403rd point latitude = 300000000000014403rd point longitude = 500000000000000004th point latitude = 000000000000000004th point longitude = 000000000000000005th point latitude = 000000000000008405th point longitude = 300000000000008406th point latitude = 300000000000008406th point longitude = 300000000000008407th point latitude = 300000000000000007th point longitude = 000000000000000008th point latitude = 000000000000000008th point longitude = 0000000000000F03F9th point latitude = 1000000000000F03F9th point longitude = 1000000000000004010th point latitude = 2000000000000F03F10th point longitude = 1000000000000004011th point latitude = 2000000000000004011th point longitude = 2000000000000F03F12th point latitude = 1000000000000004012th point longitude = 2000000000000F03F13th point latitude = 1000000000000F03F13th point longitude = 104000000Number of Figures = 4011st Figure Attribute = 1 (stroke)000000001st Figure Point Offset = 0 (figure starts with 1st point)012nd Figure Attribute = 1 (stroke)010000002nd Figure Point Offset = 1 (figure starts with 2nd point)023rd Figure Attribute = 2 (exterior polygon ring)030000003rd Figure Point Offset = 3 (figure starts with 4th point)004th Figure Attribute = 0 (interior polygon ring)080000004th Figure Point Offset = 8 (figure starts with 9th point)04000000Number of Shapes = 4FFFFFFFF1st Shape Parent Offset = -1 (no parent)000000001st Shape Figure Offset = 0 (shape starts with 1st figure)071st Shape OpenGIS Type = 7 (GeometryCollection)000000002nd Shape Parent Offset = 0 (parent shape is 1st shape)000000002nd Shape Figure Offset = 0 (shape starts with 1st figure)012nd Shape OpenGIS Type = 1 (Point)000000003rd Shape Parent Offset = 0 (parent shape is 1st shape)010000003rd Shape Figure Offset = 1 (shape starts with 2nd figure)023rd Shape OpenGIS Type = 2 (LineString)000000004th Shape Parent Offset = 0 (parent shape is 1st shape)020000004th Shape Figure Offset = 2 (shape starts with 3rd figure)034th Shape OpenGIS Type = 3 (Polygon)Object Serialized in Version 2In version 2 of the serialization format, this CURVEPOLYGON instance is a surface whose boundary is a curve. In this example, the curve is COMPOUNDCURVE.Figure SEQ Figure \* ARABIC 4: A curve polygon holeCURVEPOLYGON(COMPOUNDCURVE((0 0, 0 2, 2 2), CIRCULARSTRING (2 2, 1 0, 0 0))) is represented by the following binary string:E6100000 02 24 050000000000000000000000 0000000000000000 0000000000000040 0000000000000000 0000000000000040 0000000000000040 0000000000000000 000000000000F03F 0000000000000000 0000000000000000 01000000 03 0000000001000000 FFFFFFFF 00000000 0A03000000 02 00 03This string is interpreted as shown in the following table.Binary valueDescriptionE6100000SRID = 432602Version = 224Serialization Properties = VH (geography which is valid and larger than a hemisphere)05000000Number of Points = 500000000000000001st point latitude = 000000000000000001st point longitude = 000000000000000402nd point latitude = 200000000000000002nd point longitude = 000000000000000403rd point latitude = 200000000000000403rd point longitude = 200000000000000004th point latitude = 0000000000000F03F4th point longitude = 100000000000000005th point latitude = 000000000000000005th point longitude = 001000000Number of Figures = 1031st Figure Attribute = 3 (compound curve)000000001st Figure Point Offset = 0 (figure starts with 1st point)01000000Number of Shapes = 1FFFFFFFF1st Shape Parent Offset = -1 (no parent)000000001st Shape Figure Offset = 0 (shape starts with 1st figure)0A1st Shape OpenGIS Type = 10 (CurvePolygon)03000000Number of Segments = 3021st Segment Segment Type = 2 (First Line)002nd Segment Segment Type = 0 (Line)033rd Segment Segment Type = 3 (First Arc)HIERARCHYID Structure XE "Examples:HIERARCHYID Structure" XE "HIERARCHYID Structure example" The root node is represented by a HIERARCHYID structure.Example 1The first child of the root node, with a logical representation of /1/, is represented as the following bit sequence:01011000The first two bits, 01, are the L1 field, meaning that the first node has a label between 0 (zero) and 3. The next two bits, 01, are the O1 field and are interpreted as the integer 1. Adding this to the beginning of the range specified by the L1 yields 1. The next bit, with the value 1, is the F1 field, which means that this is a "real" level, with 1 followed by a slash in the logical representation. The final three bits, 000, are the W field, padding the representation to the nearest byte.Example 2As a more complicated example, the node with logical representation /1/-2.18/ (the child with label -2.18 of the child with label 1 of the root node) is represented as the following sequence of bits (a space has been inserted after every grouping of 8 bits to make the sequence easier to follow):01011001 11111011 00000101 01000000The first three fields are the same as in the first example. That is, the first two bits (01) are the L1 field, the second two bits (01) are the O1 field, and the fifth bit (1) is the F1 field. This encodes the /1/ portion of the logical representation.The next 5 bits (00111) are the L2 field, so the next integer is between -8 and -1. The following 3 bits (111) are the O2 field, representing the offset 7 from the beginning of this range. Thus, the L2 and O2 fields together encode the integer -1. The next bit (0) is the F2 field. Because it is 0 (zero), this level is fake, and 1 has to be subtracted from the integer yielded by the L2 and O2 fields. Therefore, the L2, O2, and F2 fields together represent -2 in the logical representation of this node.The next 3 bits (110) are the L3 field, so the next integer is between 16 and 79. The subsequent 8 bits (00001010) are the L4 field. Removing the anti-ambiguity bits from there (the third bit (0) and the fifth bit (1)) leaves 000010, which is the binary representation of 2. Thus, the integer encoded by the L3 and O3 fields is 16+2, which is 18. The next bit (1) is the F3 field, representing the slash (/) after the 18 in the logical representation. The final 6 bits (000000) are the W field, padding the physical representation to the nearest byte.CLR UDT Serialization XE "Examples:CLR UDT Serialization" XE "CLR UDT Serialization example" The following example of a common language runtime (CLR) user-defined type (UDT) contains all the primitive types that are described in this document. The CLR UDT is defined in the C# programming language as follows.[SqlUserDefinedType(Format.Native)]public struct SampleNativeUdt : INullable{ public bool BoolValue; public byte ByteValue; public sbyte SByteValue; public short ShortValue; public ushort UShortValue; public int IntValue; public uint UIntValue; public long LongValue; public ulong ULongValue; public float FloatValue; public double DoubleValue; public SqlByte SqlByteValue; public SqlInt16 SqlInt16Value; public SqlInt32 SqlInt32Value; public SqlInt64 SqlInt64Value; public SqlDateTime SqlDateTimeValue; public SqlSingle SqlSingleValue; public SqlDouble SqlDoubleValue; public SqlMoney SqlMoneyValue; public SqlBoolean SqlBooleanValue; // Implementation methods}In the preceding example, the CLR UDT’s fields are initialized with the following values.BoolValue = true;ByteValue = 1;SByteValue = -2;ShortValue = 3;UShortValue = 4;IntValue = -5;UIntValue = 6;LongValue = 7;ULongValue = 8;FloatValue = 1.234568E+08;DoubleValue = 123456789.0123456;SqlByteValue = 9;SqlInt16Value = -10;SqlInt32Value = 11;SqlInt64Value = 12;SqlDateTimeValue = "1/1/2000 12:00:00";SqlSingleValue = 1.234568E+08;SqlDoubleValue = 123456789.0123456;SqlMoneyValue = "$13";SqlBooleanValue = true;Binary formatting of this CLR UDT produces the following stream of bytes in hexadecimal notation. Anything after "--" is a comment intended to improve the readability of this example and is not part of the binary format for this CLR UDT.01 -- bool true01 -- byte 17E -- sbyte -28003 -- short 30004 -- ushort 47FFFFFFB -- int -500000006 -- uint 68000000000000007 -- long 70000000000000008 -- ulong 8CCEB79A3 -- float 123456789.01234567893E6290CBABF35BA7 -- double -123456789.01234567890109 -- SqlByte [bool true, byte 9]017FF6 -- SqlInt16 [bool true, short -10]018000000B -- SqlInt32 [bool true, int 1101800000000000000C -- SqlInt64 [bool true, long 12]0180008EAC80C5C100 -- SqlDateTime [bool true, int 36524 days since 1/1/1900, int 12960000 ticks since midnight]013314865C -- SqlSingle [bool true, float 1.234568E+08]01C19D6F34540CA458 -- SqlDouble [bool true, double 123456789.0123456]01800000000001FBD0 -- SqlMoney [bool true, long 130000]02 -- SqlBoolean trueSecurity Considerations XE "Security - implementer considerations" XE "Implementer - security considerations" None.Appendix A: Product Behavior XE "Product behavior" The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.Microsoft SQL Server 2008 R2Microsoft SQL Server 2012Microsoft SQL Server 2014Microsoft SQL Server 2016Microsoft SQL Server 2017Microsoft SQL Server 2019Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription. HYPERLINK \l "Appendix_A_Target_1" \h <1> Section 1.6: The following table lists versions of the serialization format for GEOGRAPHY and GEOMETRY structures and the products to which those versions apply.Serialization formatApplicable productVersion 1SQL Server 2008 R2SQL Server 2012SQL Server 2014SQL Server 2016SQL Server 2017SQL Server 2019Version 2SQL Server 2012SQL Server 2014SQL Server 2016SQL Server 2017SQL Server 2019 HYPERLINK \l "Appendix_A_Target_2" \h <2> Section 2.1: Microsoft SQL Server supports four building elements, except for SQL Server 2008 R2, which supports three building elements. HYPERLINK \l "Appendix_A_Target_3" \h <3> Section 2.1.1: In Microsoft implementations, a value set to 1 denotes version 1 of the structure and a value set to 2 denotes version 2 of the structure. HYPERLINK \l "Appendix_A_Target_4" \h <4> Section 2.1.2: In Microsoft implementations, a value set to 1 denotes version 1 of the structure and a value set to 2 denotes version 2 of the structure. HYPERLINK \l "Appendix_A_Target_5" \h <5> Section 2.2.1: Microsoft implementations do not produce values outside the range 00:00:00.0000000 through 23:59:59.9999999 but will accept values outside the range as described in [MS-BINXML] section 2.4.2.Change Tracking XE "Change tracking" XE "Tracking changes" This section identifies changes that were made to this document since the last release. Changes are classified as Major, Minor, or None. The revision class Major means that the technical content in the document was significantly revised. Major changes affect protocol interoperability or implementation. Examples of major changes are:A document revision that incorporates changes to interoperability requirements.A document revision that captures changes to protocol functionality.The revision class Minor means that the meaning of the technical content was clarified. Minor changes do not affect protocol interoperability or implementation. Examples of minor changes are updates to clarify ambiguity at the sentence, paragraph, or table level.The revision class None means that no new technical changes were introduced. Minor editorial and formatting changes may have been made, but the relevant technical content is identical to the last released version.The changes made to this document are listed in the following table. For more information, please contact dochelp@.SectionDescriptionRevision class1.6 Versioning and LocalizationAdded SQL Server 2019 to product behavior note.Major5 Appendix A: Product BehaviorAdded SQL Server 2019 to the product applicability list.MajorIndexAApplicability PAGEREF section_a4066830a5084666b5be89ac4bd8741e7BBasic GEOGRAPHY structure PAGEREF section_5db565bbdb144e5d81f4af0d54a875139CChange tracking PAGEREF section_65b1ff3b0731436cb3f792d8fccb8ca535CLR UDT Serialization example PAGEREF section_3533de2a9d1f4f47a280eb08efdc918530EExamples CLR UDT Serialization PAGEREF section_3533de2a9d1f4f47a280eb08efdc918530 Empty point structure PAGEREF section_d6c5f7abaa424f1e96993e9d464c12cb23 GEOGRAPHY and GEOMETRY Structures PAGEREF section_e67d772accd8429684689ed1d10c416e23 Geometry collection structure PAGEREF section_3faa3a6ac7444760b47e71658e7f433425 Geometry point structure PAGEREF section_dc988cb648124ec691cdcce329f6ecda23 HIERARCHYID Structure PAGEREF section_eed8aa556eb34962acd4633e3cfe924229 Linestring structure PAGEREF section_315c6b835ec842a4aeea8585e9a4b35a24FFields - vendor-extensible PAGEREF section_6a0bad96ee5e4526b87cd287b8e281098FIGURE packet PAGEREF section_d2ba843c26214f0cbefcae116a6f772c13FIGURE structure PAGEREF section_d2ba843c26214f0cbefcae116a6f772c13GGEOGRAPHY and GEOMETRY Structures example PAGEREF section_e67d772accd8429684689ed1d10c416e23GEOGRAPHY packet (section 2.1.1 PAGEREF section_5db565bbdb144e5d81f4af0d54a875139, section 2.1.2 PAGEREF section_35a209449c83477691c6b5f5af5fef0311)GEOGRAPHY POINT packet PAGEREF section_9911c186a699485eac776800a11da36115GEOGRAPHY POINT structure PAGEREF section_9911c186a699485eac776800a11da36115GEOGRAPHY structure PAGEREF section_8ce8272865824e7b96a08d03797678779GEOMETRY POINT packet PAGEREF section_47f5ad86257d4134bc909129e2f594e916GEOMETRY POINT structure PAGEREF section_47f5ad86257d4134bc909129e2f594e916GEOMETRY structure PAGEREF section_8ce8272865824e7b96a08d03797678779Glossary PAGEREF section_c2758e90461c4ce7bf215012ed8740805HHIERARCHYID structure PAGEREF section_6f82da7ef4874bb1afa34b0ce0acb2db17 Logical definition PAGEREF section_6afd369e602345df96bc32d684c8a47817 Physical representation PAGEREF section_b975a433e4d749a6a5107ae7558c31f317HIERARCHYID Structure example PAGEREF section_eed8aa556eb34962acd4633e3cfe924229IImplementer - security considerations PAGEREF section_b9679e286532443b9bc55510137d67e932Informative references PAGEREF section_14763f28f0114b65b7f9365f61d4e2ab6Introduction PAGEREF section_d507092f0dd24d4da5a6310f9be8939d5LLocalization PAGEREF section_d303ff8877a44b46a16678641d2f12247NNormative references PAGEREF section_827c400147b84e0b9c2b1bece2a255315OOverview (synopsis) PAGEREF section_ea7c8fa4610043e8870e915740daaf5d6PProduct behavior PAGEREF section_236596a75eb544518f40a2aa1c8afea933RReferences PAGEREF section_b303007a3c4f4c6c9c7d8e95704bd9ca5 informative PAGEREF section_14763f28f0114b65b7f9365f61d4e2ab6 normative PAGEREF section_827c400147b84e0b9c2b1bece2a255315Relationship to protocols and other structures PAGEREF section_8ea85d896d0e45aea72b802b7f41cef37SSecurity - implementer considerations PAGEREF section_b9679e286532443b9bc55510137d67e932SEGMENT packet PAGEREF section_43b13e106372432784205c34de54ae5a16SHAPE packet PAGEREF section_b0e892640e8b48aca5b412459764edde14SHAPE structure PAGEREF section_b0e892640e8b48aca5b412459764edde14Structure examples PAGEREF section_ad857a2e0520444c9b6ececde7c4231623Structures PAGEREF section_76c138c4b5d5431d9d18bfc95c3f90219 FIGURE PAGEREF section_d2ba843c26214f0cbefcae116a6f772c13 GEOGRAPHY PAGEREF section_8ce8272865824e7b96a08d03797678779 GEOGRAPHY POINT PAGEREF section_9911c186a699485eac776800a11da36115 GEOMETRY PAGEREF section_8ce8272865824e7b96a08d03797678779 GEOMETRY POINT PAGEREF section_47f5ad86257d4134bc909129e2f594e916 SHAPE PAGEREF section_b0e892640e8b48aca5b412459764edde14TTracking changes PAGEREF section_65b1ff3b0731436cb3f792d8fccb8ca535VVendor-extensible fields PAGEREF section_6a0bad96ee5e4526b87cd287b8e281098Versioning PAGEREF section_d303ff8877a44b46a16678641d2f12247 ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download