Hello,
Doing some testing on layers that are SDE 9.1 and SDE 10.1. When reviewing the properties for high precision storage the SRID consistently has a different identifier #. For example:
SRID 300004
SRID 300013
SRID 300014
SRID 300005
I've tried to research the different identifiers, - even using the Open GeoSpatial Consortium pages but I don't get any specific explanation as to why there is a different identifier for each layer.
Can anyone point me in a direction as to where I can gain some understanding on the difference between these identifiers?
Thanks in advance,
Jennifer
From ArcGIS Help 10.1:
A spatial reference identifier (SRID) is a unique identifier associated with a specific coordinate system, tolerance, and resolution.
My guess is that the layers have the same coordinate system but may differ slightly in tolerance or resolution.
Also, the geometry type may be influencing the SRID:
Some databases and spatial types, such as PostGIS geometry in PostgreSQL or the geography type in SQL Server, use a predefined subset of EPSG codes, and only spatial references with those SRIDs can be used.
Melita Kennedy is the go to person at ESRI for anything to do with coordinate systems and may be able to provide some more information.
Thanks Owen, appreciate your response,
yes there are difference with the tolerance and resolution between the 9.1 layer and 10.1 layer, but this is probably do to it going to high precision.
One of the main problems with the early ArcSDE feature class loaders was that using default coordinate reference parameters to load several overlapping shapefiles would result in a different coordinate reference for each feature class (due to slightly different data envelopes). I once found 100 different coordinate references for 145 feature classes (and I loaded the first 46 layers).
One of the major changes at ArcGIS 9.2, where HIGH precision coordinate references were introduced, was to standardize the origins for all data in different families of projections, with a standardized precision in the 1.0-0.1 millimeter range. This reduced the number of different coordrefs, but also locked in precisions that were greatly in excess of the accuracy of the data (which has the side effect of increasing the required storage, since the SDEBINARY, SDELOB, and ST_GEOMETRY storage methods rely on compression based on the magnitude of differences in integer space).
If you upgraded your 9.1 coordrefs to HIGH precision using UI tools, it's quite possible that the original "too many coordrefs" issues have been embedded in the newer geodatabase.
One way that coordinate references cannot be reduced is if some data is measured and some carry Z values, but not others. Technically, you can define 2-D layers using 3-D or 4-D coordrefs, but that requires some effort to define the desired coordref up front, then make sure that all feature classes use this common coordref.
I'm working on an add-in to optimize feature classes through a number of techniques, including less aggressive precision, spatial defragmentation, and geometry partitioning, but haven't completed my effort yet.
The Understanding Coordinate Management in the Geodatabase whitepaper will explain all the issues which surround coordinate reference design, and explain the difference between well-known coordinate system codes and coordinate reference IDs (basically, there's some naming collision on the term "SRID").
- V
Thanks Vince,
Yeah it appears that some of my feature classes in the same data set are referencing a different SRID. Appreciate your insights to this, you've provided some food for thought. I'll have to look how the geodatabase was upgrade to get a handle on this. What I have noticed in the new 10.1 SDE layers is the standardizing of the origin of min y -400 and min x -400 for each feature class that i have.
That means you mostly have data in a geographic coordinate system. We had been supporting longitude ranges from -360 to +360, which is why the minimum value was bumped out to -400.
Thanks Melita...
Quick question...do you have any experience or could provide some help with the GeometryDef Grid Count and GeometryDef Grid Size?. I've been receiving some results and there are issues with my 10.1 layers that I need some assistance with.
Hope to hear from you soon
Jennifer
Oracle 10.2.1, ArcCatalog 10.2.1, try to convert all the feature classes in afeature dataset to the same projection. Then simply copy this to another oracle database with ST_GEOMETRY and you will see the output is messed up.
SQL> select table_name,srid from sde.st_geometry_columns;
TABLE_NAME SRID
-------------------------------- ----------
WHYDRANTVALVES_1 3857
PRIMARYOVERHEAD 3857
TRANSFORMER 3857
WMAIN_1 300004
WHYDRANT_1 3857
WATERDIST_NET_1_JUNCTIONS 3857
WFITTING_1 3857
WCONTROLVALVE_1 3857
WPUMP_1 3857
WLATERALLINE_1 300004
WSERVICECONNECTION_1 3857
WSYSTEMVALVE_1 3857
WCURBSTOPVALVE_1 3857
GDB_ITEMS 4326
If we ignore GDB_ITEMS, it is an out of the box table used for internal storage of information only, then we note that even though the projection was the same on the source system, it is different after a copy paste.
To find out what is different, I look at the ST_COORDINATE_SYSTEMS table:
SQL> desc sde.st_coordinate_systems;
Name Null? Type
----------------------------------------- -------- ----------------------------
NAME NVARCHAR2(128)
TYPE NVARCHAR2(128)
DEFINITION VARCHAR2(2048)
ORGANIZATION NVARCHAR2(128)
ID NOT NULL NUMBER(38)
DESCRIPTION NVARCHAR2(256)
So we see:
set pagesize 1000
set long 1000000
SQL> select * from sde.st_coordinate_systems where ID in (3857,300004);
NAME
--------------------------------------------------------------------------------
TYPE
--------------------------------------------------------------------------------
DEFINITION
--------------------------------------------------------------------------------
ORGANIZATION
--------------------------------------------------------------------------------
ID
----------
DESCRIPTION
--------------------------------------------------------------------------------
WGS_1984_Web_Mercator_Auxiliary_Sphere
PROJECTED
PROJCS["WGS_1984_Web_Mercator_Auxiliary_Sphere",GEOGCS["GCS_WGS_1984",DATUM["D_W
GS_1984",SPHEROID["WGS_1984",6378137.0,298.257223563]],PRIMEM["Greenwich",0.0],U
NIT["Degree",0.0174532925199433]],PROJECTION["Mercator_Auxiliary_Sphere"],PARAME
TER["False_Easting",0.0],PARAMETER["False_Northing",0.0],PARAMETER["Central_Meri
dian",0.0],PARAMETER["Standard_Parallel_1",0.0],PARAMETER["Auxiliary_Sphere_Type
",0.0],UNIT["Meter",1.0]]
EPSG
3857
WGS 1984 Web Mercator Major Auxiliary Sphere
Only the 3857 is returned at all. The 300004 entry is completely missing.
So in my case I have a bug. One feature dataset is only supposed to have one projection type. Expecially if eveything is part of the same network. I am going to go look for patches in my case. But I was just debugging this and wanted to post how I matched up the projection to an SRID to sort out what string is used for which number in your database.