Geometry Boost List: [ggl] WKT empty

Subject: [ggl] WKT empty
From: Mateusz Loskot (mateusz)
Date: 2009-06-13 09:32:38

Barend Gehrels wrote:
>>> Now I see it, it is there indeed. Besides that, our
>>> LINESTRING() is probably not valid. No problem to interpret it, but we
>>> should not generate it that way.
>>>     
>>
>> I've found OGC definitions unclear myself [1], so it's not that
>> difficult to generate buggy WKT :-)
>>
>> [1] http://feature.opengeospatial.org/forumbb/viewtopic.php?t=326
>>
>>
>> Usually, EMPTY geometry is a geometry with Zero coordinates specified,
>> as stated here: http://en.wikipedia.org/wiki/Well-known_text
>>
>> However, definition of EMPTY may be extended to incomplete geometries,
>> with missing coordinates, etc., as discussed here:
>>
>> http://lists.osgeo.org/pipermail/geos-devel/2005-April/001362.html
>
>   
> Thanks, this is interesting.
> 
> I agree that there is much unclear. The Wikipedia statement "Empty
> geometries which contain no coordinates can be specified by using the
> symbol EMPTY after the type name" is already unclear. Because a geometry
> (linestring, polygons) can contains no points, or the coordinates of its
> point(s) can be zero, but "no coordinates" is difficult.

My understanding is that if linestring or polygon do not contain any
coordinates, then they should be specified with EMPTY token.
Actually, there is no other valid way to specify empty containers.

Most parsers will fail crunching:

"LINESTRING ()"
"LINESTIRNG"

because lack of meaningful terminator.
Explicit "LINESTRING EMPTY" is clear and does not require parsers to
make any implicit assumptions.

> The result of the intersection of two valid polygons can be zero, one or
> more polygons. So there must be something allowing an empty geometry. In
> the virtual world, where the outcome is a geometry of any type, it can
> be modelled such that it is a multi-polygon. So empty indeed.

Right.

> Empty linestrings and polygons can thus probably be avoided. An empty
> point makes no sense to me.

But it's valid in terms of OGC SFS.
A point entity that has no location in space.
Similarly, empty linestring does not make sense - what to define line
with no vertices for?

OGC SFS defines "is empty" operation on geometry.
For container geometries, it is easy to implement, though for point
geometry...it's not.
Possible options:
- point class stores boolean indicator set during construction and
modification
- if for coordinate_type numeric_limits::has_quiet_NaN() is true,
we could set coordinates of empty point to NaN and "is empty" check
could rely on that.

> GGL lives in the template world and the result of an intersection should
> be a typed geometry. Therefore we've modelled the intersection with an
> output iterator. So two polygons may result in an output iterator,
> outputting zero, one or more polygons. In practice this is close to
> using a multi-polygon. However, if the user would specify that the
> output would be an output iterator of points, it makes sense as well.

Here, I think we are trying to find a compromise between how to support
OGC concepts as they are defined and how to give flexibility to non-OGC
oriented users.

For OGC-oriented users, if intersection results in N>0 polygons,
returning them as a list of points but not as list of polygons or a
multi-polygon, is ambiguous.

Tough call.

> All the intersection points are outputted (close to using a
> multi-point). The output can also be linestrings. So we've problably
> some more variation here.

Yes, indeed.

> The only thing is that it is not so easy (or impossible?) to specify the
> value type of an output iterator. If you use a back_inserter, e.g., its
> value_type is void. So the resulting geometry type should be specified
> by the user. This is different from the last previews, but avoids other
> problems (such as the case where the input geometries are vectors of
> pointers).

I think type given explicitly is an option.

Cheers,
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org