-1

I can successfully upload my SHP file into Teradata database using the TDGeoImport tool. The aim is to publish the geospatial table in Teradata to GeoServer as (web) map services.

I'm curious as to how to use the -a_srs parameter. All examples in the references related to Teradata Geospatial skip this -a_srs parameter.

And by references here i mean:

  1. Teradata Geospatial Utilities - User Guide, Release 16.00 B035-2519-086K, November 2016, a 36-pages PDF, here.
  2. Teradata Geospatial Utilities Demonstration : Executing TDGeoImport (a web page), here.
  3. GeoServer and Teradata, version 1.0, July 2011, a 20-pages PDF, here.

This -a_srs parameter is not mandatory and meant for defining the SRID/coordinate system. However, it turned out that there's serious consequence on how the parameter was used. See below:

Different usage of -a_srs and its effect

Interestingly, the above table shows that with the case of TDGeoImport using -a_srs parameter in a way that gives a table with SRID = 0, Geoserver can successfully render the layer. And reversely, using -a_srs parameter in a way that gives SRID = 4326 or 1619, Geoserver fails to render the layer.

And here's the XML error message from Geoserver:

<?xml version="1.0" encoding="UTF-8" standalone="no"?><!DOCTYPE ServiceExceptionReport SYSTEM "http://MYHOST/geoserver/schemas/wms/1.1.1/WMS_exception_1_1_1.dtd"> <ServiceExceptionReport version="1.1.1" >   <ServiceException code="internalError"> Rendering process failed java.io.IOExceptionjava.sql.SQLException: [Teradata Database] [TeraJDBC 15.10.00.33] [Error 7548] [SQLState HY000] 13 ST_Intersects: ST_Geometry values cannot have unequal srid&apos;s. [Teradata Database] [TeraJDBC 15.10.00.33] [Error 7548] [SQLState HY000] 13 ST_Intersects: ST_Geometry values cannot have unequal srid&apos;s.

Now the question are:

  1. How to use this -a_srs parameter?
  2. What is the expected SRID value during importing shapefile with TDGeoImport tool?
  3. What is the risk of skipping this -a_srs parameter ?

My environment are:

  • Teradata Database 15.00.04.04
  • GeoServer 2.10.1 on JBOSS EAP 6 on RedHat Enterprise Linux 6 64-bit

closed as too broad by Vince, PolyGeo Sep 12 '17 at 10:59

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Your complaint about 32-bit operation appears unrelated to your question. It therefore serves as a distraction from your Question, which should only have one question. – Vince Sep 12 '17 at 10:53
1

Option -a_srs is probably the same as in ogr2ogr http://www.gdal.org/ogr2ogr.html but it is indeed not documented which syntax it accepts. It can be either epsg code epsg:4326 or proj4 string "+proj=longlat +datum=WGS84 +no_defs", name of the ESRI .prj file or OGC WKT definition. In your case epsg:xxxx is correct.

The GeoServer error means that database has one SRID and GeoServer sends a query with a spatial filter that is using another SRID or no SRID at all. That feels like misconfiguration on the GeoServer side. Check your setting in the Coordinate Reference Systems http://docs.geoserver.org/stable/en/user/data/webadmin/layers.html. Native SRS must be the same that you have in the database.

Risk of using an undefined SRID is that you can't reproject data into other SRID's and the geometries in the spatial filters which you use must also be in an undefined projection.

Not the answer you're looking for? Browse other questions tagged or ask your own question.