[postgis-users] Help with spatial query (bug??)
pcreso at pcreso.com
Wed Apr 6 19:50:39 PDT 2005
--- Carl Anderson <carl.anderson at vadose.org> wrote:
> You are assuming that If you present a deficient geometry of a given
> dimension, lacking some relationship component (boundary or interior or
> exterior), the engine should automatically downcast your request to the
> next lower geometry dimension.
Not quite, what I'm assuming is that _if_ a zero length linestring is accepted
as a valid value, then it _is_ treated as such. If the geometry is NOT valid
(ie: rejected on data insertion) as a linestring, then it can't be mistreated.
Whether the operator result is null as you suggest or t/f as I suggest, we both
agree that current situation is not ideal (at least I think we agree on that
I was not expecting an automatic downcast as a solution, merely suggesting that
I would have thought the appropriate result for a zero length linestring would
be the same as for a point feature, which mathematically/topologically I
believe it is.
Although now we are in this arena, I should have a play with polygons of zero
> If you agree that OGC 99-049 is the controlling specification for these
> operations, then the definitions
> of Interior and Boundary for a closed Curve and the definition of the
> Disjoint operator leave you with
> an empty boundary
> an empty interior (or an undefined interior)
> an operator that compares interiors and boundaries.
Yep, a perfect summation!!
> and no defined automatic downcast.
> There are LOTS of things in SF-SQL that I don't like and think could be
> defined in a more user friendly way.
> Those wished for additons to the spec are not debatable, the spec is
> well known and well distributed. The issue is, does the Postgis/GEOS
> engine act in a way that is conformant with the spec?
The engine does (as I understand it), but it also implements enhancements
beyond those specs. The SFS specs are a starting point, not an end point. I
couldn't see any reference to zero length strings or zero width polygons in the
spec, which suggests they either forgot, or they are valid data. Any guesses?
> Dave Blasby asserts that a 0 length LINESTRING is invalid, and as such
> outside of the scope of the SF-SQL spec. The acceptance of which into
> a PostGIS geometry then would be accidental and not intentional.
I'm happy with that approach if it is implemented, but PostGIS is quite happy
to accept a zero length line as data. So perhaps rather than amend the
operators to return a more appropriate result, the system should be modified to
reject zero length lines as invalid data.
If I can apply the bounding box operator, length, etc, with a correct result
then the geometry is only invalid for some operators.
> strk has been improving the support for geometry collections which could
> be a proper wrapper for your dataset. Your dataset is a mixture of
> POINTs and LINESTRINGs, which a geometry collection could hold.
Yep, that is one solution. My zero length lines are in fact a kludge anyway, as
I used them to represent lines with a start position but no recorded end
position. (I'm stuck with using real world data- & that's what was recorded,
For now I have added 0.000001 to the end Y coordinate value, so my lines do not
have a zero length. It works for this data & my current needs, but isn't the
most elegant fix :-)
Anyway, just in case it sounds like I'm complaining, thanks for your input on
this, 'tis appreciated! & much kudos to the developers for giving me these
little problems!!! I'd be far worse off without Postgis/GEOS/etc :-)
BTW, I sometimes wonder if the OGC SFS spec was designed by commercial GIS
vendors to limit the effectivenes of any competing products which just follow
the spec :-)
More information about the postgis-users