Geometry Boost List: Re: [geometry] Changes in WKB (read) behaviour proposal

Subject: Re: [geometry] Changes in WKB (read) behaviour proposal
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2013-12-09 09:22:31

On 29 November 2013 21:32, Mats Taraldsvik <mats.taraldsvik_at_[hidden]> wrote:
> On 11/26/2013 12:50 PM, Mateusz Loskot wrote:
>>
>> What do you (and others who are interested) think about the idea of
>> splitting parsers?
>
>
> I'm all for splitting the parsers as long as it
> - does not duplicate (parser) code
> - is easy to extend

Yes, overlapping parts may be common of course.

> Perhaps making (ogc) geometry_type e.g. a collection of static functions
> returning uint32_ts instead of an enum would make it easy to reuse in both
> WKB,EWKB and WKB2.5, and extend by users?

Yes, internally common parsing code return uint32_t, but
in public interface enumeration should be used.

In my opinion, in public interface of the library, we should keep
those formats separate:
- boost/geometry/io/wkt, boost::geometry::read_wkt
- boost/geometry/io/ewkt, with boost::geometry::read_ewkt
- boost/geometry/io/wkt25d , with boost::geometry::read_wkt25d
where all three can use common parsing components behind the scene.
Similarly for WKB-like formats.

I'd rather suggest to avoid single boost::geometry::read_wkt/wkb()
that can consume input of any of the variants, trying to determine
which format it is dealing with on parsing.
This way, we also promote more interoperability, not claiming EWKB
is equivalent to OGC WKB. There is already a lot of confusions spread [1], [2]
about those standards.

[1] http://lists.osgeo.org/pipermail/postgis-devel/2013-December/023990.html
[2] MULTIPOINT example is not correct OGC WKT
http://en.wikipedia.org/wiki/Well-known_text

That is my opinion that new code should promote some sort of
purification of those formats,
but I won't die hard for it of you and others don't agree :)

> An example is a user extending WKB to support reading and writing WKB
> Circularstring to/from (represented as) a boost::geometry linestring concept
> with minimal effort. She would not be able to use the algorithms, as the
> circularstring is represented by a linestring datastructure, but she would
> be able to leverage boost geometry's WKB reading and writing for this
> purpose with minimal effort.

Sure, good idea.

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