Subject: Re: [geometry] Changes in WKB (read) behaviour proposal
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2013-12-09 10:59:41
On 9 December 2013 15:36, Mats Taraldsvik <mats.taraldsvik_at_[hidden]> wrote:
> 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?
It is not public now, I just indicated as *if* there would be a need
to provide access to it.
Sorry for confusion.
>> > 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?
Let's have two enumerations shared between all WKB-like formats
geometry_type - all types of geometries (types, without dimension)
dimension_type - all possible dimensions with 2.5
and rely on the fact specified in OGC spec that:
geometry_type + dimension_type = type code as written in WKB bytes
Certainly, WKB2.5D bitmask will need to be handled slightly different.
A bit of pseudo-code:
point = 1,
tin = 17
xy = 0,
xyz = 1000,
xym = 2000,
xyzm = 3000,
xy25d = 0x80000000 // so called wkbZ mask as specified in
99-402r2 extension and used in PostGIS, OGR, etc.
geometry_type_parser::parse(it, end, raw_type, order);
if (raw_type& dimension_type::xy25d)
geometry_type g_type25d = (raw_type& ~dimension_type::xy25d);
... // parse as WKB 2.5D
// parse as OGC
geometry_type g_type = raw_type % 1000; // i.e. PolygonZ(1003) => 3
dimension_type d_type = raw_type - type; // i.e. PolygonZ(1003) =>
1000 => dimension_type::xyz
// dispatch geometry parsing according to g_type
// --- dispatch coordinates parsing/assign according to d_type
Would it work?
-- Mateusz Åoskot, http://mateusz.loskot.net
Geometry list run by mateusz at loskot.net