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

Subject: Re: [geometry] io - WKB
From: Mats Taraldsvik (mats.taraldsvik_at_[hidden])
Date: 2013-07-28 06:45:36

Hi Mateusz,

On 07/18/2013 11:51 PM, Mateusz Loskot wrote:
> 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.

Thanks for the explanations.

- Can I use the boostorg geometry repository on github, or is there 
another (preferably git) source I should use?

- Do you have any guidelines on where I should start?

- Should I begin with implementing the multi-geometries as-is, or should 
the implementation be changed to use streams first? Which stream type?
(As far as I can tell, for WKT, read_wkt use a std::string, while 
write_wkt use basic_ostream)

- I appreciate that in the WKB spec, an enum is used for geometry_type, 
but doesn't this make it hard to extend (for a user)?
An example is PostGIS' extended WKB type, which could be easier to 
implement on top of the wkb implementation if e.g. a static inline const 
unsigned int was used instead, or something with is 
specializable/overloadable.

- A write_wkb method is, as far as I can tell, also missing.
>
> Best regards,
> --
> Mateusz  Loskot, http://mateusz.loskot.net
> _______________________________________________
> Geometry mailing list
> Geometry_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/geometry

Regards,
Mats