Skip to main content
Question

Creating lines from (possible) WKD strings

  • February 24, 2023
  • 3 replies
  • 103 views

scarter
Contributor
Forum|alt.badge.img+10

Hello Group,

 

I'm wanting to see if I can can create lines from what may be well known binary (WKB) strings (e.g.: 0xE61000000114297C137101D7B2BFE65D8A76C0BF494030842DCBFFD3B2BF70EC7899C0BF4940). To be honest I'm not 100% certain that they are WKB.

 

I have a csv containing these potential WKB values. The workspace is...

 

Creator>

FeatureReader (reads in the csv setting the field called 'sp_geography', which contains the WKB value to varchar>

GeometryReplacer (with encoding as OGC Well Known Binary and the geometry source set to 'sp_geography').

 

When I run it all 171 records goi to the Rejected port. There's a curious blue message in the log:

 

"Invalid WKB encountered.

... Last line repeated 170 times ..."

 

This is odd as the WKD values in the csv are, as far as I can see, all unique.

3 replies

redgeographics
VIP
Forum|alt.badge.img+63

To be honest, it looks like your data isn't WKB at all. The start of that string doesn't match what the first characters of a WKB string would contain.


hkingsbury
Celebrity
Forum|alt.badge.img+73
  • Celebrity
  • February 26, 2023

The "Last line repeated 170 times" refers to the message of "Invalid WKB encounted", not the data. So its saying there were 171 instances of an invalid WKB


geomancer
Evangelist
Forum|alt.badge.img+64
  • Evangelist
  • July 20, 2026

So I consulted Google Gemini, and it told me this:

 The binary string is encoded in the Microsoft SQL Server Spatial (Geography/Geometry) Serialization Format.

It represents a geographic LineString (containing two points) using the WGS 84 coordinate system (SRID 4326), located near London, United Kingdom.

1. Byte-by-Byte Breakdown

Breaking down the hexadecimal string according to the official Microsoft specification reveals this exact structure:

  • e6100000 (SRID): Represented in little-endian byte order for 0x000010E6, which is decimal 4326. This refers to the standard WGS 84 (GPS) spatial reference system.
  • 01 (Version): The internal SQL Server spatial serialization version (Version 1).
  • 14 (Serialization Flags): The bitmask flag 0x14 (binary 00010100) identifies the object as valid and specifies that it is a standard LineString consisting of a single segment between two points.
  • The remaining 32 bytes: These contain four 8-byte double-precision floating-point numbers (IEEE 754) representing the Latitude and Longitude values.

2. Extracted Coordinates

Converting the final 32 bytes into decimal values yields the following geographic points (Latitude, Longitude):

  • Point 1: (51.498061, -0.073593)
  • Point 2: (51.498065, -0.073547)

In standard Well-Known Text (WKT) format, the geometry looks like this:

LINESTRING(-0.073593 51.498061, -0.073547 51.498065)

3. Usage in SQL Server

You can convert this binary string back into a readable native geography object inside SQL Server using the following query:

SELECT geography::STGeomFromWkb(0xe61000000114297c137101d7b2bfe65d8a76c0bf494030842dcbffd3b2bf70ec7899c0bf4940, 4326).ToString();

Conclusion: The format is the native Microsoft SQL Server Spatial Format, representing a two-point LineString near London.

If you need to parse this binary stream programmatically, let me know your programming language (e.g., Python, C#, or JavaScript). I can provide a script to extract the coordinates directly from the bytes.

Feels like cheating 😁