jeroenbourgois
Erlang bit syntax help for myxql geo support
For a project we work on we need geo support in myxql. Instead of waiting and complaining why it is not there, we decided to step in and try to add it. Having little to no understanding of bit syntax, this has already been quite a journey for me. I started out with the Mariaex code as a basis, got into the MySQL and PostGIS documenation, and with a lot of trial and error, now already able to parse a Point and a Polygon. The big goal for our own project is to get MultiPolygon support.
I am trying to figure out this line, that concerns itself with parsing the rings inside a polygon, more specifically the value of the ‘points’ variable, how I should interpret the ‘binary-size’ and ‘unit’ keywords. The actual value is the amount of points inside a polygon. It is needed to extract the correct amount of bits from the binary. I am trying to decode a MultiPolygon and used this as a reference:
<<num_points::32-little, points::binary-size(num_points)-unit(128), rest::bits>>
I found some IBM documentation as well to explain the 32 bit ‘num_points’:
wkbMultiPolygon {
byte byteOrder;
uint32 wkbType; // 6=wkbMultiPolygon
uint32 num_wkbPolygons;
WKBPolygon wkbPolygons[num_wkbPolygons];
};
In order to decode the multipolygon, I guess I also have to read out the ‘num polygons’ from the binary. Getting hold of the amount of polygons works, but the next step is thus unclear, knowing how far to read.
Other documenation about the actual internal bit format is hard to find so it seems. Any help is appreciated!
PS: if you are interested and have knack for bit syntax stuff, feel free to join the fork! We already have one volunteer which is great!
Marked As Solved
jeroenbourgois
@OvermindDL1 thanks to work from our side and @wojtekmach we managed to land a version of myxql with geo support. Just wanted to let you and the topic know ![]()
Also Liked
OvermindDL1
binary means that points will be a binary, size(...) means that the binary will have the size of num_points worth of bytes (8-bits) (where num_points was parsed previously as a 32-bit integer of little-endian order), and the unit(...) will redefine the unit size of size(...) to instead of being 8-bits will instead be 128-bits, so points will be a binary of num_points amount of points where each point is 128 bits in size (maybe some other internal structure?). The rest is just whatever’s left over unparsed as a bitstring.
For note, all documented at: Kernel.SpecialForms — Elixir v1.20.2
jeroenbourgois
Thanks, this already helps! The 128 bits will be the size of one point, which is {x,y} where each element is a 64-bit float. Thanks to point to the docs too.
I will ping the topic once we get further.
Popular in Questions
Other popular topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #phoenix_html
- #iex
- #blog-post
- #graphql
- #genstage
- #ai
- #websockets
- #supervisor
- #advent-of-code
- #elixirconf-us
- #distillery
- #processes
- #forms
- #api
- #metaprogramming
- #security
- #performance








