Spatial view coordinates out of whack

[LorneDmitruk]

Hi,

I'm working with ArcGIS 10.2.2 hitting up against an eGDB in Oracle 11g. The source for the view is in userA's schema and the view exists in userB's schema. I created the view in the database and registered the view as a layer using sdelayer -o register and can see the view as a feature class in ArcCatalog. When I bring the view into ArcMap the coordinates are way out of whack, the data is stored in GCS NAD 1983 and the features are ending up in the far reaches of the extents.

Any thoughts on what may be causing this would be appreciated.

Cheers!

[VinceAngelo]

We need more information in order to help:

• Exact version of Oracle (11.x.y.z.0)
• 'sdelayer -o describe_long' output on the source layer
• The SQL used to create the view
• 'sdelayer -o register' command used to register the view
• 'sdelayer -o describe_long' output on the view

- V

[LorneDmitruk]

Hi Vince,

Here's the info you wanted:

Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

Long description of the source layer:

ArcSDE 10.2

Layer    Administration Utility

-----------------------------------------------------

Layer Description ....: <None>

Table Owner ..........: PODS

Table Name ...........: STATIONSERIES

Spatial Column .......: SHAPE

Layer Id .............: 385

SRID .................: 7

Auth SRID.............: 300004

Minimum Shape Id .....: 1

Offset ...............:

  falsex:       -140.000000

  falsey:          0.000000

System Units .........: 100079991719344.000000

Z Offset..............:     -30000.000000

Z Units ..............: 257348550135.457000

Measure Offset .......: -100000000.000000

Measure Units ........:      10000.000000

XY Cluster Tolerance .:          0.0

Z  Cluster Tolerance .:          0.000000000008

M  Cluster Tolerance .:          0.0002

Spatial Index ........:

  parameter:    SPIDX_GRID,GRID0=2.8,FULL

  exist:        Yes

  array form:   2.8,0,0

Layer Envelope .......:

  minx:      -113.34570,        miny:         2.30607

  maxx:       -57.95347,        maxy:        57.39768

Entities .............: nslc3+M

Layer Type ...........: Extended SQL Type/ST_GEOMETRY

Creation Date ........: 10/30/13 11:39:02

I/O Mode .............: NORMAL

Autolocking ..........: Enabled

Precision.............: High

User Privileges ......: SELECT, UPDATE, INSERT, DELETE

Coordinate System ....: GEOGCS["GCS_North_American_1983",DATUM["D_North_American_1983",SPHEROID["GRS_1980",6378137.0,98.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],VERTCS["CGVD_1928",VDATUM["Canadian_Geodetic_Vertical_Datum_of_1928"],PARAMETER["Vertical_Shift",0.0],PARAMETER["Direction",1.0],UNIT["Meter",1.0]]

Layer Configuration ..: DEFAULTS

View SQL:

create view podsstationseries as select * from PODS.StationSeries

Register command:

sdelayer -o register -l podsstationseries,shape -e nslc3+M -C objectid,USER -G 4269 -t ST_GEOMETRY -i sde:oracle11g:gs_dev:sheetcutter -u xxxx -p xxxx

ArcSDE 10.2

Layer    Administration Utility

-----------------------------------------------------

Successfully Created Layer.

Spatial view long description:

ArcSDE 10.2

Layer    Administration Utility

-----------------------------------------------------

Layer Description ....: <None>

Table Owner ..........: SHEETCUTTER

Table Name ...........: PODSSTATIONSERIES

Spatial Column .......: SHAPE

Layer Id .............: 596

SRID .................: 6

Auth SRID.............: 300010

Minimum Shape Id .....: 1

Offset ...............:

  falsex:       -400.000000

  falsey:       -400.000000

System Units .........: 1000000000.000000

Z Offset..............:    -100000.000000

Z Units ..............:       1000.000000

Measure Offset .......:    -100000.000000

Measure Units ........:       1000.000000

XY Cluster Tolerance .:          0.000000008983

Z  Cluster Tolerance .:          0.002

M  Cluster Tolerance .:          0.002

Spatial Index ........:

  parameter:    SPIDX_AUTOMATIC

  exist:        No

  array form:   0,0,0

Layer Envelope .......: <EMPTY>

Entities .............: nslc3+M

Layer Type ...........: Extended SQL Type/ST_GEOMETRY

Creation Date ........: 02/12/15 07:52:52

I/O Mode .............: NORMAL

Autolocking ..........: Enabled

Precision.............: High

User Privileges ......: SELECT

Coordinate System ....: GEOGCS["GCS_North_American_1983",DATUM["D_North_American_1983",SPHEROID["GRS_1980",6378137.0,298.257222101]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]]

Layer Configuration ..: DEFAULTS

Screen shot of coordinates from display of feature class from view. This is not the full extent of the features.

Here's a comparison of the coordinates between the spatial view and the source feature class:

>>> with arcpy.da.SearchCursor("SHEETCUTTER.PODSSTATIONSERIES", 'SHAPE@XY') as rows:

...     for row in rows:

...         print(row)

...       

((2919522.7653198587, 5551640.811721431),)

((2919522.7653198587, 5551640.811721431),)

>>> with arcpy.da.SearchCursor("StationSeries", 'SHAPE@XY') as rows:

...     for row in rows:

...         print(row)

...       

((-110.82411064233189, 55.476031885485135),)

((-110.82411064233189, 55.476031885485135),)

Looks like there is major difference in the system units between the two in the long descriptions

Cheers!

[VinceAngelo · Accepted solution]

You always, always need to specify the coordinate reference SRID when registering a view (-R option).  Your view has a different SRID than the source table, which is why the content is coming out wrong.

Drop the view with 'sdetable -o delete', recreate it, and re-register using "-R 300004" (I think, not 7), then check to make sure the describe_long coordinate reference AUTHIDs are the same.

In the long run you'll probably want to regenerate the original table with a more efficient xyscale (you're probably more than doubling storage and hurting performance by 40-70% with a 1.0e+15 xyscale [which describes geometry with 11 angstrom precision -- half the size of microprocessor transistor gates], when 1.0e+6/1.0e+7 would suffice).

- V

[LorneDmitruk]

Turns out the coordinate system in schema was way out to lunch in it's extents etc. etc. I ended up getting the right projection parameters into the schema and now things are displaying in the right spot.