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

Subject: Re: [geometry] Changes in WKB (read) behaviour proposal
From: Mats Taraldsvik (mats.taraldsvik_at_[hidden])
Date: 2013-12-09 10:36:00

Hi,

On 9 Dec 2013 15:22, "Mateusz Loskot" <mateusz_at_[hidden]> wrote:
>
> 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.
>

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
[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 :)

I 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.

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_at_[hidden]
> http://lists.boost.org/mailman/listinfo.cgi/geometry

Best regards,
Mats Taraldsvik