Invalid EndianType from parseByteString

[FlogFr]

Hello,

I run into a problem with the parseByteString on a simple SQL query.
My SQL query looks like this:

-- name:getLocs :: [(LazyByteString)]
SELECT
  ST_AsBinary(loc)
FROM
  mm

I receive the LazyByteString, for instance "\x0101000000ab93331477204a4098a608707aff3440", and I try to parse it with parseByteString from wkt-geom, but it fails with the error message: "Invalid EndianType".

I'm a bit lost right now, would you be able to point me the right way to debug it?

Thanks

[dendrei]

Hi,

Are you directly parsing the wkb from the database? If you just pass your example "\x0101000000ab93331477204a4098a608707aff3440" to parseByteString it will not be encoded correctly and that's why the decode fails.

[FlogFr]

@dendrei I'm using YeshQL to map my SQL queries to PostgreSQL, and I ask to return some ByteString (I tried lazy and not lazy).
This "\x0101000000ab93331477204a4098a608707aff3440" is show wkbByteString.

[newmana]

Sorry this took so long to respond to.

I think "\x..." is a way to encode a single unicode character in Haskell. Maybe YeshQL is adding that I don't know. When I try and create "\x0101000000ab93331477204a4098a608707aff3440" in GHCI it returns "numeric escape sequence out of range at character '0'".

If you use "0101000000ab93331477204a4098a608707aff3440" instead and treat it as a hex (base 16) representation and decode it into binary (see https://www.schoolofhaskell.com/school/to-infinity-and-beyond/pick-of-the-week/bytestring-bits-and-pieces#hex-and-base64-encoding) then it decodes correctly:

> import Data.ByteString.Base16 (encode, decode)
> bytes = fst $ decode "0101000000ab93331477204a4098a608707aff3440" 
> Data.Wkb.parseByteString $ fromStrict bytes
Right (Point (GeoPoint {_unGeoPoint = GeoPointXY (PointXY {_xyX = 52.253634, _xyY = 20.997962})}))

What's weird is ST_AsBinary is what we use in Hastile (using Hasql) and it returns a binary representation whereas you seem to be getting hex representation (both ByteString unfortunately). I tried looking into YeshQL but didn't get far enough along to reproduce that problem.

I created a new type for the hex version so you can treat the ByteString (binary) and ByteString (hex) differently.

We've added a parseHexBinary which decodes it as hex and returns a geometry if successful. Hope this makes it easier to use/understand.