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-10 09:27:54

On 9 December 2013 15:59, Mateusz Loskot <mateusz_at_[hidden]> wrote:
> 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.
> }

By the way, there is also SQL/MM specification with WKT/WKB
based on/derived from OGC.
It allows use of new range of codes, see a bit of it on screenshot attached
(Unfortunately, ISO documents are not freely available.)

I haven't thought about it heavily, but perhaps it would be a good
idea to narrow down
number of readers/writers in the public interface and merge things
which have most of
properties in common.

For example, both OGC and SQL/MM specify the WKB/WKT formats in fairly
consistent way:
- text tags and text bodies are well specified
- numeric codes for types are based on whole numbers, without any bits
juggling as in the 2.5D extension

I'm still reading and comparing the documents, but so far, the only
difference seems to be:
- range of codes for higher dimensions (e.g. XYZ in OGC is +1000 and
in SQL/MM is +1000000)
- some geometry types are abstract (noninstantiable) in OGC and
concrete in SQL/MM (e.g. MultiCurve)

The first one should be easy to work around, simply check both ranges of codes.
The second one could be left for interpretation to an application, and
BG can just parse all syntactically valid input.

To get it all together, what about 3 kinds
1. OGC and SQL/MM can use common reader/writer, let's say, a pure WKT
and WKB I/O - a base implementation

2. OGC WKT/WKB 2.5D extension can be implemented as extension of the 1.
- differently interpreting geometry headers: not using Z, M, ZM
tokens, consuming SRID, using bitwise operations, etc.

3. PostGIS EWKT/EWKB can be implemented as extension of the 1. as
well, or even as extension to 2. as that should work.
- also taking care of geometry header differences, as PostGIS requires

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