Implementation of io/wkb module

[mloskot]

This task covers implementation of read/write/stream procedures for geometries encoded in OGC Well-Known-Binary (WKB) format. The relevant features should be implemented as a part of io/wkb module for basic geometries and - in future - multi/io/wkb for multi-geometry types.

I've started experimental implementation of these features and I'm going to submit them to the SVN repository soon.

The plan is to propose implementation based on binary parser engine from Boost Spirit V2.

After some discussions, we've decided to implement it without Spirit V2 - it's still fresh and not widely used. So, first version will be based on simple binary reader/writer (see ticket #3).

[mloskot]

In trunk (r797) added ggl/io/wkb module with read_wkb.hpp - initial version of Well-Known-Binary reader based on endian_value utility (see ticket #3).

The current version of reader is very early and basic, implements reading WKB of point geometry.

[mloskot]

In trunk (r798), replaced header_parser with two separated ones: byte_order_parser and geometry_type_parser, so the latter is easily reusable for reading type of geometry components of a geometry collection

[mloskot]

In trunk (r799)

• Implemented parsing Well-Known-Binary (WKB) for linestring geometry.
• In value_parser assign value to output then advance stream iterator.
• In parsing_assigner, guarantee to read WKB coordinates as type of double. coordinate_type of point is not guaranteed to be double. Throw exception instead of assign default coordinate_type().

[mloskot]

Reorganized ggl/io/wkb module in trunk (r810)

[barendgehrels]

Looks good!

About ogc.hpp (also to test this trac change). Just a note and an alternative.There are enumerations there.

In ggl/core/geometry_id.hpp there are the same ID's there. They were actually meant to share with ogc. They are also in multi (be it that they are numbered wrongly but that can be corrected).

It are mpl-integer types. The advantage is that you can specialize on them, while you cannot specialize on enum values. I can imagine that the multi-versions of WKB use the building blocks of the single versions, and it might (but it can also be otherwise) that they use it like this.

To be continued...

[barendgehrels]

About the bool return value. It was there in read_wkt but I recently changed this to exceptions. This was discussed and decided by the list.

However, given the current discussion on the list on exceptions we can wait a while until we decide what to do with exceptions / error structures.

---

About the function "parse_point". Why does it exist? Why is the specialization read_wkb<point_tag, G> not derived from point_parser<P> directly?

---

About the static function "parse" and "run". It was recently decided on the list that they will be replaced by "apply" (that was probably after this was already implemented).

To be continued...

[mloskot]

Next iteration of ggl/io/wkb driver development in trunk (r818):

• Removed parse free functions.
• Function read_wkt dispatches directly to parser specializations.
• Added detail::wkb::point_container_parser to parse simple list of coordinates - used by linestring and polygon parsers.
• Added polygon_parser and implemented parsing of polygon well-known-binary.
• Current version of read_wkb supports three simple geometries: point, linestring and polygon.

Barend, here is my reply to your comments:

1. I decided to define enums in ogc.hpp because I wasn't sure the values of geometry ID's are meant to be consistent with OGC. Second, this enumerators are specific to WKB, as they are defined by OGC specifically for WKB format, so I'm not sure they are OGC-wide values. So, as WKB, they are defined in ggl/io/wkb. I don't think there is good reason for specializing on these enumarators, but may be I can't see it at the moment.

2. Regarding bool return, I consider it as a temporary solution. At first, I introduced exceptions but I removed them and decided to leave return value only as read_wkb returns bool. Later, after we decide on errors handling technique, I'll update the parsing engine.

3. I started implementing the parser based on dispatchers defined in read_wkt. So, the free 'parse()' functions were a kind of garbage left after initial steps. I've already removed that.

4. Regarding deriving from parser, yes, that's a good idea and I've seen you refactored the read_wkt that way. First I decided to focus on correct implementation of low-level parsing operations, during next steps I'm going to refactor it to nice structures. As you can see. I've already applied some basic cleanup in r818. Next steps are coming.

5. parse() vs apply(), yes indeed. I'm aware it has been decided to rename parse() but I've left it after I have 3 simple geometries implemented. So, now I have and I will rename it while refactoring the parsers to better structure (as mentioned above).

Generally, I've started with a simple prototyping to get something working as quick as possible. Now, it's time to start refactoring and juggle the code to get nice structure. Does it sound OK?

Big thanks for comments!

[mloskot]

Updated read_wkb interface to accept pointers (r820 and r821):

• Refined iterator pre-conditions in value_parser<T> template to support plain pointers as iterators.
• Reorder template parameters of read_wkb() function accepting begin/end iterators, so iterator type goes first.
• Added new version of read_wkb() function that accepts stream of bytes passed by pointer + length.

p.s. Looking forward trac+svn integration here ;-)

[mloskot]

Implemented test cases for point geometry (r870 and r871)