Boost logo

Geometry :

Subject: Re: [geometry] dimension type of geometries
From: Mateusz Loskot (mateusz_at_[hidden])
Date: 2013-07-26 10:48:59


On 26 July 2013 14:57, Adam Wulkiewicz <adam.wulkiewicz_at_[hidden]> wrote:
> 2013/7/25 Mateusz Loskot <mateusz_at_[hidden]>
>> On 25 July 2013 02:41, Adam Wulkiewicz <adam.wulkiewicz_at_[hidden]> wrote:
>> >
>> > Does OGC allow negative dimensions? If not, should we assume that they
>> > won't
>> > be used in the future?
>>
>> In OGC (and ISO too) specifications of Simple Features, all attributes
>> related to
>> geometric dimensions are defined using signed integer.
>> In SQL/MM Spatial, an extension or predecessor of the latest OGC/ISO
>> specs,
>> there is notion of ST_PrivateDimension for which the following rule is
>> specified:
>>
>> a) If the ST_Geometry value corresponds to the empty set, then the
>> dimension is -1.
>>
>> So, I'd draw conclusion, that OGC/ISO at least do not disallow
>> negative values here.
>>
>> Behaviour of empty geometry vs empty set as in set theory might be
>> confusing
>> (some details here
>> http://trac.osgeo.org/postgis/wiki/DevWikiEmptyGeometry)
>>
>
> According to this, the empty geometry is useful in cases where the result of
> the operation isn't any geometry. Our dimensions are static and we handle
> those cases in a different way, so we probably wouldn't need to use the
> empty geometry. However we probably shouldn't assume that we won't,
> especially with Boost.Variant on the horizon.

By the way, there has been a discussion on empty geometries
with some conclusions, but I admit I've lost track on what has been
eventually implemented
http://lists.boost.org/geometry/2009/06/index.php

> So should we leave it as it is and assume that dimension may be signed or
> unsigned?

I personally support what Barend wrote in this thread:
"Unless we want to give -1 (or so) a special meaning (e.g. variable
dimension) ..."

However, in case of unforeseen future requests may happen, it might be
reasonable to consider notion of a kind of singular object for a geometry
(concept similar to singular iterators).
A singular object would be a C++ object with specified properties
like geometric type, but of unknown location (just like an empty
geometry in OGC).
So, requesting any operation on such singular instance of geometry would
lead to undefined result (similarly to dereferencing singular iterators).
Now, what would be reported dimension of such singular object?
Negative value to indicate "undefined" state sounds reasonable.

By the way, do we distinguish the two kinds of dimension:
- dimension of space in which an object is confined
- dimension of object itself (i.e. point is zero-dimensional)

I guess, we speak of the former.
As for the latter, IMHO, size_t would be the only reasonable match.

> It shouldn't be a problem to add empty geometries in the future,
> even if core_traits were using size_t and the user were using some signed
> int of different size.

In the thread above, Bruno proposed emptiness as model's trait.

Best regards,

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

Geometry list run by mateusz at loskot.net