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!
Solved! Go to 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
We need more information in order to help:
- V
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!
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
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.