[Geoserver-users] Projection issues with SDE layers

Hi I am a user of Geoserver. I have configured Geo Server with SDE plugin. I
am able to access all my SDE layers. I have successfully published my SDE
layers as well. From layers preview I have generated Google Earth KML file.
There I found an issue that layers projection is slightly shifted with an 50
meters distance.
My spatial reference was pointing to QND95 and EPSG:2932 or wkid is 2932.
For cross checking I have exported my feature classes into shape files and I
exported them POSTGIS Database using command shp2psql. After exporting I
have done the set_Transform command for all the tables that I exported.
I have configured postgresql in Geo Server and was successfully accessing
the postgis table.
That seems to be projecting in a correct way.

I am confused where exactly the problem lies. It should be considered as
major issue.

Any suggestions or help is appreciated.

Thanks,
Prasanth.

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Projection-issues-with-SDE-layers-tp5107681.html
Sent from the GeoServer - User mailing list archive at Nabble.com.

50 m sounds very specific. I would check the data at each stage and look for a difference in spatial reference system, or the definition of the spatial reference system between ArcSDE and GeoServer and Google Earth.

You may find http://spatialreference.org useful for checking?

I know in Postgis you can look at table with all the reference system definitions, is their a similar facility in ArcSDE you could check?

···

Jody Garnett

On Thu, Mar 6, 2014 at 1:42 AM, mallelaprasanth <mallelaprasanth@anonymised.com> wrote:

Hi I am a user of Geoserver. I have configured Geo Server with SDE plugin. I
am able to access all my SDE layers. I have successfully published my SDE
layers as well. From layers preview I have generated Google Earth KML file.
There I found an issue that layers projection is slightly shifted with an 50
meters distance.
My spatial reference was pointing to QND95 and EPSG:2932 or wkid is 2932.
For cross checking I have exported my feature classes into shape files and I
exported them POSTGIS Database using command shp2psql. After exporting I
have done the set_Transform command for all the tables that I exported.
I have configured postgresql in Geo Server and was successfully accessing
the postgis table.
That seems to be projecting in a correct way.

I am confused where exactly the problem lies. It should be considered as
major issue.

Any suggestions or help is appreciated.

Thanks,
Prasanth.


View this message in context: http://osgeo-org.1560.x6.nabble.com/Projection-issues-with-SDE-layers-tp5107681.html
Sent from the GeoServer - User mailing list archive at Nabble.com.


Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk


Geoserver-users mailing list
Geoserver-users@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

2014-03-06 0:55 GMT+01:00 Jody Garnett <jody.garnett@anonymised.com>:

50 m sounds very specific. I would check the data at each stage and look
for a difference in spatial reference system, or the definition of the
spatial reference system between ArcSDE and GeoServer and Google Earth.

You may find http://spatialreference.org useful for checking?

I know in Postgis you can look at table with all the reference system
definitions, is their a similar facility in ArcSDE you could check?

As Jody already pointed out the amount of displacement may be related to
datum shift.

Could you post the output of

sdelayer -o describe_long -l <table_name>,<geom_column_nam>

Cheers

Stefano

---------------------------------------------------
41.95581N 12.52854E

http://www.linkedin.com/in/stefanoiacovella

http://twitter.com/#!/Iacovellas

Hi Jody and Stefan,

I got information regarding table from SDE and the table output is

ArcSDE 10.0 for Oracle11g Build 685 Fri May 14 12:05:43 2010
Layer Administration Utility
-----------------------------------------------------
Layer Description ....: <None>
Table Owner ..........: dummy
Table Name ...........: testTable
Spatial Column .......: SHAPE
Layer Id .............: 91
SRID .................: 3
Auth SRID.............: 2
Minimum Shape Id .....: 1
Offset ...............:
  falsex: -5423300.000000
  falsey: -12407500.000000
System Units .........: 10000.000000
Z Offset..............: 0.000000
Z Units ..............: 1.000000
Measure Offset .......: <None>
Measure Units ........: <None>
XY Cluster Tolerance .: 0.001
Spatial Index ........:
  parameter: SPIDX_GRID,GRID0=27000,FULL
  exist: Yes
  array form: 27000,0,0
Layer Envelope .......:
  minx: 209510.67760, miny: 359613.82300
  maxx: 240343.70690, maxy: 440212.44500
Entities .............: nslc+
Layer Type ...........: Extended SQL Type/ST_GEOMETRY
Creation Date ........: Thu Dec 19 08:54:33 2013
I/O Mode .............: NORMAL
Autolocking ..........: Enabled
Precision.............: High
User Privileges ......: SELECT, UPDATE, INSERT, DELETE
Coordinate System ....:
PROJCS["QND_1995_Qatar_National_Grid",GEOGCS["GCS_QND_1995",DATUM["D_QND_1995",SPHEROID["International_1924",6378388.0,297.0]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",200000.0],PARAMETER["False_Northing",300000.0],PARAMETER["Central_Meridian",51.21666666666667],PARAMETER["Scale_Factor",0.99999],PARAMETER["Latitude_Of_Origin",24.45],UNIT["Meter",1.0]]

Layer Configuration ..: DEFAULTS

How to overcome with this datum shift problem. Is datum shift is because of
ESRI or with the GEOSERVER.
Please let me know.

Thanks,
Prasanth.

--
View this message in context: http://osgeo-org.1560.x6.nabble.com/Projection-issues-with-SDE-layers-tp5107681p5107842.html
Sent from the GeoServer - User mailing list archive at Nabble.com.