[postgis-users] Help with spatial query (bug??)

[Brent Wood]

--- 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
width :-)


> 
> 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,
sigh...)

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 :-) 



Many thanks,

  Brent