Geometry Boost List: Re: [geometry] io - WKB

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
> WKT.
>
> 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
> similar)?

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:
http://svn.boost.org/svn/boost/trunk/boost/geometry/geometries/variant.hpp
http://svn.boost.org/svn/boost/trunk/boost/geometry/io/wkt/write.hpp

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;
read_wkb(bytes, 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.

Best regards,
--
Mateusz  Loskot, http://mateusz.loskot.net