Subject: [ggl] WKT empty
From: Barend Gehrels (Barend.Gehrels)
Date: 2009-06-13 06:13:40
>> 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 , so it's not that
> difficult to generate buggy WKT :-)
>  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:
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.
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.
Empty linestrings and polygons can thus probably be avoided. An empty
point makes no sense to me.
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.
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.
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
-------------- next part --------------
An HTML attachment was scrubbed...
Geometry list run by mateusz at loskot.net