ewestern / geos

This is a Haskell binding to Geos, the open-source geometry library
MIT License
13 stars 9 forks source link

Example of failing test when doing round trip parse/writing hex #22

Closed jamiecook closed 7 years ago

jamiecook commented 7 years ago

It seems that something goes awry with this particular WKB string... it should be a simple MultiLineString with 4 points, and it can be read correctly - but when writing it back to Hex it somehow gets converted back into a MultiPoint

Note the single digit difference from 0105.... to 0104.... in the following test output.

image

I have traced this through this library but can't see anywhere that it would be flipping these geometry types. Not really sure how to tell if this is an upstream problem or not.

ewestern commented 7 years ago

I think I found the culprit: https://github.com/ewestern/geos/blob/master/src/Data/Geometry/Geos/Raw/Internal.hsc#L19

Mind updating that in the PR?

jamiecook commented 7 years ago

You betcha I can!!!!

I don't even know what those constants are... do they come directly from the GEOS C API? I can't find them anywhere else in this repo.

Also - while I'm bugging you with questions - am I right in guessing that this

#{
// some c code
}

is from the LANGUAGE CPP pragma? I'm guessing it allows the inclusion of c headers and ability to define that enum inline?

ewestern commented 7 years ago

Yep, they're exposed by the capi. That weird enum syntax is actually from the hsc2hs api -- it's basically syntactic sugar for expanding out an enum type in to separate constants. See docs here: https://downloads.haskell.org/~ghc/7.0.3/docs/html/users_guide/hsc2hs.html

If you look in a compiled repo, you'll find an Internal.hs (generated by cabal) which has that expanded out.