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-11-04 09:26:06

(response to Mats' e-mail received off-list due to the list posting problems)

On 2 November 2013 19:27, Mats Taraldsvik <mats.taraldsvik_at_[hidden]> wrote:
> 1. The current Point parsing behaviour is to silently ignore dimensions that
> the target point type can not handle, i.e. Z and M in a point is silently
> ignored.

Yes, this assumption is a kind of legacy after initial simplified
implementation of WKB parsing. But, we should aim to remove that
limitation.
The whole idea is to provide implementation of WKB, and WKT as well,
which conforms to the OpenGIS specifications as closely as possible.
So, whenever we or Boost.Geometry users speak of WKB or WKT,
we mean the OpenGIS.

> However, this can not easily be applied further -- to linestrings,
> polygons and multi-, because there is no way to know the dimension of points
> in the WKB while parsing (please correct me if I'm wrong here).

The WKB stream carries all (meta)data needed to determine all the
types of coordinates and geometries.
If you look at the latest OGC Simple feature access - Part 1: Common
architecture document (OGC 06-103r3, version: 1.2.0) ,
there is enum WKBGeometryType with all combinations of point types
listed with corresponding numerical identifier:
plain Point = 1, PointZ = 1001, PointM = 2001, PointZM = 3001, etc.

Then, geometries of higher dimensions carry this type in second field
of the WKB byte stream, 4 bytes unsigned integer, after the first
field of 1 byte indicating byte order.

So, we simply have to rely on that information implementing necessary
if-else branching at run-time (the WKB byte stream is an dynamic
user-defined input, so compile-time checks are not very usable here, IMO).

Does that answer your 1st concern?

> Therefore, I added a (more or less trivial) run-time check that compares the
> actual byte size and the expected byte size of the points, linestring,
> polygon etc. which will give a run-time error during parsing, if the WKB
> does not have the expected data/dimensions/size.

Right, that's the mixed run-time and compile-time test we need to
consider indeed.

I see there are a couple of possibilities:

0) If type of WKB input and (geometry) type of target container are
different, then throw error and give up.

1) WKB input w/ geometry of higher dimension than target container
a)  throw error
b) flatten (or clamp) the coordinates. I think we can assume we always
have at least 2D target container with X and Y. So, we can simply ignore
Z and M dimensions in this case.

2) WKB input w/ geometry of lower dimension than target container
a) throw error
b) ignore the higher dimension coordinates in the target geometry,
or set with zero. I think, this option makes little sense.

My opinion is that the 0) gives most consistent behaviour, but from usability
point, we may prefer combination of 1)b) and 2)a)

What do you think?

> The parser should support 3D as long as both the expected point dimensions
> and the wkb point dimensions match. I have tested this for 3D/Z. M is not
> supported by WKT yet, apparently, so I could not test this easily.

M is there too, see OGC specification in version 1.2.0.

> Coincidentally, this also removes the need to (artificially) limit the
> points parser to two dimensions, that I saw a TODO-comment suggesting.
> might statically assert that the expected_geometry has two-dimensional
> points instead, if WKB should be limited to 2D.

Yes, as I mentioned in the beginning, this is a legacy limitation that
should go.

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