[JBoss JIRA] (TEIID-2384) Managing Spatial Data Types
by Tom Arnold (JIRA)
[ https://issues.jboss.org/browse/TEIID-2384?page=com.atlassian.jira.plugin... ]
Tom Arnold edited comment on TEIID-2384 at 1/22/15 12:54 AM:
-------------------------------------------------------------
{quote}
jts does not care if the srid matches when performing the various system functions. We may need to restrict to only matching srids to stay consistent with expected source behavior.
{quote}
Oracle and PostGIS will reproject (ST_Transform) in the case where the SRIDs do not match. For other sources I think we should error, with an eye towards implementing ST_Transform as a system function:
# Add ST_Transform as a CAN_PUSHDOWN with an implementation that just says "reprojection not currently supported". Add as supported function for Oracle & PostGIS.
# In mismatched-SRID situations, wrap geometry literal in ST_Transform to do conversion to target SRID. (Dependency on storing SRID in column metadata for this to work.)
# Change ST_Transform system function to actually do reprojection. I will spend some time in GeoTools trying to get a better understanding of how this works.
was (Author: tom9729):
> jts does not care if the srid matches when performing the various system functions. We may need to restrict to only matching srids to stay consistent with expected source behavior.
Oracle and PostGIS will reproject (ST_Transform) in the case where the SRIDs do not match (from docs). For other sources I think we should error, with an eye towards implementing ST_Transform as a system function:
# Add ST_Transform as a CAN_PUSHDOWN with an implementation that just says "reprojection not currently supported". Add as supported function for Oracle & PostGIS.
# In mismatched-SRID situations, wrap geometry literal in ST_Transform to do conversion to target SRID. (Dependency on storing SRID in column metadata for this to work.)
# Change ST_Transform system function to actually do reprojection. I will spend some time in GeoTools trying to get a better understanding of how this works.
> Managing Spatial Data Types
> ---------------------------
>
> Key: TEIID-2384
> URL: https://issues.jboss.org/browse/TEIID-2384
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Affects Versions: 8.2
> Reporter: luca gioppo
> Assignee: Steven Hawkins
> Labels: spatial, types
> Fix For: 8.10
>
>
> It would be useful to be able to consume data from spatial database exposing the VDB as a spatial database to other application (imagine geoserver).
> TEIID could be strategic for merging georeferenced data and make it available to those systems.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (TEIID-2384) Managing Spatial Data Types
by Tom Arnold (JIRA)
[ https://issues.jboss.org/browse/TEIID-2384?page=com.atlassian.jira.plugin... ]
Tom Arnold edited comment on TEIID-2384 at 1/22/15 12:53 AM:
-------------------------------------------------------------
> jts does not care if the srid matches when performing the various system functions. We may need to restrict to only matching srids to stay consistent with expected source behavior.
Oracle and PostGIS will reproject (ST_Transform) in the case where the SRIDs do not match (from docs). For other sources I think we should error, with an eye towards implementing ST_Transform as a system function:
# Add ST_Transform as a CAN_PUSHDOWN with an implementation that just says "reprojection not currently supported". Add as supported function for Oracle & PostGIS.
# In mismatched-SRID situations, wrap geometry literal in ST_Transform to do conversion to target SRID. (Dependency on storing SRID in column metadata for this to work.)
# Change ST_Transform system function to actually do reprojection. I will spend some time in GeoTools trying to get a better understanding of how this works.
was (Author: tom9729):
> Checked with postgis and they mark the functions as strict/null on null, so we'll keep the current behavior. It is a minor TODO to make the pushdown for mysql/oracle match this.
(I don't completely understand what you're saying here.)
I went with an int (as opposed to Integer) for the SRID because that's how it is on the JTS Geometry. GeometryType has a constant (UNKNOWN_SRID) that indicates that the SRID is not specified. For all of the WKB functions I've looked at, the SRID is an optional argument so I changed JDBC translator to not specify it if it's unknown. I'm not sure if this is necessary if it works as-is, but I think it makes the intent a little clearer for anyone debugging the SQL.
https://github.com/Tom9729/teiid/commit/98e3ade67e3561fb91b2a5ab4a2807458...
> jts does not care if the srid matches when performing the various system functions. We may need to restrict to only matching srids to stay consistent with expected source behavior.
I think this would be a good thing to add in several places. Oracle and presumably Postgres will reproject (ST_Transform) in the case where both sides have an SRID but the SRIDs do not match. MySQL doesn't care because it doesn't use SRID. Thinking ahead, MongoDB only supports WGS84.
It would be cool to be able to offer that reprojection capability in non-pushdown cases. I will spend some time in GeoTools trying to get a better understanding of how this works.
> Managing Spatial Data Types
> ---------------------------
>
> Key: TEIID-2384
> URL: https://issues.jboss.org/browse/TEIID-2384
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Affects Versions: 8.2
> Reporter: luca gioppo
> Assignee: Steven Hawkins
> Labels: spatial, types
> Fix For: 8.10
>
>
> It would be useful to be able to consume data from spatial database exposing the VDB as a spatial database to other application (imagine geoserver).
> TEIID could be strategic for merging georeferenced data and make it available to those systems.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (TEIID-2384) Managing Spatial Data Types
by Tom Arnold (JIRA)
[ https://issues.jboss.org/browse/TEIID-2384?page=com.atlassian.jira.plugin... ]
Tom Arnold commented on TEIID-2384:
-----------------------------------
> Checked with postgis and they mark the functions as strict/null on null, so we'll keep the current behavior. It is a minor TODO to make the pushdown for mysql/oracle match this.
(I don't completely understand what you're saying here.)
I went with an int (as opposed to Integer) for the SRID because that's how it is on the JTS Geometry. GeometryType has a constant (UNKNOWN_SRID) that indicates that the SRID is not specified. For all of the WKB functions I've looked at, the SRID is an optional argument so I changed JDBC translator to not specify it if it's unknown. I'm not sure if this is necessary if it works as-is, but I think it makes the intent a little clearer for anyone debugging the SQL.
https://github.com/Tom9729/teiid/commit/98e3ade67e3561fb91b2a5ab4a2807458...
> jts does not care if the srid matches when performing the various system functions. We may need to restrict to only matching srids to stay consistent with expected source behavior.
I think this would be a good thing to add in several places. Oracle and presumably Postgres will reproject (ST_Transform) in the case where both sides have an SRID but the SRIDs do not match. MySQL doesn't care because it doesn't use SRID. Thinking ahead, MongoDB only supports WGS84.
It would be cool to be able to offer that reprojection capability in non-pushdown cases. I will spend some time in GeoTools trying to get a better understanding of how this works.
> Managing Spatial Data Types
> ---------------------------
>
> Key: TEIID-2384
> URL: https://issues.jboss.org/browse/TEIID-2384
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Affects Versions: 8.2
> Reporter: luca gioppo
> Assignee: Steven Hawkins
> Labels: spatial, types
> Fix For: 8.10
>
>
> It would be useful to be able to consume data from spatial database exposing the VDB as a spatial database to other application (imagine geoserver).
> TEIID could be strategic for merging georeferenced data and make it available to those systems.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (TEIID-2384) Managing Spatial Data Types
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-2384?page=com.atlassian.jira.plugin... ]
Steven Hawkins commented on TEIID-2384:
---------------------------------------
> oracle and others seem to use null rather than 0 for an unknown srid. So we may want to use an Integer field on the GeometryType and update the FROM Text/Binary methods appropriately.
Checked with postgis and they mark the functions as strict/null on null, so we'll keep the current behavior. It is a minor TODO to make the pushdown for mysql/oracle match this.
Added st_geomfromwkb as the dominant function as it matches the spec with an alias to st_geomfrombinary (why they have the inconsistency isn't clear).
> add get/set srid functions
This has also been added. The set srid function will create a new geometry type value and reuse the existing blob reference.
> Managing Spatial Data Types
> ---------------------------
>
> Key: TEIID-2384
> URL: https://issues.jboss.org/browse/TEIID-2384
> Project: Teiid
> Issue Type: Feature Request
> Components: Query Engine
> Affects Versions: 8.2
> Reporter: luca gioppo
> Assignee: Steven Hawkins
> Labels: spatial, types
> Fix For: 8.10
>
>
> It would be useful to be able to consume data from spatial database exposing the VDB as a spatial database to other application (imagine geoserver).
> TEIID could be strategic for merging georeferenced data and make it available to those systems.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (TEIID-3294) dynamic vdb imports nvarchar2 as object
by Steven Hawkins (JIRA)
Steven Hawkins created TEIID-3294:
-------------------------------------
Summary: dynamic vdb imports nvarchar2 as object
Key: TEIID-3294
URL: https://issues.jboss.org/browse/TEIID-3294
Project: Teiid
Issue Type: Bug
Components: JDBC Connector
Affects Versions: 8.6
Reporter: Steven Hawkins
Assignee: Steven Hawkins
Fix For: 8.10
A regression with TEIID-2644 causes nvarchar/nvarchar2 to import as object.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (TEIID-3293) Missing message for key "gss_auth_failed"
by Steven Hawkins (JIRA)
[ https://issues.jboss.org/browse/TEIID-3293?page=com.atlassian.jira.plugin... ]
Steven Hawkins resolved TEIID-3293.
-----------------------------------
Fix Version/s: 8.10
Resolution: Done
Used another existing message. Will need queued for 8.7.x
> Missing message for key "gss_auth_failed"
> -----------------------------------------
>
> Key: TEIID-3293
> URL: https://issues.jboss.org/browse/TEIID-3293
> Project: Teiid
> Issue Type: Bug
> Components: JDBC Driver
> Affects Versions: 8.7.1
> Reporter: Juraj Duráni
> Assignee: Steven Hawkins
> Fix For: 8.10
>
>
> When trying to connect to the Teiid secured with kerberos without valid credentials in the URL (*), connection fails and one exception in the stacktrace has message: <Missing message for key "gss_auth_failed" in: org.teiid.jdbc.i18n>
> (*) e.g.: jdbc:teiid:test_vdb@mm://localhost:31000jaasName=TestClient;kerberosServicePrincipleName=service/this.service.does.not.exist@THIS.REALM.DOES.NOT.EXIST.COM
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months
[JBoss JIRA] (TEIID-3293) Missing message for key "gss_auth_failed"
by Juraj Duráni (JIRA)
Juraj Duráni created TEIID-3293:
-----------------------------------
Summary: Missing message for key "gss_auth_failed"
Key: TEIID-3293
URL: https://issues.jboss.org/browse/TEIID-3293
Project: Teiid
Issue Type: Bug
Components: JDBC Driver
Affects Versions: 8.7.1
Reporter: Juraj Duráni
Assignee: Steven Hawkins
When trying to connect to the Teiid secured with kerberos without valid credentials in the URL (*), connection fails and one exception in the stacktrace has message: <Missing message for key "gss_auth_failed" in: org.teiid.jdbc.i18n>
(*) e.g.: jdbc:teiid:test_vdb@mm://localhost:31000jaasName=TestClient;kerberosServicePrincipleName=service/this.service.does.not.exist@THIS.REALM.DOES.NOT.EXIST.COM
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 11 months