]
Tom Arnold commented on TEIID-3301:
-----------------------------------
{quote}
Also if the geometry value is being computed by a function/expression, the resulting sql
could take a performance hit as the expression will be repeated. Which is why it seems
simpler to stick with the ewkb result from postgresql.
{quote}
This makes sense; I didn't really understand the problem until now. I think internal
for MySQL and EWKB for Postgres is the way to go.
For Oracle I'm thinking we could use GML to get the geometry and SRID in one function.
The SDO_UTIL GML function returns the SRID as an attribute. Unfortunately the JTS reader
doesn't use this, so we would have to do a regex to grab it for now. If performance is
too bad we could look at providing a PL/SQL function to do EWKB conversions.
{code}
<gml:Polygon srsName="SDO:8307"
Add GEOMETRY_COLUMNS view
-------------------------
Key: TEIID-3301
URL:
https://issues.jboss.org/browse/TEIID-3301
Project: Teiid
Issue Type: Feature Request
Reporter: Tom Arnold
Assignee: Steven Hawkins
Labels: spatial
Fix For: 8.10
Another OGC Simple Features implementation detail. Basically this is like a specialized
version of SYS.COLUMNS, and would be used to support GIS software (like GeoServer).
http://www.carocoops.org/resources/doc/postgis/x321.html
{code}
CREATE TABLE GEOMETRY_COLUMNS (
F_TABLE_CATALOG VARCHAR(256) NOT NULL,
F_TABLE_SCHEMA VARCHAR(256) NOT NULL,
F_TABLE_NAME VARCHAR(256) NOT NULL,
F_GEOMETRY_COLUMN VARCHAR(256) NOT NULL,
COORD_DIMENSION INTEGER NOT NULL,
SRID INTEGER NOT NULL,
TYPE VARCHAR(30) NOT NULL
)
{code}
I think we could implement this by storing SRID & friends as column properties, and
then creating a view on SYS.COLUMNS & SYS.PROPERTIES.