Subject: Re: [geometry] Changes in WKB (read) behaviour proposal
From: Mats Taraldsvik (mats.taraldsvik_at_[hidden])
Date: 2013-12-09 10:36:00
On 9 Dec 2013 15:22, "Mateusz Loskot" <mateusz_at_[hidden]> wrote:
> On 29 November 2013 21:32, Mats Taraldsvik <mats.taraldsvik_at_[hidden]>
> > 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
> > 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.
Is it really public? As far as I can tell, users aren't directly exposed to
the gemetry_type values, are they?
> 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
> about those standards.
>  MULTIPOINT example is not correct OGC WKT
> 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 :)
I agree :)
> > An example is a user extending WKB to support reading and writing WKB
> > Circularstring to/from (represented as) a boost::geometry linestring
> > with minimal effort. She would not be able to use the algorithms, as the
> > circularstring is represented by a linestring datastructure, but she
> > be able to leverage boost geometry's WKB reading and writing for this
> > purpose with minimal effort.
> Sure, good idea.
I can't see how this is possible with geometry_type as an enum, without
duplicating a complete parser?
> Best regards,
> Mateusz Åoskot, http://mateusz.loskot.net
> Geometry mailing list
Geometry list run by mateusz at loskot.net