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

enum geometry_type
{
    point = 1,
    ...
    tin = 17
}

enum dimension_type
{
      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.
}

std::uint32_t raw_type;
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
}
else
{
    // parse as OGC
   geometry_type g_type = raw_type % 1000; // i.e. PolygonZ(1003) => 3
=> geometry_type::polygon
   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?

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