SQL Anywhere version : 12.0.1 build # 3769 OS : Windows
My objective is to return list of names where associated geometry contains the specified Point. Currently I inserted some dummy data with name and associated polygon.
When I try to fire following query which I was expecting would return at least one record, started giving me following error.
"select a.name from locationdb a where a.location.ST_CONTAINS(new ST_POINT(0.5206163, 0.90219253)) =1;"
I get error
There was an error reading the results of the SQL statement. The displayed results may be incorrect or incomplete. A geometry with SRID=4326 is not supported for method ST_Contains(ST_Geometry). SQLCODE=-1435, ODBC 3 State="HY000"
Why is SRID 4326 is not supported? How do I get list of SRIDs supported by ST_CONTAINS() method?
I referred to documentation link : http://infocenter.sybase.com/help/topic/com.sybase.help.sqlanywhere.12.0.1/dbspatial/pg-api-spatial-st-geometry-type-st-contains-method.html?resultof=%22%53%54%5f%43%4f%4e%54%41%49%4e%53%22%20
but did not help much.
asked 21 Mar '13, 00:51
There are actually two different problems with the example query:
The first problem arises because a.location has SRID=4326 (as evidenced by the error message), but the ST_POINT in the query has SRID=0 (default because no SRID was specified in the constructor). To fix it you need to specify the SRID in the ST_POINT constructor. See documentation page http://dcx.sybase.com/index.html#1201/en/dbspatial/pg-api-spatial-st-point-constructor.html for ST_POINT constructor templates.
The second problem is what you asked about: ST_CONTAINS is not supported on SRID 4326. To see a list of which methods are [not] supported under round-earth reference systems, see the following documentation pages: http://dcx.sybase.com/index.html#1201/en/dbspatial/list-of-spatial-methods.html or http://dcx.sybase.com/index.html#1201/en/dbspatial/list-of-spatial-predicates.html (for predicates only).
The precise reason why certain methods are not currently supported under round-earth has to do with implementation-specific details, but the problem is roughly that the strategy we currently use for indexing round-earth data does not distinguish a geometry's boundary from its interior (which is why we don't currently support ST_BOUNDARY under round-earth).
The definition of ST_Contains is as follows (see http://dcx.sybase.com/index.html#1201/en/dbspatial/pg-api-spatial-st-geometry-type-st-contains-method.html ):
See http://dcx.sybase.com/index.html#1201/en/dbspatial/addl-info-stcontains.html for additional explanation.
Under round-earth reference systems the second part of that definition is problematic since it requires distinguishing boundary from interior, which is why it is currently unsupported. However, we do support the (vendor extension) predicate ST_COVERS, which is essentially ST_CONTAINS without the interior intersection requirement. In other words, the only case where ST_CONTAINS and ST_COVERS diverge is when the smaller object occurs entirely on the boundary of the larger object. In this case, ST_CONTAINS returns false, whereas ST_COVERS returns true. The predicates ST_WITHIN and ST_COVEREDBY are analogous.
So, this leaves you two options for your query:
answered 21 Mar '13, 10:29
There are a number of spatial operations that are not supported on round earth. Those that are supported on round earth are marked with an X in http://dcx.sybase.com/index.html#1201/en/dbspatial/list-of-spatial-methods.html.
In your case, you can use
You can determine which spatial reference systems are round earth with:
Note that you may want to install a large number of predefined spatial reference systems with
answered 21 Mar '13, 09:36