Subject: Re: [geometry] io - WKB
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2013-07-18 17:51:35
On 18 July 2013 20:04, Mats Taraldsvik <mats.taraldsvik_at_[hidden]> wrote:
> Hi all,
> I think that WKB io is an important missing feature, so I've started to
> implement WKB reader and writer, based on the existing implementation for
> Is anyone working on this already?
As you already know, there is partial implementation.
> I'm wondering what data structure I should use to store the binary data in.
> - WKT uses basic_ostream, which is possible with binary using the
> .write(char*, numberofbytes) member function, but does this make more sense
> than, say, a std::vector<(unsigned) char>?
> - Is there an obvious choice for efficiency reasons?
> - Should I use char or unsigned char?
Considering C *and* C++ interoperability, container of unsigned char
is the only that offers correctness and portability.
Considering C++ only, then container of char is a perfectly valid storage
for binary data, as C++ standard unifies all character types,
signed and unsigned, to have no padding bits.
So, in C++, std::string is a perfectly valid container for binary data, it
is a sequence of bytes, not characters.
One small issue may be important, depending on use case, it is
that In C++03 std::string is not guaranteed to be continuous memory block.
It's been fixed in C++0x/11.
For best performance, any continuous memory block will be fine, I think.
> - How closely should I mimic the WKT interface? (since it is text and
> binary, and the formats differ, is there a point in keeping the interfaces
Currently, the whole interface is just one function: read_wkb,
similarly to WKT I/O: read_wkt.
Some time ago, we were discussing variant type for geometries
and Bruno submitted some prototype, but I haven't checked it yet.
Here it is with WKT writing support:
The idea is, that once we have I/O functions for various formats (not only WKB)
that dispatch based on compile-time geometry type, then we should be
able to extend it to handle case like this:
variant<point, linestring, polygon> g;
However, such dynamic geometry type support is a further step.
> - A solution could be to read and write HEX strings using an interface that
> is similar to the one for WKT, and a different interface for raw binary
> arrays. Opinions?
IMO, no need for handling binary in HEX form.
> I consider WKB the right choice when performance matters, so we should
> strive to make it efficient.
So, HEX is not an option, IMO.
-- Mateusz Loskot, http://mateusz.loskot.net
Geometry list run by mateusz at loskot.net