Subject: [ggl] WKT empty
From: Barend Gehrels (Barend.Gehrels)
Date: 2009-06-16 17:08:11
>>
>> So I propose to handle a POINT EMPTY WKT by delivering a POINT(0 0)
>>
>
>
Having thought more about this, a few remarks.
GGL is an underlying library which might, in the future, be used by a
spatial database.
If a database parses WKT it wants to know if it is empty or if it is
not. So we should somehow supply this information.
A database will have more needs. Because we're a template and typesafe
library, it has to be known beforehand if the read_wkt function is feed
by a POINT, LINESTRING, POLYGON, etc. So we might add a pre-parsing
function checking the kind of geometry. And within that function we can
also give back info about "emptyness". It makes sense to combine this.
The read_wkt function itself does then not have to do anything in EMPTY
at all.
I've said that read_wkt would set coordinates to 0 in case of point
empty, but that is actually not true. It calls ggl::clear for a point,
and that function does nothing. This means, if a library user sets the
point beforehand to NAN or -1 or 0, and it is empty, it just keeps its
values.
We've seen also that WKB does not have an EMPTY point. So even if
wished, a database cannot create a WKT of a point which was entered as
POINT EMPTY. Curious how SQL Server 2008 would handle this.
The emptyness is a database option. An EMPTY point can be considered as
NULL by the database, and the database will handle it. So this
simplifies the things earlier in this topic, we don't have to add traits
classes to set/get it to NULL.
Another option is to use Boost.Optional. The read_wkt can have a
boost::optional<P> where P is a point, and set it to non-entered in case
of an empty point. I think this is reasonable, but does not address the
point that databases have to know the geometry type.
So my new proposal is that we make an "inspect_wkt" function which returns
- the geometry type
- if it is empty
- maybe also if it is 2D/3D and has an M-value
it can just do this by inspecting the first few tokens.
Regards, Barend
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20090616/393a217e/attachment.html